Use this reference library to answer two practical questions: what should your team do, and what should you keep to prove it happened? Each guide includes a startup-friendly implementation, a scaled approach, evidence checks, audit record guidance, and a completion checklist.
Most teams should not implement all 94 examples. There is no official minimum or universal SOC 2 control list. Start with the downloadable 33-control lean starter set, then tailor it to your services, systems, risks, customer commitments, and examination scope with your service auditor.
Maintained by GreenHat Security · Reviewed August 21, 2026
Start with the job you need to do today. The downloadable 33-control set gives a lean starting point; the full 94-guide library is here when your scope or risk needs more depth.
I am implementing SOC 2 for the first time
Name one owner, define the trigger and workflow, choose where the record will live, run one complete cycle, and fix anything the completion checklist exposes. You do not need a GRC platform to start.
I am gathering evidence for an audit
Reconcile every in-scope occurrence from its source system, account for failures and exceptions, then trace selected records through approval, execution, result, and remediation.
Identify the services, systems, commitments, and Trust Services Categories included in the intended examination.
Choose one accountable owner, the people or systems that operate the control, a backup, and the expected timing.
Put the control into the system your team already uses and complete one end-to-end cycle before relying on it.
Separate policy and design artifacts, approval and review records, and operating or technical evidence such as tickets, exports, logs, and screenshots.
Build the complete audit record set, select one item, and verify that another person can reproduce the full trail.
Search by topic, suggested owner, operating cadence, or TSC identifier, then narrow the library to a domain. Criterion identifiers are cross-references only: one control may support several criteria, and one criterion may require several controls.
Showing 94 of 94 suggested controls
2 controls · 8 unique TSC IDs
Implementation and evidence guide
Management assigns responsibility for design, operation, monitoring, evidence ownership, and remediation of controls supporting the organization's services, customer environments, security operations, and internal systems.
Implementation and evidence guide
The SOC 2 policy library is maintained with policy owners, effective dates, approval authority, publication, review cadence, exception handling, and evidence of approval.
1 control · 4 unique TSC IDs
9 controls · 14 unique TSC IDs
Implementation and evidence guide
Customer-facing commitments are maintained in an approved register with owner, source, control mapping, applicability, review status, and evidence location.
Implementation and evidence guide
New or changed customer-facing commitments are reviewed by business, legal, security, engineering, and service owners before external use.
Implementation and evidence guide
Customer, the organization, and relevant third-party responsibilities are documented for security, availability, data handling, integrations, monitoring, support, and response.
Implementation and evidence guide
Service descriptions, RFP responses, and assurance materials accurately describe implemented capabilities, limitations, dependencies, and customer obligations.
Implementation and evidence guide
Dependencies required to meet commitments are identified, assigned owners, monitored, and linked to supporting controls and procedures.
Implementation and evidence guide
Availability, monitoring, backup, recovery, support, and escalation expectations are defined, measured where applicable, and reviewed.
Implementation and evidence guide
Material changes to commitments, responsibility boundaries, or service capabilities follow controlled review and customer notification requirements where applicable.
Implementation and evidence guide
Commitment exceptions, deviations, unsupported customer assumptions, and service limitations are documented, approved, and tracked.
Implementation and evidence guide
Commitment approval records, registers, shared-responsibility matrices, customer-facing materials, and monitoring evidence are retained for SOC 2 support.
1 control · 4 unique TSC IDs
1 control · 4 unique TSC IDs
10 controls · 18 unique TSC IDs
Implementation and evidence guide
All vendors and third parties are recorded in an approved inventory with owner, service description, data access, customer impact, contract status, review dates, and risk tier.
Implementation and evidence guide
Vendors are classified based on data sensitivity, production access, availability dependency, customer impact, and control reliance.
Implementation and evidence guide
Critical and high-risk vendors undergo security review before onboarding and periodically thereafter.
Implementation and evidence guide
Vendor contracts include confidentiality, security, access, data handling, incident notification, subprocessor, return/destruction, and termination obligations where applicable.
Implementation and evidence guide
Vendor access follows least privilege, MFA where feasible, approved connection methods, logging, and prompt revocation when no longer needed.
Implementation and evidence guide
Critical and high-risk vendors are reassessed and monitored based on risk, incidents, service changes, contract renewals, and control reliance.
Implementation and evidence guide
Subprocessors and data-processing vendors are approved, tracked, and governed according to customer commitments and data protection obligations.
Implementation and evidence guide
Vendors provide timely notification of incidents, security events, data exposure, and material service disruptions that may affect the organization.
Implementation and evidence guide
Vendor access, integrations, credentials, data retention, return/destruction obligations, and offboarding evidence are addressed during termination.
Implementation and evidence guide
Vendor risk evidence is retained for SOC 2 audit support, customer assurance, management review, and ongoing monitoring.
5 controls · 8 unique TSC IDs
Implementation and evidence guide
Roles, responsibilities, reporting lines, and ownership for engineering, security operations, product, support, incident response, privacy, and compliance are documented and maintained.
Implementation and evidence guide
Background or reference checks are completed where legally permitted and appropriate based on role, responsibility, and access level.
Implementation and evidence guide
Personnel and contractors complete security and privacy awareness training during onboarding and at least annually thereafter.
Implementation and evidence guide
Management periodically evaluates personnel competency and performance for security, confidentiality, privacy, customer commitments, and control ownership.
Implementation and evidence guide
Access and company assets are removed or recovered when personnel leave, change roles, or no longer require access.
6 controls · 14 unique TSC IDs
Implementation and evidence guide
Assets supporting service delivery are inventoried with owner, environment, location, lifecycle status, classification, criticality, customer data role, and review date.
Implementation and evidence guide
Critical data flows, repositories, integrations, trust boundaries, customer-data processing paths, and AI/LLM data flows are documented and maintained.
Implementation and evidence guide
Customer data and telemetry are classified and protected according to sensitivity, contractual commitments, privacy obligations, and operational use.
Implementation and evidence guide
Retention periods, disposal methods, and confidentiality handling rules are approved and maintained by data category.
Implementation and evidence guide
Confidential information, customer data, system data, and personal information are deleted, anonymized, or rendered unrecoverable when no longer required or upon authorized request.
Implementation and evidence guide
Assets critical to service delivery, customer isolation, detection integrity, privileged access, evidence generation, recovery, or customer commitments are tagged as critical/high-value and reviewed based on risk.
6 controls · 7 unique TSC IDs
Implementation and evidence guide
Each production-impacting change has a ticket-of-record with business/security rationale, affected systems, approver, test evidence, deployment evidence, and rollback plan.
Implementation and evidence guide
Production-bound code, configuration, detection logic, infrastructure, and AI/LLM workflow changes require peer review and authorized approval before deployment.
Implementation and evidence guide
New features and material architecture changes undergo security review and threat modeling proportionate to customer data, authorization, encryption, tenant isolation, and availability risk.
Implementation and evidence guide
Automated build, unit/integration/smoke testing, dependency, secret, SAST, IaC, and container/image scanning are run before release where feasible.
Implementation and evidence guide
Deployments are performed by authorized personnel or approved CI/CD pipelines and are logged with traceability to approved changes and post-deployment validation.
Implementation and evidence guide
Development, test, staging, production, and recovery environments are logically separated; production customer data is not used in lower environments unless formally approved and protected.
8 controls · 15 unique TSC IDs
Implementation and evidence guide
AI/LLM workflows are inventoried, assigned owners, classified by use case and risk, and reviewed for approved production use.
Implementation and evidence guide
AI/LLM outputs affecting customer-facing communications, incident decisions, security recommendations, or automated actions require defined human review.
Implementation and evidence guide
Customer data, telemetry, secrets, credentials, regulated data, and confidential policy context are controlled, minimized, and restricted by approved workflow purpose.
Implementation and evidence guide
Retrieval sources, embeddings, memory, policy context, and customer context are authorized, versioned, and reviewed for accuracy and confidentiality.
Implementation and evidence guide
AI/LLM workflows with tools, scripts, API calls, ticketing, firewall exports, or customer-impacting actions use least privilege, approval gates, and kill-switch controls.
Implementation and evidence guide
Prompt, model, tool, retrieval, system-message, and workflow changes follow controlled change-management procedures.
Implementation and evidence guide
AI/LLM-generated outputs are reviewed for grounding, accuracy, sensitive data, hallucination risk, and evidence traceability before operational reliance.
Implementation and evidence guide
Material AI/LLM workflow activity, configuration, approvals, outputs, review records, and exceptions are logged and retained as SOC 2 evidence.
7 controls · 12 unique TSC IDs
Implementation and evidence guide
Administrative and privileged access is approved, least-privileged, logged, reviewed, and monitored; privileged activity and access changes are retained as evidence.
Implementation and evidence guide
Customer access enforces strong authentication, role-based authorization, and customer/tenant boundaries for portals, reports, evidence, and administrative roles.
Implementation and evidence guide
New or modified privileged access to production systems, cloud environments, repositories, security tooling, and customer-facing administrative functions is approved by an authorized owner or manager.
Implementation and evidence guide
Access is assigned based on least privilege, role, business need, environment, customer assignment, and data classification.
Implementation and evidence guide
Workforce, privileged, customer-support, service-account, administrative, and third-party access is reviewed on a defined cadence with evidence of owner approval, remediation, and closure.
Implementation and evidence guide
Access to critical systems is removed or modified within defined timelines after termination, role change, contract completion, or loss of business need.
Implementation and evidence guide
Service accounts, API keys, tokens, certificates, automation credentials, and privileged secrets are inventoried where feasible, least-privileged, protected, rotated or reviewed based on risk, and removed when no longer required.
8 controls · 12 unique TSC IDs
Implementation and evidence guide
Access controls, tenant identifiers, data stores, dashboards, APIs, reports, retrieval sources, and automation preserve customer boundaries and prevent unauthorized cross-customer access.
Implementation and evidence guide
Cloud services, organization-managed private cloud/container hosts, registries, images, and runtime environments follow approved secure configuration baselines.
Implementation and evidence guide
Network boundaries, production networks, customer integration paths, VPN access, security groups, firewalls, and WAF-equivalent controls restrict traffic to approved paths.
Implementation and evidence guide
Sensitive data, telemetry, logs, backups, administrative sessions, secrets, and keys are protected through approved encryption and key-management controls.
Implementation and evidence guide
Company-managed endpoints accessing critical systems meet a security baseline including full-disk encryption, screen lock, endpoint protection, secure configuration, and approved management tooling.
Implementation and evidence guide
Anti-malware and endpoint detection are deployed and monitored on endpoints and supported production workloads, and unauthorized software is prevented, detected, and responded to.
Implementation and evidence guide
Cloud, container, network, and infrastructure configurations are monitored for insecure settings, exposed services, privilege drift, image risk, and deviations from approved baselines.
Implementation and evidence guide
Physical access to company facilities is restricted; hosting provider physical/environmental controls are relied upon and reviewed; company devices are recovered or securely disabled when no longer required.
8 controls · 12 unique TSC IDs
Implementation and evidence guide
Required logs, review activities, retention requirements, integrity controls, and evidence production expectations are defined and implemented for security, operational, audit, and customer-support records.
Implementation and evidence guide
AOT availability, ingestion health, telemetry latency, processing capacity, storage pressure, alerting thresholds, and customer-facing monitoring commitments are measured and escalated when thresholds are exceeded.
Implementation and evidence guide
Threat-stream alerts, anomalous activity, malicious indicators, AOT detections, and system-generated findings are reviewed, prioritized, assigned, escalated, and closed based on severity, confidence, customer impact, and commitments.
Implementation and evidence guide
Threat intelligence sources are selected, evaluated, approved, operationalized, versioned, and periodically reviewed before they influence detection logic, enrichment, notifications, or recommendations.
Implementation and evidence guide
Infrastructure, cloud resources, containers, endpoints, applications, external-facing services, and supporting components are scanned or assessed for vulnerabilities and misconfigurations based on risk and cadence.
Implementation and evidence guide
Findings are prioritized by severity, exploitability, exposure, customer impact, and ownership; unresolved items require remediation, exception, compensating control, or formal risk acceptance.
Implementation and evidence guide
Changes to detection logic, threat hypotheses, real-time processing algorithms, correlation rules, risk scoring, escalation logic, and customer-facing outputs are reviewed and tested before production release.
Implementation and evidence guide
Automated or one-click mitigation features are restricted, logged, authorized, reversible where practical, and protected by safeguards that limit unauthorized or excessive customer impact.
4 controls · 6 unique TSC IDs
Implementation and evidence guide
Monitoring includes capacity, scalability, ingestion health, storage pressure, queue/backlog indicators, and service health signals needed to identify resilience risk and trigger remediation.
Implementation and evidence guide
Production data stores, configuration repositories, critical code repositories, evidence artifacts, logs, and recovery runbooks are backed up or replicated, protected, monitored, and recoverable according to criticality tier.
Implementation and evidence guide
Tier 0 and Tier 1 recovery procedures are tested at least annually and high-value backups are sampled for restore or validation at least quarterly unless an approved alternate cadence exists.
Implementation and evidence guide
Critical dependencies for services are maintained with owner, service purpose, recovery relevance, customer impact, alternatives, backup personnel, and continuity procedures.
4 controls · 8 unique TSC IDs
Implementation and evidence guide
The incident response plan defines roles, escalation paths, severity levels, communication procedures, containment steps, recovery responsibilities, and required evidence for security and availability incidents.
Implementation and evidence guide
Security events are classified as events, incidents, privacy events, availability failures, customer-impacting events, or service-commitment failures and escalated based on severity.
Implementation and evidence guide
Incidents require containment, investigation, remediation, recovery validation, root-cause analysis, corrective actions, and post-incident review where appropriate.
Implementation and evidence guide
Customer, regulator, law-enforcement, data-subject, contractual, vendor, and privacy notification obligations are evaluated, approved, executed where required, and retained.
5 controls · 5 unique TSC IDs
Implementation and evidence guide
The organization defines what correct processing looks like for each critical in-scope flow, including its data sources, rules, expected results, timing targets, dependencies, owners, and customer responsibilities, and communicates current specifications and material changes to affected teams and customers.
Implementation and evidence guide
In-scope services accept data only from expected sources and in valid formats, detect missing, duplicate, late, partial, or unauthorized inputs, and route rejected or questionable records for resolution.
Implementation and evidence guide
In-scope workflows apply approved rules in the intended sequence, compare expected and actual counts or results, detect failed, inaccurate, partial, duplicate, or out-of-order processing, and track correction or reprocessing through closure.
Implementation and evidence guide
Outputs from critical processing flows are checked against expected content, control totals, timing, and destination rules, released only to intended recipients, and monitored for inaccurate, missing, late, duplicate, failed, or unauthorized delivery.
Implementation and evidence guide
Inputs, work-in-progress records, and completed outputs used by critical flows are stored with controls that detect unauthorized change, loss, incomplete state, and improper retention, archival, or deletion.
9 controls · 25 unique TSC IDs
Implementation and evidence guide
Privacy responsibilities, data handling expectations, customer commitments, notices, processing purposes, and authorized uses are defined, reviewed, and communicated to data subjects/customers as applicable.
Implementation and evidence guide
Personal information and customer confidential information are collected and used only for approved business, security, service delivery, support, legal, or contractual purposes.
Implementation and evidence guide
Requests involving access, correction, deletion, export, restriction, accounting, or customer-directed handling are logged, validated, fulfilled or escalated, and retained.
Implementation and evidence guide
Choices, consent, and disclosure requirements for personal information are communicated, obtained where required, recorded, and reflected in approved data processing workflows.
Implementation and evidence guide
Privacy events and suspected unauthorized disclosures receive privacy-specific review, evidence handling, legal/compliance consultation, notification tracking, and corrective actions.
Implementation and evidence guide
Data classification and handling rules define Confidential, Restricted, Customer Confidential, Internal, and Public information treatment and support identification of confidential information.
Implementation and evidence guide
Confidential information is protected in transit and at rest using approved encryption, access control, segmentation, logging, and key-management practices.
Implementation and evidence guide
Confidential information is retained only as required for business, legal, customer, security, or audit purposes and disposed of using approved methods.
Implementation and evidence guide
Third parties are authorized, contractually bound, and reviewed before receiving or processing confidential information.
No. The 94 guides are optional reference examples, and the 33-control workbook is a lean suggested starting point, not an official minimum. Your scope, risks, system description, commitments, and selected criteria determine the controls you need.
Yes. A well-designed activity may support more than one criterion, while a single criterion may also require several complementary controls. Mappings should be validated in context.
No. Evidence must match the tailored control, period, systems, and population. A service auditor determines the procedures and evidence needed for the engagement.
Keep policy and design artifacts separate from approval and review records, then link the operating or technical proof: screenshots, exports, logs, tickets, reports, test results, and resolved exceptions.
GreenHat Security maintains these guides to help operating teams turn a control outcome into an owner, workflow, evidence trail, complete audit record set, and self-test. Trust Services Criteria identifiers are included only as navigation references; the guides do not reproduce AICPA criterion descriptions, points of focus, or an AICPA audit program.
Each guide combines a suggested control outcome with practical implementation steps, evidence-quality checks, record-set guidance, likely testing procedures, and common gaps. The small-company and scaled approaches illustrate possible operating models; tailor the maturity and tools to your environment.
These are educational suggestions, not official AICPA criteria, legal or accounting advice, an audit conclusion, or a guarantee of examination results. Tailor every control to your scope, risks, systems, and commitments, then confirm final mappings and testing expectations with your service auditor. SOC 2® is an AICPA trademark; GreenHat Security is not affiliated with or endorsed by AICPA.