---
title: "SOC 2, ISO 27001, NIS2, AI Act: what actually overlaps"
canonical: "https://auditbadger.com/blog/soc-2-iso-27001-nis2-ai-act-what-actually-overlaps/"
last-updated: "2026-09-14"
---

# SOC 2, ISO 27001, NIS2, AI Act: what actually overlaps

By Maciej • Published 2026-08-30 • 6 min read • Categories: Compliance Governance, Knowledge Hub, Soc2, ISO

Created with AI assistance. AuditBadger retains editorial control and responsibility.

**TL;DR:** SOC 2, ISO 27001 and NIS2 share most of a control spine: access control and multi factor authentication, asset inventory, risk assessment, incident handling, backup and continuity, supplier security, secure development and vulnerability management, effectiveness monitoring, awareness training and cryptography all appear in all three under different names. Implement each control once and it satisfies obligations in three places, which is why sequencing matters more than choosing. The AI Act is the odd one out and should not be planned as a fourth security framework: it is EU product regulation about transparency, and its article 50 duties have no analogue in the other three, just as none of the three say anything about AI transparency. The differences that survive the overlap are the ones that cost time: SOC 2 is an attestation report from a CPA firm with no regulator behind it, ISO 27001 adds a management system with audits and management reviews, NIS2 adds a reporting clock, a registration duty and personal accountability for management bodies, and the AI Act adds disclosure and marking obligations tied to product behaviour. For a small team the efficient order is usually one security framework first, then the regulation that applies to you, with the AI Act handled as a small separate workstream.

If you are staring at four acronyms and a roadmap, here is the useful shape. Three of them are security control regimes that overlap heavily, so the work compounds and sequencing matters more than choosing. The fourth, the AI Act, is not a security framework at all, and planning it as one will waste your time in both directions.

## First, a category correction

These four things are not the same kind of object, and the differences drive everything else.

- **SOC 2®** is an attestation report, produced by a licensed CPA firm, against the AICPA Trust Services Criteria. Nobody makes you do it. Your customers do.
- **ISO 27001** is certification against a management system standard, issued by an accredited certification body. Also voluntary, also driven by buyers, but it certifies a system for running security rather than a period of operation.
- **NIS2** is law, via your country's transposition. Not voluntary, no certificate at the end, and a regulator on the other side.
- **The EU AI Act** is also law, but product regulation. It governs how AI systems behave and what they tell people, not how you secure your infrastructure.

The first two are things you choose. The second two happen to you based on what you do and where you do it.

## The shared control spine

This is the part that pays. The same underlying controls appear in all three security regimes under different vocabulary.

| What you actually build | SOC 2 Common Criteria | ISO 27001:2022 | NIS2 article 21(2) |
| --- | --- | --- | --- |
| Access control and MFA | CC6.1 to CC6.3 | A.5.15 to A.5.18, A.8.5 | (i), (j) |
| Asset inventory and ownership | CC6.1 | A.5.9 to A.5.11 | (i) |
| Risk assessment and treatment | CC3.1 to CC3.4 | Clauses 6.1.2, 6.1.3 | (a) |
| Incident detection and response | CC7.3 to CC7.5 | A.5.24 to A.5.28 | (b) |
| Backup, recovery, continuity | CC7.5, A1.2 | A.5.29, A.5.30, A.8.13 | (c) |
| Vendor and supplier security | CC9.2 | A.5.19 to A.5.23 | (d) |
| Secure development, vulnerability handling | CC8.1 | A.8.8, A.8.25 to A.8.33 | (e) |
| Checking your controls work | CC4.1, CC4.2 | Clauses 9.1 to 9.3 | (f) |
| Awareness and training | CC1.4, CC2.2 | Clauses 7.2, 7.3, A.6.3 | (g) |
| Cryptography | CC6.7 | A.8.24 | (h) |

Ten rows. If you build those properly once, you have most of three regimes. This is not a theoretical claim: in our own control library, 25 sub-controls are reused across SOC 2, ISO 27001 and the Polish NIS2 transposition. One implementation, one set of evidence, three places it counts.

## Where the overlap stops

The leftovers are where the real time goes, so plan for them explicitly.

**ISO 27001 adds a management system.** Scope statement, Statement of Applicability, internal audit programme, management reviews, corrective actions. SOC 2 has nothing equivalent, which is why teams coming from SOC 2 to ISO are often surprised that the controls were the easy part.

**SOC 2 adds an observation period.** A Type II report proves controls operated over months, sampled by an auditor. ISO checks that the system exists and works; SOC 2 Type II checks that it kept working on specific dates.

**NIS2 adds three things nobody else asks for:** external incident reporting on a fixed clock, registration with a national authority, and personal accountability for management bodies who must approve the measures and take training. We covered [exactly which parts of NIS2 your ISO work already covers](/blog/you-have-iso-27001-how-much-of-nis2-is-already-done/), and the answer is most but not those.

**The AI Act adds duties none of the others touch.** Telling users they are talking to a machine, marking synthetic output, labelling deep fakes. No Trust Services Criterion or Annex A control produces any of that.

## The gap all four leave open

Worth naming because buyers increasingly ask about it: none of these four says much about whether your AI is accurate, fair or unbiased.

SOC 2 and ISO 27001 are security frameworks and are silent on model behaviour. NIS2 is about network and information system resilience. The AI Act's article 50 is about disclosure, not quality, and the parts that do address model quality apply to the high risk tier that most small SaaS is not in. Bias, accuracy and evaluation live in ISO/IEC 42001 and the NIST AI Risk Management Framework instead. If a security questionnaire is asking you about model bias, pointing at your SOC 2 report is not an answer, and we went into that in [SOC 2 for AI startups](/blog/soc-2-for-ai-startups-controls-for-llm-model-risk/).

## What order should a small team do this in?

Sequencing that wastes the least effort, for a team without a compliance department:

1. **One security framework first, chosen by your buyers.** US customers asking, start with SOC 2. European or ISO first customers, start with ISO 27001. If nobody is asking yet, do neither and spend the time on hygiene. [The choice between the two](/blog/soc-2-vs-iso-27001/) is mostly a market question, not a technical one.
2. **Then whichever law actually applies.** NIS2 only if you are in scope, which is narrower than the internet suggests. The AI Act only for the tier you are actually in.
3. **Treat the AI Act as a small separate workstream.** A register of AI touched surfaces, a labelling standard, a named editorial owner, a marking assessment. Days, not quarters, if you are in the transparency tier.
4. **Do not start two security frameworks at once.** The overlap makes the second one dramatically cheaper, but only if the first one is finished. Running them in parallel mostly multiplies the meetings.

## What "do it once" actually means

An honest caveat, because "one control, three frameworks" is the kind of claim that oversells easily.

What genuinely transfers is the control and its evidence. Your MFA enforcement, your access reviews, your backup restore tests, your vendor register: one implementation, reused. What does not transfer is the paperwork around it. SOC 2 needs a system description and an auditor's sampling. ISO needs a Statement of Applicability and an internal audit. NIS2 needs a report filed with a named authority on a deadline. Those are three different pieces of writing about the same control.

So the compounding is real, and it is roughly the control layer rather than the whole program. In our experience that is still most of the effort, which is why the second framework always feels achievable in a way the first one did not.

We went through this ourselves in that order: ISO 27001 back in 2019 at a previous company, then SOC 2 Type II for AuditBadger, certified using AuditBadger with no external consultants. The second one was faster, and not because we got smarter.

If you want the mechanics of running one control set against several frameworks at once, that is what [compliance management in AuditBadger](https://auditbadger.com/features/compliance-management/) does. NIS2 support is early access and switched on per account after a conversation, and [the NIS2 page](/nis2/) says plainly what we cover today and what we do not.