ISO 27001 Annex A Controls

Reviewed by the Fully Compliance editorial team

ISO 27001 Annex A defines 93 security controls across 14 categories that organizations must address as part of certification. Controls are not checkboxes applied identically to every organization — they are tailored to your risk assessment and scope. The categories span everything from access control and cryptography to supplier management and business continuity, and the auditor requires documented evidence that each applicable control is functioning, not just implemented.

The Control Architecture: Tailored to Your Risk, Not Applied Uniformly

Annex A defines the controls you need to address, organized into 14 categories: Information Security Policies, Organization of Information Security, Human Resource Security, Asset Management, Access Control, Cryptography, Physical and Environmental Security, Operations Security, Communications Security, System Acquisition and Development, Supplier Relationships, Information Security Incident Management, Business Continuity Management, and Compliance.

The critical principle is this: ISO 27001 requires you to perform a risk assessment, identify which information assets matter most, determine which risks are greatest, and then select which controls are necessary to address those risks. A cloud hosting company operating data centers would implement detailed physical security controls because physical infrastructure is central to their risk profile. A software company would implement lighter physical security but rigorous access control and monitoring because their primary assets are code and data. You cannot skip controls because they are expensive or inconvenient. But you can implement controls in ways that make sense for your specific context, and your documentation must explain the risk assessment, which controls are relevant, and how you have implemented them.

Asset Management and Classification — Know What You Are Protecting

Before you implement any controls, you need to know what you are protecting. Asset Management controls require you to inventory your information assets — databases, systems, documents, intellectual property — and classify them by sensitivity or criticality. Which assets are critical to business operations? Which contain sensitive or confidential information? Which hold personal data subject to privacy regulations?

You need a classification scheme applied consistently — public, internal, confidential, restricted, or whatever taxonomy fits your business. The scheme itself matters less than having one, applying it uniformly, and using it to determine what protections each asset requires. Once classification is complete, you can make informed decisions about every other control. If you have no restricted or highly sensitive information, you may not need the most rigorous encryption controls. If particular systems are business-critical, you need strong backup and recovery controls for those systems specifically. Asset management is foundational because it informs every other control decision.

Access Control — The Category You Cannot Get Wrong

Access Control is arguably the single most important control category in Annex A. It covers how people get access to systems and data, how you verify identity (authentication), how you ensure users can only access what they need (authorization), and how you ensure access rights remain appropriate over time.

User access management means you have a process for granting access when someone joins, modifying access when someone changes roles, and removing access when someone leaves. Authentication controls require identity verification beyond just passwords — multifactor authentication, hardware tokens, or equivalent mechanisms. Authorization controls ensure that someone in accounting cannot access the source code repository and someone in engineering cannot access payroll records.

Access control review is where organizations consistently fall short. They grant access and forget about it. Three years pass. Someone still has system access from a role they left two years ago. ISO 27001 requires periodic review of who has access to what, with verification that each access grant is still appropriate. The auditor will ask for evidence — logs showing quarterly access reviews, signed documentation confirming that access rights are current. According to the Verizon 2024 DBIR, credential abuse remained the most common initial access method in breaches. Access control review is not an administrative formality — it directly reduces your most likely attack surface.

Cryptography — Straightforward in Principle, Complex in Practice

Cryptography controls require you to identify which data needs encryption, determine when it should be encrypted — at rest in storage, in transit across networks, or both — and maintain documented procedures for managing encryption keys.

The principle is simple: encrypt sensitive data so that unauthorized access does not result in readable information. The practice is where complexity lives. You need to decide which data to encrypt — all data, or only data classified above a certain sensitivity level. You need to determine where encryption happens — databases at rest, web applications in transit, backups. You need encryption standards, with most organizations using AES-256 for data at rest and TLS 1.2 or higher for data in transit.

Key management is where many organizations stumble. Encryption keys must be protected as carefully as the data they encrypt. Keys must be stored securely, rotated periodically, and destroyed when no longer needed. If you have 50 databases, do you have 50 unique encryption keys? Where are those keys stored? Who can access them? How often are they rotated? Do you have documented key lifecycle management procedures? An auditor will ask every one of these questions and expect documented procedures plus evidence of execution.

Physical Security — Scope Determines Rigor

Physical Security controls ensure your facilities and equipment are protected — perimeter security, environmental controls, equipment inventory, and theft prevention. The rigor required scales directly with your risk profile.

For a software company without a data center, physical security may involve ensuring offices are locked after hours, servers sit in secure rooms with limited access, and equipment cannot walk out the door. For an organization operating a data center, physical security is extensive — multiple security layers, surveillance, access logs, environmental monitoring, fire suppression, and power redundancy. Both organizations need to document their physical security controls, explain why those controls are adequate for their risk profile, and provide evidence that the controls function.

Incident Management — Detection Is the Part Most Organizations Miss

Incident Management controls require that you detect security incidents, respond effectively, and learn from them. The gap most organizations have is not in response — most can write a response plan — but in detection. They do not know something bad is happening until someone reports it externally. That is not sufficient for ISO 27001.

Detection requires monitoring and logging. Systems must generate audit logs and security events. Those logs must be reviewed or aggregated to identify suspicious activity — whether through a SIEM that aggregates logs and alerts on suspicious patterns, or through periodic manual review of critical system logs. Either way, you need a mechanism for detecting incidents proactively, not just responding after someone else discovers the problem.

Response requires a documented, tested process. When you detect a potential incident, who gets notified? What is the investigation process? How do you contain damage? How do you document findings? How do you communicate with affected parties? If an auditor asks whether you have had security incidents and you can say "yes, here is the incident we detected through monitoring, here are the investigation notes, here is how we contained and remediated it" — that demonstrates a functioning incident management system.

Business Continuity — Testing Is What Separates Plans From Capabilities

Business Continuity controls address your ability to continue operating after a disruptive event. This includes backups of critical data, disaster recovery planning, and actual testing of recovery procedures. Many organizations invest heavily in prevention but under-invest in recovery, assuming that good controls mean incidents will not happen. That assumption is optimistic.

You need to identify which systems and data are critical — a customer data platform is business-critical, an internal wiki is not. For critical systems, you need backups, disaster recovery procedures, and tested recovery. Testing is the critical word. An untested backup is worthless because you do not know whether recovery actually works until you try it. Organizations routinely have disaster recovery plans on paper that have never been tested, only to discover during an actual disaster that backups are corrupted or procedures do not work. ISO 27001 requires evidence that you have tested recovery procedures and that they actually function.

Supplier Management — Your Vendors Are Part of Your Security Posture

Supplier Relationships controls address the security practices of vendors and service providers you rely on — email providers, cloud hosting, SaaS applications, consultants with system access. These vendors handle your data or affect your security posture, and ISO 27001 requires you to actively manage that risk.

This includes vetting vendors before engagement through security due diligence, maintaining contracts that require appropriate security practices and define breach notification obligations, and monitoring vendors to ensure they maintain agreed-upon security levels. Many organizations are weak here — they use a vendor, the vendor has a breach, and the organization is blindsided because it never reviewed the vendor's security controls. ISO 27001 requires proactive vendor risk management, not reactive surprise.

Evidence Is Mandatory — Implementation Alone Is Not Enough

The requirement that surprises many organizations is that implementing controls is not sufficient — you must prove they work. The auditor does not just want to hear that you have access reviews. They want to see access review documentation, evidence of who reviewed what, and signed approvals confirming access rights are appropriate.

For incident management, they want monitoring system logs, incident reports, investigation notes, and remediation actions. For business continuity, they want test results, recovery procedures, and evidence that you have tested recovery and it works. For encryption, they want configuration evidence, key management documentation, and verification results.

Start gathering evidence as you implement controls. If you implement access reviews, keep the documentation. If you implement monitoring, keep logs or reports showing results. If you test backups, document the test results. By audit time, you should have a complete evidence trail demonstrating that every applicable control is functioning. Organizations that build evidence collection into their daily operations pass audits efficiently. Organizations that scramble to assemble evidence after the fact pay for that lack of discipline in time, stress, and findings.

Frequently Asked Questions

Do I have to implement all 93 Annex A controls?
You must address all 93 controls, but "address" does not mean "implement identically." Your risk assessment determines which controls are applicable. For controls that are not relevant to your scope, you document why they do not apply (a Statement of Applicability). You cannot simply ignore a control — you must explicitly justify its exclusion.

What is a Statement of Applicability?
The Statement of Applicability (SoA) is a required document that lists all 93 Annex A controls and states, for each one, whether it is applicable, how it is implemented, and the justification for any exclusions. It is one of the most important documents your auditor will review.

How does Annex A relate to ISO 27002?
ISO 27002 provides detailed implementation guidance for the controls listed in Annex A. Annex A tells you what controls exist; 27002 tells you how to implement them. You are audited against 27001 (including Annex A), but 27002 is the reference that helps you implement controls correctly.

Which Annex A controls cause the most audit findings?
Access control review, incident detection capabilities, business continuity testing, supplier security management, and encryption key management are the five areas that most consistently generate findings during initial certification audits. Organizations that focus preparation on these areas typically have smoother audits.

Can I use automated tools to satisfy Annex A controls?
Yes, and many organizations do — GRC platforms for tracking controls and evidence, SIEMs for monitoring and detection, identity management systems for access control. Automation helps with consistency and evidence gathering. But the tool must be configured correctly and the outputs must be reviewed. An automated tool generating alerts that nobody reads satisfies the letter of the control but not its intent.

Fully Compliance provides educational content about IT compliance and cybersecurity. This article reflects general information about ISO 27001 Annex A controls as of its publication date. Standards and interpretations evolve — consult a qualified compliance professional for guidance specific to your organization.