Short answer: SOC 2 is an AICPA reporting framework for examining controls at a service organization that are relevant to security, availability, processing integrity, confidentiality, or privacy. Companies often say they are “SOC 2 compliant,” but the more precise outcome is a SOC 2 attestation report issued by an independent CPA firm.
What Is SOC 2 Compliance?
SOC 2 is part of the AICPA System and Organization Controls suite. A SOC 2 examination evaluates a service organization's description of its system and the controls relevant to selected Trust Services Criteria. The report is intended to help customers and other authorized users assess risk when they depend on a service provider.
In practical terms, SOC 2 answers questions such as: What is the service being examined? Which systems and people are in scope? Which security and operational risks matter? What controls are designed to address those risks? And, for a Type 2 report, did those controls operate effectively during the review period?
SOC 2 is especially relevant to SaaS providers, cloud services, API platforms, managed services, fintech products, data processors, and other vendors that become part of a customer's technology or data supply chain.
It is an attestation report
SOC 2 is not a product certification badge. An independent CPA firm performs an examination and issues a report.
It is scoped to a real system
The system description, services, infrastructure, software, people, procedures, data, and relevant third parties matter to the examination.
It is evidence-driven
Policies alone are not enough. Teams need evidence that controls are designed appropriately and, for Type 2, that they operated during the period.
It is risk and commitment based
Good scope and controls reflect what the service actually does and what customers rely on.
Why Is SOC 2 Important?
SOC 2 gives customers a structured way to evaluate a service provider's controls instead of relying only on questionnaires, sales claims, or one-off screenshots. It can also improve internal discipline because teams must define ownership, collect evidence, review exceptions, and connect controls to actual risks.
| Business Need | How SOC 2 Helps | What SOC 2 Does Not Do |
|---|---|---|
| Customer assurance | Provides an independent report describing the system, controls, and auditor testing. | It does not guarantee that a company will never have a security incident. |
| Vendor due diligence | Creates reusable evidence for security reviews and procurement. | It does not eliminate every customer-specific question or contractual requirement. |
| Operational discipline | Encourages repeatable access reviews, risk assessment, change control, monitoring, and incident processes. | It does not replace day-to-day security engineering or operational ownership. |
| Enterprise sales | Can reduce friction when buyers require independent assurance before approval or renewal. | It does not guarantee a deal, a procurement outcome, or regulatory compliance. |
A useful SOC 2 program should improve the way the company operates even when no auditor is asking for evidence. If controls only exist for the audit window, the program is fragile.
SOC 2 Trust Services Criteria Explained
The AICPA Trust Services Criteria cover five categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy. The current AICPA resource remains the 2017 Trust Services Criteria with revised points of focus issued in 2022. The scope should reflect the service and the commitments made to customers.
| Criterion | Plain-English Meaning | Typical Control Evidence | Relevant When |
|---|---|---|---|
| Security | Protect systems and information against unauthorized access, misuse, or damage. | MFA, access reviews, logging, vulnerability management, incident response, secure change processes. | Core to service-provider security assurance. |
| Availability | Keep systems available for operation and use as committed. | Uptime monitoring, capacity review, backup and restore tests, disaster recovery exercises. | The service has uptime, resilience, recovery, or continuity commitments. |
| Processing Integrity | Process information completely, accurately, timely, and as authorized. | Input validation, reconciliation, job monitoring, workflow controls, exception handling. | Incorrect or incomplete processing could materially affect customers. |
| Confidentiality | Protect information designated as confidential according to commitments. | Classification, encryption, access restrictions, retention controls, secure disposal. | The service handles proprietary, contractual, or otherwise confidential information. |
| Privacy | Address the collection, use, retention, disclosure, and disposal of personal information. | Privacy notices, data inventories, retention, rights workflows, access controls, privacy governance. | The service has material privacy commitments or obligations involving personal information. |
Do not select additional criteria simply because they sound stronger. More scope creates more controls, evidence, and testing. The better question is whether a criterion reflects a real service commitment, customer expectation, or risk.
Primary reference: AICPA 2017 Trust Services Criteria with revised points of focus (2022).
SOC 2 Type 1 vs Type 2
Both report types examine control design, but they answer different assurance questions. A Type 1 report addresses controls as of a specified date. A Type 2 report also addresses operating effectiveness over a specified period.
| Question | SOC 2 Type 1 | SOC 2 Type 2 |
|---|---|---|
| Time focus | As of a specified date. | Over a specified review period. |
| Design of controls | Evaluated. | Evaluated. |
| Operating effectiveness | Not tested over an extended period in the same way as Type 2. | Tested across the review period. |
| Useful for | An initial assurance milestone or a newly established control environment. | Demonstrating that controls operated consistently over time. |
SOC 2 Requirements Checklist
There is no universal SOC 2 requirements checklist that can be copied into every company. The checklist below is a practical readiness framework: it identifies the areas most organizations need to define, operate, and evidence before an examination. Your auditor should confirm the final scope and control set.
| Readiness Area | What to Have in Place | Evidence Examples | Common Failure |
|---|---|---|---|
| 1. System scope | Clear boundaries for products, environments, infrastructure, software, people, data, APIs, and relevant third parties. | System description, architecture, data flows, asset inventory, service boundaries. | Important production services are omitted or ownership is unclear. |
| 2. Risk assessment | A repeatable process for identifying, rating, treating, and accepting risks. | Risk register, treatment plans, approvals, review history. | The risk register is generic and disconnected from actual services. |
| 3. Policies and ownership | Policies reflect real operating procedures and have named owners and review cycles. | Approved policies, revision history, exception records, owner assignments. | Policies are copied from templates but not followed. |
| 4. Identity and access | Least privilege, MFA where appropriate, joiner-mover-leaver processes, privileged-access control, service-account ownership. | Access exports, approvals, periodic reviews, termination records, privileged account reviews. | Dormant accounts, API keys, service accounts, or admin roles escape review. |
| 5. Change management | Changes to code, infrastructure, configurations, and production systems are reviewed, tested, approved, and traceable. | Pull requests, deployment records, change tickets, approvals, rollback records. | Emergency or infrastructure changes bypass the recorded process. |
| 6. Vulnerability management | Assets are assessed for vulnerabilities and findings are prioritized and remediated under defined expectations. | Scan results, tickets, severity decisions, remediation evidence, exceptions. | Findings exist but ownership and closure evidence are weak. |
| 7. Logging and monitoring | Relevant systems produce security and operational telemetry, with defined review and alert workflows. | SIEM events, alert history, dashboards, review records, escalation tickets. | Logs are collected but nobody can show how they are reviewed. |
| 8. Incident response | Severity, escalation, containment, communication, investigation, recovery, and post-incident steps are defined and exercised. | Response plan, tabletop evidence, incident tickets, postmortems, lessons learned. | A plan exists, but there is no evidence that the team tested it. |
| 9. Vendor management | Critical vendors and subservice organizations are identified, risk reviewed, and reassessed. | Vendor inventory, risk ratings, contracts, SOC reports, review records, renewal decisions. | Third parties are approved once and never revisited. |
| 10. Data protection | Data is inventoried, classified, access controlled, encrypted where appropriate, retained intentionally, and disposed of securely. | Data inventory, encryption settings, retention rules, access reviews, deletion evidence. | Teams cannot explain where sensitive data moves or where it appears in APIs. |
| 11. Availability and recovery | Backups, recovery procedures, resilience, health monitoring, and capacity planning match service commitments. | Backup logs, restore tests, disaster recovery exercises, uptime records, capacity reviews. | Backups exist but restore capability has not been demonstrated. |
| 12. Evidence governance | Each control has an owner, frequency, evidence source, retention approach, and exception path. | Control matrix, evidence repository, review cadence, exception log, remediation tracker. | Evidence collection begins only when the auditor requests it. |
What Does Good SOC 2 Evidence Look Like?
Good evidence is specific, attributable, dated, and tied to a control. The goal is not to accumulate screenshots; it is to show that a defined process happened, who performed or reviewed it, what system it covered, and what happened when an exception appeared.
A simple evidence map
Control: Production access is reviewed periodically Owner: Security / IT System: Identity provider, cloud accounts, production admin roles Frequency: Quarterly Evidence: User export, reviewer sign-off, removal tickets, exception notes Risk: Unauthorized or excessive access Exception path: Track, approve, remediate, and retain closure evidence
Prefer system-generated evidence
Use access exports, ticket history, CI/CD records, SIEM events, monitoring data, and review logs when those sources accurately represent the control.
Show the review, not just the raw data
A report or log proves data existed. A reviewer record, decision, or ticket often proves the control was actually performed.
Track exceptions
Failures do not disappear because the audit is approaching. Record the exception, decision, owner, remediation, and closure evidence.
Keep evidence proportional
Collect enough proof to support the control without generating unnecessary sensitive data or operational overhead.
2026 Update: AI Use and SOC 2 Examinations
On September 11, 2026, AICPA published TQA Section 9561, a technical Q&A specifically addressing the effect of a service organization's use of artificial intelligence on SOC 1 and SOC 2 examinations. This is a useful signal for companies adding generative AI, machine learning, copilots, or agentic workflows to in-scope services.
The update does not mean every company suddenly needs a new “AI SOC 2” criterion. A practical response is to ask whether AI changes the system description, data flows, service commitments, risk assessment, vendors, access model, processing behavior, monitoring, or controls in the existing SOC 2 scope, and then discuss those changes with the service auditor.
Reference: AICPA TQA Section 9561 on AI use in SOC examinations.
How API Security Can Support SOC 2 Evidence
SOC 2 does not require a particular API security product. However, when APIs are part of the in-scope service, they often carry authentication, customer data, business transactions, partner integrations, and administrative operations. In that environment, API inventory, runtime telemetry, authorization monitoring, sensitive-data visibility, and incident evidence can support the controls the company has chosen to operate.
| API Security Activity | SOC 2 Readiness Value | Evidence Example |
|---|---|---|
| API discovery and inventory | Improves system scope, asset awareness, ownership, and change visibility. | Active endpoint inventory, owner mapping, deprecated/shadow API findings. |
| Authentication and authorization monitoring | Supports access-control and security monitoring workflows. | Abnormal identity usage, object-access anomalies, investigation records. |
| Sensitive-data monitoring | Helps validate where confidential or personal data is actually exposed at runtime. | Response-field findings, data classification evidence, remediation tickets. |
| Runtime alerting and forensics | Supports security monitoring, triage, incident investigation, and lessons learned. | SIEM events, alert history, request/response context, incident timeline. |
| Behavior and abuse detection | Helps identify misuse that may not look like a conventional vulnerability. | Enumeration, automation, unusual sequence, rate, or business-flow findings. |
OWASP's current API Security Top 10 is the 2023 edition. It highlights risks such as broken object-level authorization, broken authentication, unrestricted resource consumption, improper inventory management, and unsafe consumption of APIs. These are not SOC 2 requirements by themselves, but they are useful inputs when an API-heavy organization identifies technical risks and designs controls.
For deeper implementation guidance, see Ammune's API runtime security guide, API security posture management guide, API sensitive data exposure guide, centralized SIEM logging guide, and API security executive reporting guide. For the external risk reference, see the OWASP API Security Project.
Common SOC 2 Mistakes to Avoid
Treating SOC 2 as a paperwork project
Documents are useful only when they match real workflows. Controls should operate in production, not only exist in policy language.
Starting with an oversized scope
Include what is necessary for the service and commitments, but avoid adding unrelated systems that create evidence burden without improving assurance.
Collecting evidence at the last minute
Continuous or scheduled evidence collection is more reliable than rebuilding months of history right before testing.
Ignoring service accounts and APIs
Machine identities, API keys, integration accounts, and runtime endpoints can be as important as employee access.
Confusing a report with perfect security
SOC 2 provides assurance about described controls and testing; it does not mean the organization is invulnerable.
Choosing an auditor only on speed
AICPA has emphasized quality concerns around “fast and easy” SOC engagements. Evaluate the CPA firm's competence, independence, peer-review status, scope understanding, and approach.
A Practical SOC 2 Readiness Process
- Define the service and system boundary. Document the products, environments, data flows, infrastructure, software, people, APIs, and subservice organizations that support the service.
- Identify commitments and risks. Review customer contracts, security commitments, privacy obligations, service levels, and material operational risks.
- Select the relevant Trust Services Criteria. Align criteria to the service and confirm the planned scope with the CPA firm.
- Map risks to controls. For each material risk, define the preventive, detective, or corrective controls that address it.
- Assign owners and frequencies. Every control needs a clear owner and an operating cadence.
- Run the controls before the examination. Test access reviews, incident response, backup restores, change workflows, monitoring, and other controls in normal operations.
- Collect evidence continuously. Use system records where possible and keep proof of reviews, decisions, exceptions, and remediation.
- Perform a readiness gap review. Identify controls that are missing, inconsistently executed, poorly evidenced, or misaligned with the actual system.
- Fix the operating model, not just the document. If a control is painful to evidence, simplify or automate the underlying process when appropriate.
- Coordinate with the auditor. Confirm scope, timing, report type, description requirements, selected criteria, and evidence expectations early.
SOC 2 Compliance FAQ
Is SOC 2 a certification?
Not in the same sense as a certification standard. SOC 2 is an attestation examination performed by an independent CPA firm, which issues a SOC 2 report. “SOC 2 certified” is common marketing language, but “SOC 2 report” or “SOC 2 examination” is more precise.
Who can issue a SOC 2 report?
A SOC 2 examination is performed by an independent CPA firm under applicable AICPA attestation standards. When choosing a firm, evaluate competence, independence, relevant experience, and quality processes rather than only price or speed.
What are the five SOC 2 Trust Services Criteria?
The five categories are Security, Availability, Processing Integrity, Confidentiality, and Privacy. The selected scope should reflect the system and the commitments made to users of the service.
What is the difference between SOC 2 Type 1 and Type 2?
Type 1 addresses the design of controls as of a specified date. Type 2 also addresses whether those controls operated effectively over a specified period.
Is there an official universal SOC 2 checklist?
No single checklist fits every organization. SOC 2 depends on the system description, selected Trust Services Criteria, service commitments, risks, and control design. A readiness checklist is useful, but it should not replace scope planning with the auditor.
How long does SOC 2 readiness take?
There is no responsible one-size-fits-all timeline. Readiness depends on scope, control maturity, evidence history, staffing, vendor dependencies, remediation work, report type, and auditor scheduling. A company with mature controls may need far less remediation than one starting without defined processes.
Does SOC 2 require penetration testing?
SOC 2 is criteria-based rather than a checklist that mandates the same security tool or test for every company. The organization and auditor should determine which controls are appropriate for the system and its risks. Penetration testing may be part of a broader vulnerability-management approach, but do not treat it as a universal substitute for other controls.
Does SOC 2 require API monitoring?
No specific API monitoring product is mandated. If APIs are material to the in-scope system, however, API inventory, access monitoring, sensitive-data visibility, and runtime security telemetry can be useful controls or evidence sources depending on the risks being addressed.
Does using AI change SOC 2?
AICPA published a 2026 technical Q&A addressing the effect of service-organization AI use on SOC examinations. AI does not automatically create a new Trust Services Criterion, but organizations should assess whether AI changes the system description, risks, vendors, data flows, commitments, or controls in scope.
Is SOC 2 the same as ISO 27001?
No. They are different assurance approaches with different structures, requirements, and outputs. Organizations may use both, but one should not be described as automatically equivalent to the other.
Authoritative References
What to Do Next
SOC 2 readiness is strongest when it is built into normal operations. Define the system clearly, select criteria that match real commitments, make controls easy to operate, collect evidence continuously, and review exceptions rather than hiding them. If APIs are part of the service, treat API inventory, access behavior, sensitive-data exposure, and incident telemetry as part of the same evidence story.
Ammune helps API-heavy organizations discover active APIs, inspect runtime behavior, identify sensitive-data exposure, detect suspicious API activity, and send investigation-ready events into security workflows. Those capabilities can support a SOC 2 control environment when they are relevant to the organization's actual risks and control design.
Build better runtime evidence for API-heavy environments
See how Ammune connects API discovery, runtime visibility, sensitive-data monitoring, behavioral analysis, and SIEM-ready evidence without treating SOC 2 as a checkbox exercise.