Compliance-Ready Threat Intelligence: Defensible Evidence for ISO 27001, NIST CSF, DORA, and More

An external auditor sits across the table from your CISO. She has the ISO/IEC 27001:2022 controls open on her laptop. She asks one question:

“Walk me through your threat-intelligence program. I need to see sources, collection cadence, how the intelligence reaches analysts, and the decisions it informed in the last quarter.”

The honest answer in most organisations is some variation of “our SOC lead follows good people on social media, and we subscribe to Mandiant.” That answer used to work. Under Annex A 5.7 of ISO/IEC 27001:2022, it does not — because A.5.7 is a new control versus the 2013 edition, and the implementation guidance in ISO/IEC 27002:2022 §5.7 spells out three discrete layers (strategic, tactical, and operational) that the program is expected to address.

This is the gap Tradecraft Signal closes — not just for ISO 27001, but for the entire generation of cybersecurity frameworks that have been rewritten in the last three years to require evidenced, ongoing threat-awareness as an auditable practice rather than a passive subscription.

The compliance shift nobody wants to talk about

Look at what changed between roughly 2019 and 2024:

  • ISO/IEC 27001:2022 introduced Annex A 5.7 Threat Intelligence as a brand-new control. ISO 27002:2022 §5.7 expects strategic + tactical + operational layers, documented, with evidence of use.
  • NIST Cybersecurity Framework 2.0 (Feb 2024) elevated CTI from a side requirement to a top-line subcategory in two places: ID.RA-02 (intelligence received from sharing forums) and DE.AE-07 (intelligence integrated into adverse-event analysis).
  • NIST SP 800-53 Rev. 5 added RA-10 Threat Hunting as a dedicated control — previously, threat hunting was an implicit obligation buried inside System Monitoring (SI-4).
  • NIST SP 800-171 Rev. 3 retained the “Security Alerts, Advisories, and Directives” requirement (now 03.14.03) as a CMMC 2.0 Level 2 prerequisite. NIST SP 800-172 went further: §3.11.1e mandates using threat intelligence to inform architecture, monitoring, hunting, and response, and §3.11.2e mandates a documented threat-hunting capability — both required for CMMC Level 3 (“Expert”).
  • DORA (in force across the EU since 17 January 2025) made Art. 13 “Learning and evolving” a binding obligation for every financial entity in scope. Art. 24–25 require a digital operational resilience testing program; Art. 26–27 introduced TLPT (Threat-Led Penetration Testing) for significant entities, aligned with TIBER-EU — first deadlines around 17 January 2028.
  • NIS2 (Directive (EU) 2022/2555) makes baseline cyber-hygiene, training, and management-body engagement non-negotiable across essential and important entities.
  • NYDFS Part 500 (Second Amendment, November 2023) tightened §500.09 risk assessment, §500.04(c) annual CISO reporting to the senior governing body, and §500.16 IR-plan testing.
  • SEC Reg S-K Item 106 has been live since 2023 — every public registrant’s 10-K must describe processes for “assessing, identifying, and managing material risks from cybersecurity threats,” plus board oversight.
  • PCI DSS v4.0 / v4.0.1, HIPAA, SOC 2 (TSP 2017), APRA CPS 234, MAS TRM, OSFI B-13 — every regional regime has been pulled in the same direction.

The unifying thread: auditors no longer accept “we have threat intelligence” as a yes/no checkbox. They ask how you collect it, where it comes from, who reviews it, how it changes your defensive posture, and whether you can prove it was actually consumed. That last leg — evidence of use — is the one most CTI vendors don’t address at all.

What the auditor actually wants to see

Boil down every clause above and you get five concrete artefacts:

  1. A documented list of sources with collection cadence and a named curator policy.
  2. A taxonomy for organising and retrieving intelligence — ATT&CK-mapped, time-stamped, source-linked.
  3. Evidence of consumption — analysts actually engaged with the intelligence, not just that the subscription exists.
  4. Outputs that fed real decisions — risk assessments, detection priorities, hunt plans, exercise scenarios, board briefings.
  5. A forward-looking signal — emerging-threat identification, not just retrospective campaign reports.

Tradecraft Signal was built around exactly these five.

How Tradecraft Signal supports each compliance area

Threat-landscape monitoring as an auditable program

The curated operator feed runs on an hourly cadence, with every post enriched against MITRE ATT&CK at sub-technique granularity (T####.###) and shipped in STIX 2.1 / TAXII 2.1 — the structured exchange format NIST SP 800-150 explicitly recommends for cyber-threat information sharing.

That single combination — sources + cadence + structured enrichment + STIX/TAXII export — is what an auditor needs to satisfy clauses across ISO/IEC 27001:2022 Annex A 5.7, NIST CSF 2.0 ID.RA-02 / DE.AE-07, NIST SP 800-53 PM-16 / PM-16(1), NIST SP 800-171 Rev. 3 §03.14.03 (CMMC 2.0 Level 2), NIST SP 800-172 §3.11.1e (CMMC Level 3), PCI DSS Req. 12.3.1 / 12.10, HIPAA §164.308(a)(1)(ii)(A), 23 NYCRR §500.09 / §500.04(c), DORA Art. 13, NIS2 Art. 21(2), SOC 2 CC3.2 / CC7.2 / CC7.3, and SEC Reg S-K Item 106 — because they’re all asking the same underlying question with different vocabularies.

Feeding your risk-management cycle, framework by framework

The auditor isn’t impressed by a feed subscription on its own. They want to see the threat intelligence demonstrably feeding the risk-management decisions their framework requires. Every modern framework now has a named risk leg, and they each want a specific artefact. Here’s how Tradecraft Signal lands across the major regimes:

ISO/IEC 27001:2022 §6.1.2 risk assessment and §6.1.3 risk treatment. A.5.7 requires intelligence to be collected, analysed, and demonstrably used in risk and treatment decisions — not “we have a subscription.” Tradecraft Signal’s per-TTP weekly trend signals (rising / stable / fading direction labels) and statistical-surprise scoring become the documented likelihood input under §6.1.2; the ATT&CK coverage heatmap delta over time evidences treatment alignment under §6.1.3.

NIST CSF 2.0 ID.RA-05 likelihood-of-occurrence. Beyond ID.RA-02 (intelligence received), CSF 2.0 ID.RA-05 specifically requires “threats, vulnerabilities, likelihoods, and impacts” to inform risk-response prioritisation. The per-TTP velocity signals and surprise scoring are the documented likelihood input that satisfies this without resorting to gut feel. Consumption telemetry and the enterprise usage page cover the GV.RM governance leg.

NIST SP 800-53 RA-3 Risk Assessment. RA-3 expects threat intelligence to be one of the named inputs to the risk-assessment results, with documented action taken. Tradecraft Signal becomes the cited input source; the trend signals are the documented likelihood evidence; consumption telemetry shows the intel actually shaped the assessment; early-warning briefings cover the often-missed generation-side leg of SI-5 (the internal alerts the SOC itself must produce).

PCI DSS Req. 12.3.1 Targeted Risk Analyses (TRAs). Every TRA must document threats, likelihood, and impact, with named external sources. Payment-card-adjacent TTP-scoped exports become the named threat source cited in the TRA documentation. The per-TTP trend signals and surprise scoring become the documented likelihood input — and the same signals satisfy Req. 6.3.1 vulnerability ranking with threat context.

HIPAA §164.308(a)(1)(ii)(A) Risk Analysis — continuous, per OCR’s 2024 guidance. OCR was explicit in 2024: risk analysis must identify all reasonably-anticipated threats with named sources, ground likelihood in concrete data, and update when environmental or operational changes occur. Tradecraft Signal supplies the dated, sourced threat catalog for the risk register; the trend signals and surprise scoring become the likelihood input for ePHI-relevant scenarios (ransomware, credential theft, lateral movement); early-warning briefings are the documented “environmental change” trigger that prompts mid-cycle risk-analysis updates.

NYDFS §500.09 Risk Assessment + §500.04(c) CISO annual report. §500.09 requires annual review and mid-cycle updates whenever a “material change” to cyber risk occurs. The trend signals and surprise scoring are the documentary trigger for those updates — not “we noticed something changed.” For the §500.04(c) CISO annual report to the senior governing body, the ATT&CK coverage heatmap and diversity index feed the program-effectiveness section; reading-velocity totals and per-user drill-down evidence program adoption directly.

DORA Art. 13(3) and 13(4) — risk-evolution mapping. Art. 13(3) requires lessons and external knowledge to be “duly incorporated on a continuous basis into the ICT risk assessment process.” Art. 13(4) goes further: the entity must “map the evolution of ICT risk over time” and analyse “frequency, types, magnitude and evolution of ICT-related incidents and their patterns.” Tradecraft Signal’s per-TTP weekly trends, surprise scoring, and feed of newly observed TTPs are the evolution-of-risk mapping artefact — there’s no second tool needed for Art. 13(4). Consumption telemetry and the ATT&CK coverage heatmap evidence the Art. 13(3) ingestion. Enterprise reading-velocity, diversity index, and per-user drill-down feed the Art. 13(5) yearly report to the management body.

NIS2 Art. 21(1) proportionality + Art. 21(2) baseline measures. Art. 21(1) requires every measure to be calibrated to the entity’s risk exposure and the likelihood of occurrence of incidents and their severity. Proportionality demands a likelihood input. The per-TTP trend signals are exactly that. From there, each baseline measure under Art. 21(2) gets its own evidence artefact:

  • (a) risk-analysis policies — STIX/TAXII feed + trend dashboards as documented threat input
  • (b) incident handling and (c) business continuity — TTX scenarios generated from dated, source-linked tradecraft
  • (d) supply-chain security — technique-scoped feeds per supplier/vendor stack (Okta, Snowflake, AWS, GitHub, etc.)
  • (e) vulnerability handling and disclosure — trend evidence and surprise scoring feeding the SSVC Exploitation parameter
  • (f) policies and procedures to assess the effectiveness of risk-management measures — ATT&CK coverage delta over time + consumption telemetry
  • (g) cyber-hygiene practices and training — defensive analyses and TTX scenarios reusable as training material

SOC 2 CC3.2 risk identification. CC3.2 expects documented identification and analysis of risks affecting service-objective achievement, with named external inputs. Per-TTP trend dashboards and the underlying STIX bundle records become the named inputs cited verbatim in CC3.2 risk-register review minutes. Threat-landscape velocity feeds CC7.2 anomaly context; early-warning surprise scoring is the documented upstream signal informing CC7.3 event evaluation.

SEC Reg S-K Item 106 — material and emerging risks. The 10-K must describe processes for “assessing, identifying, and managing material risks from cybersecurity threats” — and Item 106 specifically asks for the processes that identify emerging risks, not just known ones. Tradecraft Signal becomes one cited input source in the processes description; the feed of newly observed TTPs and the per-TTP trend signals specifically answer the “emerging” question that traditional retrospective CTI feeds struggle with.

The point in every case above is the same: this isn’t a marketing claim that Tradecraft Signal “supports” the clause — it’s the specific artefact your team would hand an auditor when they ask “show me where this risk decision was informed by current threat intelligence.”

Tabletop exercises that auditors can actually defend

The TTX generator produces scenarios from real, dated, source-linked TTPs drawn from the live operator corpus. That directly answers the auditor question every framework asks but most exercise programs fumble: “How did you pick this scenario?”

The same generated artefact — exported with source links, ATT&CK technique IDs, and a dated after-action report — satisfies DORA Art. 24, PCI DSS Req. 12.10.2, NIST IR-3, NIS2 Art. 21(2)(g), 23 NYCRR §500.16, NERC CIP-008-6 R2, and ISO 22301:2019 §8.5 in one pass. For DORA-scope financial entities preparing TLPT engagements (Art. 26–27, TIBER-EU aligned), the underlying tradecraft trend data feeds directly into the intelligence-led red-team scenario.

Detection engineering and threat hunting

Two adjacent compliance asks share the same evidence stack: an ATT&CK technique-coverage heatmap (populated from actual analyst engagement) and a corpus of Sigma and YARA detection content reusable as SOC starter material.

For threat hunting specifically — newly mandated as NIST SP 800-53 RA-10, and amplified for CUI / CMMC Level 3 organisations under NIST SP 800-172 §3.11.2e — auditors want evidence that hunts are informed by current adversary tradecraft, not gut feel. The per-TTP trend signals plus the TAXII feed scoped to specific techniques become the documentary input for hunt logs that cite source bookmarks back to their original URLs.

MITRE-grounded defensive analysis per bookmark

Every bookmark tagged with an ATT&CK technique gets a defensive write-up whose CAR (MITRE Cyber Analytics Repository) analytic references and ATT&CK mitigation IDs are pulled deterministically from canonical MITRE data — not improvised by an LLM. The system is constrained to use only those records, eliminating the “did the AI invent this M-code?” auditor question at source.

The compliance value: it converts a generic ATT&CK heatmap into something concrete and individually testable. Instead of “we cover T1055,” the artefact reads “we surface CAR-2014-11-002 with its process_creation data-source requirement, and M1040 as the linked mitigation, for T1055.” That’s the kind of named, deployable, data-source-aware detection content that NIST SI-4(24) (Indicators of Compromise) and DE.AE-07 (CTI integrated into analysis) actually want as evidence.

A SOC can join that against its log inventory to identify genuine detection gaps — which CAR-published analytics are deployable in our environment, and which require data sources we don’t yet collect? That gap analysis is the defensible artefact.

Vulnerability prioritisation with threat context

NIST SP 800-53 Rev. 5 RA-5 vulnerability monitoring and RA-7 Risk Response — supported by NIST SP 800-40 Rev. 4 Enterprise Patch Management Planning — all require risk-based prioritisation that uses threat context, not CVSS scores in isolation.

Tradecraft Signal’s trend evidence (“technique X has been actively used by red teams across N posts in the last 30 days”) provides the documentary basis for setting CISA SSVC’s Exploitation parameter to “active” rather than “PoC” or “none.” Paired with CISA KEV and BOD 22-01 for federal civilian agencies, the platform supplies the TTP-level context for the same vulnerability classes being weaponised — turning a CVSS-only triage into a defensible, threat-informed prioritisation.

Evidence of use — the leg most CTI vendors don’t cover

Most threat-intel obligations explicitly require evidence that the intelligence was consumed, not just subscribed to. ISO/IEC 27002:2022 §5.7 implementation guidance, NIST PM-16, DORA Art. 13(2) (“use the knowledge gained from external sources”), PCI DSS Req. 12.6.2 (annual review of the awareness program) — all expect the auditor’s “how do you know your analysts actually used this?” question to have a real answer.

Tradecraft Signal records consumption events directly (deduplicated per user, per piece of content, per source channel), and surfaces three artefacts an auditor immediately understands:

  • An ATT&CK technique-coverage heatmap per user and per enterprise — direct evidence that analyst attention is mapped to a recognised framework.
  • A diversity index over month / year / all-time — defends against the “you’re only reading the same five sources” concern, and is the most direct evidence of ISO/IEC 27002:2022 §5.7’s strategic / tactical / operational layering.
  • Reading-velocity trends, top engaged TTPs, new TTPs this period, and per-user drill-down at the enterprise scope — the consumption-and-adoption narrative the CISO can cite verbatim in NYDFS §500.04(c) annual reports and that procurement / internal audit asks for at licence renewal.

Early-warning briefings — the generation leg of SI-5

NIST SP 800-53 SI-5 has an often-overlooked obligation: organisations must not only receive security alerts, advisories, and directives — they must also generate them internally when watched indicators cross defined thresholds. Most CTI vendors don’t address this leg at all.

Tradecraft Signal’s early-warning feature automates the generation side: per-user watchlists with configurable statistical-surprise thresholds, scheduled briefings (hourly / daily / weekly) with deterministic stats grounded beneath the LLM-generated narrative, an immutable briefing record, and an auditable alert trail with read/dismissed status. The deterministic stats block is reproducible from the same inputs — a property most LLM-generated CTI does not have, and the one that survives an auditor disputing the narrative.

This maps to SI-5, NIST CSF 2.0 DE.AE-02 / DE.AE-06 / DE.AE-08, ISO/IEC 27001:2022 A.5.24 / A.5.26, PCI DSS Req. 12.10.5, HIPAA §164.308(a)(6)(ii), NYDFS §500.16(a) (upstream of the §500.17 72-hour reporting trigger), DORA Art. 13(1) (upstream of Art. 17 major-incident reporting), NIS2 Art. 21(2)(b) (upstream of Art. 23 reporting), and MAS TRM Section 13 Cyber Threat Surveillance — which is a near-exact match.

Forecasting and emerging-threat identification

Risk-management clauses that demand forward-looking, likelihood-weighted inputs are the hardest to evidence with traditional CTI feeds. Tradecraft Signal exposes per-TTP weekly trend signals with a rising / stable / fading direction label, and a feed of TTPs first observed in the period. These map to NIST CSF 2.0 ID.RA-04 / ID.RA-05 (likelihood of threats exploiting vulnerabilities), NIST SP 800-30 Rev. 1 likelihood-of-occurrence input, ISO/IEC 27001:2022 §6.1.2 risk-assessment process, DORA Art. 13(1) “analyse the impacts [threats] are likely to have on digital operational resilience,” APRA CPS 234 ¶24 (“commensurate with the rate at which threats and vulnerabilities change” — TTP-velocity is the documentary evidence of that rate), and SEC Reg S-K Item 106 identification of emerging material risks.

Board and executive reporting

SEC Reg S-K Item 106(c) requires describing board oversight of cyber risk in the 10-K. NYDFS §500.04(c) requires the CISO to report annually to the senior governing body on “material cybersecurity issues such as significant cybersecurity events and the overall effectiveness of the cybersecurity program.” NIS2 Art. 20 holds management bodies accountable and requires training.

The tradecraft analytics — paired with the enterprise reading-velocity, diversity-index, and ATT&CK-coverage views — give the CISO a defensible, externally-sourced and internally-evidenced narrative for these reports. Not “we believe we’re well-positioned” — instead, “here’s the rate of new technique observation in our space, here’s our coverage versus the corpus, here’s how our consumption changed quarter-over-quarter.”

Complement, not replacement

Tradecraft Signal is positioned as a complement — not a replacement — for incumbent CTI vendors (Mandiant, Recorded Future, CrowdStrike, Flashpoint, Intel 471). The compliance argument to procurement is precise:

  • Strategic intelligence (actor motivation, geopolitical drivers, board-level briefings) → traditional CTI vendor
  • Operational intelligence (campaigns, malware families, IOC packages, sector targeting) → traditional CTI vendor
  • Tactical / tradecraft intelligence (TTPs being used right now by operators, hourly tempo) → Tradecraft Signal

ISO/IEC 27002:2022 §5.7 explicitly enumerates all three layers. A defensible program addresses them with the right tool: incumbent CTI for strategic + operational, Tradecraft Signal for the tactical layer that incumbents historically under-serve. Most enterprise buyers run both — because A.5.7 expects all three layers and one vendor cannot cover them well.

Cyber-insurance and procurement

Major carriers’ questionnaires (Marsh Cyber Self-Assessment, Aon CyQu, Munich Re, Beazley, AXIS) include explicit items on (a) subscribing to a threat-intelligence service, (b) conducting tabletop exercises at least annually, and (c) maintaining ATT&CK-mapped detection coverage. Tradecraft Signal lets the buyer answer “yes” to all three with artefacts — not aspirations.

Honest about what we don’t yet do

Compliance documents that overclaim get torn apart at audit. We maintain a clause-by-clause compliance-coverage document (available on request from your account team) that names every framework clause supported alongside the corresponding evidence artefact, and is explicit about the gaps a buyer will raise — vendor-level SOC 2 Type II / ISO 27001 certifications (in scope for the roadmap), immutable retention SLA tied to sectoral anchors (HIPAA 6 years, SOX 7 years), TLP-aware tagging per NIST SP 800-150, confidence / source-reliability scoring, a model card for the forecasting math, and broader REST/webhook exposure for the analytics and early-warning surfaces.

Disclosing these upfront is what makes the rest of the document defensible. We’d rather lose a deal to a buyer who needs SOC 2 Type II today than win one and fail the audit twelve months later.

What this means for your next audit

If you’re a CISO preparing for an ISO 27001:2022 surveillance audit, a DORA readiness review, a NYDFS examination, a PCI assessment, or an SEC 10-K cybersecurity disclosure — the question is not “do we have a threat intelligence subscription?” It’s “can we produce, on demand, the named artefacts each framework actually expects?

That’s the work Tradecraft Signal does. The compliance value isn’t in being yet another CTI feed — it’s in being the evidenced, dated, source-linked, ATT&CK-mapped, consumption-tracked, forecast-equipped, board-reportable operational layer that the new generation of frameworks now requires and that incumbent vendors weren’t built to provide.

Access Tradecraft Signal, or contact us if you want a walkthrough of how each artefact above maps to your specific framework obligations.