Compliance & Threat Intelligence

Cybersecurity compliance used to mean a once-a-year risk assessment, a binder of policies, and a quiet week before the auditor arrived. That model is gone. Today, ISO/IEC 27001:2022, the EU's NIS2 Directive, and the Digital Operational Resilience Act (DORA) all expect the same thing: prove that your controls reflect the threats your organisation actually faces, and that you keep them current.

That expectation is what threat intelligence is for. Instead of writing risk scenarios from imagination, you write them from what attackers are doing right now. Instead of static control evidence, you generate continuous, traceable signals.

Why the Regulatory Bar Moved

Three regulatory shifts converged between 2022 and 2024, and they share the same logic: paper-based controls cannot keep up with modern adversaries.

ISO 27001:2022 introduced Annex A 5.7 — Threat Intelligence, a mandatory control with very few allowable exclusions. NIS2 Article 21 asks for risk analysis, supply-chain monitoring, and incident handling to be informed by the threat context relevant to your sector. DORA forces financial entities to run threat-led penetration testing (TLPT) under TIBER-EU, with a structured threat-intelligence phase at the front of every test.

The shared message is the same: if your risk register was written last year, it is already out of date.

What a Compliance-Ready Intelligence Practice Looks Like

A small number of habits separate a team that "uses threat intelligence" from one that can stand behind it in front of an examiner.

The first habit is writing risk scenarios from real activity. When a sector-specific campaign appears in your feed, it goes into the register as a named scenario, not as a generic "phishing" line item. The second is provenance by default — every IOC, TTP, or actor reference carries a source so the auditor can trace it. The third is recency: dated within days, not months. And the fourth is closure — every piece of intelligence has a trail showing it changed something: a SIEM rule, an IR playbook, a risk score, a policy line.

If you have those four habits, the framework-specific evidence almost generates itself.

How the Frameworks Compare

They differ in scope, sector coverage, and reporting obligations, but the underlying patterns are remarkably similar. Risk analysis must be evidence-based. Vulnerability management must reflect active exploitation, not static CVSS. Incident response must be tested against realistic scenarios. Supply chains must be monitored continuously, not annually. Training content must reflect the threats your staff actually face.

The biggest practical difference is in who the regulator is and when you must report. NIS2 demands CSIRT notification inside 24 hours for significant incidents. DORA demands a documented TLPT cycle for significant financial entities. ISO 27001 has its own certification rhythm. None of that changes the underlying intelligence work — only the packaging.

Common Mistakes

• Treating each framework as a separate project, which triples the workload and dilutes the intelligence work
• Feeding auditors screenshots and PDF reports instead of structured, dated, source-linked records
• Buying a threat feed and assuming that satisfies the requirement — examiners want to see the intelligence in use, not on a shelf
• Writing "annual" threat assessments once a year and hoping no one notices the months of staleness in between
• Ignoring supplier and third-party risk because it is harder to monitor than your own perimeter

Next Steps

If you are new to the topic, start with the fundamentals in our CTI primer, then explore the framework-specific pages: ISO 27001:2022, NIS2, and DORA.