The European Compliance Playbook

Most European companies meet NIS2, the AI Act, ISO 27001 and GDPR as four separate projects — four owners, four spreadsheets, four audits. The work overlaps far more than it differs. Treated as one program, the same evidence answers most of every framework, and the marginal cost of each new regime collapses.

The instinct, when a new regulation lands, is to spin up a new workstream: a fresh policy set, a new tracker, another consultant. It feels safe and defensible. In practice it multiplies effort, because the underlying questions — who has access, how is data protected, what happens when something breaks, can you prove it — are the same questions every framework asks, in slightly different language. This guide lays out how to run them as a single program: one control environment, one evidence layer, one rhythm of work that several regulators can each inspect.

It is written for the person who owns this in practice — a founder, a head of security, a compliance lead, a dedicated CISO — who has to deliver the outcomes without quadrupling the headcount. None of it is legal advice; it is an operating model.

Why run it as one program

Each regime is written by different people for different reasons, but they converge on a small set of operational truths: know what you hold, control who can touch it, detect when something goes wrong, recover quickly, and be able to prove all of the above on demand. Build that operating core once and each framework becomes a mapping exercise — connecting what you already do to the clauses that ask for it — rather than a fresh build from zero.

The benefits compound the more regimes you are subject to:

• Less duplicated effort. One access review satisfies ISO 27001, SOC 2 and the security expectations of NIS2 at the same time. One encryption standard answers several clauses across all four.
• Fewer contradictions. Separate programs drift apart and start telling auditors different stories. A single source of truth keeps your answers consistent across every review.
• Faster onboarding of the next regime. DORA, the Cyber Resilience Act and whatever follows reuse the same foundations — you extend the map rather than start over.
• A clearer view of real risk. When everything points at one control set, gaps are obvious. Fragmented programs hide risk in the seams between them.

The shift is as much cultural as technical. A single program needs a single owner, a shared vocabulary, and a habit of asking “which controls does this touch?” whenever the business changes — a new system, a new market, a new supplier. Get that habit right and compliance stops being a periodic emergency and becomes background hum.

Where the rules overlap

Before mapping anything, it helps to see how much common ground exists. Access control, asset inventory, incident response, risk assessment, change management, encryption, logging and vendor management appear — under different names — in nearly every framework. The differences are mostly scope, emphasis and the paperwork each regulator expects to see.

The shared core

Most of the day-to-day work is shared infrastructure: identity and access, logging and monitoring, change management, data handling, business continuity and a tested incident process. Build these once, to a good standard, and you have answered the bulk of all four regimes. The framework-specific obligations — the remaining slice — are where your real, regime-by-regime attention belongs.

The framework-specific slice

Each regime adds a handful of things the others do not:

• NIS2 adds the incident-reporting clock, supply-chain security duties, and explicit management accountability.
• AI Act adds risk classification of AI systems, technical documentation, human oversight and post-market monitoring.
• ISO 27001 adds the formal ISMS, a risk methodology, and the Statement of Applicability.
• GDPR adds lawful basis, records of processing, data-subject rights and DPIAs for high-risk processing.

Notice that none of these specifics replaces the shared core — they sit on top of it. That is the whole reason the single-program approach works: you do the heavy lifting once and decorate it per regime.

The four regimes, in one breath

A quick orientation, so the rest of the guide has somewhere to hang. Each of these has its own field guide in the Academy; here is the one-paragraph version.

NIS2

The EU’s cybersecurity directive for essential and important entities across critical sectors. It expects risk-based security measures, a fast incident-reporting process (early warning within 24 hours), supply-chain security, and accountability at board level — with personal liability on the table. If you are in scope, your incident process and your governance both need to be demonstrably real.

EU AI Act

Regulates AI by risk, not by technology. Systems are sorted into unacceptable, high, limited and minimal risk, and the obligations — documentation, oversight, data governance, monitoring — scale with the tier. Deployers of high-risk systems carry duties too, not just the labs that train models.

ISO 27001

The international standard for an information security management system. It is certifiable and process-heavy: a defined scope, a risk methodology, a Statement of Applicability justifying every control, and a cycle of internal audits, management reviews and continual improvement.

GDPR

The data-protection regulation underpinning all of this. It demands a lawful basis for processing personal data, a current record of processing activities, respect for data-subject rights, and impact assessments where processing is high-risk. Much of its security expectation overlaps with the others; its rights and lawfulness obligations are unique.

Step 1 — Build one control library

Start from a single control library — not from the framework texts. List what you actually do to protect the business, then map each control outward to the clauses it satisfies. This inversion is the whole trick: controls are stable, framework text is not. A control like “all production access requires SSO and MFA” answers parts of ISO 27001, SOC 2, NIS2 and GDPR at once, and it will still be true when the next regulation arrives.

1. Inventory the controls already running across your stack and your policies — technical and organisational.
2. Tag each control with the frameworks and clauses it answers, so one control carries several references.
3. Find the gaps — clauses with no control behind them — and close those, and only those.
4. Attach the evidence that proves each control is operating, not just written down.

Resist the temptation to write a control per clause. You will end up with hundreds of near-duplicates that all need maintaining. A tight library of real controls, each mapped to many clauses, is far easier to run and far more honest about how your organisation actually works.

Step 2 — Build a single evidence layer

Evidence is where parallel programs hemorrhage time. The same screenshot, log export or approval record gets collected three times for three audits, each in its own folder, each going stale at its own pace. Collect it once, into one layer, tag it with every framework it supports, and let each review draw from the same well.

Pull evidence automatically wherever you can — from cloud, identity, code, HR and ticketing — so it is timestamped, continuous and not dependent on someone remembering to take a screenshot the week before an audit. Manual evidence is acceptable where automation is impossible, but it should be the exception, captured on a schedule rather than in a panic. Regwolf does this collection in the background, which is the entire point of compliance on autopilot.

Good evidence shares three properties: it is timestamped (you can show when the control was operating), attributable (you know which system and which control it proves), and fresh (it reflects reality now, not last year). Anything that fails those tests is a finding waiting to happen.

Step 3 — Give every control an owner and a cadence

A control with no owner is a control that quietly stops working. Assign each one to a named person, give it a cadence — continuous, monthly, quarterly — and surface drift the moment a control falls out of state, rather than discovering it the week before a surveillance audit.

Cadence matters as much as ownership. Some controls are continuous by nature (MFA enforced, logging enabled) and should be monitored automatically. Others are periodic (access reviews, supplier reassessments, policy approvals) and need a calendar with reminders and a record that they happened on time. The difference between a calm audit and a frantic one is almost always whether the periodic controls ran on schedule, with evidence, throughout the year.

Step 4 — Let one risk assessment feed everything

Every regime wants a risk assessment, and they want broadly compatible things: identify what could go wrong, judge how likely and how damaging it is, decide what to do about it, and record the reasoning. Run one risk process and feed its output into each framework’s specific format — the ISO Statement of Applicability, the AI Act risk classification, the GDPR DPIA, the NIS2 risk measures.

Keep the methodology simple and consistent: a clear scale, named risk owners, and a treatment decision (accept, mitigate, transfer, avoid) for each significant risk. What auditors and regulators reward is not mathematical precision but visible, honest reasoning that ties your controls back to real risks. A single living risk register, reviewed when the business changes, beats four static spreadsheets every time.

Step 5 — Handle incidents once

Several regimes care about incidents, with different clocks and thresholds: NIS2’s 24-hour early warning, GDPR’s 72-hour breach notification, and your own contractual commitments to customers. Build one incident-response process that can satisfy all of them, with branches for the specific notifications each triggers.

• A single detection-to-decision path, with a named decision-maker and deputy.
• Pre-agreed severity thresholds, so nobody debates “is this reportable?” mid-incident.
• A contact and channel list for each authority you might owe a notification.
• Templates for the early warning and the breach notification, ready to fill in.
• A timestamped log of detection, decisions and actions — which doubles as evidence afterwards.

Run a tabletop exercise against this process at least annually. An incident plan that has never been tested is a document, not a capability — and regulators can tell the difference.

Step 6 — Manage third-party risk once

Your suppliers are in scope whether you like it or not. NIS2 makes supply-chain security explicit; ISO 27001 expects supplier controls; GDPR requires processor agreements and due diligence. Maintain one vendor register and one due-diligence workflow that captures what each regime needs, rather than three overlapping vendor questionnaires.

For each material vendor, record what data or access they have, the assurance they provide (a certificate, a report, a completed assessment), the contractual terms that matter (a data-processing agreement, security commitments), and a date to reassess. Keep it living: onboarding a new vendor or expanding an existing one should trigger a register update, not an annual catch-up.

Step 7 — Governance and the board

NIS2 puts cybersecurity squarely on the management body: leadership must approve the risk measures, maintain oversight, and can be held personally accountable. The other regimes assume governance too, even where they are less explicit. Treat board engagement as a control in its own right.

In practice that means a standing security and compliance item on the board agenda, periodic posture reporting the board actually reads and understands, and a clean record of what was presented and approved. If a regulator asks, leadership should be able to describe the organisation’s key risks and the measures they signed off — not merely point at a document nobody opened.

A 90-day rollout

You do not boil the ocean. A workable sequence, assuming you are starting roughly from scratch:

1. Days 1–30 — Scope and assess. Confirm which regimes apply, define the scope, run a gap assessment against a single control library, and stand up the evidence layer by connecting your core systems.
2. Days 31–60 — Close the gaps. Prioritise by risk, fix the highest-impact gaps first, assign every control an owner and a cadence, and draft the framework-specific artefacts (SoA, RoPA, AI risk classifications) from the shared base.
3. Days 61–90 — Operate and prove. Switch on continuous monitoring, run a first internal review and an incident tabletop, and produce a board report. By day 90 you should be running the program, not building it.

The point of the timeline is momentum, not perfection. A program that is live and improving beats a perfect plan that never ships.

Common pitfalls

• One program per regulator. The single most expensive mistake — it guarantees duplicated work and contradictory answers.
• Policies without proof. Writing the document and never evidencing that it is enforced.
• Last-minute evidence. Reconstructing a year of access reviews the week before an audit. It shows.
• Ownerless controls. Controls that belong to “the team” belong to no one and quietly lapse.
• A frozen risk register. If it has not changed since last year, it is not describing your business.
• Treating governance as optional. Under NIS2 especially, board sign-off is not a nicety — it is a duty with teeth.

Stay continuously audit-ready

The goal is to make audits boring. When controls are mapped, owned and continuously evidenced, an audit becomes an export and a conversation — not a six-week scramble. Invite your auditor into a live, scoped view and let them see the state of the program directly, sampling evidence that is already there.

Continuous readiness also changes your posture with customers and regulators. A trust center and live evidence turn enterprise security reviews from a sales blocker into a quick yes, and turn a regulator’s questions into a same-day answer. That is the real dividend of running one program well: compliance stops costing you deals and starts protecting them.

Want the practical version for your stack? Book a 30-minute demo and we will map your first framework live on the call.

This article is general guidance, not legal advice. Verify obligations and deadlines for your organisation with qualified counsel.