mapping-selection

Mapping Selection

Choose a control's structured references — components, risks, and framework mappings — and justify each. The failure this skill prevents is confident-but-wrong selection: mapping to "related" rather than directly-relevant items, over-mapping, mixing MITRE techniques with mitigations, or picking the wrong NIST AI RMF function.

Scope: both the control direction (a control's components/risks/mappings) and the risk direction (a risk's components/controls/mappings) — see the two sections below.

Procedure

1. Components — where the defense lives

Read risk-map/yaml/components.yaml. Select the components where the control's mechanism actually operates — the locus of the defense. Guidance:

• Prefer the specific components. Each one you list should be a place the control genuinely acts, not merely a place the risk appears.
• Use "all" only for a universal/governance/assurance control that genuinely applies framework-wide.
• Use "none" only when the control applies to no specific component.
• Do not over-select. If you are tempted to list five components, check whether the control is really one control or several.

2. Risks — what the control addresses

Read risk-map/yaml/risks.yaml. Select the risks this control directly mitigates. A mapping should be defensible in one sentence ("this control reduces the likelihood/impact of risk X because…"). Flag any that are merely "related." Be selective.

If you set risks: "all", the control is universal — and those risks must not list it back (application is implicit). "none" is not valid for risks.

3. Framework mappings — the discipline

Read references/frameworks-applicability.md for the rules. In brief:

• Applicability: map only to frameworks that apply to controls.
• MITRE ATLAS: controls map to mitigations (AML.M####), never techniques (AML.T####). If no mitigation fits cleanly, omit ATLAS rather than forcing a technique.
• NIST AI RMF: use the subcategory id (e.g., MEASURE-2.7), never the category alone, and pick the right function — this is the most common mistake:
  • GOVERN — policy, roles, responsibilities, oversight, culture, risk tolerance. Most preventive design and human-oversight controls land here.
  • MAP — establishing context, framing intended use, identifying impacts.
  • MEASURE — assessment, testing, metrics, evaluation, tracking.
  • MANAGE — responding to, prioritizing, treating, and recovering from identified risks (reactive/operational). Do not use MANAGE for a preventive design control.
• OWASP Top 10 for LLM: LLMxx:2025.
• EU AI Act: Article N@2024, only when the control implements a specific regulatory obligation (e.g. human oversight → Article 14). Do not force it onto a generic technical control — see references/frameworks-applicability.md's non-US counterbalance note (D3b).
• Selective: soft cap of 4 per framework; one-sentence rationale each.
• Generate, don't hand-spell: mapping values are version-pinned. For an entity that already has a row in the corpus, produce the value with scripts/framework_mapping_maintainer.py (ADR-027). For a control being drafted pre-PR (no row yet), the tool's composition step runs before entity lookup, meaning it will compose a value structurally even for a fabricated identifier — but add still requires a corpus row (real or a stub) to complete the command; without one, the command exits 1 at the lookup step. Pointed at a scratch copy of controls.yaml with a stub row for the not-yet-real id, add composes correctly. The real reason to hand-compose here isn't that the tool can't run (with a stub row, it can): it's that the tool gives no fabrication protection either way — it composes a plausible-but-nonexistent --framework-specific-ref exactly as readily as a real one, exit 0, no existence check, and a correctly hand-composed value is byte-identical in structure to a tool-generated one, so it passes the round-trip purity check just as cleanly. So compose the value directly against the pinned pattern in risk-map/docs/contributing/framework-mappings-style-guide.md, then verify it through audit-framework-mappings: single-entity mode, naming the real id, if controlXxx already has a row in controls.yaml; candidate mode, stating entity type control, if it's a pre-PR draft with no row yet. If the entity has no row yet (goes through candidate mode) and you are deliberately deferring any other value for that same framework to a later pass, say so — see Output format for the full scope-selection and deferred-value rules (rejecting a value as not directly relevant is not deferral and needs no declaration). This declaration only matters for candidate mode; single-entity mode has no drip-feed mechanism to route it to.