The ISO 27001 Annex A Controls That Actually Get Tested

People spend weeks agonizing over their Statement of Applicability. They spend months designing an ISMS that looks beautiful on paper. Then the auditor arrives, ignores the beautiful paper, and goes straight for the operational jugular.

If you have never been through an ISO 27001 audit before, what follows will save you a significant amount of pain.

Auditors are not random. They work from risk. They sample from the ISO 27001 Annex A controls most likely to be designed poorly, operated inconsistently, or documented inadequately. Here is where their attention actually goes.

Access Control: The First Place Every Auditor Starts

Annex A 5.15 through 5.18 covers access management, and auditors treat it as table stakes. They will ask to see your access provisioning and deprovisioning records. They will pull samples: three recent joiners, three recent leavers, three role changes. They want to see that access was granted on the right day, with the right approvals, and revoked promptly when someone left.

“Promptly” is not a philosophical concept. It is a timestamp.

If your offboarding process produces access revocation within 24 hours consistently, that is clean. If you have a sample where an account sat active for two weeks after someone resigned, that is a nonconformity waiting to happen.

Privileged access gets extra scrutiny. Who has admin rights? Is it justified? Is it reviewed? Auditors want to see quarterly or more frequent reviews of privileged access with documented approvals. An access review that happened once during implementation and hasn’t run since is not a functioning control. It is a historical artifact.

Supplier Relationships: The Control Area Most Teams Under-Build

Annex A 5.19 through 5.22 covers information security in supplier relationships. This is where well-prepared teams often have gaps, because it requires operational rigor, not just a well-written policy.

Auditors will ask for your vendor inventory. They will pick three to five vendors with access to your systems or data and ask the uncomfortable questions: What due diligence did you perform before onboarding them? What contractual security requirements did you impose? How do you monitor their compliance on an ongoing basis?

The gap most teams have is simple: the vendor inventory exists, but the due diligence records do not. You cannot prove you assessed a vendor’s security posture before giving them access to customer data if you didn’t document the assessment.

Verbal conversations do not survive audits.

Third-party penetration tests and SOC 2 reports from vendors count as due diligence evidence. So does a completed security questionnaire. The point is to have something documented that shows you didn’t just hand over access on blind trust.

Incident Management: The Control That Proves Your System Is Real

Annex A 5.24 through 5.28 covers information security incident management. For this control area, auditors want to see an incident register and closed incident records with root cause analysis.

If you have never logged a single security incident, that is a problem. Not because security incidents are required, but because their absence suggests a flaw. Either you are not monitoring effectively enough to detect them, or your definition of an incident is so narrow that everyday security events slip by unrecorded.

Auditors understand that not every organization has faced a major breach. What they are looking for is evidence that your monitoring capabilities actually work, that your team knows what to do when an alert fires, and that you learn from the aftermath. A handful of minor incidents handled well, documented fully, and fed into a lessons-learned process demonstrates a functioning system.

Perfection demonstrates a blind spot.

Change Management: Where Technical and Compliance Worlds Intersect

Annex A 8.32 requires you to manage changes to information systems through a formal process. For software companies, this means your development and deployment pipeline needs to be auditable.

Auditors will pull sample deployments and trace them from request to production. They want to see approval workflows, testing evidence before deployment, and post-deployment review for significant changes. Emergency changes are a particular focus. They want to confirm that even when the servers are on fire, urgent changes went through some form of authorization and were reviewed after the fact.

Teams running mature CI/CD pipelines often have strong evidence here: pull request history with required reviewers, automated test results, deployment logs with timestamps and actor attribution. Teams running informal processes where deployments happen directly to production without review will find this control area expensive to remediate mid-audit.

Cryptography: Simpler Than Teams Expect, But Often Under-Documented

Annex A 8.24 requires a policy for the use of cryptography. Auditors check whether you have defined standards for encryption at rest and in transit, whether those standards are actually in use, and whether you manage cryptographic keys with appropriate controls.

The common failure here is not using weak encryption. Modern cloud environments encrypt everything by default, and most teams are fine technically. The failure is the translation from technical reality to documented standard.

What algorithm do you require? What key length? Who manages keys and how? What happens when a key needs rotation or revocation?

If your cryptography policy is a single paragraph that says “we use encryption,” an auditor will push for specifics. Get specific in writing before the audit begins.

Business Continuity: The Control That Requires Evidence, Not Plans

Annex A 5.29 and 5.30 address information security during disruption. Having a business continuity plan is not the same as having a tested, operational capability. Auditors know this, and they will ask for test records.

Pull your last backup restore test. When did it run? Who ran it? Did it hit your Recovery Time Objective? If you cannot produce a documented test result with a date, an executor, and an outcome, you have a gap,regardless of how detailed your BCP documentation is.

Plans that have never been tested are hypotheses, not controls.

What This Means for Your Audit Preparation

The controls above account for a disproportionate share of nonconformities in ISO 27001 certification audits. Not because they are the most technically complex, but because they require consistent operational execution over time rather than a one-time setup. Ultimately, the ISO 27001 Annex A primary goal is to ensure your security practices actually mitigate risk in the real world, not just in a spreadsheet.

Start your audit preparation by pulling your own evidence samples for these areas. Treat yourself the way an auditor will. If the evidence is thin, inconsistent, or incomplete, you have time to fix it before fieldwork begins.

Ready to simplify compliance?

At Regodit, we believe compliance should reflect reality, not obscure it. If you want a cleaner way to run this playbook, explore how Regodit helps you operationalize GRC without slowing your roadmap. Schedule a call or a short demo, and see how the evidence builds itself while your team ships.