EU & UK Cybersecurity Mandates: How Basirah Addresses DORA, NIS2, and UK NCSC CAF Requirements

2024 and 2025 marked the transition of EU and UK cybersecurity regulation from guidance to enforcement. The Digital Operational Resilience Act (DORA), the NIS2 Directive, and the UK NCSC Cyber Assessment Framework (CAF) all carry material enforcement risk, but penalty mechanics differ by legal instrument and jurisdiction. Organizations subject to these regulations need demonstrable, auditable cyber risk execution processes.

Below, we walk through three overlapping EU and UK frameworks and the operational demands they share.

Regulatory note: This is an operational summary, not legal advice. Validate scope, deadlines, and penalty mechanics with counsel and local competent authorities.

Consider a representative case: an EU payment institution with one shared remediation team, two regulators, and overlapping board reporting obligations. The same vulnerability can appear in DORA testing records and NIS2 supervisory reviews, so the main operational risk is fragmented evidence, not lack of policy language.

DORA: Digital Operational Resilience Act

DORA applies to virtually all EU financial entities: banks, insurance companies, investment firms, payment institutions, and their critical ICT third-party providers. It entered full application in January 2025.

Article 9: ICT Risk Management – Patch Deadlines and Escalation

DORA Article 9 requires financial entities to implement patch management procedures with defined timelines and escalation mechanisms. Regulators expect to see:

• Documented SLA windows for patching based on severity and business impact
• Escalation procedures that trigger when deadlines are approaching or breached
• Evidence of SLA enforcement, not just policy documents, but records showing the policy is followed

What changed from previous guidance: DORA requires operational proof that patching timelines are met, not just a policy stating they should be.

Article 6: Risk Assessment Discipline

Article 6 requires a structured ICT risk management framework. Many entities extend that into financial impact modeling for governance and board communication:

• Risk assessments must produce financial estimates, not just qualitative ratings
• Assessments must inform resource allocation and remediation prioritization
• The methodology must be documented and repeatable, not ad hoc

Articles 25-27: Testing and Verification

DORA Articles 25-27 establish requirements for independent testing of ICT systems, including:

• Independent verification that vulnerabilities identified in testing are actually remediated
• Testing documentation that provides an audit trail from finding through resolution
• Regular testing cadence with evidence of continuous improvement

Platform Alignment

Before mapping controls, the practical question is simple: can your team show the full chain from detection to verified closure without rebuilding evidence at quarter end?

DORA Article	Basirah Capability
Art. 9 (patch deadlines + escalation)	SLA enforcement with configurable deadlines, automated escalation, and business-hours-aware tracking. SLA policies configurable per severity band across multiple remediation stages.
Art. 6 (risk assessment discipline)	FAIR-based risk quantification with operational scoring and governance-level simulation, producing financial loss estimates with confidence intervals in EUR. Risk attribution tracks verified risk reduction per Work Item. Scenario analysis models remediation outcomes. Executive dashboard surfaces risk trends for financial reporting.
Art. 25-27 (independent testing verification)	Multiple verification methods including re-scan, API probe, and external audit. Work Item state machine enforces that only a PASS allows transition to CLOSED_RESOLVED. A structured workflow that moves findings through remediation, verification, and evidence generation provides an auditable execution trail.

NIS2 Directive: Network and Information Security

NIS2 expanded the scope of EU cybersecurity regulation well beyond its predecessor. It applies to essential and important entities across 18 sectors, including energy, transport, health, digital infrastructure, ICT service management, public administration, and manufacturing.

Article 21(2)(e): Vulnerability Handling with Operational Proof

NIS2 Article 21(2)(e) specifically requires entities to implement vulnerability handling procedures. The European Commission’s implementing guidance emphasizes:

• Operational proof of vulnerability management, not just scanning, but evidence that discovered vulnerabilities are handled through a defined process
• Documented remediation workflows with assigned responsibility and tracked timelines
• Audit-ready documentation that can be produced on demand for national authorities

Penalties and enforcement

NIS2 penalties are significant and defined in the directive framework:

• Essential entities: up to 10 million EUR or 2% of global annual turnover
• Important entities: up to 7 million EUR or 1.4% of global annual turnover
• Management body liability: personal accountability for senior leadership

Platform Alignment

Basirah’s end-to-end workflow is designed to produce the operational evidence NIS2 expects. The platform distinguishes between Findings (the unit of discovery) and Work Items (the unit of action); Work Items group related findings, carry a structured state machine, assigned ownership, SLA clocks, and exception management. This structured lifecycle can support Article 21(2)(e) vulnerability-handling evidence expectations.

Remediation playbooks with automated execution (Ansible, Terraform, kubectl, custom scripts) handle common vulnerability classes, with approval gating for high-risk production changes and rollback procedures. Dispatch to Jira, ServiceNow, or Linear uses reliable ticket creation with bi-directional sync.

The policy engine supports configurable policy types with exception management: temporary waivers with expiration dates, approval workflows, and justification requirements. Deferrals are documented rather than silent.

Evidence packages include:

• Finding provenance: which scanner, when detected, cross-scanner deduplication, initial severity and risk quantification
• Remediation workflow: assigned owner, SLA deadline, status transitions with timestamps, remediation playbook execution logs
• Verification outcome: verification through re-scan, API probe, or external audit with PASS/FAIL and before/after comparison
• Integrity assurance: signed and hashed evidence packages, custody chain tracking, immutable Work Item timeline snapshots, and configurable retention policies from standard through regulatory and permanent tiers

This is the level of documentation that supports both DORA’s financial-sector specificity and NIS2’s broader operational resilience requirements.

UK NCSC CAF: Cyber Assessment Framework

The UK’s National Cyber Security Centre (NCSC) Cyber Assessment Framework (CAF) applies to operators of essential services under the Network and Information Systems (NIS) Regulations. It is structured around four objectives with fourteen principles.

Principle B4.d: Vulnerability Management Verification

Principle B4.d specifically addresses vulnerability management and includes an indicator of good practice that many organizations overlook:

• Third-party verification of vulnerability posture: the NCSC expects that organizations don’t simply self-report their vulnerability status
• Documented vulnerability management processes with defined responsibilities, timelines, and escalation procedures
• Evidence of continuous improvement in vulnerability management effectiveness over time

Indicators of good practice

The CAF defines “good practice” indicators that NCSC assessors look for:

• Vulnerabilities are triaged and prioritized using a risk-based methodology
• Remediation timelines are defined and tracked, with documented justification for exceptions
• Verification is performed to confirm that remediation actions were effective
• Trends are monitored and reported to senior management

Platform Alignment

Basirah’s verification methods — including re-scan, API probe, attestation, and external audit — align with CAF B4.d indicators that emphasize independent verification and documented effectiveness. Instead of relying on self-reported closure, an independent verification confirms the vulnerability is resolved. The Work Item state machine enforces that only a PASS allows transition to CLOSED_RESOLVED.

Bassistant provides explainable insights with inline citations and evidence references, supporting the CAF’s “indicators of good practice” transparency requirement. When assessors ask why a particular remediation was prioritized, Bassistant can surface the FAIR-based risk justification grounded in platform data.

Risk exception management with approval workflows handles justified deferrals. CAF expects documented justification for any vulnerability that remains open beyond the defined timeline. Basirah’s policy engine supports temporary waivers with expiration dates, approval chains, and justification requirements.

The platform’s trending dashboards and executive reporting provide the continuous improvement evidence that NCSC assessors evaluate. Month-over-month metrics on MTTR, SLA attainment, and verification pass rates demonstrate not just compliance but operational maturity. The multi-framework overlap lens shows how CAF B4.d controls map to other frameworks the organization may also need (ISO 27001, SOC 2, NIS2), reducing duplicated compliance effort.

The cross-border challenge

The difficulty here is not that any single framework is unmanageable. It is that DORA, NIS2, and the NCSC CAF overlap in intent but diverge in jurisdiction, enforcement body, and evidence format. A payment institution headquartered in Dublin, regulated under DORA by the Central Bank of Ireland, subject to NIS2 via the national competent authority, and providing services into the UK under CAF scrutiny, faces three sets of auditors asking variations of the same question with different documentation expectations.

Basirah’s cross-framework mapping means one remediation workflow can generate evidence packages with framework-specific control references for each regulator. For financial entities already managing PSD2, GDPR, and sector-specific requirements, reducing that duplication is not a convenience — it is an operational prerequisite.

---

Need an implementation blueprint for DORA, NIS2, and UK NCSC CAF evidence flows? Schedule a working session.