ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
A cloud service agreement is where ISO/IEC 27017 stops being a control list and becomes a contract, and it is the document most cloud customers sign without reading the security half. ISO/IEC 27002:2022 control 5.23, information security for use of cloud services, asks the customer to establish what the agreement must cover; control 5.20 asks that supplier agreements address information security; and ISO/IEC 27017:2026 layers cloud-specific guidance on both, for the provider drafting the terms and the customer accepting them.
The agreement is also where the shared responsibility matrix gets its legal force: a matrix that says the provider patches the hypervisor is an intention until the cloud service agreement says so. This guide sets out the eight security clauses an agreement needs, which ISO 27017 and 27002 controls each one implements, what the provider and the customer each owe under it, the two clauses that decide what happens when the relationship ends, and the five gaps that appear when an agreement is read against the matrix.
ISO/IEC 27002:2022 control 5.23 is written for the cloud customer: processes for acquiring, using, managing and exiting cloud services should be established in accordance with the organisation’s requirements, and its guidance describes what the agreement with the provider should address — the security controls the provider operates, the customer’s own responsibilities, incident handling, the provider’s use of sub-contractors, and what happens to data at the end of the service.
Control 5.20 requires relevant security requirements to be established and agreed with every supplier. ISO/IEC 27017:2026 adds the cloud reading of both, and its dedicated controls — shared roles and responsibilities, responsibilities with other cloud partners, segregation in virtual environments — are the ones a cloud service agreement has to give contractual form. Our guide to ISO 27017 covers the 2026 edition; the shared responsibility matrix is the document the agreement should annex.
| Clause | What it fixes | Controls it implements | Who owes what |
|---|---|---|---|
| 1. Scope, service description and responsibilities | The services in scope, the deployment and service models, and the allocation of every security responsibility between provider and customer — the matrix, attached and signed | 27017 shared roles and responsibilities; 27002 5.20, 5.23 | Provider: the allocation. Customer: acceptance of its share |
| 2. Access control and administration | How customer identities are managed, how provider administrators reach customer environments, privileged access logging, MFA, and the customer’s visibility of provider access | 27002 5.15–5.18, 8.2, 8.5; 27017 guidance on administrator operational security | Provider: administrator controls and logs. Customer: its own users and roles |
| 3. Data location, transfer and jurisdiction | Where data is stored and processed, which jurisdictions apply, notice of changes, and the customer’s right to restrict regions | 27002 5.31 legal requirements, 5.14 information transfer; 27018 location of PII where personal data is involved | Provider: disclosure and notice. Customer: the choice of region |
| 4. Segregation and isolation | The provider’s commitment to isolate the customer’s data and workloads from other tenants, at every layer, and how that is tested | 27017 segregation in virtual computing environments; 27002 8.22 segregation of networks | Provider: the control and its evidence |
| 5. Monitoring, logging and audit rights | What logs the customer receives, in what format and retention, what the provider monitors, and the customer’s right to audit or to receive audit reports and certificates | 27002 8.15 logging, 8.16 monitoring; 27017 monitoring of cloud services and its annex; 27002 5.22 supplier monitoring | Provider: telemetry and reports. Customer: review and use |
| 6. Incident management and breach notification | Definitions, timelines for notifying the customer, the information provided, cooperation in investigation, and — for personal data — the processor’s notification duty | 27002 5.24–5.28; 27018 breach notification | Provider: notification within the agreed time. Customer: onward reporting |
| 7. Sub-contractors and cloud partners | Which sub-processors and partners the provider uses, notice and objection rights on change, and flow-down of the security obligations | 27017 responsibilities with other cloud partners; 27002 5.21 ICT supply chain; 27018 sub-processor disclosure | Provider: the list and flow-down. Customer: the right to object |
| 8. Exit, return and deletion | Data return format and period, deletion from all copies including backups within a stated time, certificate of deletion, and transition assistance | 27002 5.11 return of assets with 27017 cloud guidance; 27018 return, transfer and disposal | Provider: return and evidenced deletion. Customer: retrieval within the window |
Clauses 7 and 8 are where cloud service agreements most often fail their customers, and for the same reason: they describe the relationship at its start. A sub-contractor list fixed at signature with no notice mechanism is out of date within a year; an exit clause that promises deletion “in accordance with the provider’s policies” promises nothing the customer can test.
ISO 27017’s cloud guidance on the return of assets is explicit that a customer’s data has to leave the provider’s systems — including the copies in backups, caches and support tools — and a clause that names the period and the evidence is the only form of that guidance a customer can enforce. Where personal data is involved, ISO 27018’s Annex A adds return, transfer and disposal, and sub-contractor disclosure, as controls in their own right; our guide to PII processor obligations covers them.
The test of a cloud service agreement is whether every row of the shared responsibility matrix has a clause behind it. Five gaps appear repeatedly.
What should a cloud service agreement cover for security?
Eight areas: scope and the allocation of responsibilities (the shared responsibility matrix), access and provider administration, data location and jurisdiction, segregation from other tenants, monitoring and logging with audit rights, incident and breach notification with timelines, sub-contractors and cloud partners with notice rights, and exit with return and evidenced deletion. ISO/IEC 27002:2022 controls 5.20 and 5.23 and ISO/IEC 27017:2026 supply the requirements.
Is the shared responsibility matrix part of the agreement?
It should be. ISO 27017’s shared roles and responsibilities control expects the allocation to be documented and agreed; annexing the matrix to the agreement gives it contractual force.
Does ISO 27017 require specific notification timelines?
It requires incident management arrangements to be agreed; the hours are for the parties to set. Customers with their own regulatory clocks — 24 or 72 hours under NIS2, DORA or GDPR — need a provider deadline short enough to meet them.
What about personal data?
ISO/IEC 27018:2025 adds processor-specific terms — processing on instruction, sub-processor disclosure, breach notification, return and disposal, location of PII — and a data processing agreement under GDPR Article 28 or equivalent law sits alongside the security schedule.
Who is responsible if the agreement is silent?
In practice, the customer, because the provider’s default terms allocate to the customer whatever they do not expressly take. That is why control 5.23 puts the duty to define requirements on the customer.
Treat the cloud service agreement as the shared responsibility matrix in contractual form: eight security clauses, each implementing named ISO 27017 and ISO 27002 controls, with parameters — notification hours, log delivery, deletion period, sub-processor notice — that both sides can test. The provider standardises the schedule and flows it down; the customer maps it before signing and reviews it every year.
The Cloud Service Agreement Security Schedule, the Shared Responsibility Matrix Template, the Cloud Partner and Intermediary Responsibilities Procedure and the Sub-processor Register are in the ISO 27017 & ISO 27018 Cloud Toolkit, or start with the free templates.
September 20, 2026
September 19, 2026
September 19, 2026
September 19, 2026
September 19, 2026