Compliance Programs 101: How to Build One for EU Regulations

The policy framework translates regulatory obligations into internal rules that govern organisational behaviour. Structure policies in a hierarchy: a top-level compliance policy (setting the organisation's commitment to regulatory compliance and the programme's governance framework), domain policies (cybersecurity policy, data protection policy, ICT risk management policy, incident management policy, supply chain security policy), and supporting standards and procedures that provide implementation detail. This hierarchical structure allows the management body to approve top-level and domain policies while delegating procedural detail to subject matter experts, satisfying both the Article 20/Article 5(2) approval requirements and the need for operational specificity.

Each policy must address minimum content requirements imposed by the applicable frameworks. NIS2 Article 21(2)(a) requires risk analysis and information system security policies — these must cover all ten measure categories listed in Article 21(2)(a)-(j). DORA's RTS on ICT risk management (JC 2023 86) specifies minimum content for ICT security policies including information classification, cryptography, operations security, network security, project and change management, physical security, and human resources security. ISO 27001 Clause 5.2 requires an information security policy appropriate to the purpose of the organisation, providing a framework for setting objectives, and including a commitment to continual improvement. Map these requirements to avoid producing separate policies for each framework when a single integrated policy can satisfy all three.

Policy lifecycle management is as important as policy content. Every policy must have a defined owner, a scheduled review date (at least annually for NIS2 and DORA-related policies), an approval authority, and a distribution mechanism that ensures all relevant personnel can access and have acknowledged the current version. Track policy exceptions formally: when business circumstances require deviation from policy, document the exception with a risk assessment, an approving authority, a defined expiration date, and compensating controls. Policy exceptions that accumulate without resolution are a supervisory red flag — they suggest the policy framework is disconnected from operational reality.

EU organisations rarely face a single regulatory framework. The typical compliance programme must address NIS2, DORA (for financial entities or ICT service providers to financial entities), GDPR, and often ISO 27001 certification or sector-specific regulations. Designing the programme around a single framework and bolting on others as afterthoughts produces a fragmented compliance posture with redundant controls, inconsistent evidence, and gaps at framework boundaries. Instead, design the programme from the outset as a multi-framework capability with a unified control architecture.

The unified control architecture starts with a harmonised obligation register that maps requirements from all applicable frameworks to a common control set. Use a recognised mapping source as the starting point: ENISA's NIS2-to-ISO 27001 mapping, the ESA's DORA-to-existing-framework mapping references, or the Cloud Security Alliance's Cloud Controls Matrix for cross-framework alignment. For each control, document which framework requirements it satisfies (the many-to-many mapping), define the evidence required to demonstrate effectiveness, and assign a single control owner responsible for implementation and testing across all frameworks. This architecture means a control is tested once and the results count toward compliance across all linked frameworks — eliminating the redundant testing that siloed programmes generate.

Manage framework-specific requirements as extensions to the common control set rather than as separate programmes. NIS2's management body liability provisions (Article 20) have no direct equivalent in DORA or GDPR — they require specific governance controls added to the common set. DORA's register of information (Article 28(3)) has no equivalent in NIS2 — it requires a specific data management control. GDPR's data subject rights processing (Articles 15-22) has no equivalent in NIS2 or DORA — it requires specific operational procedures. These framework-specific controls sit alongside the common controls in the unified architecture, each mapped to its source obligation, each with defined evidence and ownership. The result is a compliance programme that addresses all frameworks comprehensively while eliminating duplication where requirements overlap.

Compliance programme maturity assessment provides an objective measure of how well the programme performs against its design objectives and regulatory expectations. Use a maturity model with defined levels — a common five-level scale covers: initial (ad-hoc, reactive compliance activities), developing (documented policies but inconsistent implementation), defined (standardised processes, assigned ownership, regular testing), managed (metrics-driven, quantitative understanding of compliance posture), and optimising (continuous improvement feedback loops, predictive risk identification). Assess each programme component (governance, policy framework, training, monitoring, reporting, technology) independently, as maturity levels typically vary across components.

Conduct maturity assessments annually, ideally timed to inform the management body's annual compliance programme review. Compare current maturity against target maturity — the target should be informed by regulatory expectations, peer benchmarks, and risk appetite. Not every component needs to reach the optimising level: for a mid-sized organisation, a target of defined (Level 3) for most components with managed (Level 4) for high-risk domains such as incident management and access control is realistic and defensible. Supervisory authorities assess proportionality — they expect maturity to scale with entity size, risk exposure, and the criticality of services provided.

Continuous improvement is not an aspiration — it is a regulatory requirement. NIS2 Article 21(1) requires measures that are appropriate and proportionate, implying ongoing adjustment as risks evolve. DORA Article 6(5) explicitly requires that the ICT risk management framework be improved continuously based on lessons learned. ISO 27001 Clause 10.1 mandates continual improvement of the ISMS. Build improvement inputs into the programme: post-incident reviews identifying control gaps, control testing findings revealing design weaknesses, regulatory changes requiring obligation updates, maturity assessment results highlighting capability shortfalls, and supervisory examination feedback. Channel these inputs through the compliance committee into a documented improvement plan with prioritised actions, assigned owners, and target completion dates. Track improvement plan execution as a programme-level KPI — it demonstrates the dynamic, evolving nature of your compliance programme to supervisory authorities.