NIS2, DORA and SEC Reg S-P: what each demands of your vendors

The convergence

Until recently, third-party security obligations were mostly indirect: a general duty of care, from which a supervisor might infer that you should have checked your suppliers. Three instruments changed that within roughly eighteen months of each other, and they arrive at the same place from different directions.

• NIS2 approaches it as sectoral resilience — supply-chain security is an enumerated risk-management measure for essential and important entities.
• DORA approaches it as financial stability — ICT third-party risk gets its own chapter, its own register, and an EU-level oversight regime for the providers judged critical.
• Reg S-P approaches it as consumer protection — if a service provider holds your customers’ information, its breach is your notification obligation.

For a supplier, the direction of travel is what matters more than the drafting. Each regime pushes obligations down the chain contractually, which means firms well outside the formal scope of any of them are answering their requirements second-hand.

NIS2: supply chain as a named control

NIS2 replaced the original NIS Directive and widened the population of regulated entities substantially. For third-party risk, the operative provision is Article 21, which sets out the risk-management measures essential and important entities must take. Supply-chain security is enumerated there explicitly, framed as security in the relationships between the entity and its direct suppliers and service providers.

Two features make it bite harder than its predecessor. First, it obliges entities to account for the specific vulnerabilities and overall security practice of each supplier — a supplier-specific judgement, not a blanket policy. Second, NIS2 attaches management accountability: it is not a duty that can be wholly delegated to a security function and reported upward once a year.

DORA: the register, and the oversight regime

DORA is a regulation rather than a directive, so it applies directly and uniformly across the EU, and it has applied to financial entities since 17 January 2025. It is the most prescriptive of the three on third parties, and the most demanding to evidence.

• The Register of Information. Financial entities must maintain a structured register of all contractual arrangements for ICT services, and supervisors have been collecting and testing these since the regime began. It is the closest thing in any of the three regimes to a hard, checkable artefact — which also makes it the fastest way to demonstrate that a firm does not actually know its own dependency map.
• Contractual minimums. DORA specifies what ICT contracts must contain, with a stricter set again for arrangements supporting critical or important functions.
• Concentration risk. Entities must assess whether their reliance on a provider — or on a chain of subcontractors behind one — creates a concentration they could not withstand.
• Critical ICT third-party providers. DORA reaches past the regulated entity to designate certain providers as critical and place them under direct EU oversight. This is the provision with no real analogue elsewhere: the supplier itself becomes a supervised party.

For financial entities, DORA’s third-party provisions take precedence over the equivalent NIS2 measure, so an in-scope firm follows DORA rather than reconciling both.

SEC Reg S-P: the vendor’s breach, your notification

The SEC adopted the Regulation S-P amendments in May 2024. They require covered institutions to maintain a written incident response programme designed to detect, respond to and recover from unauthorised access to customer information — and to notify affected individuals within 30 days of becoming aware that sensitive customer information was, or is reasonably likely to have been, accessed without authorisation.

The third-party element is the part most often underestimated. The programme must extend to service providers: firms are expected to conduct due diligence and ongoing monitoring, and to have arrangements ensuring the provider notifies them promptly of a breach. A firm may contractually delegate the mechanics of issuing notices to a provider, but it retains responsibility for the outcome. In practice this converts a vendor’s incident into your regulatory clock.

If you are an Indian supplier to global clients

None of these three regimes name Indian entities, and most Indian firms are not directly in scope of any of them. That has almost no practical bearing on whether they apply to you.

Obligations of this kind travel through contracts. A European bank subject to DORA must place specified terms in its ICT contracts; if you are in that chain, those terms arrive in your renewal. A US adviser subject to Reg S-P must monitor its service providers and secure prompt breach notification; if you process its customers’ information, you are the service provider being monitored. The regulator never contacts you. Your client does, and the answer determines whether the contract renews.

The domestic picture points the same way — the RBI, SEBI and CERT-In expectations covered in what boards must evidence push toward demonstrable, continuous oversight rather than periodic attestation. A firm building for one of these regimes is largely building for all of them.

What evidence actually satisfies these

All three regimes ask a question that a point-in-time artefact answers badly: not “was this supplier secure when you signed?” but “how do you know it still is?” Four things tend to survive scrutiny.

• A dependency map you can produce on demand. DORA makes this explicit through the Register; the other two assume it. Any programme that cannot enumerate its third parties, and the functions each supports, fails at the first question.
• Timestamped posture over time, per supplier. A continuously calculated external rating produces a dated record of each vendor’s security performance that does not depend on the vendor’s cooperation, and cannot be back-filled. That is a materially different artefact from a completed questionnaire.
• Evidence that change triggered action. Supervisors are increasingly less interested in whether you monitor than in what happened when monitoring surfaced something. Alert-to-action records are the artefact.
• Control mapping, not raw scores. A number means little to an examiner. The same measurement mapped to NIST CSF 2.0 or ISO/IEC 27001:2022 control areas is reviewable in the vocabulary the assessment is conducted in.

The uncomfortable implication for questionnaire-led programmes is that the artefact they produce — a supplier’s own description of its controls, accurate on the day it was signed — is the one artefact none of these three regimes is really asking for. Building a tiered programme with continuous evidence covers what replacing it looks like in practice.

Primary sources: Directive (EU) 2022/2555 (NIS2), Regulation (EU) 2022/2554 (DORA), and the SEC final rule Release No. 34-100155 amending Regulation S-P. This page is a summary for orientation and is not legal advice; scope, thresholds and national implementation vary, and NIS2 in particular applies through member-state transposition. Confirm your own position with counsel. Continuous external measurement referenced here is a Bitsight capability; BitScore Cybertech LLP is an authorised Bitsight partner.