Docs

Appearance

ISO/IEC 27001:2022 Annex A (how to use it) ​

ISO/IEC 27001 includes Annex A (normative): an information security controls reference. Annex A is often where teams get stuck — either by treating it as “the checklist” or by treating it as “someone else’s problem”.

This page is a practical guide to using Annex A as a control baseline without reproducing the standard.

What Annex A is (and isn’t) ​

Annex A is:

  • a structured reference list of common information security controls
  • a practical starting point for a control catalog
  • a tool to ensure your risk treatment is systematic and defensible

Annex A is not:

  • a guarantee of security (“we implemented Annex A” is not a security claim)
  • a substitute for risk assessment and context
  • a reason to create a spreadsheet that no one operates

How to use Annex A effectively ​

1) Start with scope and risk ​

Controls should follow from your ISMS scope and risk method. If your scope is unclear, Annex A selection becomes arbitrary.

2) Make applicability decisions (explicitly) ​

For each control you consider:

  • decide whether it applies in your scope
  • record the rationale (especially for exclusions)
  • define what “implemented and operated” means

This is where many organizations create a “statement of applicability” style record (format varies by org).

3) Translate control intent into operable work ​

Turn controls into:

  • owned work (who runs it)
  • cadence (how often it’s executed/reviewed)
  • evidence expectations (what artifacts exist)
  • escalation paths (what happens when it fails)

4) Prefer control reuse across frameworks ​

Many security controls support multiple governance programs. Reuse is the point:

  • implement a control once
  • map it to multiple requirements across frameworks
  • link evidence once and preserve the narrative

What auditors typically test ​

Auditors usually test operation and evidence, not just existence:

  • can you show the control operating in the stated period
  • can you trace evidence to the control claim
  • can you show reviews, exceptions, and corrective actions
  • do your applicability decisions make sense for your scope

Common failure modes ​

  • Checklist compliance: “we have all Annex A controls” with thin/no evidence.
  • Paper controls: procedures exist, but execution records do not.
  • Unowned controls: controls exist but no one runs them on a cadence.

How this maps into Modulos ​

In Modulos, Annex A typically becomes:

  • requirements and controls that teams execute
  • evidence attached to control components (sub-claims)
  • reviews for traceable approvals and separation of duties
  • exports for point-in-time audit packs

Disclaimer

This page is for general informational purposes and does not constitute legal advice.