If you’re a small organisation working towards ISO 27001, there’s a moment that almost always arrives…

You look at Annex A.
You look at your tech stack.
And you think:

“We don’t run servers. We barely run anything. Surely half of this is the cloud provider’s job?”

Yes… and no.

Cloud platforms absolutely reduce what you need to build from scratch. But they don’t reduce what you’re accountable for. That distinction matters. A lot.

Many of my clients immediately think they can mark half of the Annex A controls as ‘not applicable’, but it’s not that easy, I’m afraid.

---

The short version

Cloud lets you offload technical responsibility, not ownership or accountability.

In ISO language, you still need to ensure:

• controls are appropriate for your risks
• controls are implemented (whether by you or a supplier)
• controls are operating effectively
• you can evidence that to an auditor

So you can absolutely point at AWS, Microsoft, Google, Stripe, GitHub, etc. and say ‘these platforms handle controls X,Y,Z’, but you still need to show you’ve done your part.

---

The best model for auditors

If you’re using AWS, Azure, M365, Google Cloud, etc., you’re already living inside a shared responsibility model. In fact, if you search for the term and the SaaS provider’s name, they’ll likely point you towards it. -> e.g. here’s AWS’ shared responsibility model:

That model is a powerful way to explain scope and accountability in an audit. Who doesn’t like a nice diagram? I know I do!

A simple version like that works well for SMEs trying to explain how things sit between two parties:

The supplier typically handles:

• physical facilities (the data centre, fire systems, etc)
• underlying infrastructure (the tin)
• core network and hypervisor layers
• platform resilience (depending on service type)
• baseline security of the cloud service

You typically handle:

• identity and access configuration
• tenant settings
• user lifecycle
• data classification
• data retention
• encryption choices (sometimes)
• logging decisions and alerting
• secure use of the service
• what you integrate and how
• vendor selection and ongoing assurance

This is usually what auditors want to hear:

---

The biggest mistake I see

Small organisations assume: “Because AWS/M365 is secure, we’re secure.”

That’s not how auditors see it. And honestly, it’s not how attackers see it either.

Cloud services are robust. But most real-world breaches in cloud-first businesses happen because of:

• weak identity setup
• over-permissioned accounts
• poor offboarding
• insecure integrations
• sloppy data handling
• no monitoring
• no clarity on roles
• maybe even backups (seriously, check on this – not all cloud providers are taking backups of your data should it get destroyed).

In other words, the things you control. And I’m sorry to say, but often people are the weakest link, especially if they haven’t been trained on what good looks like.

---

How to approach Annex A without drowning

So, the good news; instead of trying to “map everything”, use a three-layer plan:

You’re aiming for a clear story, not a 200-page novel. Just enough to outline both to yourselves, and an auditor where the separation is between you and the supplier.

---

What you can offload (and how to prove it)

1) Parts of physical and environmental security

If you’re not running a data centre, you won’t be implementing physical controls directly.

What you do instead:

• list the supplier(s) in your supplier register
• record the service they provide
• retain assurance evidence (SOC 2, ISO 27001 certificates, or similar)
• confirm this is included in your supplier review process

Auditor-friendly evidence:

• supplier register with risk rating
• a short due diligence record
• the provider’s ISO 27001 cert or SOC report reference
• annual review entries

---

2) Some baseline infrastructure security

For most SMEs using standard cloud services, you’re not responsible for:

• physical network cabling
• building access systems
• hypervisor patching
• rack-level security
• power and cooling resilience

But you still need to show you selected a reputable supplier and you understand what they cover.

---

---

What you cannot offload

These are the controls where cloud-first SMEs must show maturity, even if everything is hosted elsewhere.

1) Identity and access control

If I had to bet on the top Annex A area that catches small cloud-first companies out, it’s this.

What good looks like:

• MFA enforced across critical systems
• least privilege is a real practice, not a slogan
• admin accounts are limited and monitored
• joiner/mover/leaver is defined and used

Easy evidence:

• screenshots of MFA enforcement
• sample access approvals
• leaver removal records
• a monthly access review log (even a lightweight one)

This is the part you own.

---

2) Data classification and handling

Cloud providers don’t know your business context. You do.

What good looks like:

• simple data categories
• clear rules for storing and sharing data
• real examples of classification in use

Easy evidence:

• your classification scheme
• a short data handling guide
• examples of labelled documents or drive structures
• DLP settings if you use them

You can keep this amazingly simple and still pass.

---

3) Logging and monitoring

Cloud platforms offer tools. They don’t force you to use them well.

What good looks like:

• defined logging expectations
• logs enabled for key systems
• alerting for high-risk events
• someone actually looks at dashboards or reports

Easy evidence:

• your logging standard
• screenshots of enabled audit logs in M365/Google
• AWS CloudTrail settings
• basic monthly security review notes

---

4) Backup and recovery decisions

This is another common misunderstanding.

Some services help with resilience.
But you are responsible for ensuring your data is recoverable within your required timeframes.

What good looks like:

• backup scope documented
• restores tested
• RTO/RPO defined at a sensible business level

Easy evidence:

• backup policy
• restore test record
• a short DR overview for cloud services

Auditors love restore tests. Because they prove reality.

---

5) Supplier management itself

Using the cloud doesn’t remove the need for third-party control. It increases it.

What good looks like:

• a supplier register
• risk-based onboarding
• security requirements built into contracts where appropriate
• periodic review for key suppliers

Easy evidence:

• supplier risk assessments
• a basic security addendum
• review records for your top 5

This is also where you slot in your cloud provider assurances.

---

A simple “cloud boundary” statement you can use

You can include something like this in your ISMS scope / context of the organisation to help clarify things.

Control responsibility statement

We use cloud services for core infrastructure and corporate systems. Security responsibilities are divided as follows:

Supplier responsibilities include: physical security, underlying infrastructure security, baseline platform resilience, and platform maintenance.

Our responsibilities include: identity and access configuration, tenant security settings, data management and classification, user lifecycle controls, logging and monitoring configuration, and incident response coordination.

We remain accountable for ensuring controls are appropriate and effective, including those delivered by suppliers.

This paragraph alone often stabilises the audit conversation. I’d back it up with a matrix of ownership explaining the shared responsibility model, and where controls sit, but it frames it.

---

How to show this in an audit without overcomplicating it

If you want a tidy way to present this:

Create a one-page matrix for your key platforms:

Platform	What we configure	What we monitor	Supplier assurance we hold
AWS	IAM, security groups, logging, encryption choices	CloudTrail, alerts, access reviews	ISO cert / SOC references
Microsoft 365	MFA, conditional access, admin roles, retention	Audit logs, sign-in risk, DLP	ISO cert / SOC references
Google Workspace	MFA, admin roles, sharing controls	Audit logs, Drive sharing reports	ISO cert / SOC references

Keep it short. Auditors want clarity more than complexity.

---

The key takeaways for small teams

You don’t need to implement everything yourself.
You do need to prove you are steering the ship, not just riding in the cargo hold.

A sensible Annex A approach for cloud-first SMEs is:

1. Choose reputable suppliers
2. Document the boundary
3. Lock down identity
4. Control your data
5. Enable logging
6. Test recovery
7. Review suppliers annually
8. Record small, regular evidence

That is typically enough to satisfy both the standard and reality.

---

An Example Control: A.8.20 Network security (using AWS)

So, to provide an example of how to approach a control, I’ve chosen ISO 27001 control 8.20 Network Security, on AWS. So, the entry might look like this;

For cloud-first organisations, the auditor mainly wants to see that you’ve secured what you control:

• clear AWS boundary statement
• segmentation and least-privilege rules
• minimal public exposure
• logging enabled
• a light recurring review

That’s the “good looks like” story in five beats.

---