← CEPF

Cross-framework overlap catalogue

An organisation subject to several regulatory regimes at once does not face a sum of separate compliance programmes. It faces one programme with shared controls — and the shared controls are where both the cost and the omissions concentrate. CEPF v7 identifies 24 of them across 19 frameworks. This page publishes the groups: what the shared control is, which regimes fall into it, and how many catalogue requirements sit inside. 75 of the 247 requirements in the catalogue — a little under a third — belong to at least one group.

By Corrado Patierno · catalogue snapshot · published

What an overlap group is

CEPF works on obligations, not on principles. Each regime is broken down into the deliverables it actually requires, the roles that produce them and the effort each one carries. An overlap group is a point where two or more regimes demand the same control: not a similar idea, but an artefact or process that can be built once and documented against each regime.

The test for membership is deliberately strict. “Both regimes care about security” is not an overlap. “Both regimes require an immutable record of privileged access, and the same log infrastructure satisfies each” is. Where the artefact is shared but the acceptance criteria differ — as with a product risk assessment under PLD 2024, the Cyber Resilience Act and the AI Act — the group records the shared method and leaves the criteria separate.

The consequence is practical: an organisation that maps its programme this way writes one policy set, keeps one evidence trail per control, and answers three auditors from it. The organisation that does not, builds the same control two or three times and still discovers, in an inspection, the one place it was never built at all.

The 24 groups

Frameworks appearing below: SOX IT (ITGC), NIS2, ISO/IEC 27001, GDPR, EU AI Act, CEPF extensions, DORA, PLD 2024, Cyber Resilience Act. The remaining frameworks in the catalogue — the ISO management-system standards, the BIM and construction norms, the Italian and Spanish national regimes — carry requirements that do not currently share a control with another regime in the catalogue.

GroupFrameworksReq.
Access controls and IAMLogical access, identity management, multi-factor authentication, segregation of duties, user access review, privileged access management.SOX IT (ITGC)NIS2ISO/IEC 27001GDPR7
Audit trail and loggingImmutable audit trail, centralised logging, log integrity. The AI Act requirement lands on the same log infrastructure as the security ones.SOX IT (ITGC)NIS2ISO/IEC 27001EU AI ActCEPF extensions5
Change managementFormal change process on in-scope systems: request, test, approval, deployment, traceability of what changed and why.SOX IT (ITGC)ISO/IEC 27001EU AI Act3
Disaster recovery and business continuityRecovery procedures, RTO and RPO targets, continuity plan and periodic test.SOX IT (ITGC)NIS22
Risk assessmentFormal risk assessment — IT, cyber, privacy, ICT and AI. Six regimes ask for one, and they can share a method and a register without sharing a scope.SOX IT (ITGC)NIS2ISO/IEC 27001GDPRDORAEU AI Act7
Vendor and supply chain managementThird-party management: service levels, audit rights, data processing agreements, supplier register.SOX IT (ITGC)NIS2GDPRDORA5
Incident notificationNotification duties to authorities — cyber authority, data protection authority, financial regulator. Different clocks, one detection and triage capability.NIS2GDPRDORA3
Policy and register productionThe documented policies, procedures and registers each regime requires. The largest group in the catalogue, and the one most often duplicated.SOX IT (ITGC)NIS2ISO/IEC 27001GDPREU AI Act9
Testing and validationUser acceptance testing, resilience testing, conformity assessment activity, internal audit.SOX IT (ITGC)ISO/IEC 27001GDPRDORAEU AI ActCEPF extensions7
Vulnerability managementVulnerability scanning, patch management, secure development practice.NIS2ISO/IEC 27001DORA3
Incident response capabilityInternal capability to detect, contain, eradicate and recover — distinct from the duty to notify.NIS2ISO/IEC 27001DORA3
Security awareness trainingSecurity training for staff and for management. ISO/IEC 27001 A.6.3 covers all personnel; NIS2 makes management training an obligation of its own.NIS2ISO/IEC 270012
AI data protection stackThe technical and legal stack specific to AI projects processing personal data in hybrid architectures: DPIA and fundamental rights impact assessment, quasi-identifier analysis, audited anonymisation.EU AI ActGDPRCEPF extensions7
Software bill of materialsOne SBOM, two regulatory purposes: documentary evidence under the product liability directive, vulnerability management instrument under the Cyber Resilience Act.PLD 2024Cyber Resilience Act2
Product technical documentationThe technical file. Structure and content are largely shared between PLD 2024, the CRA and the AI Act — written once, indexed three ways.PLD 2024Cyber Resilience ActEU AI Act3
Product risk assessmentProduct safety risk assessment: defectiveness under PLD, cybersecurity under the CRA, AI risk under the AI Act. Shared method, shared register, different acceptance criteria.PLD 2024Cyber Resilience ActEU AI Act3
Vulnerability handling processProduct vulnerability handling: PLD obliges a remedy, the CRA obliges a formal process, NIS2 applies to entities in scope. One policy, one toolchain.PLD 2024Cyber Resilience ActNIS23
Security update obligationsPost-market security update duties, nearly identical in PLD and the CRA — same procedure, same distribution channel.PLD 2024Cyber Resilience Act2
Post-market surveillanceOne surveillance plan, one monitoring system, the same reporting sources.PLD 2024Cyber Resilience Act2
Product incident response and recallIncident response for product defects, serious-incident notification under the CRA, incident management under NIS2 — partially shareable, not identical.PLD 2024Cyber Resilience ActNIS23
Supply chain product securitySupplier register for recourse purposes, cyber supply chain due diligence, supply chain security measures. One vendor register serving three duties.PLD 2024Cyber Resilience ActNIS23
Conformity assessment and CE markingConformity documentation for placing on the market and the CRA conformity assessment and EU declaration — a product in scope of both runs one exercise.PLD 2024Cyber Resilience Act3
Secure product SDLCSecure development lifecycle under the CRA and ISO/IEC 27001 A.8.25 — same process, same tooling, same team.Cyber Resilience ActISO/IEC 270012
Product evidence trailEvidence trail that can be defended in litigation under PLD, and security logging under ISO/IEC 27001 A.8.15 — the same log system serving two very different purposes.PLD 2024ISO/IEC 270012

How to read the numbers

The catalogue holds 247 requirements across 19 frameworks, with 695 document templates attached to them. 75 of those requirements belong to at least one overlap group, producing 91 group memberships in total — the difference is the requirements that sit in more than one group at once, which are the ones worth building first.

Two clusters are visible in the table. The first thirteen groups are the organisational regimes — access, logging, change, risk, incidents, suppliers, training — where NIS2, ISO/IEC 27001, SOX IT general controls, the GDPR and DORA converge on infrastructure that most organisations already partly own. The last eleven are the product cluster added for PLD 2024 and the Cyber Resilience Act, where the shared artefacts are an SBOM, a technical file, a vulnerability handling process and a post-market surveillance plan.

That second cluster is the one with a date attached. The reporting obligations of the Cyber Resilience Act start applying on 11 September 2026, and Member States must have transposed the product liability directive by 9 December 2026 — which is what the exposure assessment and the CRA deadline page are about.

What this page is, and what it is not

It is the shape of the catalogue, published so that the numbers stated elsewhere on this site can be checked against something. It is not the catalogue: the requirement codes and titles, the mapping to individual articles, the effort model and the shared-control discounts stay inside CEPF and Calibra, the software built on it.

It is also not a compliance mapping you can adopt as-is. Whether a given requirement applies to your organisation depends on your sector, your role and your size; whether one control genuinely satisfies two regimes for you depends on how it is implemented and evidenced. The groups say where to look, not what to conclude.

And it is not legal advice. Conformity is established by the procedures the regulations themselves prescribe — not by a catalogue, not by a consultant, and not by a deployment topology.

Sources

The regimes named above, in their official text. Where this page describes what an obligation requires, the act is the authority.

Related

Which of these groups already exist in your organisation?

Most organisations own more of them than they think, in places nobody has mapped. Finding out is a short engagement, not a programme.

Start the conversation →