A practical, copy-paste library of SOC-2 controls sized for solopreneurs and small teams (2-5 people). Pick what fits your stage, stack, and risk profile.
Every control traces back through this hierarchy. Auditors walk this chain top-to-bottom to verify completeness.
Why / Objectives. The five AICPA categories: Security (CC), Availability (A), Processing Integrity (PI), Confidentiality (C), Privacy (P). Security is always required; others are optional.
Rules / Intent. Board-level documents that state what the company commits to. "We will encrypt data at rest." Reviewed annually.
Testable Requirements. Specific, auditable statements that implement a policy. "All S3 buckets must have AES-256 encryption enabled." An auditor can verify pass/fail.
Execution Steps. Step-by-step runbooks that people follow to satisfy controls. "Run aws s3api get-bucket-encryption quarterly and log output."
Ownership. Named individuals (not teams) responsible for each control. In a startup, one person often wears 3-4 hats.
Enforcement Layer. Tooling that automates or enforces the control: AWS Config rules, GitHub branch protection, MDM policies, SSO providers.
Proof. Artifacts an auditor reviews: screenshots, logs, config exports, signed policy docs, ticket histories. Collected continuously, not scrambled before audit.
SOC-2 is organized around these five categories. Most startups begin with Security only, then add others as customers require them.
Protection against unauthorized access. Always in scope.
System uptime and disaster recovery commitments.
Data processing is complete, accurate, timely.
Protection of confidential information (NDA-level).
PII collection, use, retention, and disposal practices.
These are the written documents your company commits to. Each policy spawns multiple controls. Start with the required ones.
Master policy covering the company's commitment to protecting information assets. References all other policies.
How access to systems is granted, reviewed, and revoked. Principle of least privilege.
How code and infrastructure changes are proposed, reviewed, approved, and deployed.
How security incidents are detected, reported, contained, and remediated.
Framework for identifying, analyzing, and treating risks to the organization.
Defines sensitivity levels (Public, Internal, Confidential, Restricted) and handling rules for each.
How third-party vendors are evaluated, approved, and monitored for security risks.
Plans for maintaining operations during disruptions. Includes disaster recovery.
Rules for employee use of company systems, devices, and data.
How PII is collected, used, retained, disclosed, and disposed of.
In a startup, one person often fills multiple roles. What matters is that every control has a named owner. Here is a typical mapping for a 1-5 person team.
| Role | Typical Owner | Responsibilities |
|---|---|---|
| Security Officer | Founder / CEO | Policy approval, risk acceptance, board reporting, incident escalation |
| Infrastructure Lead | CTO / Lead Engineer | Cloud config, encryption, monitoring, patching, DR testing |
| Application Lead | CTO / Lead Engineer | Code reviews, dependency scanning, SDLC, change management |
| Compliance Coordinator | Founder / Ops Lead | Evidence collection, vendor reviews, policy updates, audit liaison |
| People Operations | Founder / Office Mgr | Background checks, security training, onboarding/offboarding |
| All Employees | Everyone | Follow policies, report incidents, complete training, use MFA |
Browse, filter, and copy controls for your SOC-2 program. Each control includes the full chain: TSC mapping, policy reference, testable requirement, procedures, systems, and evidence.