ISO 27001 Annex A: make the 93 controls operational

Annex A gives security teams a useful reference set. Its operational value comes from showing why a control applies, how it is implemented, and what evidence supports it in your environment. A register containing 93 green status indicators is not enough if nobody can explain which systems those indicators cover.

For a CTO, the practical challenge is translating control intent into engineering and operational work without turning the information security management system into a parallel bureaucracy. Access reviews should use real permission data. Recovery plans should reflect service dependencies. Supplier assessments should address the services the business actually consumes.

This guide explains how to select controls, distribute ownership, define implementations and test the resulting claims. The review frequencies and implementation examples below are practical recommendations, not universal intervals prescribed by the standard.

Understand what Annex A does—and what it does not

ISO/IEC 27001:2022 contains 93 Annex A controls across four themes. Clauses 4–10 contain the management-system requirements: organizational context, leadership, planning, support, operation, performance evaluation and improvement. Annex A supports control selection; it does not replace those requirements or your risk assessment.

The distinction matters during implementation. A backup configuration may support a selected control, but it does not establish that you have defined the ISMS scope, assessed risks, conducted an internal audit or completed management review. Those are separate activities with separate evidence.

Control selection is risk-based. Determine the controls necessary to treat your risks, then compare them with Annex A to check that necessary controls have not been omitted. Additional controls outside Annex A may be necessary. Conversely, a justified exclusion is possible; there is no rule that every organization must exclude something or implement exactly the same selection.

ISO/IEC 27002:2022 provides implementation guidance for the controls. Its attributes help organize them by control type, information security property, cybersecurity concept, operational capability and security domain. These are useful filtering aids, not additional certification checklists. Consult the licensed standards for authoritative wording.

Use the four themes to find the right owners

The themes provide a navigation structure, not four independent workstreams. A leaver process, for example, connects employment responsibilities, identity administration, equipment return and application access.

Organizational controls: connect governance to operating decisions

These controls cover policies, responsibilities, separation of duties, assets, information classification and handling, access governance, suppliers, incidents, continuity, legal obligations and review activities.

Start by identifying where decisions occur. Who approves a new cloud service? Who assigns an information classification? Who decides whether a reported event is an incident? A policy should make those decisions repeatable and assign authority, rather than merely express support for security.

Supplier security needs a service-specific chain of evidence: the service's business purpose, the information it handles, assessed risks, contractual responsibilities and ongoing review. A supplier's assurance report can support that assessment, but its scope, period and customer responsibilities must match your use.

Incident management similarly needs more than an emergency contact list. Define reporting routes, assessment criteria, response authority, evidence handling and learning activities. Record exercises or actual responses, including follow-up actions and owners.

People controls: make employment events reliable triggers

The eight people controls address screening, employment terms, awareness and training, disciplinary processes, responsibilities after employment changes, confidentiality, remote working and event reporting.

Build these into existing employment workflows. A joiner needs appropriate obligations, access and instruction. A mover needs permissions reassessed, not simply added. A leaver needs access removal, asset return and clarity about continuing confidentiality responsibilities.

Ownership often spans teams. HR may initiate a departure, identity administrators disable the central account, application owners remove locally managed access, and a manager confirms completion. Assigning the entire process to security hides those dependencies.

Useful evidence includes approved workflow records, training completion and overdue follow-up, acknowledged terms, and sampled employment changes. Restrict access to sensitive HR evidence; a control reviewer does not automatically need full personnel files.

Physical controls: document your boundary and the supplier's boundary

Physical controls address premises, entry, monitoring, environmental threats, secure areas, desks and screens, equipment, media, utilities, cabling, maintenance and disposal.

A cloud-first organization still needs to consider physical security. Some implementation may be provided by a cloud supplier, while office access and employee devices remain its own responsibility. Record that split instead of automatically excluding the entire theme.

For your own locations, identify who can enter, how access changes, where sensitive equipment sits and how visitors are handled. For remote devices, define storage, transport, repair and disposal arrangements appropriate to their risks.

Evidence might include access authorization records, visitor procedures, equipment inventories and disposal records. Supplier evidence should explain the facilities and services covered; it should not be treated as proof of your office or laptop controls.

Technological controls: define coverage before choosing tools

The technological theme covers endpoints, privileged access, authentication, source-code access, capacity, malware, vulnerabilities, configurations, data handling, backups, resilience, logging, monitoring, networks, cryptography, development and change management.

Begin with system coverage. An identity policy is incomplete if production access, service accounts or a separately managed application fall outside its implementation. A logging platform is incomplete if critical events never reach it or nobody responds to alerts.

For software development, connect requirements and design decisions to code review, security testing, environment separation, test-data handling and release approval. Threat modeling can help identify security requirements before implementation. Testing depth should follow risk and obligations; ISO 27001 does not impose a universal penetration-testing schedule.

For cryptography, distinguish data at rest from data in transit and document key ownership, access, recovery, rotation and revocation. “Encryption enabled” leaves important implementation questions unanswered.

What changed in 2022, and where to inspect for gaps

The 2013 edition had 114 controls across 14 domains. The 2022 edition reorganized them into 93 controls across four themes, including 11 new controls. A lower count does not mean less security work: consolidation can put several operational responsibilities under one reference.

When updating an older register, preserve the underlying implementations and evidence rather than merely replacing identifiers. Check whether the new grouping changes coverage, ownership or the tests needed to support your status.

The transition deadline for accredited ISO/IEC 27001:2013 certification was 31 October 2025. Those certificates are no longer valid; updating a control register alone does not establish certification to the 2022 edition.

The following are practical starting points for the 11 new controls, not reproductions of their authoritative text.

Avoid treating these as eleven automatic product purchases. For example, threat intelligence needs analysis and action, not just a subscribed feed. Data deletion requires an understanding of copies, backups and retention obligations, not merely a delete button. Monitoring needs an operational response path.

Record applicability and implementation separately

Your Statement of Applicability, or SoA, should identify necessary controls, explain their inclusion, record whether they are implemented, and justify exclusions of Annex A controls. These requirements sit within the risk-treatment provisions of ISO/IEC 27001.

Using all 93 references as a review index is a practical way to make the comparison inspectable. Include any additional necessary controls too. The SoA is not the risk register, treatment plan or evidence repository, although it should connect to each where relevant.

For each applicable control, capture:

• The risks or obligations supporting inclusion.
• Relevant systems, locations, information and processes.
• The actual implementation and accountable owner.
• Supporting evidence and its review period.
• Dependencies, exceptions and unfinished work.
• The next review date or event trigger.

Keep applicability independent from delivery status. “Applicable, partially implemented” is an honest and useful record. “Not applicable because we have not bought a tool” is not an applicability rationale.

An exclusion should describe the scope facts that make the control unnecessary and remain consistent with the risk assessment. “We do not develop software” needs scrutiny if a contractor develops your customer portal. Outsourcing changes the implementation and evidence path; it does not automatically remove the risk.

For distributed implementations, record the split. A physical protection control might depend on supplier-operated hosting facilities, company-managed office entry and employee handling of devices. One owner can remain accountable for the combined claim while different teams perform the activities.

A useful implementation statement is specific enough to test: “Production administrators receive named, approved access through the identity service; emergency access is separately logged and reviewed.” “Access is managed securely” cannot guide an engineer or reviewer.

Test the claim behind the status

A policy describes intended behavior. It can demonstrate design and approval, but cannot alone demonstrate operation. Build an evidence chain from the requirement to the implemented mechanism and then to an observed result.

For access management, compare approved rules with actual user permissions and departure records. Include privileged identities, non-human accounts and applications outside central identity management where relevant. Record the population, sample and exceptions rather than presenting a single convenient screenshot.

For backups, inspect configuration and a restoration result. A successful backup job proves less than a successful recovery of usable information. Check permissions, dependencies and recovery objectives; a restored database without its encryption keys may not restore the service.

For supplier security, connect the assessment to the particular service and contractual responsibilities. Review whether the evidence covers the service you use and whether identified customer-side responsibilities are implemented.

A practical test record should contain the expected outcome, method, scope, evidence date, reviewer, result and follow-up decision. Distinguish:

• Design: the proposed mechanism addresses the identified risk.
• Implementation: the mechanism exists across the stated scope.
• Operation: records show it functioning during the relevant period.
• Effectiveness: testing indicates it achieves the intended outcome.

Evidence can include configurations, exports, tickets, contracts, interviews and physical observations. Select evidence that supports the actual claim. A configuration export may show current settings; historical tickets may show whether exceptions were handled over time.

Preserve provenance: source system, collection date, covered period and any filtering. Protect evidence containing secrets or personal information through access restrictions and appropriate redaction. Evidence collection should not create a new uncontrolled repository of sensitive data.

Worked example: make a leaver process inspectable

Consider an illustrative SaaS company with 45 employees, one office, cloud hosting, centrally managed identity and two applications with local accounts. These are example assumptions, not Secani customer results.

The risk is continued access to customer or company information after departure. Relevant controls include employment-change responsibilities, identity management, access rights and return of assets. Technical authentication and access restrictions also support the implementation.

The company records the control as applicable. HR owns the departure trigger; IT owns identity and device actions; each application owner owns local-account removal. The employee's manager confirms the required departure timing. The security owner reviews the process and unresolved exceptions.

The implementation includes an authorized departure ticket, scheduled central-account disablement, session revocation where supported, local-account removal, asset return and checks for credentials the individual controlled. Shared secrets are changed where needed; personal accounts are not casually reassigned to a successor.

The evidence package connects the approved procedure, departure ticket, account-action records, local-application confirmations and equipment record. Each item supports a defined part of the claim.

During an illustrative review, the team examines four departures. Central accounts were disabled as scheduled, but one local application retained access for two days. The control is not declared fully effective on the strength of central identity evidence alone.

The application owner removes the account, assesses whether access occurred and records the outcome. The team adds the application to the departure checklist and assigns a reconciliation step. The treatment action gets an owner and due date; a later test checks that the revised workflow works.

This example shows why evidence must follow dependencies. Four systems saying “complete” do not establish completion if a fifth system was never included.

Keep controls operational between reviews

Controls change when systems, suppliers, people and business requirements change. Set review triggers for significant releases, new services, office changes, incidents and revised obligations, alongside scheduled reviews.

Use a cadence appropriate to volatility and risk. Privileged-access exceptions may need prompt review, while a stable policy may use a longer cycle supplemented by change triggers. These are management choices, not universal Annex A frequencies.

Track a small number of useful indicators: overdue remediation, uncovered systems, unresolved evidence exceptions and failed control tests. Separate these from document counts. A large evidence library may still leave a critical production environment untested.

Internal audit provides a separate evaluation of the ISMS; routine control-owner reviews do not replace it. Management review likewise needs leadership decisions about performance, changes, resources and improvement, not just a completed control spreadsheet. Certification is performed by an independent certification body, not ISO or a software provider.

Common mistakes include assigning everything to security, copying another organization's exclusions, relying on supplier certificates without checking scope, and closing findings when a policy changes rather than when the revised process has been tested.

Start with one service and a complete evidence chain

Choose a representative service and trace its systems, providers, information and operational owners. Select a small set of related controls—such as access, change management, logging and recovery—and make each implementation inspectable before expanding the register.

Secani supports this workflow by modeling systems and dependencies, connecting evidence to requirements, controls and decisions, and tracking gaps as tasks. Assign an owner and reviewer, attach existing records, and preserve review comments and approvals. Treat AI-assisted mappings or summaries as drafts: validate the sources and keep human approval explicit. Structured audit readiness explains the supporting evidence model.

The first deliverable should be a coherent chain from risk to control, implementation, evidence, test result and follow-up decision. That chain can then be repeated across the remaining scope without inventing a new process for every Annex A reference.

Practical questions

Can one record support several controls?

Yes. A departure ticket can support several related controls. Explain which claim it supports for each; sharing evidence does not make the controls identical.

Must every control have its own policy?

No. Organize policies and procedures around understandable operating processes. One document can address several controls, provided responsibilities and implementation remain clear.

Where should the authoritative control list come from?

Use the licensed ISO/IEC 27001 standard for Annex A wording and ISO/IEC 27002 for implementation guidance. Operational summaries are useful navigation aids, not substitutes for the standards.