data-quality: ISO 27001 and ISO 27002 mappings are identical for all 1020 M365 checks (should diverge)

[Daren9m]

Summary

data/registry.json currently maps every M365 check identically to BOTH iso-27001 and iso-27002 — 1020/1020 mappings are identical, 0 divergent. This is silently wrong: ISO 27001 (the ISMS standard) and ISO 27002 (the implementation guidance for Annex A controls) are different frameworks with overlapping but not identical control sets.

Surfaced by Galvnyz/M365-Assess#871 — M365-Assess has a Pester regression test (tests/Behavior/Iso-27001-27002-Mapping-Audit.Tests.ps1) currently -Skip:$true waiting for this upstream fix. Once corrected here, that test un-skips automatically on their weekly registry sync.

Why the two are different

• ISO/IEC 27001:2022 — the ISMS standard. Contains clauses 4–10 (process: risk assessment, internal audit, statement of applicability, management review) plus a normative reference to Annex A's 93 controls.
• ISO/IEC 27002:2022 — the implementation guidance for those Annex A controls. 93 controls, structured the same way as 27001 Annex A, but the document is the "how to implement" guide, not the certification standard.

A check verifying e.g. "MFA on admin accounts":

• Should map to ISO 27001 Annex A 8.5 (the control reference)
• Should map to ISO 27002 8.5 (the implementation guidance for that control)
• Should NOT map both to identical strings — the framework purposes are different even when the control numbers match.

For a check verifying e.g. "documented information security policy" (an ISMS-process control):

• Should map to ISO 27001 §5.2 (clause 5.2 — Policy)
• Should NOT map to ISO 27002 at all (27002 doesn't cover ISMS process clauses; only Annex A controls)

So the mappings should diverge in two ways:

1. Identical-numbered Annex A mappings still need different controlId semantics (A.X.Y vs X.Y — 27001 prefixes with A. because it's referencing Annex A explicitly)
2. ISMS-process controls have ISO 27001 mappings without ISO 27002 mappings

Reproducer

python -c "
import json
reg = json.load(open('data/registry.json', encoding='utf-8'))
identical = different = absent_27002 = absent_27001 = 0
for c in reg['checks']:
    fw = c.get('frameworks', {})
    has_27001 = 'iso-27001' in fw
    has_27002 = 'iso-27002' in fw
    if not has_27001 and not has_27002: continue
    if has_27001 and not has_27002: absent_27002 += 1
    elif has_27002 and not has_27001: absent_27001 += 1
    elif fw['iso-27001'].get('controlId') == fw['iso-27002'].get('controlId'):
        identical += 1
    else:
        different += 1
print(f'Identical: {identical}, Different: {different}, 27001-only: {absent_27002}, 27002-only: {absent_27001}')
"
# Currently: Identical: 1020, Different: 0, 27001-only: 0, 27002-only: 0
# Target: Different > 0 (Annex A mappings should use A.X.Y vs X.Y form);
#         27001-only > 0 (ISMS-process clause checks);
#         Identical: 0

Likely root cause

Probably one of:

1. data/scf-framework-map.json maps both iso-27001 and iso-27002 to the same SCF framework ID. The build then derives identical mappings.
2. SCF database controls_mappings table has identical entries for both framework IDs (upstream SCF data issue rather than CheckID).
3. Manual override path copies the 27001 mapping into 27002 (or vice versa) somewhere in Build-Registry.py.

Investigation: trace the build for one M365 check (e.g., ENTRA-ADMIN-001) and see where the iso-27001 + iso-27002 entries get populated.

Suggested fix scope

Path A — Different controlId formats (Annex A reference vs implementation guidance)

If ISO 27001 should always be A.X.Y and ISO 27002 should always be X.Y, the fix is mechanical: build-time format the SCF-derived ID with the appropriate prefix per framework. Verify that 27001's intent is "this check satisfies Annex A control X.Y" and 27002's intent is "this check implements 27002 guidance X.Y."

Path B — ISMS-process checks should have ISO 27001 only

Identify which CheckIDs map to ISO 27001 clauses 4–10 (ISMS process). Today these likely don't exist as ISO 27001 mappings at all (only Annex A). May want to file a separate issue if introducing ISMS-process coverage is in scope.

Path C — Both A and B

Most thorough. May warrant breaking into separate PRs.

Acceptance criteria

• Reproducer exit shows Different > 0 and Identical: 0 after fix
• Existing M365-Assess regression tests/Behavior/Iso-27001-27002-Mapping-Audit.Tests.ps1 un-skips and passes (their CI catches the change automatically on next registry sync)
• CHANGELOG documents the divergence model
• No regression in mapping count for either framework (additive or differentiation, not loss)

Cross-impact

• M365-Assess#871 — un-skip and tick the boxes in their audit doc
• The community example from M365-Assess#618 — a tenant with admin-MFA gap should NOT mark ISO 27001 as failing if MFA isn't an ISO 27001 §5.x ISMS-process clause. Verify this scenario after fix.

Out of scope

• ISMS-process check coverage (introducing checks for clauses 4–10) — separate issue
• ISO 27017 (cloud-specific) divergence — separate; v3.4.0 audit umbrella audit: comprehensive check-by-check narrative + coverage audit (MSFT + community sources) #326 noted iso-27017 as one of the 4 frameworks with no taxonomy yet (enhancement: backfill taxonomy for the 4 frameworks with none declared #323 covers)

Related

• M365-Assess#871 (the consumer test waiting on this)
• v3.4.0 audit umbrella audit: comprehensive check-by-check narrative + coverage audit (MSFT + community sources) #326 — ISO frameworks named in the multi-axis taxonomy spike spike: multi-axis taxonomy schema for frameworks #317
• enhancement: backfill taxonomy for the 4 frameworks with none declared #323 — taxonomy backfill for the 4 frameworks lacking declarations (iso-27017, gdpr, nis2, nist-800-171)

[Daren9m]

Prioritized — moved from Backlog to v3.5.0 — Cross-Cutting Reconciliation (M#44). Joins #386 and #387 as cross-cutting reconciliation work where the chosen Option determines whether implementation lands in v3.5.0 (additive) or v4.0.0 (breaking).

Current state confirmed at v3.4.0

Re-ran the reproducer against registry.json:schemaVersion=3.4.0 (1,105 checks):

Identical: 1020, Different: 0, 27001-only: 0, 27002-only: 0

Unchanged from when this issue was filed. The bug is still 100% present.

Root cause pinpointed

Of the 3 candidate causes in the issue body, candidate #3 is confirmed (Build-Registry.py mirrors the mapping). Found it at scripts/Build-Registry.py:832-835:

# iso-27002 mirrors iso-27001 — same Annex A control IDs, different semantic label
# (ISO 27001 = ISMS certification requirements; ISO 27002 = implementation guidance)
if "iso-27001" in frameworks:
    frameworks["iso-27002"] = OrderedDict(frameworks["iso-27001"])

The comment correctly identifies the semantic distinction but the code does a flat copy with no transformation. Compounding context: data/scf-framework-map.json already declares only iso-27001 with scfFrameworkId: [28, 29] (the union of ISO 27001 §4–§10 ISMS clauses + Annex A controls), per its own $comment. So the SCF-derived iso-27001 mapping already conflates the two underlying frameworks; the build then duplicates that conflation into iso-27002.

Recommended path (Path A from the issue body — semver-additive)

Replace lines 832–835 with a transformation that:

1. Keep iso-27001 referencing the union but use A.X.Y form for Annex A controls and §X.Y form for ISMS-process clauses (4–10). Today they're indistinguishable in the controlId string.
2. Derive iso-27002 by filtering out ISMS-process clauses (27002 doesn't cover them) and emitting the controlId in plain X.Y form (no A. prefix — 27002's structure is the same as Annex A but the document is the implementation guide, not the certification standard).

After fix, the reproducer should report:

• Different > 0 (Annex A mappings have A.X.Y vs X.Y)
• 27001-only > 0 (ISMS clauses live only in 27001)
• Identical: 0

This is additive for consumers reading iso-27001 (gains the A. prefix — string change, semantic preserved) and additive for iso-27002 (loses ISMS-process entries that should never have been there). M365-Assess#871 un-skip should pass on first try.

Semver routing

• Additive Path A (above) → ships in v3.5.0. The A. prefix on iso-27001.controlId is a string-format change but the underlying mapping is unchanged; consumers comparing controlId strings literal-equal will need updates, but consumers reading the mapping as "this check satisfies Annex A control X.Y" continue to work. Borderline-additive but defensible.
• Strict-additive variant — keep iso-27001 controlId unchanged (no A. prefix) and only fix iso-27002 to drop ISMS-process clauses + filter mappings. Pure additive. Defers the controlId-format question.
• Path B/C (introducing ISMS-process check coverage for clauses 4–10, breaking the assumption of no ISMS-clause coverage) → would route to v4.0.0 (M#45). Out of scope per the issue body.

Cross-impact

• M365-Assess#871 — Pester test tests/Behavior/Iso-27001-27002-Mapping-Audit.Tests.ps1 currently -Skip:$true. After this fix, their CI un-skips on next registry sync. Needs no upstream-side coordination beyond shipping.
• enhancement: backfill taxonomy for the 4 frameworks with none declared #323 (taxonomy backfill for 4 frameworks lacking declarations) — separate but related; iso-27017 is in enhancement: backfill taxonomy for the 4 frameworks with none declared #323 scope. iso-27001 and iso-27002 already have taxonomies declared — divergence here is about control mappings, not framework taxonomy.
• spike: multi-axis taxonomy schema for frameworks #317 (multi-axis taxonomy spike) — unaffected. The axes[] schema work is at the framework declaration level, not the per-check mapping level.

Suggested next step

A short PR that:

1. Picks the strict-additive variant (less argument)
2. Adds a regression test that asserts Different + 27001-only > 0 post-build
3. Updates the M365-Assess upstream tracking issue to flag the un-skip-ready state

Want me to draft this PR? Estimated 30-line build script change + a Pester gate + CHANGELOG entry.