ISO 27001 Infrastructure Checklist: Annex A in Practice

Most of ISO 27001’s Annex A is policy and process — the infrastructure work concentrates in roughly a dozen controls. The 2022 revision of the standard reorganized Annex A into 93 controls across 4 themes (organizational, people, physical, technological), and it’s the 34 technological controls (A.8) plus a handful of organizational ones like A.5.15 that dictate what changes in your AWS, GCP, or Azure account. This post filters Annex A down to that infrastructure subset — access control, cryptography, operations security, network security, logging, and backup — and gives each a concrete cloud implementation an auditor will accept.

One note before the checklist: this is engineering guidance from a practitioner, not legal or formal compliance advice — your auditor and your Statement of Applicability have the final word.

Which Annex A controls actually touch infrastructure?

Out of 93 controls, the ones that generate real cloud engineering work cluster into six domains, and you can knock most of them out with the same platform hygiene you’d do anyway. The table below is the working subset we use when scoping an ISO 27001 readiness project for a startup.

Domain	Key controls	Cloud implementation
Access control	A.5.15, A.8.2, A.8.5	SSO + IAM roles, no shared creds, MFA everywhere
Cryptography	A.8.24	KMS-managed encryption at rest, TLS in transit
Ops security	A.8.9, A.8.10	IaC-defined config, data deletion procedures
Network	A.8.20, A.8.22	Private subnets, security groups, env segregation
Logging	A.8.15, A.8.16	Centralized audit logs, alerting on anomalies
Backup	A.8.13	Automated backups, tested restores, cross-region copies

Everything else in Annex A — HR screening, physical security, supplier management — matters for certification but doesn’t change your Terraform.

How do you implement the access control requirements?

A.5.15 (access control), A.8.2 (privileged access rights), and A.8.5 (secure authentication) together mean: every human goes through SSO, every workload uses a role, and privileged access is separate and reviewed. The concrete build is the same on all three clouds — IAM Identity Center on AWS, Cloud Identity on GCP, Entra ID on Azure — federated to your identity provider, with MFA enforced at the IdP.

The parts auditors probe hardest:

• No long-lived credentials. Static access keys and service-account JSON files are the first finding in almost every readiness review. Use OIDC federation for CI and instance/workload identity for services.
• Privileged access is distinct. Admin roles should be separate assumable roles with shorter session durations, not extra policies on daily-driver accounts.
• Quarterly access reviews with evidence. A recurring calendar event plus an exported IAM report satisfies this; an untracked “we check sometimes” does not.

This is the same access story SOC 2 wants, which is why we scope both together — see the SOC 2 infrastructure package for how that overlap plays out.

What does “use of cryptography” (A.8.24) look like in the cloud?

A.8.24 asks for rules on effective use of cryptography, including key management — in practice, encrypt everything at rest with a KMS-managed key and require TLS in transit, then write down that that’s your policy. Cloud providers make the implementation nearly free: default EBS/S3 encryption on AWS, default encryption on GCP (already on for everything), storage service encryption on Azure.

What actually takes engineering time is the edges: enforcing TLS on internal service-to-service traffic, blocking unencrypted storage via policy (SCPs, org policy constraints, Azure Policy), and deciding whether customer-managed keys are worth the operational cost. For most 5–25 engineer teams, provider-managed keys with a documented rotation stance is the right call; customer-managed keys are for when a customer contract demands them.

Which operations and network controls matter most?

A.8.9 (configuration management) is quietly the highest-leverage control for a startup: if your infrastructure is defined in Terraform or OpenTofu with review-gated changes, you’ve largely satisfied it. IaC plus branch protection gives you the standard configurations, the change control, and the audit trail in one move. Pair it with a drift check and you’re ahead of most certified companies. If your stack isn’t in code yet, that’s step one — it’s the foundation for Terraform-based environments we set up for clients.

For network security, A.8.20 (networks security) and A.8.22 (segregation of networks) translate to: databases and internal services in private subnets, security groups scoped to actual need, and production segregated from staging and dev — separate accounts/projects/subscriptions, not just separate VPCs, is the clean answer on all three clouds. A.8.10 (information deletion) rounds this out: define retention on logs and data stores so deletion happens by configuration, not by ticket. A free head start on hardening baselines is covered in our CIS Benchmarks guide.

What do auditors expect for logging and backup?

A.8.15 (logging) and A.8.16 (monitoring activities) require that logs exist, are protected from tampering, and that someone would actually notice an anomaly. The build: CloudTrail/Cloud Audit Logs/Azure Activity Log shipped to a locked-down central location, application logs centralized, retention set to your documented policy, and at least basic alerting on suspicious events (root login, IAM policy changes, disabled logging). A.8.16 was newly introduced in the 2022 revision, so don’t assume an old 2013-era checklist covers it.

A.8.13 (information backup) is where startups most often fail the spirit of the control: backups exist, but nobody has ever restored one. Automated snapshots with retention are table stakes; the evidence auditors want is a documented, dated restore test. Do one per quarter, screenshot the restored instance, file it. Cross-region or cross-account backup copies are worth the modest cost for anything you’d call production.

Should you do ISO 27001 and SOC 2 infrastructure work together?

Yes — the infrastructure layer is close to identical, so doing them as one project is materially cheaper than sequencing them. Access control, encryption, logging, change management, and backup evidence all serve both frameworks; what differs is the management-system wrapper ISO 27001 adds on top. If you’re unsure which to pursue first, our ISO 27001 vs SOC 2 comparison walks through the buyer-driven logic, and the SOC 2 infrastructure checklist shows how far the overlap goes control by control.

If you want the gap analysis done for you, ByteDel’s audit maps your current AWS, GCP, or Azure setup against this exact subset and hands you a prioritized fix list — see pricing for how the audit and remediation packages work.