Boards, investors and regulators want independent assurance about an organisation's whole cybersecurity risk management programme, and a SOC 2 report was never designed to give it. SOC 2 reports on a service organisation's system for its customers. SOC for Cybersecurity, the AICPA's cybersecurity risk management examination, reports on the entity's programme: how it identifies information at risk, governs and assesses cyber risk, and whether the controls in that programme are effective. This guide explains what the examination covers, the description criteria and control criteria it uses, how identity and non-human identity controls show up in it, how to prepare, and how it relates to other frameworks. It is for CISOs, internal audit, compliance leads and anyone asked by a board or investor whether the organisation should commission one.
Key takeaways
- It reports on a programme, not a service. The subject is the entity's cybersecurity risk management programme, and any type of entity can use it, not only service organisations.
- Three parts make up the report. Management's description of the programme, management's assertion, and the CPA practitioner's report and opinion.
- Two sets of criteria apply. The AICPA description criteria (19 criteria in nine categories) govern the description; management chooses suitable control criteria, most often the 2017 Trust Services Criteria with Revised Points of Focus (2022).
- It is general use and voluntary. The report is written for broad audiences such as boards, investors and business partners, and no regulation requires it.
- Identity controls carry much of the evidence. Logical access for people, service accounts, API keys and third parties sits in the security criteria, and auditors test whether those identities are inventoried, owned and reviewed.
What it is and who it applies to
The AICPA introduced the cybersecurity risk management reporting framework in April 2017. It sits in the System and Organization Controls family alongside SOC 1, SOC 2, SOC 3 and SOC for Supply Chain, but it answers a different question. Where SOC 1 and SOC 2 give user entities an opinion on a service organisation's controls, SOC for Cybersecurity gives a wide group of stakeholders an opinion on whether the entity's description of its cyber programme is fairly presented and whether its controls were effective in achieving its cybersecurity objectives.
The current AICPA and CIMA attestation guide, Reporting on an Entity's Cybersecurity Risk Management Program and Controls, was published in 2024 and reflects SSAE No. 20 (amendments to the description of materiality) and SSAE No. 21 (direct examination engagements). The Center for Audit Quality describes the framework as objectives-based and entirely voluntary for companies and audit firms.
Who commissions one and why:
- Boards and audit committees: independent evidence for oversight of cyber risk, beyond management's own reporting. See the Board Cyber Risk Reporting Guide.
- Investors and analysts: assurance in due diligence, acquisitions and funding rounds where the target is not a service provider.
- Regulators and business partners: a single report that can be shared more widely than a restricted-use SOC 2.
- Entities without a "service": manufacturers, retailers, holding companies and public bodies that are asked for assurance but have no customer-facing system for a SOC 2.
| Aspect | SOC 2 | SOC for Cybersecurity |
|---|---|---|
| Subject matter | A service organisation's system relevant to the trust services categories | The entity's cybersecurity risk management programme |
| Who can be examined | Service organisations | Any type of entity |
| Description criteria | SOC 2 description criteria | Description criteria for an entity's cybersecurity risk management programme (nine categories) |
| Control criteria | Trust Services Criteria | Any suitable criteria chosen by management; Trust Services Criteria are the usual choice |
| Distribution | Restricted to specified users | Intended for general use |
| Primary readers | Customers and their auditors | Boards, senior management, investors, regulators, business partners |
For the SOC 2 detail, see the SOC 2 Guide; for product supply chains, the SOC for Supply Chain guide; and for how all the attestations compare, the Third-Party Attestation Comparison Map.
Structure and key requirements
The report has three parts, each with a different owner:
- Management's description: a narrative of the cybersecurity risk management programme prepared against the description criteria.
- Management's assertion: management states that the description is presented in accordance with the description criteria and that the controls were effective to achieve the entity's cybersecurity objectives based on the control criteria.
- Practitioner's report: the CPA's opinion on the description and on control effectiveness.
The description criteria are grouped into nine categories. The CPA Journal counts 19 individual criteria across them, numbered from DC1 (nature of the entity's business and operations) and DC2 (nature of information at risk).
| Description criteria category | What management must describe | Typical evidence behind it |
|---|---|---|
| Nature of business and operations | Principal products, services, markets and how operations are organised | Business overview, organisation chart |
| Nature of information at risk | Principal types of sensitive information created, collected, transmitted, used or stored | Data inventory, classification scheme |
| Cybersecurity risk management programme objectives | The entity's cybersecurity objectives and how they are set | Approved objectives, risk appetite statement |
| Factors that have a significant effect on inherent cybersecurity risks | Technologies, connection types, service providers, delivery channels, past significant incidents | Architecture diagrams, vendor inventory, incident register |
| Cybersecurity risk governance structure | Board oversight, roles, responsibilities, accountability | Charters, committee minutes, RACI |
| Cybersecurity risk assessment process | How threats, vulnerabilities and vendor or partner risks are identified and assessed | Risk register, assessment methodology, third-party risk records |
| Cybersecurity communications and quality of information | How policies and information reach people who need them | Policy library, awareness records, reporting lines |
| Monitoring of the programme | How the programme is evaluated and deficiencies corrected | Internal audit reports, KPIs, remediation tracking |
| Cybersecurity control processes | A summary of the control processes that address the risks | Control matrix mapped to the control criteria |
Control criteria. Management may use any criteria that are suitable: relevant, objective, measurable and complete enough not to omit factors that would change a reader's decision. The AICPA guide names the 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality and Privacy, with Revised Points of Focus (2022), and the CPA Journal cites the NIST framework as another example. Choosing the Trust Services Criteria makes it easier to reuse SOC 2 work; choosing a NIST-based set may suit an entity already reporting to its board against the CSF.
Engagement type. The full examination covers the description and the operating effectiveness of controls throughout a period. Entities can phase in, starting with a design-only examination at a point in time, or with a non-attest readiness engagement.
Identity and NHI requirements
The framework does not list identity controls by name; they arrive through the control criteria. If the Trust Services Criteria are used, logical access sits in the CC6 series: CC6.1 (logical access security software, infrastructure and architectures), CC6.2 (registering and authorising new users before credentials are issued) and CC6.3 (authorising, modifying and removing access based on roles and least privilege), with further criteria on external access, transmission and malicious software. The SOC 2 CC6 Logical Access Guide walks through each criterion.
What changes in an entity-wide examination is breadth. A SOC 2 can scope to one product's infrastructure; a SOC for Cybersecurity description has to reflect the programme across the entity, so every identity store and every class of credential becomes relevant:
- Workforce identities: joiner, mover and leaver processes across all directories, MFA coverage, privileged access and periodic reviews.
- Service accounts and workloads: owners, purpose, privilege level and review evidence for accounts that run applications, batch jobs and integrations.
- Secrets and keys: where API keys, tokens and certificates are stored, who can read them, and how rotation and revocation work. See the Secrets Management Guide.
- Third-party and SaaS access: the description criteria explicitly cover vendor and business partner risk, so OAuth grants, vendor accounts and partner connections need an inventory and an owner.
- AI agents and automation: where agents act with credentials, they are identities in scope; describe how they are authorised and monitored.
Expect the practitioner to ask for a complete population before sampling. An identity inventory that covers people but not service accounts or API keys is the most common reason an access control cannot be tested. The NHI Inventory Reconciliation guide explains how to build one that reconciles across sources.
Implementation steps
- Agree the purpose and audience (month 1): confirm who asked for assurance and what decision it supports. If the request comes from customers of a hosted service, a SOC 2 may be the better answer.
- Define the subject (month 1): agree with the practitioner what the programme description will cover. Keep it consistent with how the board oversees cyber risk, or the description will not hold together.
- Choose control criteria (month 1): Trust Services Criteria if you already have SOC 2 work to reuse; another suitable framework if the board already reports against it. Document why the criteria are suitable.
- Readiness assessment (months 2 to 3): map existing controls to the criteria, identify gaps and owners. A non-attest readiness engagement is an option and does not produce an opinion.
- Draft the description (months 3 to 4): write against each of the nine categories. Describe what actually operates, including significant incidents where the criteria call for them, and avoid aspirational language.
- Remediate and operate (months 3 to 6): close gaps and let controls run long enough to generate evidence for the period.
- Design-only or full examination: start with a design-only examination if controls are new; move to an examination over a period once evidence exists.
- Manage distribution: the report is general use, but decide with your auditor and counsel whether to publish it or share it on request.
Decision guidance. A smaller organisation with one main system and customers who ask for SOC 2 should usually start there and add SOC for Cybersecurity only if investors or a board want an entity-wide opinion. A larger, multi-business entity facing investor or regulator questions gains most, because one general-use report can replace many questionnaires. Public companies that already disclose cyber risk management under the SEC rules may find the description a useful, assured basis for those disclosures; see the SEC Cybersecurity Disclosure Rules Guide. The examination does not replace ISO/IEC 27001 certification where contracts require it.
Evidence and assessment
The practitioner evaluates both whether the description is fairly presented and whether controls operated effectively. Evidence needs to support both.
| Area | Evidence an auditor typically requests | Identity-specific angle |
|---|---|---|
| Governance | Board and committee minutes, charters, CISO reporting packs | Ownership of identity risk named in the governance structure |
| Risk assessment | Risk register, methodology, threat and vulnerability inputs, vendor risk assessments | Credential compromise and third-party access as recorded risks |
| Access provisioning | Complete user and account populations, approval tickets, samples | Service accounts and API keys included in the population with owners |
| Access reviews | Review records, reviewer sign-off, revocation evidence | Non-human identities reviewed, not excluded |
| Monitoring | SIEM use cases, alert handling records, internal audit results | Alerts on anomalous service account and token use |
| Incident management | Incident register, post-incident reviews | Credential-related incidents and their root causes |
Measure readiness with a small set of indicators: percentage of description criteria with evidence mapped; percentage of identity populations (workforce, privileged, service accounts, API keys) that are complete and owned; access review completion within the period; number of control exceptions from readiness testing still open; and time to remediate exceptions. For evidence automation, see the Audit Evidence and Continuous Controls Monitoring Guide.
Mapping to other frameworks
The table below is an indicative alignment prepared by NHI Mgmt Group to help reuse existing work. It is not an official AICPA crosswalk; confirm any mapping you rely on with your practitioner.
| Description criteria category | NIST CSF 2.0 | NIST SP 800-53 Rev 5 | ISO/IEC 27001:2022 |
|---|---|---|---|
| Nature of business and operations | GV.OC-01 | PM-9 | Clause 4.1 |
| Nature of information at risk | ID.AM-07 | RA-3 | Annex A 5.12 |
| Programme objectives | GV.RM-01 | PM-9 | Clause 6.2 |
| Factors affecting inherent risk, including service providers | GV.SC-07, ID.RA-03 | RA-3 | Annex A 5.19 |
| Governance structure | GV.RR-01 | PM-9 | Clause 5.3 |
| Risk assessment process | ID.RA-05 | RA-3 | Clause 6.1.2 |
| Monitoring of the programme | GV.OV-03, ID.IM-01 | CA-2, CA-7 | Clause 9.1 |
| Control processes (identity) | PR.AA-01, PR.AA-05 | AC-2, IA-5 | Annex A 5.15, 5.16, 5.18 |
For crosswalks between the main frameworks themselves, see the SOC 2 to ISO 27001 Mapping Guide and the NIST CSF to ISO 27001 Mapping Guide.
Common pitfalls
- Commissioning the wrong report: customers of a SaaS product asked for SOC 2 and received SOC for Cybersecurity, which answers a different question. Match the report to the reader.
- A description that reads like a policy: aspirational language about what the programme should do, rather than what operates. Practitioners test the description, so every claim needs evidence.
- Scope narrower than the story: the description implies an entity-wide programme while controls were only tested in head office systems. Align the subject, the description and the testing.
- Incomplete identity populations: access testing samples from a workforce directory while service accounts, cloud roles and API keys sit outside it. The Microsoft Midnight Blizzard incident shows how a legacy test account and an over-privileged OAuth application can sit outside routine review.
- Vendor risk described but not evidenced: the criteria ask how vendor and partner risk is managed, and a list of suppliers without assessments or access records does not meet it.
- Unsuitable control criteria: a home-grown control list with no rationale for completeness. Use recognised criteria or document suitability.
Practitioner checklist
- Confirm who wants assurance and that an entity-wide opinion, not SOC 2, answers their question.
- Agree the subject with the practitioner and keep it consistent with board oversight.
- Select and document suitable control criteria, usually the 2017 Trust Services Criteria with Revised Points of Focus (2022).
- Draft the description against all nine categories with evidence for every statement.
- Build complete identity populations: workforce, privileged, service accounts, API keys, third-party and agent identities, each with an owner.
- Run access reviews that include non-human identities and retain revocation evidence.
- Record significant incidents and vendor risks the way the criteria expect.
- Choose design-only or period examination based on control maturity, with a readiness pass first.
- Agree distribution of the general-use report with your auditor and counsel.
Standards and references
- AICPA and CIMA: Reporting on an Entity's Cybersecurity Risk Management Program and Controls
- AICPA and CIMA: Description Criteria for a Cybersecurity Risk Management Program
- AICPA and CIMA: System and Organization Controls Suite of Services
- Center for Audit Quality: The CPA's Role in Addressing Cybersecurity Risk
- Center for Audit Quality: Cybersecurity, How CPAs Are Addressing Cyber Risk
- The CPA Journal: Cybersecurity Risks and Controls
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: SOC 2 Guide · SOC for Supply Chain · Third-Party Attestation Comparison Map · Audit, Assurance and Compliance Guide