Information security for use of cloud services

Plain-language summary

New in 2022: deciding how your organisation acquires, uses, manages and leaves cloud services — from Microsoft 365 and Google Workspace to the hosted ERP and the file-sharing tool someone in sales signed up for — according to your own security requirements, not the provider's defaults.

What the clause is really asking

Cloud is where most organisations' information actually lives now, and this control exists because the old supplier controls assumed a contract negotiated between two parties, which is not how cloud works. The control asks you to establish and apply processes for the whole life cycle: deciding what your security requirements for a cloud service are before you buy it; selecting services that meet them (location of data, encryption, access control, logging, backup, incident notification, what happens to your data on exit); defining who in your organisation does what versus the provider under the shared-responsibility model; managing the service while you use it (monitoring, access reviews, change notifications from the provider); and planning the exit — getting your data back in a usable form and having it deleted. A topic-specific policy on cloud use is the usual anchor. In South Africa this is also POPIA's cross-border transfer question (section 72) whenever the provider's region is outside the country, and it is the control that governs the 'shadow IT' subscriptions nobody in IT approved.

What auditors look for

Auditors start by asking for the cloud service register and then go looking for services that are not on it: expense claims for software subscriptions, browser extensions, the marketing team's design tool. For a service that is on the register they ask for the security requirements you set before buying, the evidence the provider meets them (SOC 2 or ISO 27001 certificate, data-residency statement, contract or terms), the shared-responsibility split written down, and the last access review you ran inside the service. They ask what happens if you leave — where the export clause is and whether anyone has tested an export. For personal information hosted abroad they ask how the POPIA section 72 condition is met.

Typical evidence

Cloud services policy; cloud service register with owner, data classification, region and criticality; security requirements and provider assurance per service (certificates, SOC reports, terms); shared-responsibility matrix; access review records inside each service; provider change and incident notifications and your response; exit plans and a tested data-export; POPIA section 72 basis for offshore hosting.

How to comply — recommendations

Write a two-page cloud services policy that says who may approve a new cloud service, the minimum requirements any service must meet (MFA for all users, data region, provider certification, export capability, breach notification within a defined period), and that every service goes on the register. Build the register from your accounting system's subscriptions as well as IT's list — that is where shadow IT surfaces. For each critical service, fill in a one-page shared-responsibility sheet: identity, data, backup, logging, patching — who does which. Diarise quarterly access reviews inside the three services that hold the most sensitive data. Test one export a year. Record the section 72 basis for any provider hosting personal information outside South Africa.

Common nonconformities

No cloud policy or register; services in use that IT never approved; security requirements never defined before purchase; shared-responsibility split undefined, so backups and access reviews fall between the parties; no exit or export plan; personal information hosted offshore with no POPIA section 72 basis recorded; provider assurance (certificates, SOC reports) never collected or expired.

Resources for this clause

• ArticleISO/IEC 27001:2022 Annex A explained: the 93 controls in plain English, theme by theme, with the 114-to-93 map and the attribute tags
• ArticleThe Statement of Applicability, explained — what ISO/IEC 27001 clause 6.1.3 requires, the four ways an SoA fails Stage 1, and how to build one from the risk register
• ArticleISO/IEC 27001:2022 explained for people who already run ISO 9001: what is the same, what is new, and how to get certified
• Toolkit · $39Risk & SoA ToolkitScore your information security risks on a documented method, pick the Annex A controls that treat them, and the Statement of Applicability writes its own first draft — every justification citing the risks behind it.
• Toolkit · $29ISMS Metrics & Evidence TrackerThe three things an ISMS has to show after certification, in one workbook: measures with a live Green / Amber / Red status, management review minutes that cover every required input, and an evidence register that gives every control an owner, a rhythm and a due date.
• Free downloadAnnex A 93 Controls Quick ReferenceOne A3 page: all 93 Annex A controls in their four themes, the eleven new in 2022 flagged, and the ISO/IEC 27002:2022 attribute legend — the poster for the wall beside the Statement of Applicability.
• Free downloadISO 27001 Gap Analysis ChecklistWhere you stand against ISO/IEC 27001:2022 in one afternoon — the 30 management-system requirements and all 93 Annex A controls, scored, with owners, dates and a readiness figure that calculates itself.
• Free masterclass · ~27 minISO 27001 MasterclassYou already know four fifths of ISO 27001. Here is the other fifth — the risk method, the SoA, the 93 controls, the evidence rhythm, POPIA, and a 44-week path.
• Free appAudit ManagerPlan the programme, anchor each finding to its clause and drive the NC to closure.