ISO 27001 Annex A Controls

This article is for educational purposes only and does not constitute professional compliance advice or legal counsel. Requirements and standards evolve, and you should consult with a qualified compliance professional about your specific situation.

ISO 27001 requires you to implement a set of information security controls. These controls are defined in Annex A of the standard, and while they're numbered 93 controls across fourteen categories, that number matters far less than understanding what each category actually requires you to do and how you're going to implement it in your organization. This is where ISO 27001 becomes real — not the framework itself, but the actual work of securing your information.

The Control Architecture: Fourteen Categories, Flexible Implementation

Annex A defines the controls you need to address. Those controls fall into fourteen 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 important thing to understand about these categories is that they're not checkboxes that apply identically to every organization. ISO 27001 requires you to perform a risk assessment, understand what information assets matter most to your organization, identify which risks are greatest, and then determine which controls are necessary to address those risks. This is called "tailoring" controls to your scope and risk profile. A cloud hosting company might implement very detailed physical security controls because they operate data centers. A software company might implement lighter physical security controls because physical facilities are less critical, but they'd implement rigorous access control and monitoring because their primary assets are code and data.

The key principle is this: you can't skip controls because they're expensive or inconvenient. But you can implement controls in ways that make sense for your specific context. Your documentation should explain your risk assessment, explain which controls are relevant to your scope, and explain how you've implemented them. A control can be simpler in a small organization with less complex infrastructure than in a large organization, but both organizations must address the underlying security objective that the control is designed to protect.

Understanding What Needs Protecting: Asset Management and Classification

Before you implement any controls, you need to know what you're protecting. That's what Asset Management controls address. You need to inventory your information assets — what databases, systems, documents, and intellectual property does your organization maintain? You need to classify those assets by sensitivity or criticality. Which assets are critical to business operations? Which contain sensitive or confidential information? Which are personal data subject to privacy regulations?

Asset Management requires that you establish a classification scheme. Maybe you classify assets as public, internal, confidential, and restricted. Maybe you use different criteria — business critical, sensitive, standard. The scheme depends on your business. What matters is that you have one, you apply it consistently, and you use it to determine what protections each asset requires.

Once you've classified your assets, you can make informed decisions about which other controls to apply. If you don't have any restricted or highly sensitive information, you might not need the most rigorous encryption controls. If your business is heavily dependent on particular systems, you need strong backup and recovery controls. Asset management is foundational because it informs every other control.

The Control You Can't Escape: Access Control

Access Control is perhaps the single most important control category in Annex A. It covers how people get access to systems and data, how you verify they are who they claim to be (authentication), how you ensure they can only access what they need (authorization), and how you ensure those access rights are appropriate and timely.

Access Control includes several specific control areas. User access management means you have a process for granting access when someone joins the organization, modifying access when someone changes roles, and removing access when someone leaves. You need to be able to prove that each person who has access is supposed to have it. Authentication controls require that you verify identity — passwords, multi-factor authentication, hardware tokens. Different systems and data might require different authentication mechanisms, but you need something beyond just password. Authorization controls ensure people can only access what they need for their job. If someone works in accounting, they shouldn't be able to access the source code repository.

Access control review is critical and often gets short attention. Organizations grant access and forget about it. Three years pass. Someone still has system access from a job they left two years ago. ISO 27001 requires that you periodically review who has access to what and verify that each access grant is still appropriate. Many organizations struggle with this control because they treat it as a one-time activity rather than a continuous process. The auditor will ask for evidence that you've reviewed access — logs showing a quarterly access review, signed documentation proving that access rights are still appropriate.

Protecting Data: Cryptography and Encryption

Cryptography controls address protecting sensitive data through encryption. ISO 27001 requires that you identify which data requires encryption, determine when that data should be encrypted (at rest in storage? in transit across networks?), and maintain procedures for managing encryption keys.

Cryptography is straightforward in principle — sensitive data should be encrypted so that even if someone gains unauthorized access to the data, they can't read it. But encryption is complex in practice. You need to decide which data to encrypt. All data? Only data classified as sensitive or above? You need to determine where encryption happens. Your databases might encrypt data at rest. Your web applications might encrypt data in transit. Your backups might need encryption. You need to decide on encryption standards and keys. Most organizations use AES-256 for data at rest and TLS 1.2 or higher for data in transit, but these standards matter less than having a documented encryption policy.

The encryption key management part is where many organizations struggle. Encryption keys must be protected as carefully as the data they protect. Keys must be stored securely, rotated periodically, and destroyed when no longer needed. If you have fifty databases, do you have fifty unique encryption keys? Are those keys stored in a key management system? Who can access them? How often are they rotated? Do you have documented procedures for key lifecycle management? An auditor will ask these questions and expect to see documented procedures and evidence that you're following them.

Understanding Where Things Live: Physical and Environmental Security

Physical Security controls ensure that your facilities and equipment are protected. This includes perimeter security — is your data center behind locked doors? Can random people walk into your office and access servers? It includes environmental controls — fire suppression, power protection, temperature management. It includes inventory management — do you know where your hardware is? Can devices be easily stolen?

For a software company without a data center, Physical Security might involve ensuring that offices are locked after hours, that servers are in secure rooms with limited access, that nobody can just walk out with a laptop. For an organization that operates a data center, Physical Security is more extensive — you need multiple levels of physical security, surveillance, access logs, environmental monitoring.

The controls should match your risk. An organization that stores customer data in a data center needs robust physical security. An organization where most data is in the cloud and offices are secure office space needs simpler physical controls. But in both cases, you need to document what your physical security controls are, why they're adequate for your risk profile, and provide evidence that they're functioning.

Detecting and Responding to Problems: Incident Management

Incident Management controls require that you can detect when security incidents occur, respond to them effectively, and learn from them. Many organizations have incident response procedures written on paper but lack the actual capability to detect incidents. They don't know something bad is happening until someone reports it. That's not sufficient for ISO 27001.

Detection requires monitoring and logging. Your systems need to generate audit logs and security events. Those logs need to be reviewed or aggregated to identify suspicious activity. You might use a SIEM (Security Information and Event Management system) that aggregates logs from across your environment and alerts you to suspicious patterns. Or you might have someone periodically reviewing logs from critical systems. But you need some mechanism for detecting incidents, not just responding after someone else finds the problem.

Response requires having a process. When you detect a potential incident, who do you notify? What's the process for investigating? How do you contain the incident to limit damage? How do you document what happened? How do you communicate with affected parties? You need to document your incident response process, and you need evidence that you're actually following it. If an auditor asks "have you had any security incidents in the last year?" and you say "yes, here's the incident we detected through our monitoring, here's our investigation notes, here's how we contained it and remediated it," that demonstrates a functioning incident management process.

Recovery Planning: Business Continuity Management

Business Continuity Management controls address your ability to continue operating if something bad happens. This includes backups of critical data, disaster recovery planning, and actual testing of recovery procedures. Many organizations invest heavily in prevention — hardening systems, monitoring, access controls — but under-invest in recovery. The assumption is that with good controls, you won't have incidents. But that's optimistic. Sometimes incidents happen anyway.

Business Continuity controls require that you identify what systems and data are critical to your business. A customer data platform is critical — if it goes down, you can't serve customers. An internal wiki is less critical — if it's down for a day, it's an inconvenience but not a business blocker. For critical systems, you need backups, you need disaster recovery procedures, and you need to test those procedures. Testing is the critical part. An untested backup is worthless — you don't know whether recovery actually works until you try it. Organizations often have disaster recovery plans on paper but never test them. Then when a real disaster happens and they try to restore, they discover the backups are corrupted or the recovery procedures don't work. ISO 27001 requires evidence that you've tested recovery procedures and that they actually work.

Managing Your Vendors: Supplier Relationships

Supplier Relationships controls address the security practices of vendors and service providers you rely on. You use email providers, cloud hosting, third-party SaaS applications, maybe consultants who have access to your systems. Those vendors handle your data or affect your security posture. You need to assess whether they have adequate security practices, monitor them to ensure they're maintaining those practices, and have contractual terms that make them accountable for security.

This includes vetting vendors before you engage them — due diligence to understand their security controls. It includes having contracts that require appropriate security practices and define what happens if they have a breach. It includes monitoring vendors to ensure they're maintaining agreed-upon security levels. Many organizations are weak in this area — they use a vendor, the vendor has a breach, the organization is surprised that the vendor didn't have adequate controls. ISO 27001 requires that you actively manage vendor risk.

Common Implementation Gaps and How to Avoid Them

Several controls consistently trip up organizations during their first ISO 27001 audit. Understanding these common gaps helps you avoid them.

Gap one: Incident Detection. Organizations have incident response procedures but no actual mechanism for detecting incidents. They've written a response plan but they don't have monitoring in place. They don't have logging configured on critical systems. They're essentially hoping someone will report a problem rather than detecting it themselves. The solution is to implement logging and monitoring on critical systems and establish a process for reviewing those logs at least periodically.

Gap two: Business Continuity Testing. Organizations have disaster recovery plans on paper but have never tested them. They don't know whether they can actually recover. The solution is to schedule regular testing of backup and recovery procedures. Document the results. If testing reveals problems, fix them. Show the auditor your test results and evidence that you can actually recover.

Gap three: Supplier Management. Organizations use vendors but don't adequately vet them or monitor them. They've never asked a vendor about their security practices or reviewed their SOC 2 report. The solution is to establish a vendor assessment process. For critical vendors, ask about their controls. Review security documentation if they have it. Have contracts that require adequate security.

Gap four: Cryptography Key Management. Organizations encrypt data but don't have documented procedures for managing encryption keys. Keys are protected informally. Nobody knows who has access to keys or when they were last rotated. The solution is to document your encryption standards, document your key management procedures, and actually follow them. If you're using a cloud provider's encryption, understand their key management practices. If you're managing your own keys, ensure they're protected and rotated properly.

Gap five: Access Control Review. Organizations grant access but don't periodically review who has access and whether they still need it. The solution is to establish a quarterly or semi-annual access review process. Document who reviewed what. Verify that each access right is still appropriate. Remove any access that's no longer needed.

Evidence Is Mandatory, Not Optional

The requirement that often surprises organizations is that implementing controls isn't enough — you have to prove they're working. When the auditor asks about access control, they don't just want to hear that you have access reviews. They want to see evidence: access review documentation, evidence of who reviewed what, signed off approvals that access rights are appropriate.

When the auditor asks about incident management, they want evidence: logs from your monitoring systems, incident reports for any incidents you've detected, investigation notes, remediation actions. When the auditor asks about business continuity, they want test results, recovery procedures, evidence that you've actually tested recovery and it works.

This evidence gathering often gets overlooked during implementation. Organizations build controls but don't systematically gather evidence. Then when the auditor arrives, they scramble to provide proof that controls are working. Start gathering evidence as you implement controls. If you're implementing access reviews, keep the access review documentation. If you're implementing monitoring, keep the logs or reports showing monitoring results. If you're testing backups, document the test results. By the time the audit arrives, you have a complete trail of evidence that your controls are functioning.

What This Means for Your Organization

You now understand the fourteen control categories in Annex A and what they actually require. You understand that controls should be tailored to your organization's risk profile and scope. You understand the common gaps that trip up organizations and how to avoid them. You understand that evidence of control effectiveness is mandatory. You're ready to assess your current security practices against these control categories, identify gaps, and build or remediate controls as needed for certification.

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.