The Compliance Wheel: Quadrant 2, Policy & Procedures

The spokes of the wheel

From governance to workable controls

In the previous blog, we fixed the axle of the wheel: Vision & Governance. We asked the uncomfortable question about who may decide on which risks, worked through the four building blocks, and saw how the AFM confirms that a well-documented compliance function is not yet an effective one.

Now it is time for the spokes. Quadrant 2: Policy & Procedures. This is the quadrant where the legal reality outside is translated into the operational reality inside. Without strong spokes, the wheel does not retain its shape.

How it goes wrong

Your policy library runs to forty documents and nobody knows which version is current. Your risk register sits in a spreadsheet last updated when that one colleague still worked there. You have built a risk analysis for the GDPR, a separate one for NIS2, and a third for ISO 27001, with partially contradictory outcomes and triple the maintenance burden. And for AI-related developments, an entirely new shadow organisation is being set up.

The result: compliance becomes a burden rather than an instrument. And when a client, contracting authority or supervisory body asks for proof, not descriptions, but proof, the search begins all over again.

The solution is not more policy. It is better structure.

Three steps towards workable controls

Step 1: Know what is coming your way

Digital Decade legislation is not a loose pile of laws. It is a framework deliberately designed to interlock. Think in three layers:

Generally applicable: GDPR, Cybersecurity Act/NIS2, AI Act, Data Act, CRA.

Sector-specific: NEN 7510 (healthcare), BIO (government), DORA (financial sector), MDR (medical devices). Organisations deploying AI as a medical device face both the AI Act and the MDR, two overlapping frameworks each with their own conformity requirements.

Supply-chain driven: CSRD, CSDDD, the Cybersecurity Act and DORA oblige large organisations to scrutinise their supply chains. If you are in that chain, your compliance performance becomes part of your client's accountability obligations.

Do not treat this overview as a one-off exercise. Build in a regulatory radar: a structural process whereby new legislation and changes are flagged and mapped directly to your existing framework.

Step 2: From requirement to risk: the common language

The key lies in the intermediate step: risks. Every legal requirement implicitly answers the question: what could go wrong if we do not do this? By translating to risks first, you create the common language that makes a many-to-many structure possible.

GDPR art. 32, NIS2 art. 21 and ISO 27001 A.9 all point to the same underlying risk: unauthorised access to sensitive data. Identify, assess and manage it once, and you cover all three requirements at the same time.

Step 3: From risk to measure: the many-to-many structure

The question to ask for every measure is: which other risks does this control also cover? And which measure, or combination of measures, is best suited?

A well-designed RBAC system covers simultaneously: GDPR art. 32, NIS2/Cybersecurity Act art. 21, ISO 27001 A.9, AI Act art. 9 and your own data breach risk. This delivers three concrete advantages: impact analysis when a control fails, rapid gap analysis for new legislation and efficient expansion without starting from scratch.

Policy inflation: the silent killer

Good policy has an owner, a version date, a review cycle and a direct link to the risks and controls it describes. Good procedures describe not just what someone must do, but also why and what the evidence looks like. Build evidence-gathering directly into the procedure, so that evidence is created during the work, not a few weeks before the audit.

Sovereignty in this quadrant

What policy do you set for data storage outside the EU? How do you document the Transfer Impact Assessment (TIA) as a structural part of your processing register? The Data Act introduces new instruments: switching rights, access rights and prohibitions on data lock-in. Organisations with this policy in order make sovereignty demonstrable, and prepare themselves for the Cloud and AI Development Act (CADA).

AI as accelerator, and as a source of risk

AI can automate the regulatory radar. It can quickly identify complex connections, analyse documents and carry out repetitive tasks consistently. It can also link policy documents logically, flag overlaps and simplify where needed. But AI introduces new risks: garbage in, garbage out. Treat AI output as a junior colleague's draft, always have it validated and record who did so. Moreover, an AI application is itself a compliance object: the AI Act (art. 9) requires a risk management system covering the full lifecycle of high-risk AI systems.

From 'we do it' to 'we can prove it'

Demonstrability is no longer a by-product. It is the norm. Clients who themselves must comply with CSRD, NIS2 or DORA are required to scrutinise their supply chains. A client no longer asks whether you have a policy, they ask for proof.

This is where ComplianceProof comes in: an independent, legally substantiated declaration on a specific compliance question, whether it concerns GDPR compliance, AI literacy or the high-risk status of an AI system. Not an all-encompassing certification process, but targeted assurance on precisely the point where your client or supervisory body requires certainty. An organisation with its policies and controls in order will move through such an assessment faster and with less friction. The evidence is already there.

Legal anchors in this quadrant

The GDPR requires a record of processing activities and demonstrably appropriate measures; the AI Act requires technical documentation and a risk management system for high-risk applications; the Cybersecurity Act requires documented security measures; DORA requires an ICT risk framework with demonstrable controls.

What you can do this week

Count the connections. Place your registers side by side, processing activities, risks, AI systems, suppliers, and ask for each: who is the owner, when was it last updated, and is it linked to another register? Each "no" is your baseline measurement.

Do one mapping exercise. Take one new requirement and map it onto your existing risks and controls. Measure how long it takes.

Challenge your policy inventory. How many policy documents does your organisation have? Who owns each one?

In the next blog

The spokes are in the wheel. In blog 4 we pause at the hub: People, Process & Technology, why change management is the most underestimated factor in any compliance programme. And in blog 5 we zoom in on the third quadrant: Culture, because the strongest control is ultimately an employee who makes the right choice at the right moment.

Want to know how well your policies and risk registers connect? We are happy to help with a practical gap analysis.