Cloud Security Policy Template

Cloud adoption usually runs ahead of cloud policy, so accounts, subscriptions and SaaS services appear faster than anyone decides who may create them, how they are configured and who is accountable when one is exposed. This template sets out policy statements for the secure use of cloud services at [Organisation]: approval of providers, account and tenancy structure, shared responsibility, identity and access, data protection and keys, configuration guardrails, logging and monitoring, incident response, resilience and exit. It covers IaaS, PaaS and SaaS and is aligned with the NCSC Cloud Security Principles, CSA Cloud Controls Matrix v4.1, NIST CSF 2.0 and ISO/IEC 27001:2022 Annex A 5.23. It is for cloud platform, security and GRC teams adopting or refreshing a cloud policy; adapt it and have it reviewed by legal, risk and procurement before approval.

How to use this template

• Replace text in square brackets, such as [Organisation], [Cloud Platform Team] and [X days], with your own terms and values.
• "Must" indicates a mandatory requirement; "should" indicates a recommended practice where documented exceptions may be justified.
• Keep provider-specific settings (service control policies, Azure Policy definitions, organisation policies) in a supporting cloud security standard, so the policy stays provider-neutral.
• Express guardrails as code wherever possible and reference the repository in section 8.
• Review the policy at least annually and when a new provider or major service model is adopted.

1. Purpose

This policy sets the requirements for selecting, configuring, operating and exiting cloud services at [Organisation]. It ensures that cloud services are approved, owned, configured to agreed baselines, accessed through controlled identities, monitored and recoverable, and that the security responsibilities shared with each provider are understood and met.

2. Scope

This policy applies to:

• All infrastructure, platform and software as a service used to store, process or transmit [Organisation] information, whether paid for centrally, by a business unit or on a personal card.
• All cloud accounts, subscriptions, projects, tenants and organisations created by or for [Organisation], including development, test and sandbox environments.
• Workloads, containers, serverless functions, data stores, AI services and the identities, keys and secrets that use them.
• Employees, contractors and third parties who request, build, operate or administer cloud services for [Organisation].

3. Definitions

• Cloud service provider (CSP): a supplier providing IaaS, PaaS or SaaS to [Organisation].
• Cloud account: an AWS account, Azure subscription, Google Cloud project or equivalent unit of isolation and billing.
• Landing zone: the approved, pre-configured multi-account structure with central identity, logging, networking and guardrails into which new accounts are provisioned.
• Guardrail: a preventive or detective control applied centrally to accounts, such as an organisation policy that denies disabling logging.
• Shared responsibility: the division of security tasks between the CSP and [Organisation] for a given service model.
• Workload identity: a non-human identity used by a cloud workload, such as a role, managed identity or service account.
• Break-glass account: an emergency administrative account used only when normal access is unavailable.

4. Roles and responsibilities

• [Chief Information Security Officer]: owns this policy and the cloud security standard; approves exceptions above [risk level].
• [Cloud Platform Team]: operates the landing zone, guardrails, central logging and account vending.
• [Cloud Security Team]: defines baselines, runs posture management, reviews designs and monitors cloud detections.
• Account owners: named individuals accountable for each cloud account, its workloads, costs, data and access.
• Workload teams: build and run workloads within the guardrails and remediate findings within service levels.
• [Procurement and Third-Party Risk]: assesses CSPs and SaaS suppliers and ensures contract security terms.
• [Security Operations]: responds to cloud alerts and incidents.

5. Policy statements

5.1 Approval of cloud services

1. Cloud services must be approved under the [Third-Party Risk Procedure] before they hold [Organisation] data. Approval must consider the service's assurance evidence (for example ISO/IEC 27001 certification, SOC 2 reports or CSA STAR entries), data location, and contract terms.
2. SaaS services must be integrated with [Organisation] single sign-on where the service supports it.
3. Cloud services discovered without approval must be reviewed by [Cloud Security Team] and approved, replaced or blocked within [30 days].

5.2 Shared responsibility

1. For each approved service, the owner must record which security responsibilities rest with the CSP and which with [Organisation], using the provider's published model.
2. Responsibilities that rest with [Organisation] must be assigned to a named team in the cloud security standard.

5.3 Accounts and tenancy

1. New IaaS and PaaS accounts must be provisioned through [account vending process] into the landing zone, with central logging, guardrails and identity federation applied automatically.
2. Production, non-production and sandbox workloads must be in separate accounts. Sandboxes must not hold production data or credentials.
3. Every account must have a named owner, cost centre, environment and data classification recorded in the [asset inventory].
4. Root, global administrator and organisation owner credentials must be protected with phishing-resistant MFA, held by [named roles], and used only for tasks that require them.
5. Unused accounts must be closed through the [decommissioning procedure], including removal of identities, keys and data.

5.4 Identity and access

1. Human access to cloud consoles and APIs must use federated single sign-on with MFA. Local cloud users with long-lived passwords or access keys must not be created except for documented break-glass accounts.
2. Privileged roles must be granted just in time through [PAM or privileged role tooling], time-limited and logged.
3. Workloads must use provider workload identities (roles, managed identities, service accounts) or workload identity federation rather than static keys.
4. Where static access keys cannot be avoided, they must be stored in [approved secrets manager], scoped to least privilege, rotated at least every [90 days] and never committed to code or images.
5. Permissions must follow least privilege. Wildcard administrative permissions on workload identities must not be used in production without approval.
6. Access must be reviewed at least [quarterly] for privileged roles and [six-monthly] for others, including unused permissions and inactive identities.

5.5 Data protection and keys

1. Data must be encrypted at rest and in transit using provider services configured to the [Cryptography Standard]; TLS 1.2 or higher must be used for data in transit.
2. Data classified [Confidential] or above must use customer-managed keys where the service supports them, with key administration separated from data access.
3. Public access to storage must be blocked at account level unless an exception is approved for a published website or dataset.
4. Data location must comply with [Data Protection Policy] and contractual commitments.
5. Backups of critical data must be stored in a separate account or vault with restricted delete permissions.

5.6 Configuration and guardrails

1. Cloud resources must be deployed through infrastructure as code from approved pipelines in production. Manual console changes in production must be limited to break-glass and incident response.
2. Resources must meet the [cloud security baseline], derived from CIS Benchmarks for the relevant provider, and be assessed continuously by posture management.
3. Central guardrails must prevent at least: disabling audit logging, creating public storage, using unapproved regions and creating long-lived user access keys.
4. Posture findings must be remediated within [severity-based service levels: critical 7 days, high 30 days].
5. Instance metadata services must be configured to require session-based access (for example IMDSv2 on AWS) where supported.

5.7 Logging and monitoring

1. Control plane audit logs (for example CloudTrail, Azure Activity and Entra logs, Google Cloud Audit Logs) must be enabled in every account and forwarded to [central log archive] that workload teams cannot alter.
2. Logs must be retained for at least [12 months], with [90 days] immediately searchable.
3. [Security Operations] must monitor for at least: root or global administrator use, guardrail changes, new access keys, privilege escalation, unusual data reads by workload identities and activity in unapproved regions.
4. SaaS audit logs for approved services holding [Confidential] data must be collected where the service provides them.

5.8 Incident response

1. Cloud incidents must be handled under the [Incident Response Plan], with provider-specific runbooks for credential compromise, public data exposure and resource hijacking.
2. [Security Operations] must hold pre-approved access to isolate workloads, revoke sessions and disable keys in every account.
3. Contracts with CSPs must state how the provider notifies [Organisation] of incidents affecting its data.

5.9 Resilience and exit

1. Critical workloads must have documented recovery objectives and must be tested for recovery at least [annually].
2. Each critical cloud service must have an exit plan covering data export, format, timescale and deletion confirmation.

6. Exceptions

Exceptions must be requested by the account owner, risk assessed by [Cloud Security Team], approved by [approver], recorded with compensating controls and an expiry date of no more than [12 months], and implemented as a scoped guardrail exemption rather than by disabling the guardrail.

7. Compliance and monitoring

[Cloud Security Team] will report monthly to [CISO] on: accounts outside the landing zone, posture findings past their service level, long-lived access keys, identities with unused privileged permissions, accounts without central logging, and unapproved SaaS services. Non-compliant resources may be quarantined or removed. Breaches of this policy may be handled under [disciplinary procedure].

8. Related documents

• [Cloud Security Standard], [Cloud Security Baseline], [guardrail repository], [Cryptography Standard], [Data Protection Policy], [Third-Party Risk Procedure], [Incident Response Plan], [Asset Management Policy].

Implementation guidance

Framework alignment

ISO/IEC 27001:2022 Annex A 5.23 (information security for use of cloud services) covers the acquisition, use, management and exit of cloud services as a whole; ISO/IEC 27017 adds cloud-specific guidance. See the ISO/IEC 27017 Cloud Security Controls Guide.

Rollout

1. Inventory first: list every cloud account, subscription, project and SaaS service, including those on expense claims, and assign owners.
2. Apply logging guardrails before anything else: central, tamper-resistant audit logs make every later control measurable.
3. Run guardrails in detective mode for a month, report violations to owners, then switch to preventive mode account by account, starting with sandboxes.
4. Remove long-lived keys: replace user access keys and workload keys with federation and workload identities, tracking the count down to zero.
5. Move existing accounts into the landing zone in waves, with a rollback plan for each wave (keep previous access paths until the wave is verified).
6. Test incident access: confirm [Security Operations] can isolate a workload and disable keys in a sample of accounts.

Common pitfalls

• Over-privileged workload roles: in the Capital One breach, temporary credentials for a firewall's cloud role, obtained through the instance metadata service, could list and copy data from storage. Scope workload roles to the data they need and alert on bulk reads.
• Guardrails switched off for convenience: exemptions should be scoped and time-limited, not a global disable.
• SaaS left out: a policy written for IaaS misses tenant settings, third-party integrations and OAuth grants in SaaS. See the SaaS and OAuth App Governance Guide.
• Sandboxes with production secrets: developer accounts become the easiest route to production credentials.

For implementation depth, see the Cloud Security Guide, the Cloud Landing Zone Security Guide, the Shared Responsibility Models Guide and the Cloud Workload Identity Guide.

References

• NCSC: The Cloud Security Principles
• Cloud Security Alliance: Cloud Controls Matrix
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Cloud Security Guide · Cloud IAM Review Checklist · Cloud Incident Response Guide · CIS Benchmarks Guide · Asset Management Policy Template