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
Cách dùng: 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.
Xem trước
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] |
Contents
- 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-baselinefor IaaS and PaaS,isms/saas-productivity-security-baselinefor 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.
Template liên quan
Physical Security Policy Template (ISO/IEC 27001 A.7)
Site register, zone model, entry control and visitors, A.7.4 monitoring, environmental and climate threats, utilities, cabling, maintenance, third-party sites
ISMS và ISO/IEC 27001Access Control Policy Template (ISO/IEC 27001 A.5.15)
Access principles, role catalogue, joiner mover leaver SLAs, MFA and NIST SP 800-63B-4 password rules, privileged and service accounts, reviews, metrics
ISMS và ISO/IEC 27001Backup Policy Template (ISO/IEC 27001 A.8.13)
ISMS backup policy: tiers from BIA with RPO and RTO, 3-2-1-1-0 copies, immutability, encryption, retention, ransomware, SaaS backups, restore testing