sota.io
2026-04-16·13 min read·

GDPR Art.28 + NIS2 Art.21(2)(d): Data Processor as NIS2 Supplier — Dual Compliance Guide (2026)

Most SaaS developers know they need a Data Processing Agreement (DPA) with customers who fall under GDPR. What fewer realise is that the same customer — if they are an essential or important entity under NIS2 — now has a parallel obligation to verify your cybersecurity posture under NIS2 Article 21(2)(d).

The result: if your SaaS product processes personal data for a hospital, bank, energy provider, or government contractor, you are simultaneously a GDPR Art.28 data processor and a NIS2 Art.21(2)(d) supplier. The legal bases differ. The contractual mechanisms differ. But the practical requirement is the same: your customer must be able to demonstrate that you meet a defined security standard — and from June 2026, NCAs will start asking to see that evidence.

This guide maps the two frameworks, identifies where they overlap and where they diverge, and gives you the tools to address both in a single compliance workflow.

1. GDPR Art.28: The Data Processor Framework

What Art.28 Requires

Under GDPR Article 28, any organisation that processes personal data on behalf of a data controller must do so under a written contract — the Data Processing Agreement. The DPA must include:

Art.28(3) mandatory clauses:

Art.28(1) due diligence gate: Controllers must "use only processors providing sufficient guarantees to implement appropriate technical and organisational measures." This is an ongoing verification requirement — a one-time DPA signature does not satisfy it.

The Art.32 Link

Art.28 and Art.32 are structurally linked. Art.28(3)(c) requires processors to implement measures "pursuant to Article 32." Art.32 itself requires a risk-based assessment taking into account the state of the art, implementation costs, and the nature of the risks — including:

This is where the first overlap with NIS2 begins: NIS2 Art.21's ten mandatory measures cover substantially the same ground, but in the context of network and information systems security rather than personal data protection specifically.

2. NIS2 Art.21(2)(d): Supply Chain Security

What Art.21(2)(d) Requires

NIS2 Directive Art.21 requires essential and important entities to implement "appropriate and proportionate technical, operational and organisational measures" to manage cybersecurity risks. Art.21(2)(d) specifically mandates:

"supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers"

This provision has three practical implications for SaaS teams:

1. Every supplier is in scope. NIS2 Art.21(2)(d) does not limit supply chain security obligations to IT suppliers or "critical" suppliers. If an essential entity uses your SaaS product — even for non-core business processes — you are in their supply chain and subject to their Art.21(2)(d) scrutiny.

2. Security must be contractually anchored. ENISA guidance and national transpositions (BSI in Germany, NCSC in the Netherlands, BSA in Austria) are consistent: Art.21(2)(d) requires contractual security obligations in supplier agreements, not just informal assessments.

3. NCAs audit the supply chain. Under NIS2 Art.32 (proactive supervision of essential entities), NCAs can request evidence of supply chain security assessments. If your customer cannot produce documentation showing they assessed your security posture, they are exposed — and in turn, so is your commercial relationship.

The Art.21(2)(d) Contractual Minimum

Based on ENISA's "Guidelines on Supply Chain Security for NIS2" and national transpositions, the Art.21(2)(d) contractual minimum for suppliers includes:

RequirementDetail
Security obligationsSupplier must maintain specific security controls (encryption, access control, patch management)
Incident notificationSupplier must notify customer of incidents affecting the service within defined timeframe
Audit rightsCustomer may audit supplier security posture (or require third-party certification)
Sub-supplier disclosureSupplier must disclose and manage fourth-party risk
Business continuitySupplier must demonstrate continuity and recovery capabilities
Security updatesSupplier must maintain supported, patched software stack

3. Where GDPR Art.28 and NIS2 Art.21(2)(d) Overlap

The Venn diagram is significant. Both frameworks require:

Shared requirements:

Divergent requirements (Art.28 only):

Divergent requirements (NIS2 Art.21(2)(d) only):

The Compliance Gap Most Teams Miss

The gap that creates real risk is this: a GDPR-compliant DPA does not satisfy NIS2 Art.21(2)(d) obligations, and vice versa.

Your customer's DPO may have signed off on your DPA. But their CISO — now responsible for NIS2 Art.21(2)(d) compliance ahead of June 2026 NCA audits — needs different evidence. Specifically:

  1. Security questionnaire responses covering NIS2's ten mandatory measures
  2. Certification or audit evidence (ISO 27001, SOC 2 Type II, or equivalent)
  3. Incident response SLA anchored to NIS2 Art.23's 24-hour early warning timescale
  4. Sub-processor/fourth-party disclosure aligned with NIS2 supply chain mapping requirements
  5. Business continuity documentation showing RTO/RPO for your service

If your DPA covers items 1 and 2 in a generic GDPR Art.32 context, you are halfway there. But the NIS2 framing requires specificity your typical DPA does not provide.

4. Practical Implications for SaaS Providers

Scenario A: You process data for a hospital (essential entity)

Your customer is an essential entity under NIS2 Annex I (healthcare). They have both:

What they will ask you for (from June 2026):

If you cannot produce these, they may need to terminate the relationship or accept NCA audit exposure.

Scenario B: You process data for a fintech (important entity)

Important entities under NIS2 Annex II (digital infrastructure, financial market infrastructure) face Art.33 supervision rather than Art.32 — reactive rather than proactive audits. But Art.21(2)(d) still applies.

In practice, DORA (Regulation 2022/2554) for financial entities imposes stricter supply chain requirements than NIS2 for this sector. If your customer is subject to DORA, you fall under their ICT third-party risk management framework (DORA Art.28) rather than NIS2 supply chain provisions — a separate compliance track covered in our DORA+CRA Fintech Dual Compliance guide.

Scenario C: You are a SaaS-as-sub-processor (fourth party)

If your customer is themselves a data processor (a B2B SaaS company), you are a sub-processor under GDPR Art.28(2) and a fourth party under their customer's NIS2 supply chain. The downstream essential entity has Art.21(2)(d) obligations that cascade through your customer to you.

This is the fourth-party risk problem: an essential entity's NCA audit may surface your service as an unvetted fourth party even if you have no direct relationship with that entity. Your immediate customer — the data processor — needs to have documented your security posture to satisfy their own customer's NIS2 obligations.

5. What Your DPA Needs to Cover for NIS2 Compatibility

A NIS2-compatible DPA (or a DPA + NIS2 addendum) should address:

NIS2 Art.21 Security Measures (Art.28(3)(c) extension)

The DPA's security measures clause should reference or incorporate the ten NIS2 Art.21(2) mandatory measures:

(a) Risk analysis and information system security policies
(b) Incident handling (prevention, detection, and recovery)
(c) Business continuity — backup management, disaster recovery, crisis management
(d) Supply chain security (sub-processors)
(e) Security in acquisition, development, and maintenance of network and information systems
(f) Policies and procedures to assess the effectiveness of security measures
(g) Basic cyber hygiene practices and cybersecurity training
(h) Cryptography policies and encryption
(i) Human resources security, access control, and asset management
(j) Use of multi-factor or continuous authentication

A generic Art.32 "appropriate technical and organisational measures" clause does not satisfy this — it lacks the specificity NCAs will look for in Art.21(2)(d) evidence.

Incident Notification Alignment

Your DPA's incident notification clause must align with NIS2 Art.23 timescales:

Standard DPA breach notification clauses cite GDPR Art.33's 72-hour window to the supervisory authority. This is not the same as NIS2's 24-hour early warning requirement. Your DPA needs both.

Audit Rights Specificity

Art.28(3)(h) gives controllers audit rights. For NIS2 Art.21(2)(d) purposes, the audit mechanism needs to be explicit:

6. Python: GDPRNis2DataProcessorAssessor

This tool maps your current DPA clauses against the dual compliance requirements and identifies gaps:

from dataclasses import dataclass, field
from typing import List, Dict, Optional
from enum import Enum

class ComplianceStatus(Enum):
    COVERED = "covered"
    PARTIAL = "partial"
    MISSING = "missing"

@dataclass
class DPAClause:
    name: str
    gdpr_article: str
    nis2_article: Optional[str]
    status: ComplianceStatus
    gap_description: Optional[str] = None

@dataclass
class AssessmentResult:
    total_clauses: int
    covered: int
    partial: int
    missing: int
    critical_gaps: List[str]
    nis2_specific_gaps: List[str]
    gdpr_specific_gaps: List[str]
    risk_level: str

class GDPRNis2DataProcessorAssessor:
    """
    Assesses a SaaS provider's DPA coverage against dual
    GDPR Art.28 + NIS2 Art.21(2)(d) compliance requirements.
    """
    
    GDPR_ART28_CLAUSES = [
        "process_on_instructions",       # Art.28(3)(a)
        "confidentiality_obligation",    # Art.28(3)(b)
        "security_measures",             # Art.28(3)(c) → links Art.32
        "sub_processor_authorisation",   # Art.28(3)(d)
        "data_subject_rights_assist",    # Art.28(3)(e)
        "security_incident_assist",      # Art.28(3)(f)
        "deletion_return_on_end",        # Art.28(3)(g)
        "audit_rights",                  # Art.28(3)(h)
    ]
    
    NIS2_ART21_MEASURES = [
        "risk_analysis_policy",          # Art.21(2)(a)
        "incident_handling",             # Art.21(2)(b)
        "business_continuity",           # Art.21(2)(c)
        "supply_chain_security",         # Art.21(2)(d)
        "secure_dev_acquisition",        # Art.21(2)(e)
        "security_effectiveness",        # Art.21(2)(f)
        "cyber_hygiene_training",        # Art.21(2)(g)
        "cryptography_encryption",       # Art.21(2)(h)
        "access_control_hr_security",    # Art.21(2)(i)
        "mfa_continuous_auth",           # Art.21(2)(j)
    ]
    
    NIS2_INCIDENT_TIMELINES = {
        "early_warning_hours": 24,
        "notification_hours": 72,
        "final_report_days": 30,
    }
    
    def __init__(self, entity_type: str = "essential"):
        """
        entity_type: 'essential' (Art.32 proactive supervision) or
                     'important' (Art.33 reactive supervision)
        """
        self.entity_type = entity_type
        self.clauses: List[DPAClause] = []
    
    def add_clause(
        self,
        name: str,
        gdpr_article: str,
        nis2_article: Optional[str],
        status: ComplianceStatus,
        gap_description: Optional[str] = None
    ):
        self.clauses.append(DPAClause(
            name=name,
            gdpr_article=gdpr_article,
            nis2_article=nis2_article,
            status=status,
            gap_description=gap_description,
        ))
    
    def assess(self) -> AssessmentResult:
        covered = sum(1 for c in self.clauses if c.status == ComplianceStatus.COVERED)
        partial = sum(1 for c in self.clauses if c.status == ComplianceStatus.PARTIAL)
        missing = sum(1 for c in self.clauses if c.status == ComplianceStatus.MISSING)
        
        critical_gaps = [
            c.gap_description for c in self.clauses
            if c.status in (ComplianceStatus.MISSING, ComplianceStatus.PARTIAL)
            and c.gap_description
        ]
        
        nis2_specific_gaps = [
            c.name for c in self.clauses
            if c.nis2_article and c.status != ComplianceStatus.COVERED
        ]
        
        gdpr_specific_gaps = [
            c.name for c in self.clauses
            if not c.nis2_article and c.status != ComplianceStatus.COVERED
        ]
        
        # Risk level based on entity type and missing clause count
        if self.entity_type == "essential":
            if missing >= 4:
                risk_level = "HIGH — NCA audit exposure June 2026"
            elif missing >= 2 or partial >= 4:
                risk_level = "MEDIUM — Gaps may surface in Art.32 audit"
            else:
                risk_level = "LOW — Primary gaps are documentary, not structural"
        else:
            if missing >= 5:
                risk_level = "MEDIUM — Reactive supervision gap"
            else:
                risk_level = "LOW — Important entity (Art.33): reactive audit only"
        
        return AssessmentResult(
            total_clauses=len(self.clauses),
            covered=covered,
            partial=partial,
            missing=missing,
            critical_gaps=critical_gaps,
            nis2_specific_gaps=nis2_specific_gaps,
            gdpr_specific_gaps=gdpr_specific_gaps,
            risk_level=risk_level,
        )
    
    def check_incident_notification_alignment(
        self,
        dpa_notification_hours: int,
        includes_nis2_early_warning: bool,
        includes_nis2_final_report: bool,
    ) -> Dict[str, bool]:
        """Check if DPA incident notification aligns with NIS2 Art.23 timelines."""
        return {
            "gdpr_72h_window": dpa_notification_hours <= 72,
            "nis2_24h_early_warning": includes_nis2_early_warning,
            "nis2_72h_notification": dpa_notification_hours <= 72,
            "nis2_30day_final_report": includes_nis2_final_report,
            "gap_24h_early_warning": not includes_nis2_early_warning,
            "recommendation": (
                "Add NIS2 Art.23 early warning clause (24h) to DPA Art.28(3)(f)"
                if not includes_nis2_early_warning
                else "Incident notification clauses aligned"
            ),
        }


# Example usage — assessing a SaaS CRM DPA
assessor = GDPRNis2DataProcessorAssessor(entity_type="essential")

# GDPR-only clauses
assessor.add_clause(
    "process_on_instructions",
    "Art.28(3)(a)", None, ComplianceStatus.COVERED
)
assessor.add_clause(
    "data_subject_rights_assist",
    "Art.28(3)(e)", None, ComplianceStatus.COVERED
)
assessor.add_clause(
    "deletion_return_on_end",
    "Art.28(3)(g)", None, ComplianceStatus.COVERED
)

# Shared clauses — coverage may be partial
assessor.add_clause(
    "security_measures_art32",
    "Art.28(3)(c) / Art.32", "Art.21(2)(a)-(j)",
    ComplianceStatus.PARTIAL,
    "Generic TOMs clause — does not enumerate NIS2 Art.21(2) ten measures explicitly"
)
assessor.add_clause(
    "incident_notification",
    "Art.28(3)(f)", "Art.21(2)(b) / Art.23",
    ComplianceStatus.PARTIAL,
    "72h GDPR window only — missing NIS2 24h early warning obligation"
)
assessor.add_clause(
    "audit_rights",
    "Art.28(3)(h)", "Art.32 / Art.21(2)(f)",
    ComplianceStatus.PARTIAL,
    "Audit right exists but scope does not cover NIS2 ten measures or accept ISO 27001"
)
assessor.add_clause(
    "sub_processor_authorisation",
    "Art.28(3)(d)", "Art.21(2)(d)",
    ComplianceStatus.PARTIAL,
    "Sub-processor list exists but NIS2 security assessment of sub-processors not documented"
)

# NIS2-specific gaps
assessor.add_clause(
    "business_continuity",
    "Art.28(3)(c)", "Art.21(2)(c)",
    ComplianceStatus.MISSING,
    "RTO/RPO not specified in DPA — required for NIS2 Art.21(2)(d) supply chain evidence"
)
assessor.add_clause(
    "mfa_continuous_auth",
    "Art.28(3)(c)", "Art.21(2)(j)",
    ComplianceStatus.MISSING,
    "No contractual MFA obligation — NIS2 Art.21(2)(j) requires explicit commitment"
)

result = assessor.assess()
print(f"Total clauses: {result.total_clauses}")
print(f"Covered: {result.covered} / Partial: {result.partial} / Missing: {result.missing}")
print(f"Risk level: {result.risk_level}")
print(f"\nNIS2-specific gaps: {result.nis2_specific_gaps}")
print(f"\nCritical gaps:")
for gap in result.critical_gaps:
    print(f"  - {gap}")

# Check incident notification alignment
incident_check = assessor.check_incident_notification_alignment(
    dpa_notification_hours=72,
    includes_nis2_early_warning=False,
    includes_nis2_final_report=False,
)
print(f"\nIncident notification: {incident_check['recommendation']}")

7. 20-Item Dual Compliance Checklist

For SaaS Providers (Processors)

GDPR Art.28 Foundation

NIS2 Art.21 Security Measures Extension

Dual Coverage: DPA + NIS2 Addendum

June 2026 NCA Audit Readiness

8. The CLOUD Act Complication

Both GDPR Art.28 and NIS2 Art.21(2)(d) are complicated when US-domiciled sub-processors are in the supply chain. Under GDPR, US transfers require SCCs or an adequacy decision. Under NIS2, the concern is different: a US parent or sub-processor subject to the CLOUD Act may be compelled to produce data or grant access without the essential entity's knowledge.

For essential entities with Art.21(2)(d) obligations, this creates a supply chain jurisdictional risk that standard DPA SCCs do not address. ENISA guidance and several national NCAs have begun requiring explicit disclosure when a supplier or sub-supplier is subject to non-EU legal access orders.

If your infrastructure runs on AWS, Azure, or GCP, your customers who are essential entities need contractual disclosure of this risk. This is separate from your GDPR transfer mechanism — it is a NIS2 supply chain transparency obligation.

Our EU Region vs. EU Jurisdiction guide covers this gap in detail. Our NIS2+CLOUD Act Supply Chain guide maps the exact contractual clauses essential entities should require from CLOUD Act-exposed suppliers.

9. Practical Path Forward

If you are a SaaS provider (processor):

Short-term (before June 2026 NCA audit cycle):

  1. Audit your existing DPAs: do any customers qualify as essential or important entities under NIS2?
  2. Prepare a NIS2 security questionnaire package (ISO 27001 cert or SOC 2 + answers to NIS2 Art.21(2) measures)
  3. Add a NIS2 Art.21(2)(d) addendum to your standard DPA — or update your DPA template

Medium-term: 4. Align your incident notification SLA to include a NIS2 24h early warning tier 5. Document RTO/RPO commitments per service tier and make them contractually available 6. Audit your sub-processors for CLOUD Act exposure and prepare disclosure language

If you are an essential/important entity (controller):

Short-term:

  1. Map all GDPR Art.28 processors who are also NIS2 Art.21(2)(d) suppliers
  2. Issue NIS2 security questionnaires to those suppliers and request evidence
  3. Update your DPA template to include NIS2 Art.21(2)(d) clauses

For June 2026 NCA audit readiness: 4. Produce a supply chain security evidence package for your top 10 suppliers 5. Identify any CLOUD Act-exposed suppliers and document the risk assessment 6. Confirm incident notification SLAs are NIS2 Art.23-aligned (24h early warning)

Summary

Every cloud SaaS provider processing personal data for essential or important entities sits at the intersection of two overlapping but legally distinct compliance frameworks. GDPR Art.28 governs the data — what can be done with it, how it is protected, and who it can be shared with. NIS2 Art.21(2)(d) governs the security posture — how robust the technical and organisational measures are at the supply chain level.

The compliance gap is structural: a standard DPA satisfies Art.28 but leaves NIS2 Art.21(2)(d) requirements unaddressed. With NCA supervisory cycles ramping up from June 2026, essential entities will start asking suppliers for evidence that was not part of the GDPR compliance workflow. Getting ahead of that request — by extending your DPA template with NIS2-specific clauses and preparing a security evidence package — is a relatively low-effort step that eliminates a meaningful commercial risk.

sota.io processes customer deployment data under GDPR Art.28 and is subject to NIS2 Art.21(2)(d) as a software supplier. Our infrastructure is EU-native with no CLOUD Act exposure, and our DPA includes NIS2-aligned incident notification timelines and explicit Art.21(2) measure commitments. See our security posture documentation.

See Also