ISO 27001, SOC 2 and NIS2: What Differs
These three are often discussed together and demand very different things.
| ISO 27001 | SOC 2 | NIS2 | |
|---|---|---|---|
| Nature | Certifiable management system standard | Attestation report by a CPA firm | EU directive, transposed into national law |
| Driver | Certification, customer assurance | Customer assurance, mainly US market | Legal obligation for in-scope entities |
| Scope | ISMS you define | Trust Services Criteria you select | Cybersecurity risk management and reporting |
| Output | Certificate | Type I (design) or Type II (operating effectiveness) report | Regulatory compliance, supervised |
| Cadence | 3-year cycle, annual surveillance | Usually annual, with a defined observation period | Ongoing, with incident reporting deadlines |
The practical consequence is that ISO 27001 asks whether you run a system, SOC 2 asks an auditor to describe and test your controls for a customer audience, and NIS2 imposes duties on you by law — including management accountability and incident notification within tight deadlines.
ISO 27001: The ISMS, Not the Controls
The most common misunderstanding is that ISO 27001 is Annex A. It is not. Annex A is a reference set of 93 controls in the 2022 revision, and the certifiable content is clauses 4–10: context, leadership, planning, support, operation, performance evaluation, and improvement.
What auditors actually test:
- Scope statement — defensible, and consistent with what you claim to customers.
- Risk assessment methodology — documented, repeatable, and actually applied rather than reconstructed before the audit.
- Statement of Applicability — every Annex A control included or excluded, with justification. Exclusions are legitimate; unjustified exclusions are a finding.
- Risk treatment plan — traceable from assessed risks to selected controls.
- Internal audit and management review — evidence they happened, with outputs.
- Nonconformities and corrective actions — tracked to closure.
The 2022 revision reorganised Annex A into four themes (organisational, people, physical, technological) and added controls including threat intelligence, information security for cloud services, data leakage prevention, and secure coding. Organisations that certified against the 2013 version needed to re-map.
SOC 2: Criteria, Not Controls
SOC 2 defines Trust Services Criteria and leaves the controls to you. Security (the common criteria) is mandatory; availability, processing integrity, confidentiality and privacy are selected based on what you commit to customers.
The distinction that costs organisations time is Type I versus Type II. Type I opines on control design at a point in time. Type II opines on operating effectiveness across an observation period, typically three to twelve months — which means evidence must exist continuously across that window. Evidence assembled retrospectively is the single most common reason a Type II observation period has to be restarted.
NIS2
NIS2 applies to essential and important entities across sectors including energy, transport, banking, health, water, digital infrastructure, public administration and others, with size thresholds. Its notable features:
- Management accountability. Management bodies must approve cybersecurity risk-management measures and can be held liable; they are also required to undergo training.
- Incident reporting on a clock. An early warning within 24 hours of becoming aware, an incident notification within 72 hours, and a final report within one month.
- Supply chain security as an explicit obligation, not a nice-to-have.
- Supervision and penalties, with administrative fines and, for essential entities, the possibility of management suspension.
Because it is a directive, the detail lives in each member state's transposing law. Check the national implementation for your jurisdiction rather than the directive text alone.
Where the Frameworks Overlap
The overlap between these three is substantial — typically 40–60% of controls satisfy more than one. Access control, change management, incident response, business continuity, supplier management, logging and monitoring, and awareness training appear in all of them under different names and different levels of prescription.
That overlap is only useful if you exploit it deliberately. The mechanism is a control-to-framework mapping matrix: each control defined once, with columns for every framework it satisfies, tested once, and the evidence counted everywhere it is mapped. Maintaining a separate control set per framework triples the testing effort and guarantees the three sets will drift apart.
Building the Evidence Trail
Whichever framework drives you, the operational problem is the same: demonstrating that controls operated, continuously, with evidence an auditor accepts.
That means each control needs an owner, a test frequency, a defined evidence artefact, and a retained history of results and exceptions. Evidence collected on a schedule is cheap; evidence reconstructed before an audit is expensive and, for SOC 2 Type II, often not acceptable at all.
How ActiveERM Supports Information Security Compliance
The GRC platform holds one control library mapped across ISO 27001 Annex A, SOC 2 Trust Services Criteria, NIS2 requirements and any other framework you carry, so a control is tested once and satisfies all of them. Policies, risks, controls, evidence, incidents and audit findings sit in one system with the linkages an assessor follows.
Because it shares the platform with risk management and business continuity, the ISO 27001 risk assessment is not a separate exercise from enterprise risk, and continuity controls are not maintained twice.