Free · complete · nothing held back
Your American customer wants a SOC 2. You have ISO 27001. How much of it counts?
Nearly all of the controls, and almost none of the evidence. That sentence is the whole answer, and the thirty-eight rows below are the working. This is the same crosswalk we supply to clients, published in full, because a mapping is a map and maps are more useful when everyone has one.
It is not the controls. It is the evidence.
An organisation with a working ISO 27001 management system already has most of the controls a SOC 2 report tests. What it usually does not have is the way the evidence must be produced — and that, not the control set, is what makes a first SOC 2 take two or three quarters longer than anyone budgets for.
- Attestation, not certification. ISO 27001 gives you a certificate from an accredited certification body. SOC 2 gives you a report carrying an opinion from a licensed CPA firm. There is no such thing as a SOC 2 certificate, and a vendor claiming to be “SOC 2 certified” is telling you something about their care with language.
- A period, not a point in time. The big one. A Type 2 report covers a window — commonly six to twelve months — and the auditor tests whether each control operated throughout it. You cannot tidy up the week before. If your access reviews were skipped in March, the report says so.
- Sampling, not a sample. An ISO auditor looks for the process and some evidence that it runs. A service auditor pulls a statistical sample of changes, of leavers, of access reviews, and tests each one. A process that works nine times out of ten fails.
- A system, not an organisation. SOC 2 reports on a defined system — a product, a platform, the services around it. Your ISMS scope is usually wider. Getting the system description right is the first deliverable and the one most often rewritten.
- No Statement of Applicability. SOC 2 has no equivalent and cannot exclude a common criterion. All thirty-three apply to every report. Your SoA is still good evidence for CC5.1, but it does not let you scope anything out.
- Subservice organisations. Your cloud provider’s controls are either carved out of your report — with their SOC 2 relied on and the complementary user entity controls handed back to you — or included. Almost everyone carves out. Almost nobody reads the complementary controls they have just accepted responsibility for.
The expensive mistake
Do not open the observation window until the controls are actually running.
The commonest costly error is starting a twelve-month Type 2 window in month one, then failing criteria for the first four months because the process was still being built. Run a Type 1 first, or run the controls quietly for a quarter, and start the window when you could survive being sampled. The window is the product; the controls are only the input.
And the number people quote at each other: on our mapping, thirty-six of the thirty-eight criteria below are already covered, fully or nearly, by ISO 27001 work. That is a good starting position, not a short project. It measures control coverage and says nothing about the evidence, which is most of the effort.
The crosswalk
Thirty-three common criteria — every SOC 2 report contains all of them — plus availability and confidentiality, the two optional categories most often added. Criteria names and descriptions are written in our own words; the reference numbers follow the AICPA 2017 Trust Services Criteria with the 2022 revised points of focus, which remain the current version and which you will need to obtain from the AICPA. Nothing here reproduces that text.
CC1 — Control environment
Borrowed from COSO, and the part of SOC 2 that feels least like ISO 27001. This is where an ISO shop finds most of its gaps.
That the organisation demonstrates a commitment to integrity and ethics, and that this is visible in how people are hired, told what is expected, and dealt with when they fall short.
That those charged with governance are independent of management and actually exercise oversight of internal control.
That the organisation chart, reporting lines and delegated authorities are defined and match how decisions are actually taken.
That the organisation hires, develops and retains people competent to operate the controls, with evidence rather than assertion.
That individuals are held to account for their control responsibilities, including through performance measures and consequences.
CC2 — Communication and information
That the organisation obtains and uses information good enough to support the functioning of internal control.
That security responsibilities and the information people need are communicated internally, and that there is a route to report problems.
That the organisation communicates with customers, suppliers and regulators about matters affecting internal control, including how outsiders report a problem.
CC3 — Risk assessment
That objectives are stated with enough clarity that risks to them can be identified.
That risks to objectives are identified across the organisation and analysed as a basis for deciding how to manage them.
That the organisation explicitly considers fraud — misappropriation, misreporting, management override — when assessing risk.
That significant changes — to the business, systems, people or suppliers — trigger a reassessment of risk rather than being noticed later.
CC4 — Monitoring activities
That the organisation carries out ongoing and separate evaluations to establish that controls are present and functioning.
That deficiencies are communicated to those responsible for corrective action, and to management, in time to act.
CC5 — Control activities
That controls are selected and developed to bring risks to an acceptable level.
That general controls over technology are selected and developed to support the achievement of objectives.
That policies establish what is expected and procedures put those policies into effect, with named responsibility.
CC6 — Logical and physical access
Almost entirely covered by Annex A.7 and A.8. If your ISMS is real, so is this section.
That logical access security software, infrastructure and architecture are implemented to protect information from unauthorised access.
That new access is registered and authorised before it is granted, and that the authorisation is recorded.
That access is modified and removed on role change and departure, on a least-privilege basis, and reviewed periodically.
That physical access to facilities holding information assets is restricted to authorised people.
That physical assets and media are disposed of in a way that makes the information unrecoverable.
That the organisation protects its boundaries against threats from outside.
That information is protected when transmitted, moved or removed, including on portable media and devices.
That the organisation prevents or detects unauthorised or malicious software.
CC7 — System operations
That the organisation maintains standard configurations and detects departures from them, and identifies vulnerabilities.
That systems are monitored for anomalies that indicate a security event, and that someone looks at the result.
That security events are evaluated to determine whether they are incidents.
That identified incidents are responded to under a defined programme, with containment, communication and remediation.
That the organisation recovers from incidents and improves as a result.
CC8 — Change management
One criterion, and the one an auditor samples hardest.
That changes to infrastructure, data, software and procedures are authorised, designed, developed, tested, approved and implemented under a defined process.
CC9 — Risk mitigation
That the organisation identifies and mitigates risks from business disruption, including through insurance where appropriate.
That the organisation assesses and manages risks from vendors and partners, including obtaining and reviewing their assurance reports.
Availability — an optional category
That capacity is monitored and managed so that availability commitments are met.
That environmental protections, backup processes and recovery infrastructure exist and are maintained.
That recovery procedures are tested, not merely written.
Confidentiality — an optional category
That confidential information is identified and maintained as such through its life.
That confidential information is disposed of when it is no longer needed to meet objectives.
Where the line falls
This is a mapping, not an audit, and we will never be your service auditor.
A SOC 2 report is issued only by a licensed CPA firm. We are not one and do not intend to become one. This crosswalk is our professional view of how the two frameworks relate; your service auditor’s view is the one that decides, and where the two differ, theirs wins. Treat every row as a starting point for that conversation rather than an answer to it.
Costs nothing, and there is nothing to give us for it — no email address, no form, no follow-up. If it is useful, the documentation packs are where we make our living, and the obligations you pick up abroad is the page to read next. This crosswalk is in English only; our runbooks are published in French Canadian as well, and if you need a paid document in French, ask.
If a US customer has just asked you for one
The first question is not which controls you need. It is what system the report covers, which categories the customer actually wants, and when the observation window can honestly begin. Those three answers decide the cost and the date, and they are worth an hour with somebody before you commit to either.