Skip to content

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

Description

@parthrohit22

What problem does this solve?

compliance/frameworks/iso27001.json maps every rule to ISO/IEC 27001:2013 Annex A (e.g. A.9.4.2, A.12.4.1, A.13.1.1). The transition period to the 2022 edition ended on 31 October 2025, so certificates against 2013 are no longer valid. An ISO report from OpenShield now cites a control set auditors no longer assess against, which undermines the evidence-based reporting work in #302.

Describe the solution

  • Remap every rule to the 2022 Annex A structure (93 controls in 4 themes: A.5 Organizational, A.6 People, A.7 Physical, A.8 Technological). Most of our rules land in A.8. Examples:
    • A.9.4.2 Secure log-on procedures → A.8.5 Secure authentication
    • A.12.4.1 Event logging → A.8.15 Logging
    • A.12.6.1 Technical vulnerabilities → A.8.8 Management of technical vulnerabilities
    • A.13.1.1 Network controls → A.8.20 Networks security
    • A.13.1.3 Segregation in networks → A.8.22 Segregation of networks
  • Use the new 2022 controls where they fit better than a legacy one: A.8.9 Configuration management, A.8.16 Monitoring activities, A.5.23 Information security for use of cloud services.
  • Bump mapping_pack_version, update version / published, and keep every entry's review_status: pending_review until a maintainer reviews it. validate_mapping_pack.py must pass.
  • Scans are stamped with the mapping-pack snapshot (bug(compliance): make framework reports current, evidence-based, and non-certifying #302), so historical reports keep showing the 2013 pack they were produced with. No retroactive reinterpretation.
  • Follow-ups, tracked separately: NIST CSF 1.1 → 2.0, and adding Microsoft Cloud Security Benchmark (MCSB).

Sequencing: #310, #292 and #280 all modify iso27001.json. This remap should land after them (or they rebase onto it), so the 2022 migration covers their new rules too and nobody resolves a 150-entry conflict.

Alternatives considered

Keeping 2013 alongside 2022. Rejected as the default: it doubles the maintenance for a withdrawn standard. The snapshot already preserves 2013 for old scans.

Additional context

Refs #302.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

enhancementNew feature or requestpriority: highImportant, should be fixed in the current sprint

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions