Strm Mapping

NIST IR 8477 STRM Mapping — GRC Toolkit Skill

When to Activate

Activate this skill whenever the user asks to:

• Map, crosswalk, align, or compare any two frameworks, catalogs, or control sets
• Create a STRM CSV output file between any two documents
• Perform a gap analysis between any source and target document
• Extend or verify an existing STRM mapping file

Working Directory

All work must be performed inside the working-directory/ folder at the repository root. Claude Code must be opened from the repository root so relative paths resolve correctly.

working-directory/

• Read input files from this directory or from knowledge/ and examples/ in the repo root.
• Write all in-progress and output files here.
• Never write output to the repo root or any other location.

Saving Completed Mappings

When a mapping is fully complete, create a dated artifact folder inside:

working-directory/mapping-artifacts/

Artifact Folder Naming Convention

YYYY-MM-DD_<FocalFramework>-to-<TargetFramework>

Use the same short framework names as the CSV file naming convention. Examples:

Use today's date (YYYY-MM-DD) at the time the mapping is completed.

Artifact Folder Contents

Place the following inside the dated folder:

Runtime Parameters

Before beginning any work, confirm both parameters with the user if they were not already specified in the request:

If the user provides only one document, ask which document it should be mapped to. Either document can be a proprietary catalog, a regulatory framework, an audit questionnaire, or any structured list of controls or requirements.

Step-by-Step Workflow

Scripts to Call (by Step)

1. Gather Source Files

Locate and read the relevant input files before generating any output:

knowledge/ir8477-strm-reference.md                    ← STRM methodology rules
working-directory/<source-document>.csv/.pdf/.md/.json/.yml/.toml      ← Focal document
working-directory/<target-document>.csv/.pdf/.md/.json/.yml/.toml      ← Reference document

Search for input files in this order:

1. working-directory/ — primary location for user-supplied inputs
2. Project root — for catalog CSVs or PDFs placed there
3. knowledge/ — for structured control definitions

When an input is JSON and uses HTML-tagged descriptions, run:

node scripts/bin/strm-extract-json.mjs <input.json> [output.csv]

Default output is working-directory/<framework>-extracted.csv with columns: controlId,title,family,description.

Write all intermediate files (extracted control lists, partial drafts) to working-directory/scratch/. Do not use system temp directories.

If a prior STRM file already exists for this source→target pair, read it first to avoid duplicates and maintain consistency.

2. Identify the Focal Document Element (FDE) and Reference Document Element (RDE)

• FDE = a single control or requirement from the source document
• RDE = a single control or requirement from the target document

Determine for each document:

• Full name and URL (or citation)
• Control ID format (e.g., D1.G.Ov.B.1, A.5.1, PR.AC-1, AC-2)
• Maturity or tier structure, if any
• The column or field that contains the control text

3. Assign STRM Attributes per Mapping Row

For each FDE → RDE mapping, assign all six STRM attributes:

Strength Score Calculator

strength = base_score + confidence_adj + rationale_adj
base_score  : equal=10  subset_of=7  superset_of=7  intersects_with=4  not_related=0
confidence  : high=0    medium=-1    low=-2
rationale   : syntactic=-1   semantic=0   functional=0
result      : clamp(strength, 1, 10)

Calibration Defaults

Observed Distribution Reference (calibration only)

4. Write the Output CSV

File Naming Convention

Set Theory Relationship Mapping (STRM)_ [(<FocalFramework>-to-<BridgeFramework>)-to-<TargetFramework>] - <FocalFramework> to <TargetFramework>.csv

• When the focal and bridge frameworks are the same (direct mapping), repeat the focal name in both slots: (NIST_CSF-to-NIST_CSF).
• Substitute actual framework names for <FocalFramework>, <BridgeFramework>, and <TargetFramework>.

Examples:

• Set Theory Relationship Mapping (STRM)_ [(NIST_CSF_2.0-to-NIST_CSF_2.0)-to-ISO_IEC_27001_2022] - NIST CSF 2.0 to ISO_IEC 27001 2022.csv
• Set Theory Relationship Mapping (STRM)_ [(FFIEC-to-FFIEC)-to-NIST_SP_800-53] - FFIEC to NIST SP 800-53.csv
• Set Theory Relationship Mapping (STRM)_ [(ISO_IEC_27017_2015-to-ISO_IEC_27001_2022)-to-CIS_Controls_v8] - ISO_IEC 27017 to CIS Controls v8.csv

Required CSV Structure (12 columns)

Row 1: FDE#,FDE Name,Focal Document Element (FDE),Confidence Levels,NIST IR-8477 Rational,STRM Rationale,STRM Relationship,Strength of Relationship,<Target> Requirement Title,Target ID #,<Target> Requirement Description,Notes
Row 2+: <data rows>

Column definitions:

5. Rationale Writing Pattern

The STRM Rationale field (Column F) must follow this structure:

<Source Framework> <FDE#> requires <what the FDE requires>. <Target Framework> <Target ID#> requires <what the target control requires>. Both <shared objective>.

Example (FFIEC → NIST SP 800-53):

FFIEC D3.PC.Am.B.4 requires periodic user access reviews for all systems. NIST SP 800-53 AC-2 requires managing information system accounts including periodic review of account authorizations. Both address periodic access review requirements.

For intersects_with mappings, conclude with the divergence:

Both address . additionally covers ; additionally covers .

6. Manual Adjudication Pass (Required Before Declaring Done)

Script-generated rows are a starting point only. Before validation and completion:

1. Review every mapping row manually.
2. Confirm STRM Relationship is defensible for the pair.
3. Re-check equal rows first:
   • If scope/mechanism differs materially, downgrade to intersects_with or subset_of/superset_of.
4. Re-check intersects_with rows:
   • If wording and scope are substantially identical, promote to equal.
5. Re-check subset_of/superset_of rows:
   • Verify containment direction is correct.
6. Ensure Notes explain why the grading was chosen for that row (no placeholder boilerplate).
7. Recompute strength using the formula after any relationship/confidence/rationale-type changes.
8. Save a manual-review log in the artifact folder:
   • Manual_Review_<Focal>-to-<Target>.md
   • Include at minimum: rows reviewed, rows changed, and the list of changed FDE IDs.
   • For every changed row, include a one-line rationale explaining why the relationship/confidence/rationale-type was changed.
   • Required per-row log format:
     • Row <n>: <FDE#> -> <Target ID #> (<old> => <new>) | Reason: <justification>

Transitivity Rules

When deriving indirect mappings (A→C via A→B and B→C):

Indeterminate = do not create a derived row; flag for manual review.

Inverse Relationships

When generating reverse mappings (Target → Source):

Quality Rules

1. Never leave Column F (Rationale) empty — every row needs a narrative.
2. Strength score must match the formula — do not guess; compute explicitly.
3. One FDE can map to multiple target controls — create one row per target control.
4. not_related rows are rare — only use when there is genuinely zero overlap.
5. Do not invent target control IDs — every Target ID # must come from the actual target document provided.
6. Confidence defaults to high — use medium only when interpretation or jurisdictional ambiguity exists; use low only when the mapping requires significant inference.
7. Focus on Baseline maturity first — when a framework has maturity tiers, prioritize baseline/foundational controls before advanced ones.
8. Adapt column header labels — replace <Target> in columns I and K with the actual target document name (e.g., ISO 27001 Requirement Title, ISO 27001 Requirement Description).
9. Run a relationship distribution self-check after all rows are complete:
   • If subset_of + superset_of = 0%, review equal rows; many may actually be subset_of.
   • If equal > 50%, review each equal row and confirm neither control explicitly requires more than the other.
   • If one control says "SHALL" and the other says "SHOULD", this is typically subset_of, not equal.
10. Manual QA is mandatory — never declare completion from script output alone.
11. Validation and gap report run after manual QA only — do not run post-completion checks in parallel with row generation.

Optional: Risk and Threat-Enriched Mappings

These inputs are ONLY used when the user explicitly requests risk or threat data. Do not load, reference, or incorporate these files in any standard framework-to-framework or control-to-control mapping unless the user specifically asks for it.

When to Activate

Activate this section only when the user says something like:

• "include risk data", "add threat context", "risk-to-control mapping"
• "threat-to-risk", "threat-to-control", "comprehensive mapping with risks/threats"
• "use the risk library", "use the threat library"

Source Files

Relationship Chain

Threat → Risk → Control

• Each risk (risk_id) links to controls via mapped_controls and to threats via threat_ids
• Each threat (threat_id) links to risks via mapped_risk_ids
• Risks already carry embedded STRM set_theory_relationships — use these when available

Specialized Mapping Types

Risk-to-Control

Use when the user wants to map risks from the library to framework controls.

• FDE = risk entry from risks.json (risk_id as FDE#, title as FDE Name, description as FDE text)
• RDE = target framework control
• Use the embedded set_theory_relationships[].relation and confidence_alignment from the risk record as starting points; override with independent analysis if needed
• Include likelihood and impact scores in the Notes column

Threat-to-Risk

Use when the user wants to map threats to risks.

• FDE = threat entry from threats.json (threat_id as FDE#, title as FDE Name, description as FDE text)
• RDE = risk entry from risks.json
• Derive the STRM relationship from the threat's materiality and the risk's scope
• Note threat_grouping (Natural, Manmade, Technical) in the Notes column

Threat-to-Control

Use when the user wants to map threats directly to framework controls (skipping the intermediate risk layer).

• FDE = threat entry from threats.json
• RDE = target framework control
• Traverse threat → risk → control chain to derive the relationship
• Apply transitivity rules — if any intermediate relationship is intersects_with, mark derived as indeterminate and flag for review

Output Naming for Risk/Threat Mappings

Follow the same artifact folder convention but reflect the mapping type:

Quality Rules (Risk/Threat specific)

• Never auto-include risk or threat files — wait for explicit user request
• Respect embedded STRM data in risks.json — do not contradict without justification
• Flag unmapped threats (mapped_risk_ids: []) in Notes — they require manual risk derivation
• Materiality fields in threats (pre_tax_income_5_percent, etc.) are informational — include relevant values in Notes if present

Existing Mappings in This Repository

Before starting a new mapping, search for existing files to avoid duplication. Run a glob across the project root and frameworks/ for any CSV whose name contains Set Theory Relationship Mapping or STRM. The file name pattern encodes both source and target, so it is the fastest way to check for prior work.

Template Reference

A blank STRM template lives at:

TEMPLATE_Set Theory Relationship Mapping (STRM).csv

Copy (do not modify) that file as the starting point, then rename the copy according to the file naming convention above.

Related Resources