# Cloud Services Security Policy: [Organization name]

> Sets the rules for acquiring, using, managing and exiting cloud
> services (IaaS, PaaS and SaaS) so that information processed in them
> stays protected under the shared responsibility model. It supports
> ISO/IEC 27001:2022 + Amd 1:2024 Annex A control A.5.23 (security for
> cloud service use, new in the 2022 edition), with guidance from
> ISO/IEC 27002:2022, ISO/IEC 27017:2026 and ISO/IEC 27036-4:2016.
> Replace every `[bracketed]` value and every row marked *Example*.
> This is a documentation format, not legal advice.

<!--
Guidance: How to use this template
- Use it when the organization buys or runs any cloud service, which in
  practice means every organization. A.5.23 is about not letting cloud
  services drift in unmanaged: each one needs an owner, known rules and
  an exit route, and those rules come from what your own security
  needs are, not from the provider's defaults.
- Fill section 4 (cloud service categories and approval tiers) and
  section 12 (cloud service register) first. Everything else hangs on
  knowing which services you use and how critical each one is.
- Main pitfall: writing a policy that only covers the main IaaS platform
  and ignores SaaS. Most sensitive data now sits in SaaS (mail, file
  sharing, CRM, HR, ticketing), and most cloud incidents start with a
  SaaS misconfiguration or a forgotten account.
- Related templates: `isms/cloud-exit-plan` (exit), `isms/cloud-27017-controls`
  (cloud provider or customer control set), `isms/cloud-pii-27018-processor`
  (PII in public cloud), `isms/supplier-register`,
  `compliance/supplier-security-assessment`,
  `isms/supplier-security-agreement-27036`,
  `isms/saas-productivity-security-baseline`,
  `security/cloud-security-posture-review`,
  `isms/secure-configuration-baseline`, `isms/access-control-policy`.
-->

## Document control

<!-- Guidance: The policy owner is usually the ISMS manager or the head of cloud platform, with procurement and legal as reviewers. Auditors check approval, version and that the policy is communicated to the people who buy cloud services, not only to IT. -->

| Field | Value |
|---|---|
| Document ID | DOC-ISMS-044 |
| Version | [1.0] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@isms-manager] |
| Approvers/reviewers | [@cto], [@head-of-procurement], [@legal-counsel], [@dpo] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal] |
| Standard and edition | ISO/IEC 27001:2022 + Amd 1:2024 (A.5.23); ISO/IEC 27002:2022; ISO/IEC 27017:2026; ISO/IEC 27036-4:2016 |
| Next scheduled review | YYYY-MM-DD (at least every 12 months and after any major cloud incident or provider change) |
| Applies to | [All employees, contractors and business units that buy, configure or use cloud services] |
| Parent policy | Information security policy DOC-ISMS-001 |
| Related records | Cloud service register (section 12), supplier register DOC-ISMS-066, cloud exit plan DOC-ISMS-076 |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Policy owner | [@isms-manager] | [Prepared] | YYYY-MM-DD |
| Top management sponsor | [@cto] | [Approved / Approved with changes] | YYYY-MM-DD |
| Procurement | [@head-of-procurement] | [Reviewed] | YYYY-MM-DD |
| Legal and privacy | [@legal-counsel], [@dpo] | [Reviewed] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@author] | First draft |
| 1.0 | YYYY-MM-DD | [@author] | Approved for issue |
| [x.y] | YYYY-MM-DD | [@author] | [Change summary] |

## Contents

- [1. Purpose and scope](#1-purpose-and-scope)
- [2. Policy statements](#2-policy-statements)
- [3. Shared responsibility](#3-shared-responsibility)
- [4. Cloud service categories and approval tiers](#4-cloud-service-categories-and-approval-tiers)
- [5. Acquisition and due diligence](#5-acquisition-and-due-diligence)
- [6. Contract requirements](#6-contract-requirements)
- [7. Secure configuration and use](#7-secure-configuration-and-use)
- [8. Monitoring and ongoing assurance](#8-monitoring-and-ongoing-assurance)
- [9. Change management for cloud services](#9-change-management-for-cloud-services)
- [10. Exit and termination](#10-exit-and-termination)
- [11. Shadow IT and unapproved services](#11-shadow-it-and-unapproved-services)
- [12. Cloud service register](#12-cloud-service-register)
- [13. Roles and responsibilities](#13-roles-and-responsibilities)
- [14. Size tiers](#14-size-tiers)
- [15. Records and evidence](#15-records-and-evidence)
- [16. Compliance, exceptions and review](#16-compliance-exceptions-and-review)
- [17. References](#17-references)
- [Standard and licence note](#standard-and-licence-note)

## 1. Purpose and scope

<!-- Guidance: Say which services count as "cloud" for this policy. Include SaaS bought on a credit card, free tiers used with company data, and AI services. A narrow scope is the most common reason shadow IT escapes the ISMS. -->

This policy defines how [Organization name] selects, contracts, configures,
operates, monitors and leaves cloud services so that the confidentiality,
integrity and availability of information processed in them meet the
organization's risk criteria (DOC-ISMS-010) and legal, regulatory and
contractual obligations (DOC-ISMS-014).

For this policy, a cloud service is any on-demand, network-accessed
computing capability provided by a third party: infrastructure (IaaS),
platform (PaaS), software (SaaS), and specialised services such as managed
databases, identity providers, content delivery networks, backup as a
service and hosted AI models. The NIST definition (SP 800-145) is a useful
reference for the service and deployment models.

| Item | In scope | Out of scope |
|---|---|---|
| Service types | IaaS, PaaS, SaaS, managed security services, AI and machine learning APIs, free or trial services used with company data | Purely personal accounts with no company data |
| Data | All information classified Internal or above (see `data/data-classification-policy`) | Public information already published |
| Users | Employees, contractors, interns, suppliers acting on our behalf | Customers using our own product (covered by product security documents) |
| Role | The organization as a cloud service customer | The organization as a cloud service provider (use `isms/cloud-27017-controls`) |

If the organization also provides cloud services to customers, apply this
policy to the services it consumes and document the provider side in the
ISO/IEC 27017 control set.

## 2. Policy statements

<!-- Guidance: Keep the statements short and testable. Each one should map to a record an auditor can sample. Avoid "where possible" unless you define who decides. -->

1. Only cloud services recorded as Approved in the cloud service register
   (section 12) may process information classified Internal or above.
2. Every cloud service has a named business owner and a named technical
   owner, recorded in the register.
3. Before acquisition, each service is categorised (section 4) and
   assessed in proportion to its tier (section 5).
4. Contracts for Tier 1 and Tier 2 services include the security terms
   in section 6, or the gap is recorded as an accepted risk.
5. The shared responsibility split is documented for each Tier 1 and
   Tier 2 service (section 3), and customer-side duties are assigned.
6. Cloud services are configured against an approved baseline, with
   single sign-on and multi-factor authentication wherever the service
   supports them (section 7).
7. Cloud administrative access is privileged access and follows
   `security/privileged-access-standard`.
8. Logs from Tier 1 services are collected and reviewed under the
   security monitoring procedure (DOC-ISMS-064).
9. Each Tier 1 service has a documented, tested exit approach
   (DOC-ISMS-076); each Tier 2 service has at least a data export method.
10. Shadow IT is detected and handled under section 11; it is not
    tolerated silently.
11. Cloud risks are assessed under DOC-ISMS-010 and recorded in the risk
    register DOC-ISMS-016.

## 3. Shared responsibility

<!-- Guidance: Auditors often ask "who patches the guest operating system?" or "who configures retention in your SaaS?". Write the answer per service model. The provider's own responsibility matrix is the starting point, not the answer: your contract and configuration decide the final split. -->

Security responsibilities are split between the cloud service provider
(CSP) and [Organization name] as cloud service customer. The split moves
with the service model. The table below is the organization's default
view; record any service-specific difference in the register.

| Layer | IaaS | PaaS | SaaS |
|---|---|---|---|
| Physical data centre, hardware, hypervisor | Provider | Provider | Provider |
| Network infrastructure of the provider | Provider | Provider | Provider |
| Guest operating system, patching | Customer | Provider | Provider |
| Runtime, middleware, managed database engine | Customer | Provider | Provider |
| Application code and its configuration | Customer | Customer | Provider (configuration settings: Customer) |
| Identity, accounts, roles, MFA | Customer | Customer | Customer |
| Data classification, retention, deletion settings | Customer | Customer | Customer |
| Encryption key choice and management | Customer (provider tools) | Shared | Shared or Provider |
| Network controls inside the tenant (security groups, private endpoints) | Customer | Shared | Provider (IP allow lists: Customer) |
| Logging enablement and log review | Customer | Customer | Customer (provider supplies logs) |
| Backup of customer data | Customer | Shared | Customer unless contract says otherwise |
| Incident detection in customer configuration | Customer | Customer | Customer |
| Incident notification to customer | Provider | Provider | Provider |

The customer is always responsible for identity, data and configuration.
No contract transfers accountability for the information itself.

```mermaid
flowchart TD
  A["Information and data: Customer"] --> B["Identities and access: Customer"]
  B --> C["Configuration of the service: Customer"]
  C --> D{"Service model"}
  D -->|IaaS| E["OS, runtime, apps: Customer"]
  D -->|PaaS| F["Apps and code: Customer, runtime: Provider"]
  D -->|SaaS| G["Application: Provider, settings: Customer"]
  E --> H["Physical, hardware, hypervisor: Provider"]
  F --> H
  G --> H
```

## 4. Cloud service categories and approval tiers

<!-- Guidance: Tiering keeps the effort proportionate. A full assessment of a diagram tool used by three people wastes time; a light check of the main production platform is negligent. Base the tier on data classification and business dependence, not on price. -->

Each cloud service is placed in one tier using the highest criterion that
applies.

| Tier | Criteria (any one is enough) | Assessment depth | Approver |
|---|---|---|---|
| Tier 1, critical | Hosts production systems or customer data; processes Confidential or Restricted data at scale; outage stops a critical business process (BIA, DOC-ISMS-120); identity provider or security tooling | Full due diligence (section 5), contract review, shared responsibility matrix, exit plan, annual reassessment | ISMS manager and top management sponsor |
| Tier 2, important | Processes Internal or Confidential data for a department; personal data in limited volume; outage hurts but has a workaround | Standard questionnaire, assurance report review, contract security terms, data export method, two-yearly reassessment | ISMS manager or delegate |
| Tier 3, low | Public or Internal data only, no personal data beyond user accounts, easy to replace | Short checklist (SSO, MFA, data location, terms of use), register entry | Line manager and IT |
| Prohibited | Fails a mandatory requirement (for example no MFA for a Tier 1 use, data location not allowed by contract or law, provider refuses breach notification) | Not approved; alternative proposed | Not applicable |

Service categories used in the register: IaaS, PaaS, SaaS business
application, SaaS collaboration, identity and access, security service,
developer tooling, AI service, backup and storage.

## 5. Acquisition and due diligence

<!-- Guidance: Show the auditor a repeatable path from request to approval. The key evidence is the completed assessment for each Tier 1 and Tier 2 service and the decision record. Reuse `compliance/supplier-security-assessment` for the questionnaire rather than inventing a second one. -->

### 5.1 Request to approval flow

Every new cloud service, including free tiers and trials used with
company data, follows this path before any Internal or higher data is
placed in it.

```mermaid
flowchart LR
  R["Request raised by business owner"] --> T["Classify data and assign tier"]
  T --> P{"Prohibited criterion met?"}
  P -->|Yes| X["Reject and propose alternative"]
  P -->|No| D["Due diligence per tier"]
  D --> K["Contract and DPA review"]
  K --> RK["Risk assessment and treatment"]
  RK --> AP{"Approver decision"}
  AP -->|Approved| REG["Register entry and onboarding"]
  AP -->|Rejected| X
  REG --> CFG["Configure to baseline"]
```

### 5.2 Due diligence checklist

| Area | Tier 1 | Tier 2 | Tier 3 | Evidence to collect |
|---|---|---|---|---|
| Independent assurance (ISO/IEC 27001 certificate with scope covering the service, SOC 2 Type 2 report, CSA STAR entry) | Required | Required or questionnaire | Optional | Certificate, scope statement, report period, bridge letter |
| Certificate validity checked (certification body accredited by a signatory of the Global ACI MRA, formerly the IAF MLA; scope matches the service; not expired) | Required | Required | Not applicable | Screenshot of the IAF CertSearch result (check that the database is still the current one) or of the accreditation body's register |
| Security questionnaire (`compliance/supplier-security-assessment`, or a CAIQ v4.1 response) | Required | Short form | Not applicable | Completed questionnaire |
| Data location and transfers (regions, sub-processors, transfer mechanism) | Required | Required | Basic check | Region list, sub-processor list, transfer assessment (`compliance/transfer-impact-assessment`) |
| Identity: SSO with the corporate identity provider, MFA, role-based admin | Required | Required | MFA required | Configuration screenshot or test |
| Encryption in transit and at rest, key management options | Required | Required | Basic check | Provider documentation |
| Logging available to the customer (admin activity, data access, retention) | Required | Required | Not applicable | Log types and retention |
| Incident notification commitment and time | Required | Required | Basic check | Contract clause |
| Resilience (availability commitment, regions, backup, provider DR testing) | Required | Basic check | Not applicable | SLA, architecture notes |
| Data export and deletion on exit | Required | Required | Basic check | Export format, deletion confirmation process |
| Financial and concentration risk (provider viability, dependence on one provider) | Required | Optional | Not applicable | Note in risk assessment |
| Sub-processor and supply chain transparency | Required | Required | Not applicable | Sub-processor list, change notice terms |

### 5.3 Worked example

| Field | Value |
|---|---|
| Request ID | CLD-REQ-014 *(Example)* |
| Service | Managed analytics data warehouse (PaaS) for Quillmere Analytics Ltd |
| Data | Customer analytics data including personal data (processor role); classification Confidential |
| Tier | Tier 1 (customer data at scale, production dependency) |
| Assurance | ISO/IEC 27001 certificate covering the service, SOC 2 Type 2 report for a 12-month period ending 3 months ago |
| Data location | Same two regions as the main platform (primary and DR) |
| Gaps found | Customer-managed keys only on a higher plan; admin activity logs kept 90 days by default |
| Risk | RISK-031 *(Example)*: likelihood 2, impact 4, score 8 (Medium) after treatment |
| Treatment | Buy the plan with customer-managed keys; export admin logs to the central log store (365-day retention) |
| Decision | Approved by ISMS manager and CTO on YYYY-MM-DD |

## 6. Contract requirements

<!-- Guidance: You rarely negotiate with large providers, so the work is to read the standard terms, find gaps and decide whether to accept them. Record the gap and the decision. For processors of personal data, a data processing agreement is required under laws such as the GDPR. Ask legal counsel which laws apply. -->

Contracts or accepted standard terms for Tier 1 and Tier 2 services must
address the points below. Where the provider's standard terms do not
cover a point and cannot be changed, record the gap, assess the risk and
obtain acceptance under section 2.4 of DOC-ISMS-010.

| Ref | Requirement | Tier 1 | Tier 2 |
|---|---|---|---|
| CON-01 | Provider security obligations, including maintenance of a recognised security certification or audit report for the service | Required | Required |
| CON-02 | Right to receive assurance reports, certificates and summaries of penetration tests | Required | Required |
| CON-03 | Incident and personal data breach notification without undue delay, with a stated maximum time | Required | Required |
| CON-04 | Data processing agreement with processor duties where personal data is processed | Required | Required |
| CON-05 | Data location commitments and notice of changes to regions or sub-processors | Required | Required |
| CON-06 | Ownership of customer data stays with the customer; provider use of data limited to service delivery (including any AI model training restrictions) | Required | Required |
| CON-07 | Availability commitment, service credits and maintenance notice | Required | Recommended |
| CON-08 | Data export in a usable format during the term and for a defined period after termination | Required | Required |
| CON-09 | Secure deletion of customer data after exit, with confirmation | Required | Required |
| CON-10 | Notice of material changes to the service that affect security | Required | Recommended |
| CON-11 | Cooperation with customer audits, regulators and investigations, including access to logs | Required | Recommended |
| CON-12 | Liability and insurance appropriate to the data at risk | Required | Recommended |

For regulated sectors, map these terms to the sector rules (for example
DORA contractual requirements for ICT third-party services in EU
financial entities) and keep the mapping in `isms/supplier-security-agreement-27036`.

## 7. Secure configuration and use

<!-- Guidance: Most cloud breaches come from customer-side misconfiguration: public storage, unused admin accounts, missing MFA, over-broad API keys. The policy sets the rules; the technical detail lives in the baselines. Auditors sample a few services and compare settings with the baseline. -->

### 7.1 Configuration rules

1. Configure every Tier 1 and Tier 2 service against a documented
   baseline before production use: `isms/secure-configuration-baseline`
   for IaaS and PaaS, `isms/saas-productivity-security-baseline` for the
   collaboration suite, or the vendor hardening guide recorded in the
   register.
2. Connect the service to the corporate identity provider using single
   sign-on. Local accounts are limited to documented break-glass accounts.
3. Enforce MFA for all users; phishing-resistant MFA for administrators
   of Tier 1 services.
4. Grant administrative roles by named individual, with least privilege,
   and review them in the quarterly access review (`ops/access-review`).
5. Manage infrastructure as code for IaaS and PaaS where practical, with
   peer review of changes.
6. Block public exposure of storage and databases by default; any public
   resource needs a recorded business reason.
7. Use separate accounts, subscriptions or projects for production and
   non-production, with no production personal data in non-production
   unless masked (see `isms/data-masking-dlp-standard`).
8. Store secrets in a secrets manager, never in code or configuration
   files (`security/secrets-management-standard`).
9. Apply encryption according to `security/cryptography-standard`, and
   record the key ownership model in the register.
10. Enable the provider's security posture tooling or an equivalent
    cloud security posture management (CSPM) capability for Tier 1 IaaS
    and PaaS.

### 7.2 Use of AI cloud services

Cloud-hosted AI services follow the same tiering. In addition, users must
not submit Confidential or Restricted data to an AI service unless the
register shows that the contract excludes model training on customer
data and the data location is acceptable. See `ai-data/ai-usage-policy`.

## 8. Monitoring and ongoing assurance

<!-- Guidance: A.5.23 covers management of the service through its life, not only buying it. Show a cycle: logs every day, posture weekly, provider assurance yearly. Auditors look for the last reassessment date in the register and evidence that findings were followed up. -->

| Activity | Frequency *(Example)* | Tier | Owner | Output |
|---|---|---|---|---|
| Collect admin and security logs into the central log platform | Continuous | Tier 1 | Platform team | Log source inventory entry |
| Review posture findings (CSPM or provider security centre) | Weekly | Tier 1 IaaS and PaaS | Platform team | Ticket per finding, trend in monthly report |
| Review provider status and security bulletins | Weekly | Tier 1 and 2 | Technical owner | Notes in change or incident record |
| Review new or expiring certificates and assurance reports | Annually, or at report expiry | Tier 1 and 2 | ISMS manager | Updated register fields |
| Reassess due diligence | Tier 1 annually, Tier 2 every 24 months | Tier 1 and 2 | ISMS manager with business owner | Updated assessment and risk entries |
| Posture review (`security/cloud-security-posture-review`) | Twice a year | Tier 1 IaaS and PaaS | Security team | Review report and actions |
| Review admin role assignments | Quarterly | Tier 1 and 2 | Technical owner | Access review record |
| Check usage and cost anomalies that may indicate compromise | Monthly | Tier 1 IaaS | Platform team | Anomaly log |

Monitoring findings that indicate an incident go to the security event
reporting procedure (DOC-ISMS-023) and the incident response plan
(DOC-ISMS-020).

## 9. Change management for cloud services

<!-- Guidance: Cloud services change under you: providers ship new features, move regions, add sub-processors. Decide which provider changes trigger a review on your side. Customer-side changes follow the normal change process. -->

Customer-side changes to Tier 1 services follow the change process
(`ops/change-enablement-policy`). Provider-side changes are handled as
follows.

| Provider change | Action | Owner |
|---|---|---|
| New sub-processor or region | Check against data location rules; object within the contractual window if needed | DPO and technical owner |
| New feature enabled by default that touches data sharing, AI or external access | Assess and disable or configure before it reaches users | Technical owner |
| Change to terms, data processing agreement or security commitments | Legal review; update the register and risk entry | Legal counsel |
| Deprecation of a security feature or service | Plan replacement; risk entry if the gap exceeds 30 days *(Example)* | Technical owner |
| Provider security incident affecting the service | Handle under DOC-ISMS-020; reassess tier and risk | ISMS manager |
| Provider acquisition or change of control | Reassess due diligence and concentration risk | ISMS manager and procurement |

## 10. Exit and termination

<!-- Guidance: An exit plan written on the day you need it is too late. For Tier 1 services, keep the plan in `isms/cloud-exit-plan` and test the data export at least once a year. Auditors ask "how would you leave this provider?" and expect a document, not a shrug. -->

1. Each Tier 1 service has an exit plan in DOC-ISMS-076 covering exit
   triggers, data export, alternative provider or in-house option,
   timeline, roles and verification of deletion.
2. Each Tier 2 service has a recorded data export method and a named
   person who has tried it.
3. On termination: export data, verify completeness and integrity, revoke
   all integrations, API keys and federated trust, remove user accounts,
   request deletion and keep the provider's deletion confirmation.
4. Update the register status to Retired, with the exit date and the
   location of the deletion confirmation.
5. Keep exported data under the retention rules in
   `data/data-retention-deletion-standard`.

```mermaid
stateDiagram-v2
  [*] --> Requested
  Requested --> Assessed: due diligence complete
  Assessed --> Approved: approver signs
  Assessed --> Rejected: fails criteria
  Approved --> Operating: configured to baseline
  Operating --> Reassessed: annual or trigger
  Reassessed --> Operating: still acceptable
  Reassessed --> Exiting: unacceptable or replaced
  Operating --> Exiting: business decision
  Exiting --> Retired: data exported and deletion confirmed
  Rejected --> [*]
  Retired --> [*]
```

## 11. Shadow IT and unapproved services

<!-- Guidance: You will find unapproved services. The question is whether you find them in a planned way and bring them under control, or in an incident. Offer a fast approval path for Tier 3 services so people do not route around the policy. -->

Shadow IT is any cloud service used with company data that is not in the
register. The organization detects and handles it as follows.

| Detection source | How | Frequency *(Example)* |
|---|---|---|
| Identity provider sign-in logs and OAuth app grants | Review third-party apps users have authorised against corporate accounts | Monthly |
| Expense and card statements | Finance flags software and cloud subscriptions | Monthly |
| Network or secure web gateway logs | Report on cloud application categories in use | Monthly |
| Endpoint software inventory | Desktop clients for cloud services | Quarterly |
| Staff declaration | Annual awareness reminder and amnesty | Annually |

Handling: the ISMS manager contacts the user, assigns a tier, and either
starts the approval path (section 5), replaces the service with an
approved one, or blocks it and arranges data recovery and account
deletion. Repeated or deliberate use of a prohibited service is handled
under the disciplinary process (DOC-ISMS-052). Free AI tools and browser
extensions with access to company data are treated as cloud services.

## 12. Cloud service register

<!-- Guidance: This register is the core record for A.5.23. Keep it in one place, either here or in the supplier register (DOC-ISMS-066) with cloud-specific columns. Every Tier 1 and Tier 2 service needs a current assessment date and an exit approach. -->

| ID | Service and category | Business owner | Technical owner | Tier | Data classification | Personal data | Regions | Assurance and expiry | SSO and MFA | Exit approach | Last assessed | Status |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| CLD-001 *(Example)* | Public cloud IaaS and PaaS (production platform) | CTO | Head of Engineering Operations | 1 | Confidential | Yes, processor | Primary and DR region | ISO/IEC 27001 cert, SOC 2 Type 2, expires 2027-06-30 | SSO, phishing-resistant MFA for admins | Exit plan DOC-ISMS-076 (platform copy) | 2026-09-15 | Approved |
| CLD-002 *(Example)* | Collaboration suite (mail, files, chat), SaaS collaboration | COO | IT lead | 1 | Confidential | Yes, controller and processor | Provider region set by tenant | ISO/IEC 27001 cert, expires 2027-03-31 | SSO, MFA | Exit plan DOC-ISMS-076 (collaboration suite copy) | 2026-08-02 | Approved |
| CLD-003 *(Example)* | CRM, SaaS business application | Head of Sales | IT lead | 2 | Confidential | Yes, controller | Single region | SOC 2 Type 2, period ends 2026-12-31 | SSO, MFA | CSV and API export, tested 2026-05-10 | 2026-05-10 | Approved |
| CLD-004 *(Example)* | Diagramming tool, SaaS collaboration | Head of Product | IT lead | 3 | Internal | No | Not applicable | Checklist only | SSO | Export to files | 2026-02-01 | Approved |
| CLD-005 *(Example)* | Free online file converter | Not applicable | Not applicable | Prohibited | Not applicable | Not applicable | Unknown | None | None | Not applicable | 2026-07-20 | Blocked |

Status values: Requested, Approved, Approved with conditions, Rejected,
Blocked, Exiting, Retired.

## 13. Roles and responsibilities

<!-- Guidance: Name roles, not departments. The business owner is accountable for the decision to use the service; the technical owner for its configuration. Without a business owner, nobody pays for the secure plan. -->

| Role | Responsibility |
|---|---|
| Top management sponsor | Approves Tier 1 services and accepts High residual cloud risks |
| ISMS manager | Owns this policy and the register, runs due diligence, reports cloud risk to management review |
| Business owner | Requests the service, justifies it, owns the data decisions and the budget for required controls |
| Technical owner | Configures to baseline, manages admin access, monitors posture and provider changes, maintains the exit approach |
| Procurement | Ensures no cloud purchase is completed without a register entry and approval |
| Legal counsel and DPO | Review contract terms, data processing agreements, transfers and sub-processor changes |
| Security team | Posture reviews, log monitoring, shadow IT detection, incident handling |
| All users | Use only approved services, report suspected unapproved use and incidents |

## 14. Size tiers

<!-- Guidance: The control is the same at every size; the depth and tooling change. Small organizations can run the register in a spreadsheet and rely on provider-native tools. Large groups need procurement integration and central posture management across many tenants. -->

| Aspect | Small: Quillmere Analytics Ltd (46 staff) | Medium: Quillmere Health Systems (320 staff) | Large: Quillmere Group (2,400 staff, 6 sites) |
|---|---|---|---|
| Typical estate *(Example)* | One public cloud provider in two regions (primary and DR), one collaboration suite, about 25 SaaS tools | Colocation suite plus one public cloud, about 80 SaaS tools, clinical customer integrations | Several cloud providers across 4 countries, regional tenants, OT vendor cloud portals, over 300 SaaS tools |
| Register | Spreadsheet owned by the 0.5 FTE ISMS manager (Head of Engineering Operations) | Register in the GRC or ticketing tool, linked to the supplier register | Central register fed by procurement workflow and identity provider app catalogue, regional owners |
| Approval | Tier 1 by ISMS manager and CTO; Tier 3 self-service checklist | Tier 1 by ISMS manager and steering committee; Tier 2 by security team | Tier 1 by group CISO and regional business head; architecture board for new platforms |
| Due diligence | Assurance report review and short questionnaire, reuse of provider trust pages | Full questionnaire for Tier 1, healthcare contract terms, data location review for hospital contracts | Third-party risk team, tiered questionnaires, concentration risk across group, sector rules per country |
| Posture monitoring | Provider-native security centre, weekly review | CSPM tool across cloud and colocation-hosted workloads, SIEM integration | Central CSPM across all tenants, security operations centre, policy as code guardrails |
| Shadow IT detection | Monthly review of identity provider app grants and card statements | Secure web gateway reports and expense review | Cloud access security broker, procurement controls, regional reviews |
| Exit testing | Annual export test for the platform and the collaboration suite | Annual export test for all Tier 1 services, exit plan per hospital-facing service | Exit plans per Tier 1 provider per region, tested on a rotating schedule |

## 15. Records and evidence

<!-- Guidance: List the records that prove this policy operates. Link each to the control evidence matrix (DOC-ISMS-033) so the Stage 2 auditor can sample them. Keep at least the current and previous cycle. -->

| Record | Proves | Owner | Location | Retention *(Example)* |
|---|---|---|---|---|
| Cloud service register | Services are known, tiered, owned and assessed | ISMS manager | [GRC tool / register file] | Current plus 3 years of history |
| Due diligence assessments and decisions | Acquisition followed the policy | ISMS manager | [Supplier folder per service] | Life of service plus 3 years |
| Contract and DPA gap reviews | Contract requirements were checked | Legal counsel | [Contract repository] | Life of contract plus 6 years |
| Shared responsibility matrices | Customer duties are assigned | Technical owner | [Architecture repository] | Life of service |
| Baseline configuration evidence and posture reports | Services are configured and monitored | Technical owner, security team | [CSPM tool exports, tickets] | 2 years |
| Admin access reviews | Privileged cloud access is controlled | Technical owner | [Access review records] | 3 years |
| Shadow IT review records | Unapproved use is detected and handled | ISMS manager | [Review log] | 3 years |
| Exit tests and deletion confirmations | Exit is possible and data is removed | Technical owner | [Exit plan annex] | 6 years after exit |

Map each record to control A.5.23 in `isms/control-evidence-matrix` and
reference the policy in the Statement of Applicability (DOC-ISMS-011).

## 16. Compliance, exceptions and review

<!-- Guidance: Say how compliance is checked and how exceptions are granted. Exceptions need an owner, an expiry date and a compensating control, or they turn into permanent holes. -->

- Compliance is checked through the internal audit programme
  (DOC-ISMS-082), the posture reviews in section 8 and the shadow IT
  reviews in section 11.
- Exceptions are requested with `security/security-exception-request`
  (DOC-ISMS-122), assessed under DOC-ISMS-010 and approved at the
  authority the risk methodology (DOC-ISMS-010 section 2.4) sets for the
  residual risk: the risk owner for Low; the risk owner and department
  head for Medium (top management if the risk category is Averse,
  DOC-ISMS-015 section 9 rule 1); top management with a treatment
  decision for High, recorded in the risk acceptance record
  (DOC-ISMS-019). Critical residual risk is not approvable as an
  exception: treat it or stop the activity. Maximum duration is 12
  months for Low or Medium and 6 months for High; at expiry the
  exception is reassessed, and a renewal is a new decision (DOC-ISMS-122
  section 7).
- Breaches of this policy are handled under DOC-ISMS-052.
- This policy is reviewed at least every 12 months, and after a major
  cloud incident, a new Tier 1 provider, a change in law affecting data
  location, or a relevant audit finding.

## 17. References

<!-- Guidance: Cite only editions you checked. ISO/IEC 27017 was republished in 2026: check its control set before mapping to it. -->

| Reference | Edition | Use |
|---|---|---|
| ISO/IEC 27001:2022 + Amd 1:2024, https://www.iso.org/standard/82875.html and https://www.iso.org/standard/88435.html | Current | A.5.23 and related supplier controls A.5.19 to A.5.22 |
| ISO/IEC 27002:2022, https://www.iso.org/standard/75652.html | Current | Control guidance for cloud service use |
| ISO/IEC 27017:2026, https://www.iso.org/standard/82878.html | New edition July 2026; check the control set | Cloud-specific controls for customers and providers |
| ISO/IEC 27018:2025, https://www.iso.org/standard/88150.html | Current | PII protection in public clouds acting as processors |
| ISO/IEC 27036-4:2016, https://www.iso.org/standard/59689.html | Current | Supplier relationships, security of cloud services |
| NIST SP 800-145, The NIST Definition of Cloud Computing | September 2011, https://csrc.nist.gov/pubs/sp/800/145/final | Service and deployment model definitions |
| CSA Cloud Controls Matrix v4.1 and CAIQ v4.1 | Released January 2026 (names only) | Optional questionnaire format for providers |
| Related templates | | `isms/cloud-exit-plan`, `isms/cloud-27017-controls`, `isms/cloud-pii-27018-processor`, `isms/supplier-register`, `compliance/supplier-security-assessment`, `isms/supplier-security-agreement-27036`, `isms/saas-productivity-security-baseline`, `security/cloud-security-posture-review`, `isms/control-evidence-matrix`, `compliance/statement-of-applicability` |

## Standard and licence note

Structure aligned with ISO/IEC 27001:2022 + Amd 1:2024 (Annex A control
A.5.23), ISO/IEC 27002:2022, ISO/IEC 27017:2026 and ISO/IEC 27036-4:2016.
Control numbers are cited with original short labels; the policy
statements, tables, tiers and examples are original text, and no text
from ISO/IEC standards is reproduced. Obtain the official standards from
ISO, IEC or your national standards body to implement the requirements.
NIST SP 800-145 is a US government publication; the CSA Cloud Controls
Matrix and CAIQ are cited by name only. Check the current edition of each
standard before use: ISO/IEC 27017 was republished in 2026.

Template licence: MIT.