This page maps the architecture to the SOC 2 Trust Services Criteria
(TSC) so an auditor can trace every criterion to a concrete control. It is
a living document maintained with the code — infrastructure controls are
enforced by the CDK; process controls by runbooks in this repository.
CC1 – Control environment
| Criterion | Implementation |
|---|
| CC1.2/CC1.3 Responsibilities | Single owner per area (eng, security, privacy); documented in CONTRIBUTING.md and the incident-response runbook |
| CC1.4 Hiring | Background checks for employees with production access (policy, pre-launch) |
| Criterion | Implementation |
|---|
| CC2.1 Communication of objectives | Security policy (this site), quarterly review cadence |
| CC2.2 Internal communication | SECURITY.md reporting path; alerts → SNS → ops chat (wired at launch) |
| CC2.3 External communication | Privacy page, security page, vulnerability disclosure policy |
CC3 – Risk assessment
| Criterion | Implementation |
|---|
| CC3.1 Risk identification | Threat model (see below); quarterly risk review |
| CC3.2 Risk mitigation | Controls in the security overview; residual risk accepted by leadership |
Threat model (top risks)
- Data breach of documents → KMS + TLS + least privilege + WAF; residual:
insider risk (mitigated by CloudTrail + no standing prod access).
- Account takeover → MFA + adaptive auth + token revocation.
- Abuse (spam/DDoS) → WAF rate limits, budgets, publishing abuse review.
- Availability loss → serverless multi-AZ, PITR, DR runbook.
- Supply chain → pinned dependencies, CI builds from lockfile, code review.
CC4 – Monitoring activities
- CloudWatch alarms: API 5xx, p99 latency, Lambda errors, DynamoDB throttles.
- GuardDuty findings, WAF metrics, budget alarms → SNS.
- Security Hub (CIS + Foundational) continuous checks.
CC5 – Control activities
- Change management: all changes via PR → pipeline; stage/prod require
manual approval; pipeline is the only prod deployer.
- Configuration management: infrastructure is code (CDK); runtime config
injected per environment; Config managed rules detect drift.
- Segregation of duties: developers cannot deploy prod directly;
approvals in the pipeline.
CC6 – Logical & physical access
| Criterion | Implementation |
|---|
| CC6.1 Access provisioning | IAM least privilege; no standing prod credentials; SSO at launch |
| CC6.2 User access review | Quarterly IAM access review (runbook) |
| CC6.3 Access removal | Offboarding runbook (part of incident-response guide) |
| CC6.4/CC6.5 Least privilege | Per-component IAM roles (Lambda, pipeline); S3 presigned URLs |
| CC6.6 Physical access | AWS-managed (AWS SOC 2 report inherited) |
| CC6.7 Authentication | Cognito + MFA + adaptive auth; SSO for staff |
CC7 – System operations
- Vulnerability management: Config rules + Security Hub + dependency
updates; private reporting with 90-day policy.
- Capacity: serverless autoscaling; alarms for throttling/latency.
- Backups: DynamoDB PITR (35 days), S3 versioning, lifecycle rules —
see the disaster-recovery guide.
CC8 – Change management
- Code review required; tests + typecheck in CI; deployments only through
the pipeline; approval gates for stage/prod; rollback runbook.
CC9 – Risk mitigation
- Business continuity: DR runbook with RPO/RTO; insurance pre-launch.
Annual activities
- Penetration test (external firm) — before public launch, then annually.
- SOC 2 Type I report after 3 months of stable operations; Type II the
following year.
- Tabletop incident-response exercise twice a year.