Cyber Threat Intelligence in France: NIS2 Compliance Guide

Organisations cannot manage cyber risk effectively by relying only on historic incidents or generic annual risk assessments. Threat conditions change too quickly, and attackers continually adapt their techniques, targets and infrastructure.

Organisations assessing cyber threat risk in France need a structured process for collecting, analysing and applying cybersecurity intelligence to their systems, suppliers and essential services. Effective cyber threat intelligence can reveal who may target the organisation, which vulnerabilities are being actively exploited, which attack techniques are increasing, which assets face the greatest exposure and where suppliers may introduce additional risk. It can also identify controls requiring urgent improvement and support decisions about whether an incident may need to be reported.

NIS2 does not require every regulated organisation to build a large internal intelligence department. It does require proportionate cybersecurity risk management, threat monitoring, vulnerability handling, supply chain security and significant-incident reporting.

This guide covers NIS2 scope in France, intelligence collection and analysis, risk management, incident reporting, governance, training and a practical compliance roadmap.

What Is Cyber Threat Intelligence?

Cyber threat intelligence is analysed information about existing or emerging cyber threats that supports security, operational and business decisions. It is more valuable than raw data because it explains what a threat means for the organisation and what action should follow.

Raw security data may include an IP address, malware hash, suspicious domain or vulnerability alert. Threat information adds context, such as identifying a known campaign or affected technology. It becomes actionable threat intelligence when the organisation understands why it matters, which systems are exposed, how reliable the source is, what the likely impact may be, what response is required and who is responsible for acting.

Strategic threat intelligence

Strategic intelligence helps executives, boards and risk leaders understand long-term threat trends, sector exposure, geopolitical developments, potential business impact and cybersecurity investment priorities.

Operational threat intelligence

Operational intelligence supports incident responders by analysing threat actors, campaigns, motivations, attack infrastructure and likely targets.

Tactical threat intelligence

Tactical intelligence explains how attackers operate. It may cover phishing, credential theft, lateral movement, privilege escalation and data exfiltration.

Technical threat intelligence

Technical intelligence includes rapidly changing indicators such as malicious domains, IP addresses, file hashes, indicators of compromise and actively exploited vulnerabilities.

An effective cyber threat intelligence programme should combine all four levels. Collecting technical indicators without operational or business context can create alert volume without improving decisions, prioritisation or resilience.

How NIS2 Applies in France

Directive (EU) 2022/2555, known as the NIS2 Directive, establishes a common cybersecurity framework across the European Union. It requires covered entities to implement proportionate cybersecurity risk-management measures and strengthens requirements concerning management-body accountability, incident reporting, supply chain security, business continuity, vulnerability handling, cybersecurity training, regulatory supervision and voluntary information sharing.

French implementation status

France has continued developing its national NIS2 transposition framework. As of July 2026, the European Commission stated that France had not yet notified complete transposition and referred France to the Court of Justice of the European Union. Organisations should therefore distinguish between obligations in the Directive, enacted French rules and preparatory guidance that is not yet legally definitive.

Businesses should monitor the European Commission’s NIS2 transposition information and verify:

• Final French legislation

• Implementing decrees and orders

• ANSSI security requirements

• Entity registration procedures

• Incident-notification processes

• Compliance deadlines

• Sector-specific instructions

ANSSI’s role

ANSSI is expected to play a central role in French implementation through regulatory guidance, entity registration, cybersecurity support, incident-reporting services and national supervision. Its NIS2 portal already provides scope-assessment tools, pre-registration services, preparation resources and access to incident-reporting channels. CERT-FR also supports national coordination, threat information and incident response.

Organisations should use ANSSI’s official NIS2 information and preparation portal to assess potential scope and begin readiness work without assuming that every draft measure is already binding.

Publication note: French transposition details should be checked again immediately before publication because the national legal framework is still evolving.

Which Organisations May Fall Within NIS2 Scope?

NIS2 scope depends on more than an organisation’s sector. Businesses must assess the type of service they provide, their size, the importance of that service, their place of establishment and any specific inclusion or designation rules. The Directive generally applies to medium-sized and large entities operating in the sectors listed in Annexes I and II, subject to legal definitions and exceptions.

Essential entities

Sectors commonly associated with essential entities include:

• Energy

• Transport

• Banking

• Financial-market infrastructure

• Health

• Drinking water and wastewater

• Digital infrastructure

• ICT service management

• Space

• Public administration

Classification also depends on the entity’s size and the precise service it provides.

Important entities

Additional sectors can include postal and courier services, waste management, chemicals, food production and distribution, manufacturing of specified critical products, online marketplaces, search engines, social-networking platforms and research organisations.

Entities covered by Annex I or II that do not qualify as essential entities may generally be treated as important entities.

Size thresholds

Medium-sized and large organisations in listed sectors are commonly within scope. However, some entities may be covered regardless of size because they provide a uniquely critical service, hold a monopoly position, could create systemic disruption, are classified under another critical-entity framework or are specifically designated by a competent authority.

Supply chain exposure

An organisation outside direct NIS2 scope may still face contractual cybersecurity requirements from regulated customers. This can affect managed service providers, cloud suppliers, software vendors, logistics companies, security providers, data processors and maintenance contractors.

Businesses should complete a documented scope assessment covering sector, services, size, establishment, criticality and customer obligations rather than relying on a broad industry label alone.

Why Threat Intelligence Matters for NIS2 Compliance

NIS2 requires covered organisations to take an all-hazards, risk-based approach to cybersecurity. Cyber threat intelligence supports that approach by helping organisations understand which threats are relevant to their services, systems and suppliers at a given time.

A structured intelligence capability can help an organisation:

• Identify relevant threat actors and campaigns

• Prioritise exposed or business-critical assets

• Detect actively exploited vulnerabilities

• Improve alerting and incident detection

• Test whether security controls remain effective

• Assess supplier and software dependency risks

• Update business continuity and crisis scenarios

• Brief management bodies on current exposure

• Support incident-escalation and reporting decisions

• Demonstrate that controls reflect current threats

Threat intelligence is an input, not the final control

Purchasing threat feeds or receiving alerts does not, by itself, establish compliance. Intelligence must lead to documented action.

This may include patching an exposed vulnerability, blocking malicious infrastructure, resetting compromised credentials, increasing monitoring, reviewing a supplier, isolating a system, updating phishing training, escalating a suspected incident or revising the cyber risk register.

Proportionality

The operating model should reflect the organisation’s size, services and exposure. A smaller regulated entity may rely on ANSSI alerts, CERT-FR information, ENISA reports, vendor advisories, managed security providers and sector information-sharing communities.

A larger organisation may maintain dedicated analysts, security information and event management tools, threat intelligence platforms, detection engineering, malware analysis and formal sector partnerships.

The key requirement is not organisational scale. It is the ability to convert relevant threat information into timely, proportionate and evidenced security decisions.

Build a Cyber Threat Intelligence Lifecycle

A cyber threat intelligence programme should operate as a repeatable cycle rather than a collection of disconnected alerts. Each stage should produce a clear decision, action or improvement.

Step 1: Define intelligence requirements

Start with specific business and security questions:

• Which threats could interrupt essential services?

• Which vulnerabilities are being actively exploited?

• Which suppliers create concentration risk?

• Are attackers targeting our sector?

• Which systems or data are most attractive?

• Which warning signs require immediate escalation?

• Which incidents could trigger NIS2 reporting?

Step 2: Identify reliable sources

Relevant sources may include ANSSI, CERT-FR, ENISA, vendors, cloud providers, sector ISACs, security operations centres, managed security providers, vulnerability databases, internal logs, incident reports, fraud reports and employee reports.

Step 3: Collect and normalise information

Collect only information that supports defined requirements. Normalise formats, remove duplicates and filter low-value alerts so teams are not overwhelmed by unstructured feeds.

Step 4: Analyse

Assess source reliability, relevance, confidence, severity, potential impact, affected systems and required response time. Distinguish confirmed evidence from assumptions.

Step 5: Disseminate

Tailor outputs to the audience. Executives need business implications. Security teams need indicators and detection logic. IT teams need remediation priorities. Procurement teams need supplier risk. Employees need practical warnings. Compliance teams need regulatory consequences.

Step 6: Act

Convert intelligence into assigned actions with named owners, deadlines and escalation thresholds. Actions may include patching, blocking indicators, increasing monitoring, reviewing suppliers or activating incident response.

Step 7: Review effectiveness

Measure whether intelligence improved detection speed, patching, prioritisation, exposure reduction, incident handling and risk accuracy. Refine sources and processes when intelligence repeatedly fails to produce useful action.

Connect Threat Intelligence to NIS2 Risk Management

Article 21 of the NIS2 Directive requires covered entities to implement appropriate and proportionate technical, operational and organisational cybersecurity measures. These measures must address an all-hazards approach and reflect the organisation’s exposure, size, implementation costs and the potential impact of incidents. Threat intelligence helps keep those measures aligned with current attacker activity rather than outdated assumptions.

Risk analysis and security policies

Use relevant intelligence to update risk registers, security policies, system classifications and attack scenarios. It should also influence control priorities and residual-risk decisions. For example, evidence that attackers are exploiting a vulnerability in the organisation’s sector may justify accelerated remediation or temporary restrictions.

Incident handling

Threat intelligence can help teams recognise known attacker behaviour, prioritise alerts, preserve relevant evidence and contain attacks. It can also reveal related systems, accounts or suppliers that require investigation and support the assessment of whether an incident may be significant under NIS2.

Business continuity and crisis management

Translate credible threat scenarios into exercises involving ransomware, cloud outages, supply chain compromise, destructive malware, credential theft, data exfiltration and distributed denial-of-service attacks. Exercises should test decision-making, communications, service recovery and regulatory escalation.

Supply chain security

Assess supplier access, known vulnerabilities, previous incidents, software dependencies, subcontractors, concentration risk and patching performance. Threat intelligence should also inform termination and transition planning where reliance on a critical supplier creates unacceptable exposure.

Vulnerability handling and disclosure

Use intelligence to distinguish between theoretical weaknesses, publicly disclosed vulnerabilities, available proof-of-concept exploits, confirmed active exploitation and weaknesses affecting critical assets. This allows remediation deadlines to reflect actual exposure rather than severity scores alone.

Cyber hygiene and training

Current threat patterns should shape phishing exercises, password controls, multifactor authentication, privileged-access management, secure administration and employee-reporting guidance.

The compliance value comes from evidence that intelligence changed a decision. Organisations should retain the alert, assessment, assigned action, owner, deadline and outcome so they can demonstrate that current threats are feeding practical NIS2 risk management.

Use the Référentiel Cyber France to Structure Preparation

ANSSI released the working version of the Référentiel Cyber France, known as ReCyF, on 17 March 2026. The framework is intended to help future essential entities prepare for the cybersecurity objectives expected under France’s NIS2 implementation. ANSSI describes it as a structured set of recommended measures designed to support readiness and promote a proportionate level of security.

The current Référentiel Cyber France, ReCyF version 2.5 addresses areas such as:

• Information system inventories

• Compliance and maturity assessments

• Governance and risk analysis

• Supplier and ecosystem controls

• Human resources security

• Vulnerability management

• Incident detection and evidence preservation

• Business continuity and crisis response

• Security monitoring

• Auditing and remediation planning

ReCyF can therefore provide a practical structure for organising NIS2 preparation, assigning responsibilities, and identifying missing evidence.

Important qualification: ReCyF version 2.5 is expressly identified as a working document. Organisations should use it for preparation and gap analysis, but they should verify the final French legislation, implementing measures and ANSSI requirements before treating every control as legally definitive.

Practical ReCyF gap assessment

Create a control-tracking table containing:

• Security objective

• Current control

• Available evidence

• Identified gap

• Risk level

• Remediation action

• Responsible owner

• Target date

• Completion status

This turns ReCyF into an operational improvement plan rather than a static checklist and helps management track whether identified weaknesses are being resolved.

Threat Monitoring and Vulnerability Intelligence

Vulnerability management should reflect both technical severity and actual threat activity. A high severity score does not always mean a vulnerability presents the greatest immediate risk, while a lower-scored weakness may require urgent action if attackers are actively exploiting it against exposed systems.

Monitor relevant vulnerabilities

Organisations should track vulnerabilities affecting internet-facing assets, remote-access systems, identity infrastructure, cloud platforms and operational technology where applicable. Monitoring should also cover supplier advisories, unsupported software and weaknesses affecting critical third-party products.

Prioritise by organisational impact

Remediation decisions should consider:

• Exploit availability

• Evidence of active exploitation

• Asset criticality

• External exposure

• Privilege required

• Existing compensating controls

• Potential service interruption

• Personal-data impact

• Supplier dependencies

This approach helps teams prioritise vulnerabilities according to real operational risk rather than severity scores alone.

Establish remediation rules

Define clear criteria for emergency patching, standard remediation deadlines, temporary compensating controls and exception approval. High-risk exceptions should require documented justification, ownership and management visibility.

After remediation, verify that the patch or control was applied successfully and did not create new operational issues.

Preserve evidence

Retain vulnerability alerts, risk assessments, patching decisions, approved exceptions, supplier communications, remediation records and verification results.

These records help demonstrate that the organisation identified relevant threats, assessed exposure and took proportionate action. They also support incident investigations, management reporting and future NIS2 assurance reviews.

Threat Information Sharing Under NIS2

NIS2 encourages organisations to participate voluntarily in trusted cybersecurity information-sharing arrangements. Article 29 allows covered entities, and where relevant other organisations, to exchange information about cyber threats, vulnerabilities, near misses, attack techniques, indicators of compromise, adversarial tactics, security alerts and recommended defensive configurations.

Shared information may include:

• Threat and compromise indicators

• Newly identified vulnerabilities

• Attack techniques and adversarial tactics

• Security alerts

• Detection methods

• Recommended configurations

• Lessons from incidents

• Relevant defensive actions

Benefits of information sharing

Effective sharing can provide earlier warning of active threats, improve sector-wide visibility, and accelerate detection. It may also support coordinated defense, faster incident response, shared learning, and stronger supply chain resilience.

Information Sharing and Analysis Centres, known as ISACs, provide structured environments for organisations to exchange sector-relevant threat information, experience, and analysis. ENISA supports the development and cooperation of European ISACs as a way to strengthen cybersecurity collaboration. See ENISA’s official Information Sharing and Analysis Centres guidance.

Safeguards

Before sharing, organisations should consider confidentiality, trade secrets, personal data, legal privilege, contractual restrictions, security classification, Traffic Light Protocol markings, recipient trust and the accuracy and confidence of the information.

Sharing arrangements should define who can receive information, how it may be redistributed, and how errors are corrected. They should not result in unnecessary disclosure of personal data, sensitive operational details or information that could increase security risk.

NIS2 Incident Reporting Requirements

NIS2 introduces a staged reporting process for incidents that significantly affect the provision of covered services. Organisations need procedures that support rapid escalation because the reporting clock begins when the entity becomes aware of a significant incident, not when the investigation is complete. The applicable sequence is set out in Article 23 of the NIS2 Directive.

Early warning

An early warning is generally required within 24 hours of becoming aware of the significant incident. Where applicable, it should indicate whether unlawful or malicious activity is suspected and whether the incident could have a cross-border impact.

The early warning is intended to support rapid regulatory awareness. It does not require complete forensic findings.

Incident notification

A more detailed incident notification is generally required within 72 hours of awareness. It should update the early warning and provide available information concerning:

• The initial assessment

• Incident severity and impact

• Indicators of compromise

• Relevant technical findings

Intermediate reporting

The competent authority or CSIRT may request intermediate reports or progress updates while containment, investigation and recovery continue.

Final report

A final report is generally required within one month after the incident notification. Subject to the rules for incidents that remain ongoing, it may describe the root cause, type of threat, mitigation measures, cross-border impact and completed or planned remediation.

Threat intelligence supports notification decisions

Reporting readiness depends on reliable detection, defined escalation thresholds, time-stamped evidence and clearly assigned decision-makers. Legal, compliance and cybersecurity teams should maintain current authority contact details and pre-agreed reporting templates.

Organisations should not wait for complete forensic certainty before beginning escalation. Threat intelligence can help connect indicators, assess likely impact, identify affected services and determine whether the incident may meet the NIS2 significance threshold.

When NIS2 and GDPR Incident Reporting Overlap

A single cyber incident can trigger several reporting regimes. Examples include ransomware affecting personal data, unauthorised access to customer records, employee-data theft, credential compromise, accidental disclosure, or the destruction, loss or unavailability of personal information.

Under the GDPR, a personal-data breach must generally be reported to the CNIL without undue delay and, where feasible, within 72 hours of awareness when it is likely to create a risk to individuals’ rights and freedoms. The CNIL’s official personal-data breach notification guidance explains the notification process and the information organisations should provide.

NIS2 and GDPR apply different legal tests. One notification does not automatically satisfy the other, and different authorities may require different technical, operational and personal-data information. Organisations should coordinate timelines, evidence and decision-making while keeping each assessment distinct.

A single incident-assessment form should include separate questions for:

• NIS2 significance and reporting

• GDPR breach risk

• Sector-specific notifications

• Contractual obligations

• Cyber-insurance notifications

• Potential law-enforcement involvement

This structure reduces missed deadlines and helps ensure that evidence, impact assessments and reporting decisions remain consistent across parallel obligations.

Implementing Regulation for Certain Digital Entities

Commission Implementing Regulation (EU) 2024/2690 provides detailed technical and methodological requirements for specified digital entities covered by NIS2. It also further defines when incidents affecting those entities should be considered significant.

The regulation applies to certain:

• DNS service providers

• Top-level domain registries

• Cloud computing providers

• Data centre providers

• Content delivery network providers

• Managed service providers

• Managed security service providers

• Online marketplaces

• Online search engines

• Social networking platforms

• Trust service providers

Its annex sets out more detailed expectations relating to cybersecurity risk assessment, incident handling, business continuity, supply chain security, security testing, cryptography, access control, asset management, staff training and threat monitoring. The measures must be applied proportionately, taking account of factors such as the entity’s size, structure, criticality, risk exposure and the potential severity of incidents.

Organisations should confirm whether they fall within one of the listed categories before applying the regulation. It should not be treated as a universal technical rulebook for every entity within NIS2 scope. Other covered organisations may instead be governed by national transposition measures, sector-specific requirements and the broader obligations in the NIS2 Directive.

Management Body Responsibilities

NIS2 places cybersecurity oversight at management-body level. Senior leaders cannot treat cyber risk as an issue owned only by the IT or security team. They must be prepared to approve cybersecurity risk-management measures, supervise implementation and understand the organisation’s material exposure.

Management bodies should also review significant incidents, challenge delayed remediation, allocate appropriate resources, receive relevant cybersecurity training and oversee compliance with legal and regulatory obligations.

Threat intelligence for executives

Executive reporting should convert technical findings into business decisions rather than present unfiltered alerts, indicators or vulnerability lists.

A useful management report may include:

• Main threats to essential services

• Critical vulnerabilities and exposed assets

• Risks affecting key suppliers

• Significant incidents and near misses

• Remediation progress and overdue actions

• Detection and response performance

• Business continuity readiness

• Regulatory-reporting status

• Decisions requiring approval or risk acceptance

Reports should explain potential operational, financial and regulatory impact so leaders can prioritise action.

Evidence of oversight

Organisations should retain evidence showing that management actively supervised cybersecurity measures. Relevant records may include:

• Meeting minutes

• Approved policies

• Risk-acceptance decisions

• Training records

• Budget and resource decisions

• Incident briefings

• Remediation plans

• Follow-up actions

Management oversight should be demonstrable, not merely inferred from job titles or organisational charts. Regulators and auditors should be able to see what information leaders received, which decisions they made and whether corrective actions were tracked to completion.

Build a Proportionate Threat Intelligence Operating Model

Not every NIS2-regulated entity needs a dedicated internal threat intelligence team. The operating model should reflect the organisation’s size, critical services, technical environment, supplier exposure and available expertise. What matters is that relevant intelligence reaches the right people and leads to timely action.

Assign roles

Responsibilities may be shared across:

• An executive sponsor

• The cybersecurity leader

• A threat intelligence owner

• The security operations team

• The incident response lead

• The vulnerability manager

• A compliance or legal adviser

• The data protection officer

• A procurement representative

• Relevant business service owners

One person may hold several roles in a smaller organisation, but ownership for analysis, escalation and decision-making should remain clear.

Define escalation levels

Routine intelligence should be monitored, recorded and reviewed during normal operations.

Elevated intelligence may require increased monitoring, exposure checks, notification of affected system owners and accelerated remediation.

Critical intelligence should trigger incident-response procedures, isolation of affected systems where necessary, supplier contact, management briefing and assessment of regulatory-reporting obligations.

Choose an operating model

Possible models include:

• Fully internal

• Managed security provider

• Hybrid internal and external

• Sector-shared service

• Group-level intelligence function

Outsourcing collection or analysis does not transfer accountability. The regulated entity must still make risk, escalation and reporting decisions.

Establish minimum documentation

Maintain records of:

• Intelligence requirements

• Approved sources

• Source-evaluation criteria

• Analysis findings

• Distribution lists

• Action decisions

• Escalation records

• Review dates

• Performance metrics

This documentation should show how threat information was assessed, who received it and what action followed.

Supply Chain Threat Intelligence

NIS2 places specific emphasis on supply chain security because regulated organisations often depend on external providers for software, infrastructure, data processing, maintenance and operational support. Threat intelligence should therefore cover not only the organisation’s own environment, but also risks introduced by critical suppliers and subcontractors.

Relevant intelligence may include supplier compromises, vulnerable products, software dependencies, cloud outages, credential theft, malicious software updates, remote-access exposure, concentration risk, subcontractor weaknesses and end-of-support technologies.

Supplier due diligence questions

Organisations should ask:

• Which systems, networks or data can the supplier access?

• Has the supplier experienced significant security incidents?

• How does it monitor emerging cyber threats?

• How quickly does it communicate vulnerabilities?

• Does it provide software bills of materials where relevant?

• How are subcontractors assessed and controlled?

• What logging and audit evidence are available?

• What incident-notification timelines apply?

• Can supplier access be revoked rapidly?

• How will data and services be recovered after disruption?

Answers should be reviewed against the supplier’s actual role and criticality.

Contract controls

Contracts should address incident notification, vulnerability disclosure, security updates, audit rights, evidence provision, subcontractor controls, cooperation with authorities, business continuity and termination assistance.

Threat intelligence should also trigger contract and supplier reviews when new vulnerabilities, incidents or concentration risks emerge. The objective is not simply to collect supplier information, but to identify where third-party exposure could interrupt essential services and ensure that proportionate controls, escalation routes and recovery measures are in place.

Cybersecurity Training and Threat Awareness

NIS2 requires covered organisations to implement cyber hygiene practices and provide cybersecurity training. Training should be risk-based, role-specific and connected to the organisation’s current threat environment rather than treated as a generic annual exercise.

Training for management bodies

Management should understand:

• NIS2 accountability and oversight duties

• The organisation’s main cyber threats

• Risk-acceptance decisions

• Incident escalation

• Reporting deadlines

• Business continuity expectations

• Supply chain exposure

Training should help leaders challenge delayed remediation, allocate resources and make informed decisions during significant incidents.

General workforce training

Employees should understand common risks such as phishing, credential theft, social engineering and malicious attachments. They should also know how to use multifactor authentication, report suspicious activity, work securely outside the office, handle data appropriately and use only approved systems and tools.

Specialist training

Provide role-specific instruction for security analysts, incident responders, IT administrators, procurement teams, legal and compliance staff, communications teams and senior managers. Each group should understand the decisions, evidence and escalation duties relevant to its role.

Use current intelligence in training

Update examples using recent phishing themes, active attack techniques, sector-specific threats, supplier compromises and lessons from internal incidents. This makes training more relevant and helps employees recognise realistic warning signs.

Confidential threat information should not be included in broad workforce training. Sensitive operational details should be limited to personnel who need them for detection, response or risk management.

Using ISO Standards Without Misstating the Law

ISO standards can help organisations structure cybersecurity governance and control activities, but they are not substitutes for NIS2 legal analysis. Regulatory obligations must be assessed against the Directive, French implementing rules and applicable ANSSI requirements.

ISO/IEC 27001

ISO/IEC 27001:2022 sets requirements for establishing, implementing, maintaining and continually improving an information security management system.

Its management-system approach can support:

• Governance and accountability

• Information security risk assessment

• Internal audits

• Corrective action

• Document and evidence control

• Continual improvement

These processes can help an organisation organise its NIS2 preparation and demonstrate that cybersecurity controls are reviewed systematically.

Threat intelligence controls

ISO/IEC 27002 provides supporting guidance on information security controls, including the collection and analysis of information about existing and emerging cyber threats. Organisations can use these principles to define intelligence requirements, assess sources, distribute findings and convert relevant intelligence into action.

However, NIS2 does not universally require ISO certification. Certification does not automatically prove full compliance, and an uncertified organisation may still apply ISO principles effectively.

Where an ISO control differs from a binding regulatory requirement, the legal obligation takes priority. Organisations should therefore map their management system and available evidence directly to applicable NIS2 and French requirements.

Cyber Threat Intelligence Metrics

Cyber threat intelligence metrics should measure whether intelligence improves security decisions and reduces exposure. Counting alerts, indicators or reports may show activity, but it does not prove that the programme is effective.

Useful metrics include:

• Time from threat publication to internal assessment

• Percentage of critical assets covered by relevant monitoring

• Time to remediate actively exploited vulnerabilities

• Percentage of material intelligence alerts resulting in action

• Number of detection rules updated from intelligence findings

• Supplier alerts reviewed and escalated

• Incidents detected through threat intelligence

• False-positive rates

• Time from assessment to escalation

• Executive actions completed

• Training updates linked to current threats

Metrics should be reviewed by audience. Security teams may need operational measures such as detection speed and remediation time, while management needs evidence of reduced exposure, completed actions and unresolved risk.

Avoid measures that reward volume without value, including the number of feeds purchased, indicators collected or reports distributed. A smaller programme that produces timely, relevant decisions is more effective than a large programme generating information that no one uses.

Common NIS2 Threat Intelligence Mistakes

Mistake 1: Buying threat feeds without defining requirements
Correction: Start with the organisation’s essential services, critical assets, suppliers, risks and decisions that intelligence must support.

Mistake 2: Treating all threats as equally important
Correction: Prioritise findings by relevance, source confidence, organisational exposure and potential business impact.

Mistake 3: Limiting intelligence to technical indicators
Correction: Combine technical data with strategic, operational and supply chain intelligence.

Mistake 4: Failing to assign actions
Correction: Every material finding should have a named owner, deadline, escalation level and documented outcome.

Mistake 5: Keeping intelligence within the security team
Correction: Provide tailored reporting to management, IT, procurement, legal, compliance and relevant business owners.

Mistake 6: Ignoring suppliers
Correction: Monitor threats affecting critical third parties, cloud platforms, software dependencies and subcontractors.

Mistake 7: Waiting for complete certainty before escalating
Correction: Use defined confidence, severity and impact thresholds to support timely escalation and incident assessment.

Mistake 8: Treating ISO certification as automatic NIS2 compliance
Correction: Map the organisation’s actual legal obligations to operational controls, records and evidence. Certification may support governance, but it does not replace regulatory analysis.

Practical NIS2 Threat Intelligence Roadmap

A phased roadmap helps organisations build threat intelligence capability without creating an unnecessarily complex programme.

Phase 1: Scope and governance

Determine whether the organisation may qualify as an essential entity. Identify critical services and supporting systems, assign executive and operational ownership, review the current French implementation status and establish a process for monitoring legal, regulatory and ANSSI updates.

Phase 2: Threat and asset understanding

Create an accurate asset inventory and identify the systems, data and suppliers supporting essential services. Define clear intelligence requirements, approve trusted information sources, map critical third parties and record the main threat scenarios that could disrupt operations.

Phase 3: Operational integration

Connect intelligence to vulnerability management, security monitoring and incident response. Define escalation thresholds, update detection rules, establish incident workflows, create management reporting and introduce regular supplier intelligence reviews.

Phase 4: Reporting readiness

Define the criteria for identifying a significant incident. Create 24-hour early-warning and 72-hour notification workflows, prepare reporting templates and coordinate NIS2 and GDPR assessments. Maintain current ANSSI and CERT-FR contact information and conduct a practical reporting exercise.

Phase 5: Assurance

Complete a ReCyF gap assessment, test incident-response procedures and review evidence-retention controls. Train management bodies, audit key measures and track corrective actions to completion.

The programme should also be reassessed after incidents, major supplier changes, new threats, system changes or updates to French NIS2 requirements. This helps ensure that threat intelligence remains connected to current risks, regulatory expectations and operational decisions.

NIS2 Cyber Threat Intelligence Compliance Checklist

Use this checklist to assess whether threat intelligence is integrated into your NIS2 preparation and cybersecurity risk-management programme.

Scope

• Have we assessed whether NIS2 applies to the organisation?

• Have we identified essential services and supporting systems?

• Are French transposition and ANSSI updates monitored?

• Have relevant entities, assets and systems been inventoried?

Governance

• Has management approved cybersecurity risk-management measures?

• Are executive and operational responsibilities documented?

• Does management receive useful, risk-based threat reporting?

• Are risk-acceptance and remediation decisions recorded?

Intelligence

• Have intelligence requirements been defined?

• Are sources assessed for reliability and confidence?

• Is intelligence relevant to our sector, services and assets?

• Are material findings converted into assigned actions?

• Are analysis and escalation decisions documented?

Risk management

• Is threat intelligence included in risk assessments?

• Are actively exploited vulnerabilities prioritised?

• Are critical suppliers and dependencies monitored?

• Are business continuity scenarios threat-informed?

• Are security controls tested against current threats?

Incident reporting

• Can significant incidents be identified quickly?

• Are 24-hour and 72-hour reporting workflows defined?

• Are NIS2 and GDPR assessments coordinated?

• Are logs, evidence and decision records preserved?

• Are reporting exercises conducted?

Training

• Has management received cybersecurity training?

• Are employees trained on current threats?

• Are specialists trained for their roles?

• Are training records retained?

Assurance

• Has a ReCyF gap assessment been completed?

• Are audits scheduled?

• Are remediation actions tracked?

• Is the programme reviewed after incidents and material changes?

Build the Capability to Implement NIS2

Turn NIS2 Requirements into an Operational Compliance Programme

NIS2 compliance requires more than collecting security alerts or purchasing new technology. Organisations need clear governance, structured risk assessments, incident-reporting procedures, supply chain controls, role-specific training and evidence that cybersecurity measures are operating effectively.

The French Compliance Institute’s NIS2 Lead Implementer Course is designed to help professionals understand the directive and develop a practical approach to implementation, governance, risk management and continuous improvement.

The course can support wider NIS2 readiness, but it should form part of an organisation-specific compliance programme based on applicable legal requirements, systems, services and risks.

Conclusion

NIS2 requires regulated organisations to implement proportionate technical, operational and organisational cybersecurity measures. Cyber threat intelligence supports this work by helping teams understand current threats, prioritise exposed systems and convert warning signals into action.

Intelligence should inform risk assessments, vulnerability management, supply chain security, incident handling, business continuity and executive oversight. French organisations should also monitor the evolving national transposition framework and use ANSSI’s ReCyF to support preparation and gap analysis.

Because NIS2 and GDPR reporting duties may apply to the same incident, organisations need coordinated escalation, evidence preservation and decision-making. Training should cover both management accountability and operational response.

Organisations that convert relevant threat information into documented security decisions will be better prepared to meet NIS2 expectations and respond effectively to cyber threats in France.