Many service organizations are asked for both an ISO/IEC 27001 certificate and a SOC 2 report. The two are often run as separate projects, with separate control lists, evidence folders and owners. That doubles the work, and the two descriptions of the company drift apart.
Most of the underlying activity is the same. This guide shows how to run both from one control set, and where each still needs separate attention.
Two different kinds of assurance
ISO/IEC 27001:2022 is a standard for an information security management system (ISMS). Clauses 4 to 10 set requirements for context, leadership, planning, support, operation, performance evaluation and improvement. Annex A lists 93 reference controls in four themes: organizational, people, physical and technological. An accredited certification body audits the ISMS and issues a certificate, maintained through surveillance audits and periodic recertification.
SOC 2 is an attestation report, not a certification. An independent CPA firm examines a service organization's controls against the AICPA Trust Services Criteria and gives an opinion. The Security category, also called the common criteria, is always in scope. Availability, Processing Integrity, Confidentiality and Privacy are added where relevant to the service.
A Type 1 report covers the design of controls at a point in time. A Type 2 report covers design and operating effectiveness over a period, typically between three and twelve months.
One consequence matters for planning. ISO/IEC 27001 asks whether you run a working management system that selects controls based on risk. SOC 2 asks whether the controls you described were suitably designed and, for Type 2, operated throughout the period.
Where the requirements overlap
The common criteria are organized in nine series. CC1 to CC5 follow the COSO internal control framework: control environment, communication and information, risk assessment, monitoring activities and control activities. CC6 to CC9 cover logical and physical access, system operations, change management and risk mitigation.
The table is an indicative mapping at the level of control areas. It is a starting point for your own mapping, not a substitute for one.
| Control area | ISO/IEC 27001:2022 | SOC 2 Trust Services Criteria |
|---|---|---|
| Governance, policy, roles | Clause 5; Annex A 5.1 to 5.4 | CC1, CC2, CC5 |
| Risk assessment and treatment | Clauses 6.1, 8.2 and 8.3 | CC3 |
| Internal audit and management review | Clauses 9.2 and 9.3 | CC4 |
| Identity and access | Annex A 5.15 to 5.18, 8.2 to 8.5 | CC6 |
| Logging, monitoring, incident management | Annex A 8.15, 8.16, 5.24 to 5.28 | CC7 |
| Change management and secure development | Annex A 8.25 to 8.32 | CC8 |
| Supplier and cloud service management | Annex A 5.19 to 5.23 | CC9 |
| Backup, redundancy, continuity | Annex A 5.29, 5.30, 8.13, 8.14 | Availability criteria |
The AICPA has published mappings between the Trust Services Criteria and ISO/IEC 27001. Use them to check your own mapping for gaps.
Build the control set around your own controls
The most useful design decision is to make your own controls the primary key. Do not adopt Annex A as your control list and then attach SOC 2 to it, or the reverse.
Write each control as a statement of what your organization does: who performs it, how often, on which systems, and what record it leaves. Then tag it with the Annex A controls and the criteria it supports.
A control record should hold at least:
- a unique identifier and a named owner
- the control statement, including frequency and the systems in scope
- mapped Annex A controls and Trust Services Criteria
- the evidence it produces and where that evidence lives
- the risks it treats, linked to the risk register
Two outputs are then generated from the same source. The Statement of Applicability lists every Annex A control, whether it applies, the justification and its implementation status. The SOC 2 control matrix lists your controls against the criteria.
The points of focus in the Trust Services Criteria are guidance, not requirements. You do not need a control for every point of focus. You do need to meet every criterion in scope.
Align scope first
Scope mismatch is the most common cause of duplicated work. ISO/IEC 27001 scope is defined under clause 4.3 in terms of the organization, its activities and its interfaces. SOC 2 scope is set by the system description: the services provided and the infrastructure, software, people, procedures and data that deliver them.
Aim for the same boundary in both. If the ISMS covers the whole company and the SOC 2 report covers one product, decide that deliberately and record which controls are company-wide and which are product-specific.
Treat third parties consistently. Cloud providers that operate controls on your behalf are subservice organizations in SOC 2, usually handled by the carve-out method. The same providers fall under the supplier controls in Annex A. One supplier register and one review process should serve both.
Collect evidence for the stricter test
A Type 2 examination tests operation across the whole period. The auditor asks for a population, such as all production changes or all new joiners, and selects samples from it. ISO audits also sample, but place more weight on whether the management system is functioning. Evidence designed for the Type 2 test will generally serve the ISO audit too.
- Prefer system-generated records over screenshots taken at audit time.
- Make populations easy to produce: ticket queries, identity provider exports, pipeline logs.
- Record exceptions and the response to them. A documented exception is better than a gap.
A sequence that works
- Define scope and run the risk assessment. The risk treatment plan justifies the controls.
- Write the unified control set and map it to both references.
- Operate the controls and collect evidence from the first day. This starts the clock for a Type 2 period.
- Complete an internal audit and a management review. ISO auditors expect both, and both support CC4.
- Hold the ISO Stage 1 and Stage 2 audits, and a SOC 2 Type 1 if an early report is needed.
- Complete the Type 2 period. Where possible, schedule the ISO surveillance audit close to the SOC 2 fieldwork, so evidence is pulled once.
Common mistakes
- Maintaining two control lists with different wording for the same activity.
- Treating the Statement of Applicability as a checklist with no link to risk.
- Writing controls that leave no record. What cannot be evidenced will fail a Type 2 test.
- Neglecting internal audit, management review and corrective action, where many first ISO audits find nonconformities.
- Omitting complementary user entity controls from the SOC 2 description, so the report implies you do things your customers must do.
Onion Infosec supports this kind of work through its compliance readiness service.