Compliance used to be something you proved once a year to an auditor and then forgot. In 2026, three overlapping European regulations have turned it into a continuous engineering obligation with personal liability attached. Operational resilience — the demonstrable ability to keep critical services running, recover fast, and account for every dependency when something breaks — is now the organizing principle behind the Network and Information Security Directive 2 (NIS2), the Digital Operational Resilience Act (DORA), and the Cyber Resilience Act (CRA). Together they move the burden of proof from your suppliers onto you, and from an annual checkbox to an always-on capability.
For teams running on cloud, this changes the design conversation. It is no longer enough to be secure; you must be able to prove resilience, report incidents on tight clocks, inventory and govern every third party in your supply chain, and — under the CRA — ship products that stay secure across their whole lifecycle. This article maps the three regimes, shows where they intersect with multi-cloud resilience and FinOps discipline, and explains what all of it means for engineering teams in Tunisia and North Africa who build for, and increasingly are considered part of, the European regulated supply chain.
Three regulations, one theme: accountability moves to you
The three regimes target different scopes but share a spine.
- ▸NIS2 raises the security baseline for essential and important entities across many sectors, with management-body liability and strict incident timelines.
- ▸DORA governs financial entities and, crucially, their ICT providers, mandating operational-resilience testing and deep third-party risk management.
- ▸CRA governs products with digital elements placed on the EU market, making security a lifecycle obligation enforced by CE marking.
Read together, they encode one message: you are accountable for your dependencies, you must prove resilience rather than assert it, and you must report fast when things go wrong.
NIS2: the security baseline expands
The NIS2 directive replaced the original 2016 regime and widened both scope and teeth. The transposition deadline passed in October 2024, and through 2026 national enforcement is ramping up.
- ▸Wider scope: many more sectors and mid-sized companies now qualify as essential or important entities, pulling supply-chain vendors into scope they never expected.
- ▸Management liability: boards and senior managers can be held personally responsible for cybersecurity governance failures, which is why this is now a leadership topic and not just an IT one.
- ▸Tight incident reporting: an early warning within 24 hours of awareness, a fuller notification within 72 hours, and a final report within one month.
- ▸Supply-chain security: entities must assess and manage the security of their suppliers, which pushes requirements down to subcontractors, including nearshore development partners.
DORA: operational resilience for finance and its suppliers
DORA applies from January 2025 and is the most prescriptive of the three. It targets banks, insurers, payment firms, and the ICT providers that serve them, structured around five pillars.
- ▸ICT risk management: a documented framework aligned with recognized standards, not ad hoc controls.
- ▸Incident reporting: harmonized classification and reporting of major ICT-related incidents to regulators.
- ▸Digital operational resilience testing: regular testing, escalating to threat-led penetration testing modeled on the TIBER-EU framework for the most significant entities.
- ▸Third-party risk: a maintained register of information covering every ICT contract, mandatory contractual clauses, audit rights, concentration-risk analysis, and documented exit strategies. Critical ICT third-party providers face direct oversight by the European supervisory authorities.
- ▸Information sharing: encouraged threat-intelligence exchange among financial entities.
The register of information and the exit-strategy requirement are the sleeper obligations: they force firms to know, in structured detail, every cloud and software dependency and to prove they could leave any one of them.
The Cyber Resilience Act: security becomes a product feature
The CRA is the first horizontal law making cybersecurity a mandatory property of products with digital elements — hardware and software — sold in the EU. It entered into force in late 2024, its vulnerability and incident reporting duties begin in September 2026, and its main obligations apply from December 2027.
- ▸Essential requirements: secure by design and by default, no known exploitable vulnerabilities at release, and secure update mechanisms across the support period.
- ▸Vulnerability handling: maintain a coordinated disclosure policy, produce a software bill of materials, and issue timely security updates.
- ▸Reporting duties: actively exploited vulnerabilities and severe incidents must be reported to ENISA and national authorities within tight windows, including a 24-hour early warning.
- ▸CE marking: products must carry the CE mark for cybersecurity conformity, with stricter assessment for important and critical product classes.
For anyone shipping software or connected devices into the EU, the SBOM stops being optional hygiene and becomes a legal artifact. Open formats such as SPDX and CycloneDX are how you produce it at scale.
Where FinOps and multi-cloud resilience meet compliance
Resilience regulation and cost discipline are usually treated as separate conversations. Under DORA in particular they converge.
- ▸Exit strategies have a price tag: proving you can leave a provider means understanding egress costs, data-transfer paths, and re-platforming effort. That is a FinOps analysis as much as an architecture one.
- ▸Concentration risk favors portability: over-dependence on a single provider is now a documented regulatory risk, which pushes teams toward portable foundations — containers, open formats, and infrastructure-as-code — rather than deep proprietary lock-in.
- ▸Resilience is not free redundancy: active-active across regions or providers raises both resilience and spend. FinOps practice, including the FOCUS cost specification, gives you the unit-economics view to decide where multi-cloud is worth it and where a strong single-region design with tested recovery is enough.
- ▸Tag for accountability: consistent resource tagging is what lets you tie spend, ownership, and criticality together — the same metadata that feeds your register of information.
A compliance readiness checklist
Sequence the work rather than attempting everything at once.
1. Scope yourself honestly: determine which of NIS2, DORA, and CRA apply to you and to your customers, because supply-chain flow-down may pull you in indirectly. 2. Build the dependency register: inventory every ICT provider, cloud service, and critical software component, with owners and criticality. 3. Fix incident response to the clock: rehearse the 24-hour, 72-hour, and one-month reporting cadence with named responsibilities and templates. 4. Generate SBOMs in CI: automate SPDX or CycloneDX output for every build and store it as a first-class artifact. 5. Test resilience for real: run recovery exercises and, where required, threat-led penetration testing aligned with TIBER-EU. 6. Write and validate exit plans: document how you would migrate off each critical provider, and cost it. 7. Assemble audit evidence continuously: keep policies, test results, registers, and reports in a state where an examiner sees retrieval, not scramble.
The North Africa angle, Monday actions, and the outlook
For Tunisian and North African firms, these regulations are not distant European affairs — they are the terms of doing business with Europe. A Tunis-based company that develops or hosts for an EU bank is, under DORA, an ICT third-party provider: expect contractual audit rights, inclusion in a client register of information, subcontracting limits, and exit-plan cooperation. A regional product company selling connected devices or software into the EU must meet the CRA, complete with SBOMs and CE conformity. And any supplier to a NIS2 entity will feel the supply-chain security requirements flow downhill. The firms that treat this as a capability — documented controls, ISO 27001 alignment, SBOM automation, and rehearsed incident reporting — convert compliance from a barrier into a reason European clients pick them over higher-cost onshore alternatives.
What to do Monday: pick one EU client relationship and ask a blunt question — if a regulator asked us to produce our dependency register and last resilience test for this account, could we, today? The gap you find is your roadmap. Looking forward, expect these regimes to converge in practice as shared tooling emerges around SBOMs, continuous control monitoring, and machine-readable evidence, and expect post-quantum readiness and AI-system governance to be the next obligations layered on top. The organizations that build resilience as an engineering habit now — in Tallinn, Nicosia, or Tunis alike — will spend the rest of the decade competing on trust while everyone else is still filling in forms.