ISO 27001 Annex A Controls: Who Owns What, and Where the Evidence Lives

What does an ISO 27001 audit ask you to prove, and who has to prove it? Annex A holds most of the answers. It lists the 93 information security controls certified organizations choose from, and it sets what an auditor asks to see.

For most businesses the pressure to certify comes from outside. Enterprise, financial, and government buyers want the certificate before they sign, so a delayed audit becomes a delayed contract.

The work splits unevenly. Policies and risk records belong to the compliance function, while roughly a third of the controls can only be evidenced from the systems IT runs every day. Annex A names outcomes and leaves the mechanism to you, so two organizations with identical cybersecurity compliance obligations end up with very different evidence workflows.

In this blog, you will see all 93 Annex A controls by theme, what changed in 2022, which controls IT operations owns, the evidence an auditor asks for against each, the five places that evidence goes missing, and where ownership falls between IT, HR, legal, and facilities.

What is ISO 27001 Annex A?

ISO 27001 Annex A is a reference list of 93 information security controls that an organization draws on when deciding how to treat the risks its information security management system has identified. It works as a catalogue that your risk assessment selects from.

Three properties of the annex shape how you should read it:

• A reference set: Applicability is decided by your risk assessment, and any control addressing no identified risk can be excluded with a written justification

• Outcomes only: Each control is a single line describing a result, with no implementation detail attached

• Full coverage in the Statement of Applicability: This document records a decision for all 93 controls, including the ones you exclude

Two organizations can satisfy the same control in completely different ways and both pass, provided each can trace the choice back to a risk.

What is the ISO 27001 Framework, and Why does Annex A Matter?

The ISO 27001 framework is the international standard for building and running an information security management system, made up of mandatory management requirements in Clauses 4 to 10 plus the Annex A control reference.

Certification against it earns three things a self-declared security policy cannot:

• Independent verification: An accredited body confirms the management system operates the way your documentation claims

• Shorter buyer reviews: Enterprise, financial, and government customers accept the certificate in place of a bespoke security assessment

• A recurring discipline: Surveillance audits happen annually, so the risk assessment and its evidence cannot go stale unchallenged

Annex A matters because it is where the framework becomes specific. The clauses tell you to treat risk without saying how, and Annex A supplies the vocabulary that auditors, procurement reviewers, and security questionnaires all share. When a prospect asks how you handle logging, "A.8.15, implemented, reviewed monthly" answers faster than a paragraph of description.

How Annex A Relates to Clauses 4 to 10

Clauses 4 through 10 carry the mandatory ISO 27001 requirements, covering context, leadership, planning, support, operation, performance evaluation, and improvement. Every certified organization has to meet all of them. Clause 6.1.3 only requires you to compare your chosen risk treatments against Annex A and confirm nothing necessary has been left out.

An auditor examines both, and the questions differ:

• Clause questions: Who owns the ISMS, how was risk assessed, when was the last management review

• Annex A questions: Which controls apply, why were others excluded, and where is the evidence each applied control is operating

How does Risk Treatment Under Clause 6.1.3 Work?

Clause 6.1.3 sets the sequence that produces your control selection, and the comparison against Annex A comes at the end of it. This is ordinary IT risk management applied to information security, written down so an outsider can follow the reasoning. Four steps run in order:

1. Identify risks: Record the risks to confidentiality, integrity, and availability inside your ISMS scope

2. Choose a treatment option: Modify, retain, avoid, or share each risk

3. Determine the controls needed: Decide what has to be in place to carry out the treatment you chose

4. Compare against Annex A: Confirm nothing necessary was left out

The order matters. Every control exists to bring a specific identified risk down to a level the organization accepts, so a control with no risk behind it has no justification to write in your Statement of Applicability. You are also free to implement controls appearing nowhere in Annex A when your risk assessment calls for them.

What is the Difference Between ISO 27001 and ISO 27002?

ISO 27001 is the certifiable standard, containing the management system requirements and the Annex A control reference. ISO/IEC 27002:2022 is guidance that expands those same 93 controls into implementation detail, purpose statements, and attributes.

The numbering matches exactly, so a control listed as A.8.15 in Annex A appears as 8.15 in ISO 27002. Buy both if you are implementing, since the annex alone gives you titles with no guidance behind them.

What are the 93 Controls in ISO 27001 Annex A?

The 93 controls in ISO 27001 Annex A are grouped into four themes, replacing the 14 domains used in the 2013 version. The full Annex A controls list runs from A.5.1 to A.8.34, and the themes carry very different weights, from 8 controls at the smallest to 37 at the largest.

Auditors work theme by theme, so knowing which block a control belongs to shortens every evidence request. The table below sets out the four themes, their control ranges, and what each one covers.

Which Annex A Themes Reach Into IT Operations?

Organizational controls carry most of the governance weight, though several reach straight into IT: A.5.9 asset inventory, A.5.23 cloud service use, and A.5.24 through A.5.28 for the incident lifecycle. People controls draw mainly on HR records, with A.6.8 event reporting running through the service desk. Physical controls stay with facilities apart from A.7.9, A.7.10, and A.7.14, which trace back to the asset register.

Technological controls generate more operational evidence than the other three themes combined. Five account for most of what IT operations will be asked to produce:

• A.8.8 Management of technical vulnerabilities: Identification, assessment, and remediation of known weaknesses

• A.8.9 Configuration management: Approved baselines and detection of drift away from them

• A.8.15 Logging: Recording, retaining, and protecting event logs

• A.8.16 Monitoring activities: Watching systems and networks for anomalous behavior

• A.8.32 Change management: Controlled assessment, approval, and implementation of changes

Two of those five, configuration management and monitoring activities, did not exist in the previous edition of the standard. Knowing which controls arrived in 2022 tells you where the gaps are most likely to be.

What Changed Between ISO 27001:2013 and ISO 27001:2022?

The 2022 revision reduced Annex A from 114 controls to 93 and replaced the 14 legacy domains with the four themes above. The reduction came from consolidation, with 24 overlapping controls merged, 58 updated, and 11 added, so nothing was dropped in substance.

These 11 new controls generate the most transition work, because no 2013 predecessor exists to point at:

1. A.5.7 Threat intelligence

2. A.5.23 Information security for use of cloud services

3. A.5.30 ICT readiness for business continuity

4. A.7.4 Physical security monitoring

5. A.8.9 Configuration management

6. A.8.10 Information deletion

7. A.8.11 Data masking

8. A.8.12 Data leakage prevention

9. A.8.16 Monitoring activities

10. A.8.23 Web filtering

11. A.8.28 Secure coding

Six of those eleven land on IT operations. Threat intelligence, cloud service governance, ICT continuity readiness, configuration management, monitoring activities, and web filtering all depend on what your infrastructure can show you.

One change worth knowing lives outside Annex A entirely. ISO/IEC 27001:2022/Amd 1:2024 added climate change considerations to Clauses 4.1 and 4.2, leaving the control set at 93.

The transition window is closed as well. Certificates issued against ISO 27001:2013 expired on 31 October 2025, so every valid certificate today runs on the 2022 revision and its set of ISO 27001 controls. According to the ISO Survey, 96,709 ISO/IEC 27001 certificates were valid worldwide across 179,877 sites in the most recent published count.

With the structure settled, the practical question becomes who inside the organization answers for which control.

Which Annex A Controls does IT Operations Actually Own?

Around 32 of the 93 Annex A controls depend on evidence that only IT operations can produce, with a further seven shared with identity and access management. The split works out as follows:

• 32 owned outright: Evidenced from monitoring, logging, asset, change, incident, and patch records

• 7 shared: Identity, authentication, and access rights, held jointly with the identity and access function

• 54 owned elsewhere: HR, legal, facilities, procurement, and the ISMS function

An IT director asked to "support the ISO 27001 audit" needs to know which third of the annex will land on their desk, and which parts can be handed back with an owner's name attached. Getting that split wrong is expensive in a way that shows up late, because an unassigned control produces no evidence and surfaces as a finding weeks before the certificate date. Asset-related controls carry the heaviest shared load, so ITAM compliance practice usually sets the pace for the rest.

Handing a single owner all 93 controls guarantees a slow start. The operational subset itself breaks into two groups: one evidenced from monitoring and infrastructure systems, the other from service management and asset records. The next two sections map each group control by control.

Annex A Controls Mapped to IT Monitoring and Logging

Sixteen Annex A controls are evidenced primarily through monitoring, logging, and infrastructure data. An auditor here wants system output, and a dashboard screenshot rarely settles the question on its own.

Detection speed is why this group carries weight. IBM's Cost of a Data Breach Report puts the mean breach lifecycle at 241 days, split between 181 days to identify and 60 to contain, the lowest figure in nine years of the study. An auditor reading A.8.16 is asking whether your monitoring would shorten that first number.

Three of these are where evidence tends to fall apart under questioning.

A.8.15 Logging: Coverage, Retention, and Integrity

A.8.15 asks for three things at once, and most organizations can produce two:

1. Coverage: Every in-scope system is actually sending logs

2. Retention: Those logs are held for the full period your policy states

3. Integrity: Nobody can quietly edit them after the fact

The test an auditor applies is simple: pick an in-scope server at random, ask for its audit log from six months ago, and see how long the answer takes. Centralized log monitoring turns that into a search.

A.8.16 Monitoring Activities: What Counts as Detection

A.8.16 was new in 2022 and asks for something narrower than general observability. The control wants anomalous behavior detected and acted on, which means three artifacts:

• A rule set: The detection logic in force and the thresholds it applies

• An alert history: What fired, when, and against which system

• A disposition record: Who reviewed each alert and what they concluded

A dashboard proves you can see the data, while an alert record carrying a reviewer name and a timestamp proves someone looked.

A.8.17 Clock Synchronization: Why Timestamps Decide Your Log Evidence

A.8.17 receives less attention than any other technological control, and it quietly determines whether your log evidence holds together. If two in-scope systems disagree on the time by four minutes, any incident timeline built from their combined logs is unreliable.

Two checks satisfy the control, and both are cheap:

• NTP source configuration: One authoritative time source, set through NTP, the network time protocol that keeps system clocks aligned, and applied to every in-scope device class

• Drift readings: A periodic report showing how far each system has moved from that source

Fixing this after a finding costs far more than checking it now.

Network device configuration is where several of these controls converge, and network compliance management gives you baseline comparison and drift detection across the infrastructure.

Annex A Controls Mapped to IT Service Management

Sixteen Annex A controls are evidenced through service management, asset, and endpoint records, covering the incident lifecycle, the asset register, change control, patching, and the documented procedures behind them.

Evidence here carries approvals and human decisions. An auditor reviewing A.8.32 wants to see who assessed the risk, who approved the change, and what the back-out plan was, which makes the completeness of each record matter as much as its existence.

What is ISO 27001 Annex A Control 5.27?

A.5.27 requires that knowledge gained from information security incidents is used to reduce the likelihood or impact of future ones. It asks for a closed loop across three records:

• Incident: The event itself, with cause and impact captured

• Review: A post-incident analysis that reaches a decision

• Change: A documented change traceable back to that decision

Organizations run post-incident reviews and file the findings, then never link them to a change record, which leaves nothing to show the loop closed. Linking problem records to their source incidents and to the changes they trigger satisfies A.5.27 in one trace.

Records held in separate systems are what break this group. When the asset register, the vulnerability scanner, and the patch console each hold their own version of the truth, no single export shows which vulnerability a given patch closed.

What Evidence do Auditors Ask for Against Each Annex A Control?

Auditors ask for four kinds of artifact against Annex A controls: a documented procedure, a configuration state, an operational record, and a review record. Most findings come from producing three of the four and assuming the fourth is implied.

A policy document proves intent, a configuration export proves the control is in place, an operational record proves it ran, and a review record proves someone checked.

Assemble all four artifact types ahead of the assessment instead of during it.

For A.8.15, the four artifacts look like this:

• Procedure: The logging policy stating which systems are in scope and how long logs are retained

• Configuration: The collector configuration showing those sources connected and the retention setting applied

• Operational record: A retrieved log entry from a date inside the retention window

• Review record: Proof that log coverage was checked against the in-scope system list at a stated interval

Apply the same four-part test to every applicable control and the gaps surface before an assessor finds them. The document recording the result of that test, control by control, is the Statement of Applicability.

How do you Build a Statement of Applicability from Annex A?

A Statement of Applicability lists all 93 Annex A controls and records, for each one, whether it applies, why, and its current implementation status. Mandatory under Clause 6.1.3, it is usually the first document an auditor asks to see.

Four columns carry the weight:

• Control: The Annex A reference and title, all 93 of them

• Applicable: Yes or no, with no blank rows

• Justification: The risk assessment result or requirement driving inclusion, or the reason for exclusion

• Status: Implemented, partially implemented, or planned, with an owner and a date

Exclusions attract more scrutiny than inclusions, so the justification has to be specific. "Not applicable, the organization holds no source code and performs no software development" survives questioning against A.8.28. "Not relevant to our business" does not.

The mapping also carries across frameworks, which matters commercially. ISO 27001 compliance rarely stands alone in a regulated business, so once your Annex A evidence is organized by artifact type, extending it to SOC 2, POPIA compliance, or a sector-specific obligation becomes a relabeling exercise. One evidence set answering three frameworks is the difference between one audit program and three.

What is the Best Way to Implement Annex A Controls?

The best way to implement Annex A controls is to work outward from the risk register, giving each applicable control an owner and a system of record before anyone writes a procedure. Starting from the control list instead produces 93 small projects, most of which nobody needed.

A workable sequence has five steps:

1. Finish the risk assessment first: Control selection has nothing to anchor to until identified risks and treatment decisions exist

2. Assign an owner per control: Name a person and a function, because unowned controls generate no evidence

3. Name the system of record: Decide where evidence for each control will live before implementation starts

4. Implement the operational controls early: Logging, monitoring, asset inventory, change, and patch controls carry the most evidence weight and take the longest to build history

5. Write the procedure last: Documenting a process you already run produces procedures that match what happens

The sequence is a budgeting decision as much as a technical one. Controls implemented in the first quarter have three quarters of evidence behind them by audit day, while controls implemented in the final month have almost none, whatever the platform underneath them can do.

Where do Organizations Most Often Lose Annex A Evidence?

Annex A evidence is most often lost in five places, and none of them involve a control that was never implemented. Each describes a control operating correctly with no durable record that it did.

1. Log retention shorter than the policy claims: The written policy states twelve months, the collector is configured for ninety days, and nobody compared the two

2. Clock drift across in-scope systems: Timestamps disagree between hosts, so incident timelines built from combined logs cannot be defended under A.8.17

3. Emergency changes approved outside the workflow: The change happened, the approval exists in a chat thread, and the change record shows a gap under A.8.32

4. Asset register accurate only at export: New devices appear in discovery but never receive an owner or classification, leaving A.5.9 evidence incomplete

5. Reviews without a resulting action: Post-incident reviews and access recertifications are completed and filed, with no linked change to show anything came of them under A.5.27

The pattern is the same across all five: the control works, the evidence is transient, and the audit arrives after the evidence has gone.

What a Single Evidence Gap Costs

Consider a mid-sized insurer three weeks out from its Stage 2 audit, the certification assessment itself. The assessor picks A.8.32 and asks for every change made to in-scope production systems in the past quarter, with the approval behind each one.

Ninety-one of the ninety-four changes come back clean from the change workflow. The remaining three were emergency fixes during an overnight outage, approved verbally and confirmed in a group chat the following morning. The control operated exactly as designed, and the record does not exist anywhere the auditor can accept it.

That gap becomes a minor nonconformity, meaning a formal finding that a requirement was not fully met. It costs a corrective action plan, a documented root cause, and a follow-up review before the certificate issues. Three weeks of buffer turns into six, and the deal waiting on the certificate waits with it.

How do you Keep Annex A Evidence Audit-Ready Between Surveillance Audits?

Keeping Annex A evidence audit-ready means running collection as a standing cadence with fixed intervals and named owners. Surveillance audits, the shorter annual checks between three-year recertifications, arrive whether or not your evidence kept pace, and evidence accurate at certification decays quietly in between. A workable cadence has four layers:

• Continuous: Log collection, continuous monitoring, configuration baseline comparison, and asset discovery, all running without anyone triggering them

• Weekly: Alert review with reviewer attribution, patch compliance status, and change records checked for completeness

• Quarterly: Access recertification, backup restore tests, log coverage reconciled against the in-scope system list, and clock drift readings

• Annually: Statement of Applicability review, risk assessment refresh, and internal audit against every applicable control

Assign each line an owner and a system of record. Run it for a year and, on any given day, evidence for the previous twelve months already exists, which turns audit preparation into a retrieval exercise. The saving is measured in senior staff weeks that no longer disappear into the run-up to every audit.

Move Annex A Evidence from Audit-Week Assembly to Everyday Operation with Motadata ServiceOps

One concession is worth making plainly: no IT operations platform will get you certified on its own. Your risk assessment, Statement of Applicability, policies, and internal audit program are governance work that belongs to the ISMS owner.

What a platform contributes is the operational evidence behind roughly a third of Annex A:

• Motadata ServiceOps: Asset register, incident and problem records, change approvals, patch compliance status, and versioned procedures, with the links between them intact, covering A.5.9, A.5.24 through A.5.28, A.8.8, A.8.19, and A.8.32

• Motadata ObserveOps: Log collection, retention, alert history, and configuration baselines, covering A.8.15, A.8.16, A.8.9, and the network security group

Holding those records in one place turns evidence gathering from an assembly job into a query.

ServiceOps is a PeopleCert ATV product covering 12 ITIL 4 practices, so the incident, problem, and change processes producing that evidence already follow a recognized structure. For the controls that give you the most trouble at audit, that structure is what separates a record an assessor accepts from one that invites another question.

FAQs