Third-party risk across GDPR, NIS2, and DORA

The same supplier can create privacy, cybersecurity, and operational resilience obligations. A payroll provider processes personal data; a managed service provider holds privileged access; a cloud platform supports business-critical applications. Sometimes one supplier does all three.

A shared supplier record helps teams coordinate the assessment, provided each obligation remains identifiable. For a CTO, the practical challenge is to connect contractual commitments to technical reality: what the supplier can access, how failures propagate, which controls are evidenced, and whether the organization can recover or leave.

Establish applicability before combining assessments

These instruments overlap, but they do not apply to every organization or supplier in the same way.

GDPR Article 28 requires controllers to use processors providing sufficient guarantees. An Article 28 agreement is not appropriate merely because a supplier receives data: establish the actual processing role first.

NIS2 Articles 20–23 address management oversight, risk-management measures, and significant-incident reporting. NIS2 is a directive implemented through national law, so scope and procedures require jurisdiction-specific checks.

DORA has applied since 17 January 2025. It primarily covers specified financial entities; ordinary ICT suppliers may face customer contractual requirements, while designated critical ICT providers have a separate oversight regime. For covered financial entities, DORA operates as sector-specific EU law for relevant NIS2 areas. Do not automatically duplicate both control sets.

Build the record around the dependency

Start from the service, not the supplier questionnaire. One supplier may provide several services with different data, access, and operational importance.

As a practical baseline, record:

• Service, supplier legal entity, business owner, technical owner, and reviewers.
• Supported functions, systems, integrations, and privileged access.
• Personal-data categories, processing purposes, locations, and subprocessors.
• Availability requirements, recovery objectives, and tolerable disruption.
• Underlying providers, contractual dependencies, and realistic alternatives.
• Applicable obligations, evidence dates, unresolved gaps, and decisions.

Identify which functions would fail or degrade after compromise or outage. A supplier that stores little sensitive data may still control authentication or deployment pipelines. Conversely, a low-availability-risk service may expose highly sensitive personal data.

Keep these dimensions separate rather than collapsing them into one unexplained “high risk” score. For DORA-covered financial entities, connect this operational inventory to the required register of information on ICT contractual arrangements; a generic vendor list is not necessarily sufficient.

Reuse evidence without reusing conclusions blindly

A security report, data-flow map, or recovery test may support several reviews. Check its service scope, reporting period, exclusions, exceptions, and customer responsibilities before relying on it.

For example, a report covering the supplier’s infrastructure does not necessarily cover its support personnel’s access to customer records. A documented backup policy does not show that restoration meets your application’s recovery requirements.

Maintain an evidence-to-question matrix:

An ISO certificate or SOC 2 report supports assurance within its scope; neither establishes GDPR or NIS2 compliance. Preserve the reviewer’s reasoning, not just the uploaded document. Evaluating security assurance should be a repeatable technical review, not a badge check.

Translate requirements into contracts and controls

Under GDPR Article 28, processor terms must address the processing subject matter, duration, nature and purpose, data types, and categories of individuals. They also cover documented instructions, confidentiality, security, subprocessor conditions, assistance, deletion or return, and information and audit obligations. International transfers require a separate Chapter V assessment; EU hosting alone does not settle access or onward-transfer questions.

NIS2 Article 21 includes supply-chain security and consideration of direct suppliers’ vulnerabilities and cybersecurity practices. Practical contractual expectations can include access restrictions, vulnerability handling, incident cooperation, and evidence provision. Tailor these to the service and national requirements rather than treating one universal clause pack as legally sufficient.

DORA Article 30 specifies ICT contractual provisions, with additional requirements for services supporting critical or important functions. Review service descriptions, locations, data protection and recovery, assistance, termination, and relevant oversight rights. Those critical or important functions require particular attention to service levels, reporting, contingency measures, testing cooperation, audit rights, and transition arrangements.

Then verify implementation. If a contract promises restricted administrative access, obtain evidence of role separation, authentication, approval, and logging. If it promises deletion, establish what happens to backups and retained records. Assign legal gaps and technical gaps to the appropriate reviewers.

Design incident handoffs before an incident

A supplier’s incident-response policy can support a security assessment while leaving notification duties unresolved. Specify contact channels, escalation coverage, initial information, update expectations, and responsibility for preserving evidence.

Under GDPR Articles 33–34, a processor notifies the controller without undue delay. The controller assesses supervisory notification without undue delay and, where feasible, within 72 hours of awareness, unless the breach is unlikely to risk individuals’ rights and freedoms. High risk can require communication to individuals, subject to exceptions. Record the reasoning when notification is not required.

NIS2’s EU reporting stages for significant incidents include a 24-hour early warning, a 72-hour notification, and generally a final report within one month of notification; check national and sector rules. DORA has its own reporting framework for major ICT-related incidents. Do not replace these assessments with a single supplier “breach” flag.

As a practical recommendation, exercise a supplier incident using incomplete information. Test whether teams can establish affected services, exposure, operational impact, and reporting decisions without waiting for a final root-cause report.

Worked example: one service, three review paths

Assume, illustratively, that a covered financial entity uses a hosted customer-support platform processing personal data and supporting a function it has classified as critical or important under DORA.

The supplier provides an assurance report, an incident policy, and a recovery-test summary. Security finds that administrative access controls are evidenced, but the recovery test excludes the customer’s integration.

Privacy separately identifies an unclear subprocessor-change process and unresolved remote-access transfer arrangements. The DORA review finds that transition assistance and relevant audit provisions need attention.

The resulting action plan is specific:

• The technical owner tests integration recovery and documents the result.
• The privacy reviewer resolves subprocessor and transfer questions.
• Legal and procurement address contractual gaps.
• The accountable owner decides whether temporary use is acceptable, with conditions and a review date.

Evidence is reused, but none of the three conclusions is inferred from another. A passed security review does not close the privacy or resilience gaps.

Monitor changes, concentration, and executable exit

Set review frequency according to dependency and risk. Trigger additional review after incidents, major service changes, new subprocessors, data-location changes, ownership changes, or contract renewal.

Look beneath supplier names: several services may depend on the same cloud region, identity provider, or subcontractor. Assess correlated disruption and whether the proposed alternative shares that dependency. DORA Article 29 explicitly addresses ICT concentration risk assessment.

Maintain a proportionate exit plan covering data export, migration, continuity, access revocation, and deletion evidence. Test export usability and identify who can operate the replacement. A termination right is more useful when the organization can execute it.

Consequences also differ. GDPR has infringement-specific penalty tiers; NIS2 requires national penalty arrangements with different ceilings for essential and important entities. DORA sanctions for financial entities depend on applicable arrangements, while critical-provider oversight penalties are distinct. Do not model exposure using one supposed universal fine.

Start with one consequential dependency

Choose one supplier supporting an important function. Reconcile its service inventory, contracts, evidence, open risks, and exit assumptions. Finish with named owners and separate, dated conclusions for each applicable obligation.

In Secani, teams can model the service and external provider, connect requirements and controls to evidence, and track gaps as tasks with owners. Human-reviewed decisions, source links, comments, and timestamps preserve the reasoning. That supports shared supplier context without hiding the distinct privacy, security, and resilience judgments.