The NIS2 Tech Stack Checklist for 2026

Each item below is grouped into one of five operational domains. For every checklist item you will find:

• **What NIS2 expects** — the requirement translated into plain, operational language. • **What typically goes wrong** — the failure pattern we see most often in mid-market and enterprise environments. • **What evidence an auditor would expect** — the documentation, logs, or configuration proof that demonstrates compliance.

This is not a legal interpretation of NIS2. It is a practical translation for infrastructure and security teams who need to act, not just understand.

**1.1 Enforce multi-factor authentication on all privileged accounts**

What NIS2 expects: Article 21(2)(j) requires "the use of multi-factor authentication or continuous authentication solutions" for access to critical systems. In practice, this means MFA on every account with administrative or elevated privileges — no exceptions.

What typically goes wrong: Service accounts and break-glass accounts are left without MFA. Legacy systems that "don't support MFA" are granted exemptions that are never revisited. MFA is enabled on the identity provider but not enforced — users can skip enrolment.

What evidence an auditor would expect: IdP configuration export showing MFA enforcement policies. A register of any MFA exemptions with documented risk acceptance and compensating controls. Audit logs showing MFA challenges on privileged access events.

**1.2 Implement role-based access control with least-privilege enforcement**

What NIS2 expects: Access to network and information systems must be limited to what is necessary for the user's role. This requires documented role definitions and regular access reviews.

What typically goes wrong: Roles are created but never pruned — users accumulate permissions as they change teams. "Admin" is used as a catch-all role. Access reviews are conducted annually but not acted upon. Shared credentials exist for legacy systems.

What evidence an auditor would expect: RBAC policy documentation mapping roles to permissions. Quarterly access review records with evidence of revocations. Audit trail of privilege escalation events. List of shared or generic accounts with justification.

**1.3 Automate user lifecycle management (joiners, movers, leavers)**

What NIS2 expects: Organisations must ensure that access rights are promptly adjusted when personnel change roles or leave the organisation. Manual processes are insufficient at scale.

What typically goes wrong: Offboarding takes days or weeks. Access to SaaS tools outside the IdP (shadow IT) is not revoked. Contractors retain access after engagement ends. No automated deprovisioning is connected to HR systems.

What evidence an auditor would expect: Documented JML (Joiner, Mover, Leaver) process with SLAs. Integration between HR system and identity provider. Logs showing deprovisioning events within the defined SLA. Reconciliation reports comparing active directory accounts to HR records.

**2.1 Maintain a complete, current inventory of all cloud services and infrastructure components**

What NIS2 expects: Article 21(2)(a) requires organisations to conduct risk analysis based on a complete understanding of their information systems. You cannot protect what you have not inventoried.

What typically goes wrong: Shadow IT — teams procure SaaS tools on corporate credit cards without security review. Cloud accounts proliferate across departments. Infrastructure-as-code exists but does not match the actual deployed state. The "inventory" is a spreadsheet last updated six months ago.

What evidence an auditor would expect: Automated asset inventory covering IaaS, PaaS, and SaaS. Evidence of periodic reconciliation against financial records (credit card statements, procurement logs). Configuration management database (CMDB) or equivalent with ownership attribution.

**2.2 Ensure all production workloads run on infrastructure with documented security controls**

What NIS2 expects: Organisations must implement technical measures appropriate to the risk, including securing the infrastructure on which critical services run.

What typically goes wrong: Development and staging environments use production data without equivalent security controls. Container images are pulled from public registries without vulnerability scanning. Infrastructure patching is inconsistent — some systems are months behind. Cloud security posture management (CSPM) tools are deployed but alerts are not actioned.

What evidence an auditor would expect: Patching policy with defined SLAs by severity. Vulnerability scan reports for production infrastructure. Evidence of container image scanning in CI/CD pipelines. CSPM dashboard or equivalent showing compliance posture over time.

**2.3 Implement network segmentation and zero-trust principles**

What NIS2 expects: Network and information systems should be designed to limit the blast radius of security incidents. Flat networks with unrestricted lateral movement are a clear non-compliance indicator.

What typically goes wrong: VPNs provide full network access rather than application-level access. East-west traffic within the network is unmonitored. Microsegmentation is planned but not implemented. Cloud security groups are overly permissive.

What evidence an auditor would expect: Network architecture diagrams showing segmentation boundaries. Firewall and security group rules with documented justification. Evidence of east-west traffic monitoring. Zero-trust architecture assessment or roadmap.

**3.1 Map all data flows to identify where data is stored, processed, and transferred**

What NIS2 expects: Organisations must understand their data flows as part of risk analysis. For essential entities in particular, knowing where data resides and which jurisdictions can compel access is fundamental to resilience planning.

What typically goes wrong: Data flow mapping exists for GDPR personal data but ignores operational data, configuration data, and telemetry. SaaS tools process data in regions the organisation has not explicitly chosen. Backup and disaster recovery data flows are not mapped. Sub-processors change data locations without notification.

What evidence an auditor would expect: Data flow diagrams covering personal, operational, and configuration data. Record of processing activities (ROPA) extended to cover NIS2 scope. Documented data residency selections for all cloud services. Evidence of sub-processor monitoring for location changes.

**3.2 Assess jurisdictional risk of critical technology providers**

What NIS2 expects: NIS2's supply chain security requirements (Article 21(2)(d)) require organisations to assess the security practices of their direct suppliers and service providers — including jurisdictional risk.

What typically goes wrong: Jurisdictional risk is treated as a GDPR-only concern. Organisations use "EU region" deployments of US-headquartered providers and assume sovereignty is addressed. The distinction between data residency and legal jurisdiction is not understood. Risk assessments do not account for the US CLOUD Act or equivalent extraterritorial legislation.

What evidence an auditor would expect: Vendor risk assessments that include jurisdictional analysis. Documentation distinguishing data residency from legal jurisdiction. Risk acceptance records where US-jurisdictioned providers are used for critical functions. Evidence of periodic reassessment as regulatory landscape evolves.

**3.3 Ensure encryption controls align with data classification**

What NIS2 expects: Appropriate cryptographic measures must protect data at rest and in transit. For sensitive data, customer-managed encryption keys provide an additional sovereignty layer.

What typically goes wrong: Default provider-managed encryption is assumed sufficient for all data classifications. Encryption at rest is enabled but key management is delegated entirely to the provider. TLS versions are not enforced — legacy TLS 1.0/1.1 remains active. Certificate management is manual and prone to expiry incidents.

What evidence an auditor would expect: Encryption policy mapping data classifications to encryption requirements. Key management documentation showing who controls encryption keys for each data class. TLS configuration reports showing minimum version enforcement. Certificate inventory with automated renewal evidence.

**4.1 Implement centralised logging with tamper-evident storage**

What NIS2 expects: Article 21(2)(b) requires incident handling capabilities, which depend on comprehensive logging. Logs must be available, reliable, and protected from tampering.

What typically goes wrong: Logging is fragmented across systems with no centralised aggregation. Log retention periods are insufficient for incident investigation (less than 90 days). Logs are stored in the same environment as production systems — an attacker who compromises production can delete logs. Cloud provider audit logs are not exported or monitored.

What evidence an auditor would expect: Centralised log management platform (SIEM or equivalent). Log retention policy with defined periods by log type. Evidence that logs are stored in a separate, tamper-evident environment. Configuration showing cloud provider audit logs (CloudTrail, Azure Activity Log, etc.) are ingested.

**4.2 Establish and test an incident response plan**

What NIS2 expects: Organisations must have incident response procedures and must report significant incidents to the relevant CSIRT within 24 hours (early warning) and 72 hours (full notification). This is stricter than GDPR's breach notification.

What typically goes wrong: Incident response plans exist as documents but have never been tested. The plan references roles that no longer exist or people who have left. Communication channels for incident response depend on the same infrastructure that may be compromised. The 24-hour early warning requirement is not reflected in on-call procedures.

What evidence an auditor would expect: Documented incident response plan with defined roles, escalation paths, and communication procedures. Records of tabletop exercises or simulated incident drills (at least annually). Post-incident review reports from any actual incidents. Evidence that the 24-hour notification SLA is achievable (on-call rosters, out-of-band communication channels).

**4.3 Monitor for anomalous activity with automated detection**

What NIS2 expects: Proactive threat detection is an implicit requirement of NIS2's risk management measures. Waiting for incidents to be reported externally is not compliant.

What typically goes wrong: Detection rules are deployed but never tuned — the team is drowning in false positives. Monitoring covers network perimeter but not cloud workloads, identity systems, or SaaS applications. Detection coverage does not map to known threat frameworks (MITRE ATT&CK). Alert fatigue means critical alerts are missed or deprioritised.

What evidence an auditor would expect: Detection rule inventory mapped to threat categories (e.g., MITRE ATT&CK). False positive rates and tuning records. Mean time to detect (MTTD) and mean time to respond (MTTR) metrics. Evidence of detection coverage across network, endpoint, identity, and cloud layers.

**5.1 Maintain a risk-rated register of all critical vendors and sub-processors**

What NIS2 expects: Supply chain security is a first-class NIS2 obligation. Article 21(2)(d) explicitly requires organisations to address "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers."

What typically goes wrong: Vendor registers exist but are not risk-rated. Sub-processors are not tracked — the organisation knows its direct vendors but not the fourth parties those vendors depend on. Risk ratings are static and not updated when vendors change their infrastructure or ownership. Procurement teams manage vendor relationships without security team input.

What evidence an auditor would expect: Vendor register with risk ratings based on data sensitivity, operational criticality, and jurisdictional exposure. Sub-processor mapping for critical vendors. Evidence of periodic vendor security assessments (questionnaires, SOC 2 reports, penetration test summaries). Documented process for responding to vendor security incidents.

**5.2 Include sovereignty and jurisdiction in vendor risk assessments**

What NIS2 expects: Risk assessments must consider the full threat landscape, including risks arising from jurisdictional exposure and geopolitical dependencies. For essential entities, this is not optional.

What typically goes wrong: Vendor risk assessments focus on technical security controls and ignore jurisdiction. "GDPR compliant" is accepted as sufficient without analysing CLOUD Act exposure. Sovereignty risk is treated as a procurement concern rather than a security concern. No distinction is made between vendors incorporated in the EU and those merely hosting data in EU regions.

What evidence an auditor would expect: Vendor risk assessment template that includes jurisdictional analysis. Documentation of sovereignty risk for critical vendors, distinguishing data residency from legal jurisdiction. Risk acceptance records where sovereignty risk has been acknowledged. Evidence that sovereignty considerations are part of procurement decision criteria.

**5.3 Establish contractual security requirements for critical suppliers**

What NIS2 expects: Organisations should ensure their contracts with critical suppliers include appropriate security requirements, incident notification obligations, and audit rights.

What typically goes wrong: Standard procurement contracts lack security schedules. Incident notification from vendors is not contractually required or has vague timelines. Audit rights are not included or are never exercised. Security requirements reference generic standards without specific, measurable obligations.

What evidence an auditor would expect: Contract templates with security schedules for critical suppliers. Evidence that security requirements are negotiated and agreed, not just template-imposed. Incident notification clauses with defined timelines and communication channels. Records of exercised audit rights or vendor security review meetings.

Manually auditing your tech stack against these five domains is feasible but time-consuming — and the landscape changes as vendors update their infrastructure, change ownership, or modify data processing locations.

SovereigntyScore's Stack Scout automates the jurisdictional and sovereignty dimensions of this checklist. When you run a Stack Scout report, the platform:

• **Maps jurisdictional exposure** — identifies which vendors are incorporated outside the EU and subject to extraterritorial legislation like the US CLOUD Act. • **Assesses data residency** — evaluates whether vendors offer genuine EU data residency or merely EU-region deployments of US-jurisdictioned services. • **Scores sovereignty risk** — provides a 0–100 sovereignty score for each tool in your stack, enabling risk-rated vendor classification. • **Flags regulatory relevance** — highlights which tools in your stack intersect with NIS2, DORA, and GDPR obligations. • **Tracks changes** — as vendor infrastructure evolves, your sovereignty assessment stays current without manual reassessment.

This does not replace a full NIS2 compliance programme. It does automate the most labour-intensive and error-prone component: understanding the sovereignty and jurisdictional profile of every tool in your technology stack.

For the identity, monitoring, and incident response dimensions of this checklist, specialist tooling and organisational processes are required. SovereigntyScore focuses on the data residency, vendor risk, and jurisdictional domains where automated assessment delivers the most value.