Auditing Cloud Security Under ISO 27001
Most organisations now run on infrastructure they do not own. That changes what evidence looks like but not what the requirements are: using somebody else’s platform is a way of treating risk, not a way of transferring the requirement. The audit question is what the organisation did about the dependency, and what it can show.
Most organisations now run on infrastructure they do not own. That changes what evidence looks like but not what the requirements are: using somebody else’s platform is a way of treating risk, not a way of transferring the requirement. The audit question is what the organisation did about the dependency, and what it can show.
The organisation in the worked finding on this page is invented, and so is the finding.
Where cloud security actually sits in ISO 27001
There is one control with cloud in its title, and it is not where most of the auditing happens. The cloud reaches into the management system clauses first, and into several other controls after that.
| Requirement | What the cloud does to it |
|---|---|
| Clause 4.3 scope | The third consideration is interfaces and dependencies with other organisations. A platform the organisation depends on is exactly that, and a scope drawn without reference to it has skipped a limb of the clause |
| Clause 6.1.2 risk assessment | The risks of using the service have to be identified, analysed and evaluated like any others, with risk owners |
| Clause 8.1 operation | Externally provided processes, products or services relevant to the ISMS must be controlled. That wording is wider than the “outsourced processes” it replaced, and a purchased service reaches it as readily as an outsourced function |
| A.5.23 | Processes for acquisition, use, management and exit from cloud services, established in accordance with the organisation’s information security requirements. One of the eleven controls the 2022 revision added |
| A.5.19 to A.5.22 | The cloud provider is a supplier. Every supplier control applies to it, and A.5.23 sits alongside them rather than replacing them |
| A.8.21 | Security mechanisms, service levels and service requirements of network services, identified, implemented and monitored |
Start at the Statement of Applicability. A.5.23 and the supplier controls alongside it are ones the organisation selected at Clause 6.1.3, and what that document claims about each is your first criterion. The clauses named alongside them apply whatever it says, which is worth remembering when an auditee answers a scope question with a control reference.
The four verbs in ISO 27001 Annex A.5.23
Acquisition, use, management and exit. Read them as four separate things, because an organisation can be sound on one and empty on another, and a finding has to name which.
Acquisition — what the organisation requires of a cloud service before it takes one, and how it decides.
Use — how the service is configured and operated against those requirements once it is running.
Management — who owns the relationship, what is watched, and what happens when the provider changes something.
Exit — the arrangements for leaving, which almost nobody has and almost everybody has agreed to in a contract they have not read since.
Exit is the limb organisations most often have on paper and least often have worked through. The control asks for a process, so what is auditable is whether one exists and what it covers — not your view of what a good exit arrangement ought to contain. Where the organisation’s own arrangements set out what exit requires of it, those are the criteria.
Not sure about the course yet?One year of free retraining on the same exam version is included.
What you can and cannot audit in an ISO 27001 cloud audit
This is the part auditors get wrong in both directions, so it is worth being exact.
| In scope for your audit | Not in scope |
|---|---|
| What the organisation determined it needed from the service | Whether the provider’s own controls are well designed |
| What the organisation configured, in the parts it controls | The provider’s internal operations |
| What the organisation monitors, reviews and does about what it finds | The provider’s certification, beyond whether the organisation looked at it and what it concluded |
| What the organisation would do if the service failed or ended | The provider’s resilience, as a fact about the provider |
You are not auditing the cloud provider in this audit. You have no audit agreement with them, no access, and no standing. What you are auditing is the organisation’s management of a dependency — and the fact that the dependency is large does not make the organisation’s obligations smaller. An auditee who says “that is the provider’s responsibility” has answered a different question from the one you asked, which was what the organisation does about it.
The mirror error is worse. An auditor who starts assessing the provider’s architecture has left the audit criteria behind, is making judgements they cannot evidence, and will lose the argument the moment the auditee asks which requirement is being cited.
The audit trail for ISO 27001 cloud security
Start with the list. Which cloud services does the organisation use, and who says so? A list held by procurement, a list held by IT and a list of what is actually paid for are three different documents in most organisations, and the difference between them is where the audit is.
Then take one service and follow it. Not the biggest one — one you choose, ideally one new enough to have gone through whatever process exists. What did the organisation require of it before adopting it? Who decided it was acceptable? What is watched now?
Then ask about the parties behind it. A cloud provider is itself a customer of other providers, and the organisation’s information may reach several of them. What the organisation knows about that chain, and what its arrangements say about changes to it, is a real question with an unrehearsed answer.
And ask the exit question. It is the one nobody prepares for.
Looking for an approved provider?3FOLD TRAINING is a CQI and IRCA Approved Training Partner, ATP 6039853.
A worked ISO 27001 finding on Annex A.5.22
Falkirk Bookbinders runs its order management and customer records on a hosted platform, adopted three years before the audit through a documented acquisition process with a recorded security assessment.
| Statement | A cloud service the organisation classifies as critical has not been monitored or reviewed since adoption, and changes to the service are not managed. |
|---|---|
| Objective evidence | The supplier management procedure requires each service classified as critical to be reviewed at least annually against its security requirements, with the review recorded, and requires notified changes to a service to be assessed before they take effect. The hosted platform is classified critical in the supplier register and was adopted three years and two months before the audit. One review is recorded, dated at adoption; none since. The provider’s status and release pages show eleven feature releases in the period and two changes to its authentication options, both of the latter announced as requiring customer action. No record of any assessment of any of them was produced. The service owner confirmed that release notices go to a shared mailbox that nobody is assigned to read, and that the organisation acted on one of the two changes requiring action after a user reported a problem. The organisation holds the provider’s current certification and a recent assurance report; neither has been read against the organisation’s own requirements, and no record of any conclusion drawn from either was produced. |
| Requirement | ISO/IEC 27001 Annex A.5.22 requires the organisation to regularly monitor, review, evaluate and manage change in supplier information security practices and service delivery. The organisation’s supplier management procedure, section 7, sets an annual documented review for services classified critical and requires notified changes to be assessed before they take effect. |
| Grade | Major — the annual review the organisation set itself has been performed once in three cycles for a service it classifies as critical, changes have gone unassessed as a matter of routine rather than in particular instances, and the assurance material held has produced no conclusion, so the monitoring and review the control requires is not happening rather than happening imperfectly. |
Note which control this cites, and which it does not. The organisation’s acquisition process ran and is documented, so a finding against A.5.19 or against the acquisition limb of A.5.23 would be defeated by producing the assessment. What has not happened is everything after adoption. Cloud findings cluster at the beginning of the relationship because that is where the paperwork is; the requirements do not stop there.
What a minor on the same control would look like. The reviews performed on schedule for every other critical service and missed once here; or the reviews performed and recorded, with one notified change assessed late. The grade turns on whether the activity happens and slipped, or does not happen. Here it does not happen, and the unread mailbox is why.
One discipline in writing any of these. What you were told goes in where it establishes how far the failure reaches; your own diagnosis of why it happened stays out, because the cause is the organisation’s to establish under Clause 10.2. The service owner’s account of the unread mailbox is recorded because it establishes reach — it tells the reader that the gap covers every notice, not the two that happened to matter.
Preparing for the PR373 exam?Full-length mock exams and exam application support are included.
Cloud shared responsibility, and how to audit it under ISO 27001
Every cloud arrangement divides the work between the provider and the customer, and the division moves depending on what kind of service it is.
| Roughly | More usually the provider’s | More usually the organisation’s |
|---|---|---|
| Infrastructure services | Physical, host and hypervisor | Operating systems, network configuration, identity, data, everything above |
| Platform services | The above, plus the runtime | The application, its configuration, identity, data |
| Software services | Almost all of it | Identity and access, configuration options, the data itself, and what leaves |
That table is an orientation, not a criterion. The real division is in the organisation’s own arrangements with its provider, and those are what you audit against. An auditor who cites a general model rather than the organisation’s own documents has invented a requirement.
What the model shows is that the division moves but never disappears. In every row, identity, access and data stay with the organisation, which is why so much cloud auditing turns out to be access control in a different setting.
Major or minor in an ISO 27001 cloud finding
Major territory: a class of service adopted with no process at all; nothing monitored or reviewed across the whole period for a dependency the organisation itself classifies as critical; network services obtained with no security mechanisms or service levels identified for any of them.
Minor territory: one service missing from the register; one change assessed late; an exit arrangement that exists but has never been reviewed.
Escalation: several services all showing the same gap after adoption is a case about A.5.22 or about who owns supplier management, rather than a run of separate findings.
And the criteria are the standard, the organisation’s own requirements and its legal and contractual obligations. On this subject the temptation to substitute your own view of good cloud practice is stronger than anywhere else, because the technology moves faster than the standard does. It is still not a criterion.
ISO 27001 cloud security: where does the cloud touch the standard?
Pick a clause or control to see what the cloud does to the requirement.
How to use it: Choose the option that fits you from the list. The answer appears below.
From the table in this article. A cloud provider is a supplier, so the supplier controls apply as well as A.5.23.
Frequently asked questions about auditing cloud security under ISO 27001
Which ISO 27001 control covers cloud services?
A.5.23, information security for use of cloud services, which requires processes for acquisition, use, management and exit from cloud services to be established in accordance with the organisation’s information security requirements. It is one of the eleven controls new in the 2022 revision, and it sits alongside the supplier controls at A.5.19 to A.5.22 rather than replacing them.
Can I audit the cloud provider in an ISO 27001 audit?
Not as part of this audit — you have no audit agreement with them and no access. What is auditable here is the organisation’s management of the dependency: what it required, what it configured, what it monitors and what it would do if the service ended. A provider’s own ISMS is a separate engagement with a different auditee.
Does a cloud provider’s certificate satisfy the ISO 27001 requirement?
It is information the organisation may rely on, not a substitute for anything. What the standard asks about is what the organisation did with it — whether it read the certificate’s scope against its own requirements, and what it concluded. A certificate on file with no conclusion drawn from it is a document, not evidence.
Is a cloud service inside the ISO 27001 ISMS scope?
Clause 4.3 requires the scope to be determined considering interfaces and dependencies with other organisations. A service the organisation depends on has to be accounted for in that reasoning, whoever operates it. How it is expressed in the scope statement is the organisation’s decision; whether it was considered is auditable.
Where do most ISO 27001 cloud findings sit?
After adoption rather than at it. Acquisition tends to be documented because it involves a purchase; monitoring, change management and exit tend not to be, because nothing forces them to happen.
The other ISO 27001 control areas
auditing backup and recoverability
auditing supplier and third-party security
For the controls behind these areas, the four Annex A theme pages set out what each group requires: the A.5 organizational controls, the A.6 people controls, the A.7 physical controls, the A.8 technological controls.
3FOLD TRAINING is a CQI and IRCA Approved Training Partner, ATP number 6039853. Its ISO 27001 Lead Auditor training course is the CQI and IRCA Certified ISO/IEC 27001:2022 Lead Auditor (Information Security Management Systems) Training Course. The course identification number is 2889. Both the partner approval and the course certification are on 3FOLD TRAINING’s Approved Training Partner record, and any provider’s certified courses can be looked up in CQI and IRCA’s own directory of certified courses and approved training partners. The course page carries the schedule and what the course includes. If you would rather ask a person first, use the course enquiry form.
Booking a PR373 course? See the schedule, trainers and what’s included.
Leave a reply