|6 min read|Yvann Lièvre

Your detection rules, mapped to NIS2 and ReCyF

Every ThreatClaw feed subscription now ships with a per-requirement coverage map for NIS2 and ReCyF, an OSCAL export, and a connector that pre-fills your GRC. Here is exactly how it works, and what it does not claim.

NIS2ReCyFComplianceOSCAL

Buying detection rules and buying a compliance answer have always been two separate purchases. A SIEM feed tells you what it detects, mapped to MITRE ATT&CK. A GRC tool tracks your controls, on paper. Nobody connects the two: which of your detection rules actually provide evidence for a given regulatory requirement, and where the gaps are.

That is what we just shipped. Every ThreatClaw feed subscription now includes a compliance layer, bundled at no extra cost.

What you get

For each requirement of NIS2 (the ENISA technical mapping) and of ReCyF (the French Cyber Reference published by ANSSI), the bundle tells you:

  • which of your rules cover it, typed by pack (detections, policy-as-code),
  • the gaps: requirements no rule addresses, including the ones that are purely organizational and cannot be covered by a rule at all,
  • an audit-ready report (HTML) and a machine-readable OSCAL export for your other tools,
  • an ATT&CK Navigator layer that shows your detection coverage visually.

How the mapping is built

The link is traceable end to end, and every step uses a public, redistributable source:

Sigma rule to ATT&CK technique to NIST 800-53 control (MITRE CTID) to CSF 2.0 subcategory (NIST OLIR) to NIS2 requirement (ENISA).

Your Sigma rules are already tagged with ATT&CK techniques. MITRE publishes the ATT&CK to 800-53 mapping. NIST publishes the 800-53 to CSF 2.0 references. ENISA publishes the NIS2 to CSF 2.0 table. We only join what already exists, using control identifiers, never the copyrighted text of the standards. For the French frameworks (ReCyF, SecNumCloud, HDS) we project through the intuitem CISO Assistant libraries, identifiers only.

Import it into your GRC

If you run a GRC such as CISO Assistant, a connector creates or updates your audit and, for each covered requirement, attaches a ThreatClaw evidence and control, then sets the requirement to "to review". You, or your CISO, validate and assert the final "compliant".

The connector never ticks your compliance on its own. That distinction matters: our layer proves the design (a rule exists that addresses the requirement), not the operating effectiveness in your environment over time, and certainly not a certification.

What it honestly does not do

We would rather lose the sale than overclaim, because an auditor sees through it immediately.

  • It is not a certification and not automatic compliance. Compliance is an organizational process that your CISO owns.
  • Coverage is partial by design. Many requirements are organizational (governance, staff training, supplier contracts) and no technical rule can cover them. We show them as gaps.
  • For DORA, there is no official EU crosswalk, so we scope narrowly and label it as non-official: we back the articles our rules directly support (detection, resilience testing), and our red-team pack supports the TLPT article without being the certified TLPT engagement.

Why it is bundled, not a separate product

A coverage map is only useful if you have the rules it maps. So the compliance layer ships with your feed subscription, scoped to the packs you actually take: a Sigma-only subscriber sees exactly what the Sigma feed covers, and what the policy pack would add. It makes the feeds more useful, it is not a product you buy on its own.

Already a subscriber? The compliance bundle lands with your next sync. New here? Start with the free demo pack and see the coverage for yourself.

Related articles