StandUp Security Practices

Version: 1.0 Last updated: 2026-04-05 Owner: StandUp (solo founder operation, pre-revenue) Audience: School IT administrators, district security reviewers, prospective partners Companion document: data-flow-diagram.md — visualizes every hop student data makes through the platform.

0. Purpose and Scope

This document describes the security practices StandUp currently has in place. It is written as a self-assessment for school IT administrators who need to evaluate StandUp against FERPA, district data governance policies, and standard ed-tech vendor review checklists.

Honest framing (per D-26, D-27): StandUp is an early-stage platform. We do not currently hold a SOC 2 Type II certification. Instead, we rely on the SOC 2 Type II / ISO 27001 certifications of our underlying infrastructure providers (Vercel and Supabase) and document our own controls here. A timeline for third-party penetration testing and independent audit is published in §14 below — it describes a "now vs. later" posture, not a "lightweight vs. real" one.

If any information in this document is outdated or insufficient for your review, contact the founder directly and we will respond within 3 business days.

1. Infrastructure

StandUp is a serverless web application. We do not operate physical servers or self-managed virtual machines. All infrastructure is provided by SOC 2 Type II certified cloud vendors.

1.1 Hosting — Vercel

• Provider: Vercel Inc.
• Services used: Edge Network (CDN + TLS termination), Serverless Functions (Next.js API routes), Static Asset Hosting.
• Certifications: SOC 2 Type II, ISO 27001, GDPR-aligned DPA, HIPAA BAA available.
• Regions: US edge regions only (see §5, Data Residency).
• Public reference: https://vercel.com/security and https://vercel.com/legal/dpa
• SOC 2 report: Available from Vercel on NDA request.

1.2 Database and Authentication — Supabase

• Provider: Supabase Inc.
• Services used: Postgres (row-level-security enforced), Supabase Auth, Supabase Storage, Realtime channels.
• Certifications: SOC 2 Type II, HIPAA BAA available, GDPR DPA.
• Regions: us-east-1 only. No EU or cross-region replication.
• Public reference: https://supabase.com/security and https://supabase.com/docs/guides/platform/hipaa-compliance
• SOC 2 report: Available from Supabase on request.

1.3 AI Providers (sub-processors)

See ../../.planning/phases/01-compliance-security-posture/01-05-ai-subprocessor-disclosure-PLAN.md and the upcoming AI Sub-Processor Disclosure document. In summary:

• Anthropic (Claude) — primary LLM provider. Zero-retention business tier. SOC 2 Type II.
• OpenAI — failover LLM provider via lib/ai-provider.ts. Business-tier zero-retention. SOC 2 Type II.

1.4 Payment Infrastructure

• Provider: Stripe. PCI DSS Level 1 certified. StandUp never stores or processes card data directly.

1.5 Domain and DNS

• DNS managed via Vercel. DNSSEC enabled where supported.

2. Encryption

2.1 In Transit

• All traffic: TLS 1.2 minimum, TLS 1.3 preferred. Enforced at the Vercel edge.
• HSTS: Enabled with max-age=31536000; includeSubDomains; preload.
• Internal API → database: TLS (Supabase enforces TLS on all Postgres connections).
• API → AI providers: HTTPS only, TLS 1.3 to Anthropic and OpenAI endpoints.

2.2 At Rest

• Database: AES-256 encryption at rest (Supabase-managed, AWS KMS keys).
• Object storage: Supabase Storage with AES-256 at rest.
• Backups: Encrypted at rest with the same keys as primary storage.
• Client devices: StandUp does not install anything on student or teacher devices. No client-side encryption keys exist.

2.3 Secrets

• Secrets are stored in Vercel Encrypted Environment Variables (AES-256 at rest, decrypted only at function execution time).
• No secrets in client bundles; enforced by NEXT_PUBLIC_ prefix convention. No plaintext secrets in git history (verified by credential audit — see Plan 01-01).

3. Authentication

3.1 User Authentication

• Provider: Supabase Auth (GoTrue).
• Methods: Email + password, Google OAuth, (optional) phone SMS.
• Password hashing: bcrypt with a cost factor of 10 (Supabase default).
• Password policy: Minimum 8 characters; rejection of the 10,000 most common passwords.
• Session tokens: JWTs signed with HS256. Access tokens expire in 1 hour. Refresh tokens rotate on use.
• Password reset: Signed, single-use, time-limited email links.

3.2 MFA

• Available through Supabase Auth (TOTP) for school administrator accounts.
• Required for the founder account and any future operational staff accounts.

3.3 Service Authentication

• Server-to-database: Postgres role with the minimum privileges required.
• Server-to-AI-provider: Scoped API keys, rotated per §7.4 below.

4. Access Controls

4.1 Application Authorization — Row Level Security

StandUp uses Supabase Postgres Row-Level Security (RLS) as the primary authorization mechanism. RLS policies are defined in SQL, versioned in the repository, and enforced at the database layer — not just in application code.

Three primary roles:

RLS policies cover every table that contains student data: profiles, classes, enrollments, questions, answers, chat_messages, ai_usage, lesson_materials, quizzes, quiz_attempts.

4.2 Administrative Access

• Database: Founder has direct database console access via Supabase dashboard (MFA required).
• Logs: Founder has read access to Vercel and Supabase logs.
• Principle of least privilege: No shared accounts. When operational staff are hired, per-person accounts will be provisioned.

4.3 Physical Access

• No physical infrastructure. Founder's personal development machine uses full-disk encryption (FileVault / BitLocker), screen-lock timeout, and no production credentials in plaintext on disk.

5. Data Residency

• Primary database: us-east-1 (Supabase).
• Object storage: us-east-1 (Supabase Storage).
• Edge/compute: Vercel US edge regions only. StandUp does not currently deploy to EU, APAC, or other international regions.
• Backups: Stored in the same US region as primary data.
• AI processing: Anthropic and OpenAI both process inference requests in US regions under their business-tier agreements.
• No cross-border transfers: Student data does not leave US regions under normal operation.

6. Backups and Recovery

6.1 Database Backups

• Frequency: Automated daily full backups via Supabase.
• Point-in-time recovery: 7-day window, with WAL-based PITR to any second within that window.
• Encryption: Same AES-256 at-rest as primary.
• Testing: Restore tested quarterly against a staging project.

6.2 Object Storage Backups

• Supabase Storage is backed by S3-compatible storage with 11-nines durability.
• Versioning is enabled on critical buckets (lesson materials).

6.3 Code and Configuration

• Source in GitHub with branch protection on main.
• Infrastructure-as-code where possible (Supabase migrations, Vercel project config, SQL RLS definitions all checked in).

6.4 RPO / RTO Targets

• RPO (Recovery Point Objective): ≤ 1 hour for database, ≤ 24 hours for object storage.
• RTO (Recovery Time Objective): ≤ 4 hours for a full service restore to the most recent backup.

7. Secret Management

7.1 Storage

• Production secrets live exclusively in Vercel Encrypted Environment Variables.
• Local development uses .env.local, which is .gitignored and never committed.

7.2 Client vs. Server

• Only variables with the NEXT_PUBLIC_ prefix are exposed to browsers. All other secrets (service-role keys, AI API keys, Stripe secret keys) are server-only and accessible only inside Next.js API routes or server components.

7.3 Key Inventory

• Supabase service-role key (server-only)
• Supabase anon key (public)
• Anthropic API key
• OpenAI API key
• Stripe secret key
• Stripe webhook signing secret
• Resend / email provider API key

7.4 Rotation

• Policy: Rotate on any suspicion of exposure, on offboarding, and at least every 90 days for high-sensitivity keys.
• Historical: See Plan 01-01 (Credential Rotation) for the baseline rotation log performed at the start of this compliance phase.
• Internal log: Rotation events recorded in a private internal log (not published, per D-10).

8. Vulnerability Management

8.1 Dependency Security

• npm audit run on every pull request via GitHub Actions.
• GitHub Dependabot enabled for the repository; security updates auto-PR'd.
• Lockfile discipline: package-lock.json committed; dependencies pinned.

8.2 Secret Scanning

• GitHub secret scanning enabled, including push protection — blocks pushes that contain recognized secret patterns.
• Pre-commit scanning via gitleaks recommended for local development.

8.3 Automated Security Scanning (per D-24)

• Baseline automated scanning is performed using OWASP ZAP (or equivalent DAST tool) against the production deployment.
• Results are saved to an internal log and are available to school IT reviewers on request.

8.4 Code Review

• Solo-founder stage: all changes are self-reviewed with an AI-assisted review pass and the project's test suites. When operational staff join, two-person review will be required for any change touching authentication, RLS, or billing.

8.5 Patch Cadence

• Critical vulnerabilities: patched within 24 hours of disclosure.
• High: within 7 days.
• Medium/Low: within 30 days.

9. Logging and Monitoring

9.1 Application Logs

• Vercel function logs capture request metadata, status codes, and error stack traces.
• Supabase Postgres logs capture authentication events and query errors.

9.2 Audit Logs

• Sensitive actions are recorded in an audit_log table: user creation, role changes, class deletions, export events, admin access to student data.
• AI usage logging: Every AI call is logged to ai_usage with user, timestamp, provider, model tier, token counts. No raw student PII is stored in this table — only metadata (per D-13).

9.3 Monitoring and Alerting

• Vercel monitoring with uptime pings.
• Supabase dashboards for query performance and connection counts.
• Error alerts to founder email for 5xx spikes.

9.4 Log Retention

• Application logs: 30 days (Vercel default, extended as needed).
• Audit logs: retained as long as the underlying account, then purged 30 days after account deletion.

10. Incident Response

StandUp maintains a detailed Incident Response Plan — see the forthcoming incident-response.md (produced by Plan 01-06).

Key commitments:

• Severity classification: SEV-1 through SEV-4 with defined response times.
• FERPA breach notification: Affected schools will be notified within 72 hours of confirming a breach involving student records, in line with FERPA expectations and most state data breach laws.
• Post-mortem: Blameless post-mortem published internally and summarized to affected schools within 14 days.
• Contact: Founder is the primary and currently only incident contact. A structured escalation chain will be added as staff are hired.

11. Personnel Security

• Staffing: StandUp is operated by a solo founder at this stage.
• Background: The founder's identity and background are known and verifiable. No offshore contractors have access to production systems or student data.
• Training: Founder has self-certified FERPA familiarity and tracks ongoing ed-tech compliance reading.
• Device security: Founder's work laptop uses full-disk encryption, automatic screen lock, and a password manager for all production credentials.
• Offboarding: Not applicable yet. When staff are added, offboarding will follow a written checklist: revoke SSO access, rotate any shared keys, remove GitHub and Vercel org membership, archive personal workspace.

12. Sub-Processors

StandUp uses a small number of sub-processors to deliver the service. A complete list with data categories, purposes, and retention is maintained in:

• The Data Processing Addendum (DPA) produced by Plan 01-03
• The AI Sub-Processor Disclosure produced by Plan 01-05

Summary list:

Schools will be notified in advance of any new sub-processor addition.

13. Third-Party Certifications Referenced

StandUp inherits significant compliance posture from its underlying providers. The following certifications are currently in force at our sub-processors:

SOC 2 reports for sub-processors are available directly from the providers under NDA. StandUp can assist a school's IT reviewer in requesting them.

14. Penetration Testing and Independent Audit (per D-24, D-25, D-27)

StandUp's posture on external security testing is phased and published transparently so that IT reviewers can evaluate it without ambiguity.

14.1 Now

• Automated scanning: Baseline OWASP ZAP (or equivalent DAST) scans run against production on a recurring cadence. Results saved to an internal log, available on request.
• Dependency scanning: Continuous via npm audit and Dependabot.
• Secret scanning: Continuous via GitHub secret scanning with push protection.
• Code review: Self-review with AI assistance and full test-suite enforcement.

14.2 Later — Triggers for third-party penetration test (whichever hits first)

• First signed paid pilot contract at $5,000 ARR or above
• Completion of a funding round of $25,000 or above
• Explicit request from an IT administrator at a target school as a condition of contract

When any trigger is met, StandUp will engage an independent penetration testing firm, remediate findings, and provide a letter of attestation and high-level findings summary to partner schools.

14.3 Framing

This is a now-vs-later timeline, not a lightweight-vs-real posture. The current automated posture is real security hygiene. The scheduled third-party audit adds an independent attestation layer once the platform reaches the stage where that investment is justified by contracted revenue.

15. Data Flow

For a visual of how student data moves through StandUp, see data-flow-diagram.md. The diagram annotates every hop, identifies where PII is stripped before AI inference, and includes a simplified student-data path for IT admin presentations.

16. Contact

Security questions, vulnerability reports, and IT reviewer inquiries:

• Primary: StandUp founder — contact address published at /trust
• Response target: 3 business days for IT reviewer questions, 24 hours for suspected security issues

This document is maintained in version control and updated as practices change. The canonical source of truth is the repository; published versions may lag the repository by up to 7 days.

StandUp Data Flow Diagram

Version: 1.0 Last updated: 2026-04-05 Companion document: security-practices.md Purpose: Visualize every hop that student data makes through StandUp so that an IT administrator can verify where data lives, who it touches, and where PII is stripped before AI inference.

This document satisfies decisions D-21 (visual diagram of browser → edge → database → AI providers), D-22 (annotated with data categories and retention), and D-23 (Mermaid format for versionability).

1. Full Data Flow

This diagram shows every major data path in the StandUp platform, including user roles, storage, AI providers, and payment. It is intended for detailed technical review.

flowchart LR
    %% Clients
    subgraph Clients["User Devices (Browsers)"]
        Student["Student Browser"]
        Teacher["Teacher Browser"]
        Admin["School Admin Browser"]
    end

    %% Edge and compute
    subgraph Vercel["Vercel (US Edge, SOC 2 Type II)"]
        Edge["Vercel Edge Network<br/>TLS 1.3 termination"]
        API["Next.js API Routes<br/>Serverless Functions"]
    end

    %% Database
    subgraph Supabase["Supabase us-east-1 (SOC 2 Type II)"]
        Auth["Supabase Auth<br/>(JWT, bcrypt passwords)"]
        DB[("Postgres with RLS")]
        Storage["Supabase Storage<br/>(lesson materials, uploads)"]
        subgraph Tables["Key tables"]
            Profiles["profiles"]
            Classes["classes / enrollments"]
            AIUsage["ai_usage<br/>(metadata only)"]
            Lessons["lesson_materials"]
            Chats["chat_messages"]
            Audit["audit_log"]
        end
        DB --- Profiles
        DB --- Classes
        DB --- AIUsage
        DB --- Lessons
        DB --- Chats
        DB --- Audit
    end

    %% PII stripper
    Strip{{"PII Stripper<br/>lib/ai-provider.ts<br/>(strips names, emails,<br/>student IDs, phone)"}}

    %% AI
    subgraph AI["AI Providers (zero-retention business tier)"]
        Anthropic["Anthropic Claude API<br/>US region"]
        OpenAI["OpenAI API<br/>US region (failover)"]
    end

    %% Payments
    Stripe["Stripe<br/>PCI DSS Level 1"]

    %% Email
    Resend["Resend<br/>transactional email"]

    %% Student flows
    Student -- "HTTPS: question text<br/>+ auth token" --> Edge
    Teacher -- "HTTPS: class CRUD<br/>+ lesson uploads" --> Edge
    Admin -- "HTTPS: roster reads<br/>(RLS-scoped)" --> Edge

    Edge -- "request routing" --> API

    API -- "JWT verify" --> Auth
    API -- "SQL over TLS<br/>(RLS enforced)" --> DB
    API -- "signed URLs<br/>uploads / downloads" --> Storage

    API -- "lesson context<br/>+ question text" --> Strip
    Strip -- "sanitized prompt<br/>(PII stripped)" --> Anthropic
    Strip -- "sanitized prompt<br/>(failover only)" --> OpenAI

    Anthropic -- "model response" --> API
    OpenAI -- "model response" --> API
    API -- "persist transcript<br/>+ user_id" --> Chats
    API -- "log usage metadata" --> AIUsage

    API -- "payment intents<br/>billing contact only" --> Stripe
    Stripe -- "webhook:<br/>signed events" --> API

    API -- "transactional messages" --> Resend

2. Simplified Student Data Path (IT Admin Presentation View)

This is the diagram intended for live IT admin review meetings. It shows only the path that student-originated data takes, with PII-stripping clearly visible.

flowchart LR
    S["Student Browser"] -- "TLS 1.3" --> E["Vercel Edge (US)"]
    E --> A["Next.js API"]
    A -- "read/write<br/>(RLS enforced)" --> DB[("Supabase Postgres<br/>us-east-1")]
    A -- "lesson context + question" --> P{{"PII Stripper<br/>(names, emails,<br/>IDs removed)"}}
    P -- "PII stripped" --> C["Claude API<br/>(zero retention)"]
    C -- "answer" --> A
    A -- "transcript stored<br/>under student ID" --> DB

Single sentence summary for non-technical reviewers: Student questions travel over TLS to US-based Vercel, are processed by our API, have personal identifiers stripped before being sent to Claude for inference, and the resulting transcript is stored in row-level-security-protected Postgres in us-east-1.

3. Hop Annotation Table

Each row is one hop in the full diagram above. "Data" describes what travels over that hop, "stored where" describes where (if anywhere) that data comes to rest, and "retention" describes how long it persists.

4. PII Stripping: Why This Hop Exists (per D-13)

Before any prompt is sent to an AI provider, StandUp's AI provider abstraction (lib/ai-provider.ts) passes the payload through a PII stripper that removes:

• Student and teacher full names
• Email addresses
• Phone numbers
• Student IDs and school-issued identifiers
• Parent/guardian names
• Home addresses

Only the sanitized text is transmitted to Anthropic or OpenAI. Both providers operate under business-tier zero-retention agreements — they do not store the prompt or response after returning the completion, and the content is not used for model training.

This means a compromise of Anthropic or OpenAI would not expose student PII originating from StandUp, because PII never leaves the StandUp application boundary in the outbound AI request.

5. Cross-Border Transfers

None. All storage and compute is in US regions. No EU, APAC, or other international hops. Schools in non-US jurisdictions are not currently supported.

6. What Is Not on These Diagrams

• Client-side local storage: StandUp uses short-lived JWTs in HTTP-only cookies where possible. No student data is persisted in browser localStorage beyond UI preferences.
• Analytics and marketing trackers: StandUp does not run third-party advertising trackers on authenticated pages. Marketing site (/, /trust, /privacy) uses privacy-preserving analytics only.
• Third-party chat or support widgets: None embedded in the authenticated app.

7. Change Management

This diagram is versioned in the repository. Any architectural change that adds a new sub-processor, a new data category, or a new cross-border hop requires:

1. Update to this diagram
2. Update to security-practices.md §12 (sub-processors)
3. Update to the DPA sub-processor list
4. Customer notification where required by the DPA

Related: security-practices.md · AI Sub-Processor Disclosure (Plan 01-05) · DPA (Plan 01-03)