feat(compliance): migrate the ISO 27001 mapping pack to ISO/IEC 27001:2022 (#358)

[parthrohit22]

What does this PR do?

Remaps the ISO 27001 mapping pack from ISO/IEC 27001:2013 to the 2022 Annex A. The 2013 transition period ended on 31 October 2025, so a report citing 2013 controls references a control set auditors no longer assess against.

Type of change

• Compliance mapping

What changed

• compliance/frameworks/iso27001.json: all 144 rules moved to 2022 controls. Framework is now ISO/IEC 27001:2022, version 2022, published 2022-10, mapping_pack_version 2.0.0 (new edition, so a major bump).
• Rule-by-rule method: each 2013 control moved to its published 2022 successor, for example A.9.4.2 to A.8.5, A.12.4.1 to A.8.15, A.13.1.1 to A.8.20, A.13.1.3 to A.8.22, A.12.6.1 to A.8.8. The 24 correspondences the pack uses were checked against a published 2013-to-2022 table.
• New 2022 controls where they fit better (6 rules, each a judgment call for review):
  • A.8.16 Monitoring activities: AZ-IDN-009, AZ-IDN-023, AZ-BAK-006, AZ-SECOPS-008, AZ-SECOPS-009. These are about alerting and detection coverage, not log production.
  • A.8.9 Configuration management: AZ-AKS-005 (Azure Policy governance on AKS).
• Left alone on purpose: the four N/A-STOR-* non-mappings and the PQC not_applicable entries keep their status. Every entry stays pending_review, so nothing starts counting towards a score.
• Each rule's own FRAMEWORKS["ISO27001"] (131 files in scanner/rules/) now matches the pack. Findings show that value, so it has to agree with what is scored. Before this PR the two agreed for all 144 rules.
• Descriptions that named a 2013 control by number were rewritten in our own words for the new control. Generic rule-specific sentences were kept.
• Docs and examples: docs/compliance-mapping-pack.md, the rules table, CONTRIBUTING/adding-a-rule/API examples, two blog posts and the compliance diagram.

Historical reports

Scans saved with a full mapping snapshot keep reporting against the 2013 controls they were scored with, since get_compliance_score reads the snapshot and not the file. A scan saved before full snapshots existed falls back to the pack on disk, and its mapping_provenance already says so. The 2013 pack is not kept as a legacy file, as decided in #358. docs/compliance-mapping-pack.md previously said older packs should be kept, so I added a section explaining this exception.

Testing

• Tested against a real Azure free trial subscription (N/A: metadata only, no scanner behaviour changes)
• tests/test_iso27001_2022_pack.py (9 tests): every control ID is a real 2022 Annex A control or a declared non-mapping, no 2013 numbering or edition label survives, names are consistent per control, and each rule's own ISO value equals the pack. Checked that they fail against the old pack and against a drifted rule.
• validate_mapping_pack.py passes
• Full suite with PostgreSQL: 1562 passed, 3 skipped. ruff check and ruff format --check are clean.
• Website builds (15 pages). verify-site needs a CMS OAuth client ID from the CI environment, so I left that to CI.
• No hardcoded credentials or secrets

Not in this PR

• compliance/assurance/physical_layer.json and the Physical Layer Assurance API use ISO 27001:2013 A.11 physical controls as their own catalogue. That is a separate feature and a follow-up.
• NIST CSF 1.1 to 2.0 and MCSB, which feat(compliance): migrate the ISO 27001 mapping pack from 2013 to ISO/IEC 27001:2022 #358 lists as follow-ups.
• Ordering: feat(compliance): migrate the ISO 27001 mapping pack from 2013 to ISO/IEC 27001:2022 #358 says to land after feat: add enterprise governance and tenant controls #292 and Feat (ci-rules) : Add AZ-CI-001..004 CI/CD workflow security rules (issue #259 PR 1/3) #280, which also edit iso27001.json. fix(compliance): make framework reports evidence-based and non-certifying #310 has merged. feat: add enterprise governance and tenant controls #292 and Feat (ci-rules) : Add AZ-CI-001..004 CI/CD workflow security rules (issue #259 PR 1/3) #280 are still open, so whichever lands second needs a rebase. New rules must now use 2022 control IDs, and the new test fails if a rule's ISO value drifts from the pack.

Related issue

Closes #358

Checklist

• Every commit includes a DCO Signed-off-by trailer
• I have not committed any real Azure credentials
• My branch name follows the convention: feat/description