We get this question often, in some variation: "We're SOC 2 Type II. Doesn't that already cover NIS2?"
The honest answer is: it covers a lot of NIS2. Not all of it. And the parts it doesn't cover are the parts NIS2 cares about most. If you walk into an audit conversation thinking SOC 2 is a NIS2 substitute, you will be unpleasantly surprised by the third question.
This post unpacks what SOC 2 actually attests to, what NIS2 actually demands, where they overlap, and where the gaps quietly live.
What SOC 2 actually says about you
A SOC 2 report is an attestation by a CPA firm that you have controls in place addressing one or more of five Trust Services Criteria: Security (the only mandatory one), Availability, Confidentiality, Processing Integrity, and Privacy. Type I says the controls are designed appropriately on a given date. Type II says they were also operating effectively over a defined period — usually six or twelve months.
It's a useful, well-respected report. It tells a buyer that an independent third party has tested your controls and found them functioning. For a US-buyer-facing SaaS company, it's often the difference between getting and not getting a deal.
It is, however, framed around the buyer trusting the SaaS provider — not around the provider managing its own supply chain, training its management body, or proving the ongoing effectiveness of its measures in the way NIS2 frames the question.
What NIS2 actually demands
NIS2 Article 21 lists ten broad areas of cybersecurity risk management measures every covered entity must implement. The list is sectoral and deliberately general — "appropriate" technical, operational, and organisational measures across each area. The areas include risk policy, incident handling, business continuity, supply chain, secure acquisition and development, effectiveness review, basic hygiene and training, cryptography, HR/access/asset, and MFA + secured comms.
Article 20, separately, requires the management body to actively oversee cybersecurity risk and to undergo training. That's a personal-liability article for executives, not a control article — and it has no SOC 2 equivalent.
Article 23 layers in incident reporting obligations: a 24-hour early warning, a 72-hour full notification, and a one-month detailed report for significant incidents. That's also outside SOC 2's framing.
Where they overlap (and it's a lot)
If you have a Type II SOC 2 covering Security, you've almost certainly got documented evidence that satisfies — at least in part — most of the operational cybersecurity articles in NIS2:
- Risk policy (21(2)(a)): SOC 2's control environment criteria require a documented information security policy
- Incident handling (21(2)(b)): SOC 2 requires documented incident response procedures and evidence they were exercised
- Business continuity (21(2)(c)): Availability TSC requires documented recovery and continuity controls
- Acquisition and development (21(2)(e)): SOC 2 commonly covers SDLC and change management
- Cryptography (21(2)(h)): Confidentiality TSC and the Security TSC control objectives both require encryption-in-transit and at-rest evidence
- HR, access, asset (21(2)(i)): SOC 2 covers logical and physical access, HR onboarding/offboarding, and asset inventory
- MFA + secured comms (21(2)(j)): Security TSC routinely tests MFA and secure transmission
- Training and hygiene (21(2)(g)): SOC 2 requires annual security awareness training evidence
That's eight of the ten Article 21 areas at least partially evidenced by a Type II SOC 2 — and frequently more, depending on how broadly your TSC scope was set.
Where they don't — three articles SOC 2 quietly skips
The gaps are narrow in count but wide in consequence. There are three places where SOC 2 gives you very little and NIS2 expects a lot.
Article 21(2)(d) — supply chain security
SOC 2 cares whether you manage your security. NIS2 also cares whether you manage your suppliers' security — because their failures land on you. A SOC 2 report tells a buyer about you; it doesn't tell anyone how you assessed and documented the cybersecurity posture of your sub-processors.
In SOC 2 practice, sub-service organisations are usually carved out ("not in our scope") or carved in with a brief description. NIS2 wants the opposite: an explicit supplier inventory, risk-tiering, evidence of assessment, decision trace, and reassessment cadence. That's not a control SOC 2 typically tests.
This is the single biggest gap, and it's the one regulators are most likely to ask about first.
Article 21(2)(f) — assessing the effectiveness of cybersecurity measures
SOC 2 attests that your controls were operating. It does not require you to have a documented internal process for reviewing whether the controls remain effective as the threat picture changes. That's a separate clause in NIS2 and it's often missing in practice — most SOC 2 organisations do not maintain a documented "control effectiveness review" programme that's distinct from the audit itself.
If your only effectiveness signal is the annual SOC 2 audit, that's annual. NIS2 wants something operating between audits.
Article 20 — management training and accountability
NIS2 makes management bodies personally accountable for cybersecurity risk and explicitly requires them to follow training to acquire sufficient knowledge and skills. SOC 2's control environment requires "commitment to competence" from management, but does not require documented executive-level cybersecurity training records.
Practically: if your CEO and board members can't produce evidence of recent cybersecurity training when a competent authority asks, your SOC 2 won't help.
What does satisfy NIS2 — practically
For an organisation that's already SOC 2 Type II, the closing-the-gap work is real but not enormous. Roughly:
1. Build a NIS2 control crosswalk. Take your SOC 2 control matrix and map every control to one or more Article 21 sub-clauses. Where the mapping is partial or missing, you have a documented gap. This crosswalk also becomes the spine of your regulator-response artefact when the question eventually comes.
2. Layer in a real supplier programme. Inventory the suppliers handling regulated services. Risk-tier them. Collect proportional evidence per tier. Document the review cadence and the decisions taken. This is the work Vittnor — Supply Chain Assurance for the mid-market — exists to make easier. A well-run spreadsheet plus a defensible decision trail is also acceptable, particularly at smaller portfolio sizes.
3. Document an effectiveness-review programme. A quarterly internal review of selected controls, with a written outcome and remediation actions. Your existing SOC 2 testing supplies most of the evidence; what's new is the documented review process between audits.
4. Get management training records on file. Annual cybersecurity training for the management body, attendance recorded, content suitable for non-technical executives. Many existing CISO-to-board updates already cover the ground; what changes is the formality of recording them as training.
5. Stand up the incident reporting clock. Confirm your IR plan triggers the 24-hour and 72-hour NIS2 reporting cycles, not just internal escalation. Brief the on-call team. Decide who phones the regulator at hour 23.
The shorter answer
SOC 2 gets you most of the technical-control story. NIS2 also wants the supplier story, the effectiveness story, and the management-accountability story. Building those three layers on top of an existing SOC 2 is the most cost-effective path for organisations that already have one.
If you want a written, defensible picture of where your specific organisation sits today — including whether your existing SOC 2 evidence covers more or less than the average — the NIS2 Supplier Exposure Assessment is built for that. Two to three weeks. Fixed price. The deliverable is the report.
Or for a quicker directional steer, try the readiness check — twenty questions, an article-anchored gap report, free.