Our path to SOC 2 Type II.

Code of Conduct + Acceptable Use Policy define the integrity standard. Founder is sole acknowledger today; pattern scales when the first hire signs the same.

• Policy: Code of Conduct
• Policy: Acceptable Use Policy

Solo founder — no board exists. Mitigation: external pen test + external security disclosure surface (security@) provide independent oversight. Will satisfy after Seed raise + first board seat.

• Policy: Information Security Policy
• Separation of Duties memo — Control 7

Information Security Policy section 4 names the roles, reporting lines, and decision authorities. Today they all collapse to the founder; the structure scales without rework.

• Policy: Information Security Policy
• Policy: Access Control Policy

Annual security training documented in Secure SDLC Policy section 11 (founder watches OWASP refresher + reviews own threat model). Will graduate to formal vendor-delivered training once headcount > 1.

• Policy: Secure Software Development Policy

Quarterly self-review (Separation of Duties memo Control 6) plus auditable production_access_reviews table. Reviews skipped = visible gap.

• Policy: Access Control Policy
• Policy: Acceptable Use Policy
• Production Access Inventory + quarterly review log

Logging & Monitoring Policy + Sentry + the audit_log table provide quality information. Logs are append-only at the app layer.

• Policy: Logging & Monitoring Policy

Solo founder makes internal comms trivial. The policies + SoD memo document the comms paths that scale at first-hire (PR review channel, IR Slack channel, quarterly review meeting).

• Policy: Change Management Policy
• Policy: Incident Response Plan

External comms surface: SECURITY.md, /trust page, /status page, monthly customer email, and the security@ inbox. All publicly accessible.

• Policy: Incident Response Plan
• Policy: Vulnerability Management Policy
• SECURITY.md
• Public status page
• +1 more

Information Security Policy section 2 names the objectives (CIA + customer trust + SOC 2 Type II ready by Q3 2026). Risk Assessment Policy section 3 traces risks to these objectives.

• Policy: Information Security Policy
• Policy: Risk Assessment Policy

18-entry risk register scored Likelihood x Impact on a 5x5, reviewed quarterly. Methodology documented in Risk Assessment Policy.

• Policy: Risk Assessment Policy
• Risk register

Separation of Duties memo enumerates the fraud-risk surface (single-human bypass) and the 8 compensating controls. Risk register entries R-PPL-02 + R-FIN-01 track residuals.

• Policy: Risk Assessment Policy
• Separation of Duties memo

Change Management Policy section 4 requires risk assessment on significant changes (new sub-processor, schema change, auth-flow change).

• Policy: Change Management Policy
• Policy: Risk Assessment Policy

Quarterly self-review (founder reviews access inventory, finds, PRs, sub-processor bills). Recorded in production_access_reviews. Annual external pen test.

• Policy: Access Control Policy
• Policy: Vulnerability Management Policy
• Quarterly review log

Incident Response Plan section 6 defines deficiency communication (customer notify, status page update, post-incident report). Pen-test findings tracked in the risk register.

• Policy: Incident Response Plan
• Policy: Vulnerability Management Policy

18 policies map to control activities across CC + A + C. Selection driven by Risk Assessment Policy.

• Policy: Information Security Policy
• Policy: Risk Assessment Policy

General IT controls: Access Control, Change Management, Cryptography, Vulnerability Management, Logging & Monitoring policies.

• Policy: Access Control Policy
• Policy: Change Management Policy
• Policy: Cryptography Policy
• Policy: Vulnerability Management Policy
• +1 more

Every policy in /policies/ is signed-commit-versioned, reviewed annually, acknowledged by every person with credentials.

• Policy: Information Security Policy
• Policy library

Access Control Policy + Production Access Inventory list every system, principal, role, and MFA status. Reviewed quarterly.

• Policy: Access Control Policy
• Production Access Inventory

Onboarding / Offboarding Policy ships per-system checklists for joiners + leavers, even at headcount 1 (the founder followed it for self-onboarding).

• Policy: Onboarding / Offboarding Policy
• Policy: Access Control Policy

Access Control Policy section 4 defines least-privilege roles per system. Inventory enforces named accounts with documented roles.

• Policy: Access Control Policy

No physical office. Acceptable Use Policy section 6 + Onboarding Policy cover home-office posture (locked devices, no shoulder-surf in coffee shops, no Restricted data on disk).

• Policy: Acceptable Use Policy
• Policy: Onboarding / Offboarding Policy

Data Retention & Disposal Policy section 5 defines disposal methods per asset class. Devices wiped via OS reset + DBAN-equivalent before redeployment or destruction.

• Policy: Data Retention & Disposal Policy
• Policy: Onboarding / Offboarding Policy

Boundary protection: TLS 1.3 only on web tier (Cryptography Policy), Fly private networking between app + worker + DB, Cloudflare WAF for public surface.

• Policy: Cryptography Policy
• Policy: Access Control Policy

All in-transit data over TLS 1.3 (HSTS preloaded). At-rest encryption: Postgres EBS-equivalent (Neon), Redis (Upstash), R2. Cryptography Policy section 3 specifies algorithms.

• Policy: Cryptography Policy
• Policy: Data Classification & Handling Policy

Secure SDLC Policy section 3 forbids eval/dynamic-import/child_process-with-user-args. Dependency hygiene via Dependabot daily security + lockfile + signed commits.

• Policy: Secure Software Development Policy
• Policy: Vulnerability Management Policy

Vulnerability Management Policy: Dependabot daily security, weekly non-security, annual third-party pen test, severity-based remediation SLAs (Critical: 7d, High: 30d).

• Policy: Vulnerability Management Policy
• SECURITY.md disclosure surface

Sentry alerts on error spikes, Fly logs piped to retention storage, app-layer audit_log table for sensitive actions. Gap: no SIEM. Documented in risk register R-INF-02 with mitigation plan.

• Policy: Logging & Monitoring Policy

Incident Response Plan section 3 defines event-classification (informational / event / incident) + section 4 the response phases.

• Policy: Incident Response Plan

Incident Response Plan + quarterly tabletop. Sev definitions, communication SLAs, sub-processor breach handling, evidence-preservation steps.

• Policy: Incident Response Plan

Business Continuity & DR Plan: RTO 4h for web tier, 24h full data restore. Quarterly DR test (Backup Policy section 5). Solo-founder BCP scenarios memo covers founder-specific failure modes.

• Policy: Business Continuity & DR Plan
• Policy: Backup Policy
• Solo-founder BCP scenarios memo

Change Management Policy: PR -> CI -> AI-assisted review -> branch-protected merge -> auto-deploy. SoD memo Control 1+2+3 detail the compensating controls.

• Policy: Change Management Policy
• Policy: Secure Software Development Policy
• Separation of Duties memo

Business Continuity & DR Plan + Key Person Risk memo (Tier 1/2/3 succession) + Solo-founder BCP scenarios memo. Risk register entries R-PPL-01 + R-PPL-03 tracked.

• Policy: Business Continuity & DR Plan
• Key Person Risk memo

Vendor Management Policy: tiered (Critical / High / Standard) review cadence. Sub-processors published with 30-day customer notice for adds.

• Policy: Vendor Management Policy
• Public sub-processor list