Annex A is a reference set used to check that necessary information security controls have not been overlooked during ISO 27001 risk treatment. The 2022 edition contains 93 controls across organisational, people, physical and technological themes. It is a completeness reference within a management system, not a universal shopping list or a substitute for understanding the organisation’s risks.
This article explains how to use that reference in practice without reproducing the protected catalogue. Control facts and the selection process have been checked against the licensed ISO/IEC 27001:2022 standard. Suggested design methods and examples are original implementation guidance, and their suitability depends on the organisation’s scope and requirements.
Understand why the reference set exists
Organisations can overlook necessary protections when they design controls only from recent incidents or the interests of one specialist team. Annex A broadens the comparison. A technically strong organisation may need better supplier responsibilities or information handling. A policy-rich organisation may need stronger monitoring or recovery verification. The reference helps challenge these blind spots.
Clause 6.1.3 requires the organisation to determine necessary controls for its treatment choices and compare them with Annex A. Controls can also come from other sources or be designed for specific needs. The result is recorded through the Statement of Applicability (SoA) and treatment planning. This process is set out in ISO 27001’s risk treatment requirements.
Do not reverse the logic by purchasing one solution for every control heading and assuming the information security management system (ISMS) is complete. A single operating process may support several reference controls, while one control objective may require several technical and organisational measures. The design should follow the needed outcome and the environment in which it must operate.
Use the four themes to broaden the discussion
The reference set comprises 37 organisational, eight people, 14 physical and 34 technological controls. These counts describe the 2022 Annex A structure; they do not indicate relative importance or a required budget allocation. The licensed ISO 27001 publication provides the authoritative control reference and its relationship to risk treatment.
Organisational controls direct attention to governance, information management, relationships and operational coordination. People controls address the human lifecycle and security responsibilities. Physical controls consider locations, equipment and environmental protection. Technological controls address the systems and technical measures that support information security. These broad descriptions help assemble the right participants without reproducing the standard’s detailed wording.
Expect overlap. Remote work involves people, devices, access, communication and physical conditions. Supplier support involves contracts, identity, logging and incident coordination. Assigning each theme to a separate team without managing these connections can produce individually complete checklists and an incomplete service protection model.
Keep control implementation connected to management requirements
Annex A receives considerable attention because it appears concrete. However, an ISMS also needs context, leadership, risk processes, objectives, resources, evaluation and improvement. Clauses 4 to 10 are requirements for a claim of conformity; they cannot be excluded through the Annex A applicability process. Installing technical measures cannot replace these management activities. The organisation must be able to explain why the controls are needed, whether they work and what changes when the business changes.
Use the management system to resolve tradeoffs. A control may introduce operating cost, affect user experience or depend on another team. Risk owners and leadership need information to decide the design and resources. Without that route, control implementation often becomes a negotiation between security and delivery teams with no clear authority to resolve disagreement.
Connect control performance to review. If a process repeatedly fails, ask whether the design, capacity, competence or underlying assumption is wrong. Continual improvement should change the system where needed. Repeating a failed activity and recording another completion percentage provides little assurance that the intended protection has improved.
Translate a reference into a local operating outcome
Begin with the reason the control is necessary. Identify the information or service, the exposure and the intended result. Then define the population, trigger, owner, activity, exception route and evidence. This produces an operating design that staff can follow and reviewers can evaluate.
For an access-related outcome, ask which identities and systems are covered, who approves permissions, how changes are detected and when access ends. For a recovery-related outcome, ask what information and service must be restored, by whom and under what conditions. The reference title alone will not answer those questions for the organisation.
Keep design decisions separate from implementation detail. A control description can specify accountable approval and timely removal, while a procedure explains the current tool workflow. This separation helps maintain the control when technology changes. The organisation should preserve the required outcome while updating the operating method in a controlled way.
Assign ownership across functions and providers
A control owner should understand the outcome and have access to the people and information needed to evaluate performance. Ownership does not necessarily mean performing every task. HR may supply departure information, IT may remove access and a service owner may approve exceptions. Define how those contributions connect.
For provider-operated controls, identify what the provider does and what your organisation must still do. Cloud services may supply technical capabilities that require customer configuration. A managed service may monitor events while your team retains incident decisions. Contract language, service design and actual operating evidence should support the allocation.
A responsibility matrix is useful only if tested. Walk through a routine case and an exception with the named owners. If everyone assumes another party acts first, the design needs revision. This is particularly important for urgent incidents, service restoration and access removal, where an unclear handoff can undermine several controls at once.
Choose evidence according to the assertion
Different records answer different questions. Approval evidence shows that a decision was authorised. Configuration evidence shows how a system was set at a point in time. Transaction records show operation. Tests and performance results can help evaluate whether the intended outcome was achieved. Avoid treating one screenshot as proof of every aspect of a control.
Define the population and period behind a sample. A review of ten accounts means little if the reviewer does not know whether they represent ten of twelve or ten of several thousand, or whether privileged and external identities were omitted. The control owner should be able to explain the sample’s purpose and limitations.
Collect evidence through normal work where possible. A service request, approved change, automated report or exercise record can support assurance without a separate manual archive for every task. Protect sensitive evidence and retain enough context for later interpretation. The objective is trustworthy information, not maximum file volume.
Evaluate technology by the control capability it enables
Security products can enable important controls, but a product name does not demonstrate implementation. A monitoring platform needs relevant sources, detection logic, response ownership and maintenance. An identity platform needs accurate populations and lifecycle processes. A data protection tool needs rules that reflect actual information use and exception handling.
Before procurement, define a small set of realistic acceptance scenarios. Include integration dependencies and operating costs. Ask who will maintain the rules, interpret alerts and handle false positives. The answer may reveal that a simpler design with strong ownership is more effective for the organisation than a feature-rich platform nobody can operate.
After deployment, test the complete workflow. A generated alert that nobody receives does not establish an effective response capability. A blocked action that prevents legitimate critical work may drive unsafe workarounds. Control design should account for business use while preserving the necessary security outcome.
Hypothetical example: an education platform joins technical and people controls
A hypothetical education platform has implemented strong authentication for staff but still experiences risky account recovery requests during examination periods. The initial response is to consider another authentication feature. A workflow review shows that temporary support staff are uncertain about identity verification and escalate inconsistently when deadlines are urgent.
The team designs a combined response: clear recovery criteria, role-specific practice, restricted recovery privileges, recorded approvals and monitoring of unusual activity. The design draws on several control themes. It is owned through a single service workflow so that responsibility does not disappear between HR training, service desk operation and identity engineering.
Testing includes a legitimate urgent request and an ambiguous request with incomplete evidence. The exercise reveals that the escalation contact is unavailable outside normal hours. The team resolves cover and retests. The control outcome improves because the organisation addressed the complete pathway rather than counting separate tools and training sessions.
Hypothetical example: an aerospace supplier protects approved design information
A hypothetical aerospace component supplier needs reliable control of customer design files. Its security inventory focuses on file encryption and endpoint protection. A process walkthrough identifies additional dependencies: approved versions are transferred to production, external specialists review selected designs and obsolete files remain accessible in a local archive.
The supplier defines a coherent information lifecycle. It assigns ownership for classification, approved release, external sharing, retention and disposal, then maps the necessary controls against Annex A. A specific reconciliation between engineering approval and production use is included because the risk treatment needs it. The organisation does not assume that general access restrictions alone protect integrity.
Evidence follows a sample design from receipt to production and eventual archive. The sample reveals that an external reviewer retained access after the project ended. The corrective action changes the project closure process and checks similar workspaces. The reference set helped broaden the review, while the actual service workflow supplied the implementation detail.
Prioritise implementation without losing necessary coverage
Prioritisation is a delivery decision, not an applicability decision. A necessary control can be scheduled according to risk and dependencies, but it should not be labelled unnecessary because it is difficult to implement. Keep the gap visible, evaluate interim exposure and obtain appropriate decisions under the organisation’s risk criteria.
Identify foundational capabilities. Reliable inventories, identity information and ownership may enable several other controls. Investing in those foundations can improve the quality of later reviews and monitoring. Conversely, implementing advanced analytics on incomplete data can create a misleading sense of coverage.
Track progress through design, implementation, operation and verification. The stages need not be bureaucratic, but they should distinguish intention from evidence. A project can be technically complete while the operating team still lacks a usable procedure or the ability to interpret results.
Review the control system for gaps and duplication
Use service walkthroughs to check connections. Follow one supplier onboarding, one employee departure or one emergency change across the relevant controls. Look for missing handoffs, contradictory approvals and evidence that cannot be reconciled. This method can reveal weaknesses that separate control-by-control reviews overlook.
Also identify unnecessary duplication. Two teams may review the same access population with different criteria, or several dashboards may report different versions of the same measure. Consolidate where it preserves the intended outcomes and accountability. A simpler operating model can improve consistency without reducing necessary assurance.
CyberVantage360’s ISO 27001 service offers a route to discuss control design in context. Share your control implementation challenge with the affected service, current responsibilities and evidence gaps so that the discussion can focus on practical outcomes.
Make control handover explicit
Before the implementation team leaves, have each receiving owner demonstrate the operating activity and explain its exceptions. Confirm that the owner can retrieve evidence, interpret performance and obtain a decision when a control fails. A handover document is useful, but a practical demonstration reveals whether knowledge has transferred.
Record unresolved dependencies and the next review date. If a control still relies on temporary project staff or a supplier’s informal assistance, make that reliance visible and assign a transition action. Sustainable operation requires a workable owner and support arrangement after the initial project attention has moved elsewhere.
Frequently asked questions
Are all 93 controls automatically mandatory?
No. Control necessity is determined through the standard’s risk treatment process and the comparison with Annex A. The SoA explains necessary controls, implementation status and justified exclusions. The reference set must be considered properly, but appearing in it does not turn every control into an identical mandatory technology purchase.
Can one process satisfy several control needs?
Yes. A well-designed supplier onboarding or access lifecycle process may support several necessary controls. Keep the mapping and evidence clear so that the organisation can explain which outcomes the process provides. Consolidation should preserve accountability and coverage rather than hide gaps behind one broad process name.
Can additional controls be used?
Yes. Annex A is not exhaustive. The organisation may need controls designed for its particular risks, obligations or service model. Record the necessary control, its purpose and implementation, and maintain the connection to risk treatment and the SoA.
Is implementing Annex A enough for certification?
No. ISO 27001 also includes management system requirements concerning context, leadership, planning, support, operation, evaluation and improvement. Controls must be part of that functioning system. Certification involves independent assessment by a certification body, rather than a self-declared count of completed control entries.