Security Overview & SOC 2 Roadmap

1. Architecture

Ludwitt is built on a modern, serverless architecture designed for security, scalability, and reliability. All infrastructure components are hosted by SOC 2 Type II certified providers.

• Application Layer: Deployed on Vercel's Edge Network, providing serverless compute with automatic scaling, zero server management, and built-in DDoS protection.
• Database & Authentication: Firebase/Firestore on Google Cloud Platform (us-central1 region), providing real-time data synchronization with automatic replication across multiple availability zones.
• AI Processing: Anthropic Claude API for adaptive learning features, with all requests routed through server-side API routes — no direct client-to-AI communication.
• Payment Processing: Stripe for all financial transactions, PCI DSS Level 1 certified. No payment card data is stored on Ludwitt systems.

2. Authentication & Authorization

Ludwitt implements enterprise-grade authentication and authorization controls to protect user accounts and institutional data.

Single Sign-On (SSO)

• SAML 2.0: Full support for SAML 2.0-based SSO with domain-based routing for institutional deployments.
• LTI 1.3: Deep integration with Learning Management Systems via LTI 1.3 Advantage, enabling seamless authentication through the LMS.
• Multi-Factor Authentication (MFA): Phone MFA is optional and is not required on API routes.

Session Management

• Session cookie: `__session` is an HTTP-only cookie that holds a copy of the Firebase ID token for two hours. Middleware checks that the cookie is present. API routes re-verify the bearer token.
• Logout: The cookie is cleared. There is no separate idle timeout or seven-day absolute timeout.

Role-Based Access Control (RBAC)

Ludwitt implements a granular RBAC model with the following roles: Student, Instructor, Institution Admin, Developer, and System Admin. Each role has explicitly defined permissions enforced at both the API and database layers through Firebase Security Rules and server-side middleware.

3. Encryption

Data at Rest

• Infrastructure-level: All data stored in Google Cloud Firestore is encrypted at rest using AES-256, managed through Google's Key Management Service (KMS).
• Application-level: Date of birth is encrypted with AES-256-GCM and is not also stored in `ageVerification.birthDate`. Email and display name stay as Firebase Auth and Firestore plaintext under Google default encryption.
• Content Security Policy: `unsafe-inline` and `unsafe-eval` are an accepted residual so Next.js can hydrate.
• Backups: All automated backups are encrypted with the same standards as primary data stores.

Data in Transit

• TLS 1.3: All data in transit is encrypted using TLS 1.3. Older TLS versions (1.0, 1.1) are not supported.
• HSTS: HTTP Strict Transport Security is enforced with a max-age of one year, including subdomains and preload.
• Certificate management: TLS certificates are automatically provisioned and rotated by Vercel.

4. Access Control

Ludwitt follows the principle of least privilege across all layers of the application.

• Firestore Security Rules: Every database collection has explicit read/write rules. Backend-only collections deny all client-side writes. Owner-only collections enforce user ID matching at the query level.
• Admin role verification: Administrative operations require server-side verification of the admin custom claim on the Firebase ID token. Admin actions are logged separately.
• API route protection: All API endpoints use the authenticateRequest middleware, which validates the Firebase ID token and extracts the authenticated user identity before any business logic executes.
• Service account scoping: Firebase Admin SDK service accounts are scoped to the minimum permissions required for each function.

5. Network Security

• Vercel Edge Network: Global CDN with built-in DDoS protection and automatic traffic filtering. Anycast routing ensures requests are served from the nearest edge location.
• Firebase Security Rules: Act as a server-side firewall for all database operations, enforcing authentication, authorization, and data validation at the query level.
• CORS policy: Cross-Origin Resource Sharing is restricted to the production domain and authorized subdomains.
• Content Security Policy (CSP): Strict CSP headers prevent XSS attacks by controlling allowed script sources, style sources, and frame ancestors.
• Rate limiting: API endpoints implement rate limiting to prevent abuse and ensure fair usage across all tenants.

6. Monitoring & Logging

• Error tracking: Sentry provides real-time error tracking and performance monitoring across the application, with alerts configured for critical errors.
• FERPA audit logs: All access to student education records is logged with timestamps, user identity, action performed, and data accessed. Logs are retained for a minimum of 7 years.
• Backup monitoring: Automated monitoring of backup completion, integrity verification, and alerting on backup failures.
• Uptime monitoring: External monitoring services check application availability every 60 seconds from multiple geographic locations.

7. Incident Response

Ludwitt maintains a formal incident response plan with defined severity levels and response time commitments.

Breach notification: In the event of a confirmed data breach involving student education records or personally identifiable information, Ludwitt will notify affected institutions within 72 hours, in compliance with FERPA, applicable state breach notification laws, and contractual obligations.

8. Vulnerability Management

• Dependabot: Automated dependency vulnerability scanning with pull requests generated for all security updates. Critical and high-severity updates are reviewed within 24 hours.
• CodeQL analysis: The CodeQL job runs on pull requests to main and does not block merge until GitHub Advanced Security can ingest results. The merge gate is the `gate` job in the CI workflow, which requires the build, test, and security jobs. CodeQL is not part of that gate.
• npm audit: Automated npm audit runs in the CI pipeline on every build. Builds with critical vulnerabilities are blocked from deployment.
• Critical patch cadence: Critical vulnerabilities are patched within 48 hours of disclosure. High-severity vulnerabilities are patched within 7 days.
• Penetration testing: Annual third-party penetration testing is scheduled. Results and remediation reports are available to institutional customers under NDA.

9. Data Classification

All data processed by Ludwitt is classified according to the following scheme, with corresponding protection requirements.

10. SOC 2 Type II Roadmap

12-Month Timeline

• Q1 2026 (Complete): Gap analysis and readiness assessment. Identified and remediated control gaps. Selected audit firm.
• Q2 2026 (Complete): Policy formalization, control implementation, and evidence collection framework established.
• Q3–Q4 2026 (In Progress): Observation period. Continuous control operation and evidence collection across all Trust Services Criteria.
• Q1 2027 (Planned): Formal Type II audit engagement, report issuance, and distribution to customers.

Trust Services Criteria Mapping

11. Compliance Certifications