Every SOC 2 control in plain English. Browse by trust criterion, search by keyword, and understand exactly what your auditor will ask — before they ask it.
The nine control families every SOC 2 audit includes. These are the non-negotiables — security, access, operations, and governance.
Management sets the tone at the top — establishing, communicating, and enforcing a culture of ethics and integrity throughout the organization.
Adopt a written Code of Conduct and Ethics policy. Have every employee sign it at hire and annually. It doesn't need to be long — it needs to exist and be acknowledged.
The governing body provides oversight of the system, ensuring management doesn't operate without checks. For small companies without a board, this maps to founder/advisor oversight.
If you have a board, document their oversight of security. If you don't, designate a security owner (usually a founder) and document that responsibility in an org chart or roles document.
The organization defines clear roles, responsibilities, and reporting structures so that security accountability is not diffuse or ambiguous.
Write a simple roles and responsibilities document. Name who owns security, who owns infrastructure, who can approve changes. An org chart plus a one-page RACI is enough for a small team.
The organization hires, trains, and retains competent people and holds them accountable for their security responsibilities.
Include security responsibilities in job descriptions. Conduct annual performance reviews that touch security adherence. Keep records of security training completion.
Management takes corrective action when individuals fail to follow established policies and procedures.
Document your disciplinary process for policy violations (typically in the employee handbook). You don't need to have used it — you need to have it written down.
The organization identifies and captures the information needed to operate the system and meet its objectives — including external information like threat intelligence.
Subscribe to at least one security advisory feed (US-CERT, vendor security mailing lists). Document that you review advisories relevant to your stack. A simple log of 'reviewed CVEs this month' satisfies this.
Information about security responsibilities, incidents, and changes is communicated internally to the right people at the right time.
Establish a security communication channel (a #security Slack channel works). Document that security incidents and changes are announced there. Keep an incident log showing you used it.
The organization communicates security-relevant information to external parties — customers, vendors, regulators — as required.
Publish a security page or trust center. Create a vulnerability disclosure policy (security.txt). Document your process for notifying customers of breaches (required by law in most states).
The organization has a defined process for identifying threats, vulnerabilities, and risks to the system and its data.
Conduct a simple annual risk assessment. List your assets (data, systems), the threats to each (breach, outage, insider), and the likelihood/impact. A spreadsheet with 10-15 rows is sufficient for a small company.
The organization considers risks introduced by vendors and business partners who provide services or access to the system.
Maintain a vendor inventory. For each vendor with data access, note what data they can touch and whether they have their own SOC 2 report. Review the list annually.
The organization assesses risk when significant changes occur — new products, new vendors, new infrastructure, new regulations.
Add a 'security review' step to your change process for significant changes. Document that you reviewed risk before launching a new service or onboarding a new vendor.
Management communicates how identified risks are being addressed — accepted, mitigated, or transferred — to the appropriate parties.
Document your risk treatment decisions in the risk assessment. For each risk, note: accepted, mitigated (how), or transferred (insurance). Review with leadership at least annually.
The organization monitors the system on an ongoing basis to confirm that controls continue to operate effectively.
Set up automated monitoring — uptime checks, access log reviews, alerting on suspicious activity. Document what you monitor and who reviews the output. A weekly log review checklist satisfies this.
The organization periodically evaluates whether existing controls still address the risks they were designed to mitigate.
Conduct an annual control review. Walk through each control and confirm it's still operating as designed. Document the review date and reviewer. This is the backbone of your SOC 2 Type II operating effectiveness evidence.
The organization identifies the specific control activities (policies, procedures, technical controls) needed to address identified risks.
Map each risk from your risk assessment to a specific control. This is mostly documentation — your policies and procedures are the control activities. The mapping shows the auditor you didn't pick controls at random.
Selected control activities are formalized in policies and procedures that establish what is expected and how it is accomplished.
This is the policy library itself. Your access control policy, change management policy, incident response policy, etc. ClearPass drafts these for you — each one is a control activity made formal.
The organization uses technology to automate or support control activities — access controls, logging, encryption, monitoring.
Document the technical controls you rely on: MFA enforcement, SSO, encryption at rest and in transit, logging, alerting. Screenshots of configuration (AWS IAM, GitHub settings, SSO dashboard) serve as evidence.
The organization restricts logical access to the system and its data to authorized users, and prevents unauthorized access by others.
Use SSO (Google Workspace, Okta) for all systems. Enforce MFA on every access point. Remove access immediately when someone leaves. Document your onboarding/offboarding access checklist. This is the most-tested control in a SOC 2 audit.
The organization has a formal process for granting, changing, and revoking access permissions based on role and need-to-know.
Document your access request and approval workflow (even if it's a Slack message to IT). Document your offboarding checklist (revoke access within X hours of departure). Keep records of access changes.
The organization periodically reviews access permissions to confirm they remain appropriate — least privilege.
Conduct quarterly access reviews. List everyone with admin or sensitive access and confirm they still need it. Document the review with a date and sign-off. This is high-frequency audit evidence for Type II.
The organization uses authentication mechanisms (passwords, MFA, certificates) to verify user identity before granting access.
Enforce MFA on all systems — not just email. Use SSO to centralize authentication. Document your password policy (length, complexity, rotation if applicable). Screenshots of MFA enforcement settings are key evidence.
The organization uses network controls (firewalls, segmentation, VPNs) to restrict access to system components.
Document your network architecture. Use a cloud provider's security groups or firewalls. Restrict database access to application servers only — never to the public internet. A network diagram serves as evidence.
The organization restricts physical access to facilities that house system components (servers, network equipment).
If you use a cloud provider (AWS, GCP, Azure), their SOC 2 report covers the physical security of the data center — you inherit it. Document that you rely on the provider's report. If you have a physical office, document keycard access and visitor logging.
The organization protects data in transit using encryption (TLS) to prevent unauthorized access or modification during transmission.
Enforce TLS 1.2+ everywhere. Redirect HTTP to HTTPS. Use HSTS headers. Document that all data in transit is encrypted. A TLS scan (e.g., SSL Labs) screenshot is strong evidence.
The organization protects data at rest using encryption to prevent unauthorized access to stored data.
Enable encryption at rest on all databases, storage volumes, and backups. Most cloud providers make this a checkbox. Document that encryption is enabled and which keys (provider-managed or customer-managed) are used.
The organization detects anomalies and security incidents through monitoring, alerting, and logging.
Centralize logs (CloudTrail, Cloud Logging, a SIEM). Set up alerts for suspicious activity — failed logins, privilege escalation, unusual data access. Document what you alert on and who receives the alerts.
The organization has a defined process for responding to detected incidents — triage, containment, eradication, recovery.
Write an Incident Response Plan. It doesn't need to be elaborate — define severity levels, who is on the response team, and the steps: detect, contain, eradicate, recover, post-mortem. ClearPass drafts this for you.
The incident response process includes procedures for communicating incidents to affected parties — customers, regulators, law enforcement.
Add a communication section to your IR plan: who notifies customers, within what timeframe (most state laws require 'without unreasonable delay'), and what information is communicated. Reference breach notification laws that apply to you.
The organization resolves incidents, identifies root causes, and implements corrective actions to prevent recurrence.
Conduct a post-mortem after every significant incident. Document what happened, why, what you fixed, and how you'll prevent it. Keep post-mortem records — they're strong Type II operating effectiveness evidence.
The organization has procedures to recover from disruptions — backups, disaster recovery, business continuity.
Write a simple Disaster Recovery / Business Continuity plan. Document your backup strategy (what, how often, where). Test restoration at least once and document the result. A backup that's never been restored is not a backup.
The organization manages changes to the system through a formal change management process — development, testing, approval, deployment.
Use pull requests with required reviews (GitHub, GitLab). Document your environments (dev, staging, prod). Require approval before deploying to production. Your git history and PR approval records are the evidence — you're probably already doing this.
The organization identifies vendors that provide services or access to the system and manages the risk they introduce.
Maintain a vendor inventory. For each vendor with data or system access, collect their SOC 2 report (or equivalent). Review the inventory annually. Document that you reviewed vendor risk before onboarding a new vendor.
The organization evaluates the controls of vendors and business partners to confirm they meet the organization's requirements.
For each critical vendor, obtain and review their SOC 2 report annually. Document that you reviewed it and noted any qualified opinions or exceptions. Keep the reports on file — the auditor will ask to see them.
Ready to see which of these apply to you?
Start your gap report