Cloud Computing Security Policy and Procedure

1. Purpose

This document makes sure that cloud services are chosen, configured, used and exited in a way that protects the Organisation's information, meets its legal and contractual duties, and keeps the Organisation in control of data it places with a provider. It sets the rules, assigns accountability under the shared responsibility model, and gives the steps to follow before any cloud service is used.

2. Scope

The document covers every public, private, hybrid or community cloud service used for Organisation information, whether bought by the central function or by a team on a company card: infrastructure (IaaS), platform (PaaS), software (SaaS), storage, collaboration, development and analytics services, and managed security services.

• In scope: new services, renewals, changes of use, trials that use real data, and cloud services provided to the Organisation's customers by the Organisation.
• In scope: employees, contractors and suppliers who select, administer or use cloud services.
• Out of scope: personal consumer accounts that hold no Organisation information; their use is limited by the Acceptable Usage Policy.

3. Terms and Definitions

4. Roles and Responsibilities

5. Cloud Computing Security Policy

5.1 General requirements

1. Cloud services holding Organisation information must be approved before use through the cloud service procedure below. A service that is not on the register of approved cloud services must not hold information classified Internal or higher.
2. Each approved service must have a cloud service owner and an entry in the cloud service register showing provider, purpose, data classes, locations, administrators, contract end date and review date.
3. The responsibilities of the provider and the Organisation must be written down for every service, in the shared responsibility table. Where the provider does not cover a control, the Organisation must cover it or accept the risk in the risk register.
4. Providers must give independent assurance, such as a recent audit report or certification against a recognised security standard that covers the service in use and its locations. Absence of assurance is a risk to be assessed, not an automatic approval.
5. Production and non-production environments must be in separate accounts, subscriptions or projects with separate access.
6. Cloud infrastructure must be defined as code where practical, so that changes follow the Change Management Policy and Procedure and baseline drift can be detected.
7. The cloud service owner must keep an exit plan for every Tier 1 and Tier 2 service and test it at least once every [24 months] or at the next material change.
8. Use of services outside the register is shadow IT and must be reported to the information security manager, who decides within [10 working days] whether to approve, migrate or stop it.

5.2 Service levels and contracts

Contracts and service agreements for cloud services must be reviewed by procurement, legal, the data protection officer and the information security manager before signature. The following terms are the minimum for services holding Internal data or higher.

Service levels are measured by the cloud service owner against provider reports each [month], and breaches are raised with the provider and recorded for supplier review.

5.3 Cloud access control

• Access to cloud consoles, management interfaces and APIs must use named accounts, single sign-on with the Organisation's identity provider where available, and multi-factor authentication for all users and always for administrators.
• Roles must follow least privilege. Shared accounts and long-lived access keys are not allowed; where service accounts are necessary they are held in a secrets manager, owned by a named person and rotated at least every [90 days].
• The root or global administrator account of each cloud tenant must be protected by hardware-based or strong multi-factor authentication, held in sealed break-glass storage, used only in an emergency, and each use reviewed within [1 working day].
• Privileged access must be time-limited and approved. Access rights in each cloud service must be reviewed by the cloud service owner [quarterly] for administrators and [every six months] for other users.
• Administrative access from outside the Organisation's network must be limited to managed devices, and access from unusual locations must be blocked or alerted.
• Access of the provider's own staff to Organisation data must be limited, logged and, where the service permits, approved by the Organisation.

5.4 Cloud data security

• Data must be classified before it goes to the cloud under the Information Classification and Handling Policy. Personal data processing in the cloud must comply with the Digital Personal Data Protection Act, 2023 and its Rules, and with applicable law in each jurisdiction where the Organisation operates (such as the EU General Data Protection Regulation) [confirm the current requirement].
• Data must be encrypted in transit and at rest as set out in the Cryptography Policy. Public exposure settings such as open storage buckets, public links and anonymous access are blocked by default and may be enabled only by approved change.
• Backups of data held in cloud services must follow the Backup and Restoration Policy, including a copy that the provider cannot delete with the same credentials.
• Logs from cloud services must be sent to the Organisation's central log store and retained as set out in the Logging and Monitoring Policy.
• Cloud configuration must be scanned for drift and misconfiguration at least [daily] using a cloud posture tool, and high findings must be fixed within [7 days].
• When a service ends, the data must be deleted according to the retention schedule, and written confirmation of deletion from the provider kept.

6. Cloud Computing Security Procedure

6.1 Request and assess a cloud service

1. Raise the requestThe requester completes the cloud service request (Annexure A) naming the business purpose, data classes, users and expected cost, and obtains approval from the line manager. Output: request record. Target: same day.
2. Register an ownerA cloud service owner is named, who accepts accountability for the service.
3. Assess securityThe information security manager reviews the provider's assurance evidence, architecture, data location, encryption and access options, logging, incident handling and sub-processors against the checklist in Annexure B. Target: within [10 working days].
4. Assess privacyThe data protection officer checks personal data processing, transfers, the processing contract and the need for a data protection impact assessment.
5. Rate the riskRecord the risks in the risk register and apply the Risk Management Policy. High risks need treatment or acceptance by the Head of IT Security and the business owner.
6. DecideThe Head of IT Security approves, approves with conditions, or rejects. Conditions are tracked to closure before go-live.

6.2 Contract and set up

1. Agree termsProcurement and legal negotiate to the minimum terms in the service levels table and record any gaps as accepted risks.
2. Configure to baselineThe cloud administrator builds the tenant to the secure configuration baseline: identity and multi-factor authentication, roles, network rules, encryption, logging, alerting and backup.
3. TestVerify the controls, run a configuration scan, and test restore of data where applicable. Evidence is attached to the request.
4. Go liveGo-live follows the Change Management Policy and Procedure. The service is added to the cloud service register on the same day.

6.3 Operate and monitor

1. Day-to-day controlThe cloud administrator watches alerts, drift findings and provider notices, and fixes issues within the times in the policy.
2. ReviewsThe cloud service owner reviews access [quarterly], service levels [monthly], and provider assurance [yearly]; the information security manager reviews configuration [quarterly].
3. IncidentsIncidents in or involving the provider are handled under the Information Security Incident Management Policy and Incident Management Procedure.
4. ChangesA change to use, data class, region or provider terms restarts the assessment.

6.4 Exit or change of provider

1. PlanThe cloud service owner activates the exit plan at least [90 days] before termination where possible, including data export, transfer, and dependency list.
2. Migrate and verifyData and configuration are moved and checked; the new service goes through the assessment above.
3. Delete and confirmThe provider deletes data from the old service, and the Organisation obtains written confirmation. Keys are destroyed.
4. CloseUpdate the register and risk register; remove access; record lessons learned.

6.5 Cloud security checks

7. Compliance and Monitoring

The information security manager reports cloud findings, open conditions and overdue reviews to the information security forum each [quarter]. Internal audit tests the cloud service register against invoices and network data at least once a [year] to find unregistered services.

8. Measures

9. Records and Evidence

• Cloud service register, assessments, contracts and exit plans, kept for the life of the service plus [3 years].
• Shared responsibility tables and configuration baselines, with version history.
• Access review records, configuration scan results and provider assurance reports, kept for [3 years].

Annexure A: Cloud service request form

Annexure B: Cloud provider security checklist

10. Exception

Exceptions to this document are allowed only where compliance is not practicable and the risk has been assessed. A request must state what is to be excepted, why, the risk it creates, the compensating controls, and an end date no later than [6 months]. It is approved in writing by the document owner and the risk owner, recorded in the exceptions register, and reviewed at the end date. An exception does not change the document.

11. Enforcement

Compliance is monitored through internal audits, management review and routine checks by the document owner. Non-compliance is reported through the incident or non-conformity process and handled under the organisation's disciplinary procedure, and under the terms of any contract for people who are not employees. Serious or repeated non-compliance may lead to loss of access and, where the law is broken, to referral to the authorities.

12. Review

This document is reviewed at least every [12 months], and when there is a significant change to the organisation, its systems, its risks or the law, or after an incident that shows it was not effective. Each review is recorded in the revision history.

ISO/IEC 27001:2022 references

Related documents

• Supplier Relationship Management Policy
• Supplier Relationship Management Procedure
• Access Control Policy
• Information Classification and Handling Policy
• Data Protection and Privacy Policy
• Cryptography Policy
• Logging and Monitoring Policy
• Backup and Restoration Policy