Cloud Services Security Policy Template (ISO/IEC 27001 A.5.23)

Cloud policy for A.5.23: shared responsibility, tiers, due diligence, contract terms, configuration, monitoring, exit, shadow IT, cloud register

ISMS und ISO/IEC 27001VollständigISO/IEC 27001:2022 A.5.23 (cited only); ISO/IEC 27002:2022; ISO/IEC 27017:2026; ISO/IEC 27036-4:2016cloud services security policyAktualisiert 01.11.2026

Im Editor öffnen.md herunterladen

Anleitung: Use it when the organization buys or runs any IaaS, PaaS or SaaS service and needs one policy for acquiring, using, managing and exiting cloud services. Fill the approval tiers and the cloud service register first. The main pitfall is covering only the main IaaS platform and forgetting SaaS, free tools and AI services.

Vorschau

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.

Document control

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]

1. Purpose and scope
2. Policy statements
3. Shared responsibility
4. Cloud service categories and approval tiers
5. Acquisition and due diligence
6. Contract requirements
7. Secure configuration and use
8. Monitoring and ongoing assurance
9. Change management for cloud services
10. Exit and termination
11. Shadow IT and unapproved services
12. Cloud service register
13. Roles and responsibilities
14. Size tiers
15. Records and evidence
16. Compliance, exceptions and review
17. References
Standard and licence note

1. Purpose and scope

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

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

3. Shared responsibility

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.

4. Cloud service categories and approval tiers

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

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.

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

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

7.1 Configuration rules

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.
Connect the service to the corporate identity provider using single sign-on. Local accounts are limited to documented break-glass accounts.
Enforce MFA for all users; phishing-resistant MFA for administrators of Tier 1 services.
Grant administrative roles by named individual, with least privilege, and review them in the quarterly access review (ops/access-review).
Manage infrastructure as code for IaaS and PaaS where practical, with peer review of changes.
Block public exposure of storage and databases by default; any public resource needs a recorded business reason.
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).
Store secrets in a secrets manager, never in code or configuration files (security/secrets-management-standard).
Apply encryption according to security/cryptography-standard, and record the key ownership model in the register.
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

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

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

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.
Each Tier 2 service has a recorded data export method and a named person who has tried it.
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.
Update the register status to Retired, with the exit date and the location of the deletion confirmation.
Keep exported data under the retention rules in data/data-retention-deletion-standard.

11. Shadow IT and unapproved services

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

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

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

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

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

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

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.