Cybersecurity compliance management: method, roles and indicators

Cybersecurity compliance management means identifying the security requirements that apply to your organisation, turning them into controls, proving that they are applied and dealing with gaps, on an ongoing basis. With NIS 2, DORA, the GDPR, HDS, ISO 27001 and now the AI Act and the Cyber Resilience Act, a CISO may have five or six texts on the table. The key is not to handle them one by one: bring them together into a common set of controls, assessed once. This article in our GRC Ops series sets out the method, roles and indicators.

Compliance is the “C” in GRC (governance, risk and compliance). In cybersecurity, it covers four sources of requirements:

• laws and regulations: NIS 2, DORA, GDPR, AI Act, CRA, plus sector-specific rules such as the French HDS certification for hosting health data;
• standards you have chosen to follow or certify against, ISO 27001 first among them;
• contracts: customer requirements, security assurance plans, clauses DORA imposes on your providers;
• your own rules, gathered in your information security policy.

A compliance project, which closes gaps before a deadline, is not the same as compliance management, an ongoing activity that maintains the level, absorbs new texts and produces evidence on demand. Regulatory compliance does not replace risk management: it sets a minimum baseline, which risk analysis completes where threats specific to your business require it.

Everything starts with a simple, often poorly handled question: which texts really apply to us, and to what scope? The same company can be an important entity under NIS 2 for one subsidiary, a processor under the GDPR for another business line, and a manufacturer under the CRA for a software product. The table below summarises where the main texts stood on 8 October 2026.

For each text you keep, record the scope concerned (entities, sites, products, processing), the competent authority, deadlines and who monitors changes. Our articles on the AI Act, the Cyber Resilience Act, NIS 2 and health data hosting cover each of them. Do not forget contractual requirements: they often arrive first, as questionnaires from customers subject to DORA or NIS 2 (see what NIS 2 and DORA require regarding providers).

Read side by side, these texts overlap widely. All of them ask for access management, backups, incident management, supplier oversight, logging and staff awareness. Assessing them text by text means asking the same teams the same question five times. Framework mapping means linking each requirement to a control in a common set, assessed only once.

Choose a pivot

In practice, you pick a pivot framework, usually ISO 27001 and the 93 controls of its Annex A, because most teams know it and other texts map onto it easily. The NIST Cybersecurity Framework 2.0 can play the same role in an international group. Your ISMS then becomes the backbone, and every text hooks onto it.

Use published mappings

You do not have to build everything. ENISA's implementation guidance for the NIS 2 measures (June 2025) includes tables mapping each requirement of Implementing Regulation 2024/2690 to European and international standards. In France, ANSSI accompanies its ReCyF framework, published in March 2026 as a working document, with a tool to compare it with existing frameworks, standards and regulations.

Keep specific obligations separate

Mappings are rarely exact. An ISO 27001 control may only partly cover a NIS 2 requirement; some texts impose obligations with no equivalent elsewhere: incident reporting deadlines under Article 23 of NIS 2, the DORA register of information, the GDPR data protection impact assessment (see our article on DPIAs), CRA vulnerability reporting. Record for each link whether it is full or partial, and handle the remainder as specific requirements. An overly optimistic mapping is the most expensive mistake, because it only shows up during an inspection.

The GDPR set the tone in 2018 with the accountability principle (Article 5(2)): being compliant is not enough, you must be able to demonstrate it. Good evidence is:

• linked to a control, and through it to every requirement concerned;
• dated and given a validity period (an account extract is good for a few months, an approved policy for a year);
• assigned to an owner who knows they will need to renew it;
• bound to a clear scope: which subsidiary, which system, which site.

Assessment happens through campaigns with the teams concerned, internal audits, and increasingly automatic collection for technical controls. That last approach, continuous compliance, replaces the annual snapshot with regular measurement. AI assistants can help link evidence to requirements or pre-fill questionnaires, under human control: see our article on AI and GRC.

Every nonconformity follows the same path:

1. Qualify the gap: which requirement, which scope, how serious in terms of risk.
2. Decide: fix it, compensate with another measure, or accept it formally and temporarily.
3. Plan the corrective action: owner, due date, budget if needed.
4. Check closure with fresh evidence, not a mere statement.

Exceptions (or waivers) deserve special attention. An accepted exception must be signed by the right person, justified, backed by compensating measures and given an end date. Without one, it becomes a risk accepted by default that nobody reviews.

Compliance seldom fails for lack of method; it fails for lack of owners. Recent texts have clarified the role at the top: Article 20 of NIS 2 requires management bodies to approve cybersecurity measures, oversee their implementation and take training; Article 5 of DORA gives them ultimate responsibility for ICT risk management, and Article 6 requires management, control and internal audit functions to be kept separate.

In a mid-sized organisation, one person often holds several roles. What matters is that each requirement and control has a named owner, and that whoever operates a control is not the only one assessing it.

To steer, and to report to management as NIS 2 and DORA require, a handful of indicators is enough:

• Compliance rate by framework and scope, calculated from the common set of controls.
• Coverage: share of applicable requirements linked to at least one control.
• Evidence freshness: share of controls whose evidence is still valid.
• Open gaps by severity, and how old they are.
• Average time to close a gap, against the target.
• Current exceptions, with their expiry dates.
• Assessment campaign progress: who has answered, who needs a reminder.

Thanks to the mapping, these indicators break down by text without double entry: one control feeds the NIS 2 rate, the DORA rate and the ISO 27001 rate.