by Tradecraft Signal

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

complianceenterpriseGRCaudit

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 carries the “Security Alerts, Advisories, and Directives” requirement — 3.14.3 in Rev. 2, renumbered 03.14.03 in Rev. 3. Note the version pin: CMMC Level 2 is assessed against the 110 requirements of Rev. 2, incorporated by reference in 32 CFR Part 170; moving CMMC to Rev. 3 requires fresh rulemaking. 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 sit in the 24-requirement subset CMMC Level 3 (“Expert”) draws from the Feb 2021 edition. NIST published SP 800-172r3 in May 2026, which renumbers the enhanced requirements into the 03.11 series, but CMMC Level 3 stays pinned to Feb 2021 until DoD updates the rule.
  • 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(b) annual written CISO reporting to the senior governing body — with §500.04(c) adding a standing duty to report timely on material cybersecurity issues between those annual reports — 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.1 (the only active version since v4.0 retired on 31 December 2024), 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 formats NIST SP 800-150 identifies for automated 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 3.14.3 / 03.14.03 (Rev. 2 / Rev. 3 — CMMC Level 2 is assessed against Rev. 2), NIST SP 800-172 3.11.1e (CMMC Level 3, Feb 2021 edition), PCI DSS Req. 12.3.1 / 12.10, HIPAA §164.308(a)(1)(ii)(A), 23 NYCRR §500.09 / §500.04(b), 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. (HHS’s January 2025 Security Rule NPRM would make an annual risk analysis explicit, but it remains proposed — final action has slipped to 2027 on OMB’s agenda — so today’s obligation still rests on the existing rule plus OCR guidance.)

NYDFS §500.09 Risk Assessment + §500.04(b) 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(b) CISO annual written report to the senior governing body, the ATT&CK coverage heatmap and diversity index feed the overall-program-effectiveness section; reading-velocity totals and per-user drill-down evidence program adoption directly. The separate §500.04(c) duty to report timely on material cybersecurity issues between annual reports is where the early-warning briefings land.

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 — describing the identification process. Item 106(b) requires the 10-K to describe processes for “assessing, identifying, and managing material risks from cybersecurity threats.” The rule text does not use the word “emerging” — but the obligation is to describe a process that identifies risk, and a purely retrospective feed is hard to defend as identification rather than confirmation. Tradecraft Signal becomes one cited input source in the processes description; the feed of newly observed TTPs and the per-TTP trend signals are what make the identification leg concrete.

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 (Feb 2021 edition, the one CMMC assesses against; renumbered into the 03.11 series by SP 800-172r3 in May 2026) — 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(3) (external knowledge and lessons “duly incorporated on a continuous basis into the ICT risk assessment process”), 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(b) 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 §12 Cyber Security Operations — cyber event monitoring and detection plus cyber threat intelligence and information sharing, 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 ¶27–28 (a systematic testing program whose nature and frequency is “commensurate with the rate at which the vulnerabilities and threats change” — TTP-velocity is the documentary evidence of that rate), and SEC Reg S-K Item 106’s requirement to describe the process by which material cybersecurity risks are identified.

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(b) requires the CISO to report in writing at least annually to the senior governing body on the cybersecurity program, material cybersecurity risks, the overall effectiveness of the program, and material cybersecurity events — with §500.04(c) requiring timely reporting on material cybersecurity issues in between. 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.