1. Purpose
The purpose of this Cloud Security Policy is to establish requirements for the secure selection, use, configuration, operation, monitoring, and management of cloud services used by the organization.
The policy is intended to protect organizational information, customer data, personal data, applications, systems, credentials, and business operations from risks associated with cloud computing.
The organization shall manage cloud security using a risk-based approach, considering the type of cloud service, information processed, business criticality, access requirements, shared-responsibility model, regulatory obligations, and contractual requirements.
2. Scope
This policy applies to all cloud services used to store, process, transmit, develop, host, monitor, secure, or manage organizational information.
It includes:
- Infrastructure as a Service (IaaS)
- Platform as a Service (PaaS)
- Software as a Service (SaaS)
- Cloud databases
- Cloud storage
- Cloud networking
- Cloud identity and access services
- Cloud security services
- Cloud backup and disaster recovery services
- Cloud development and CI/CD platforms
- Cloud-hosted applications
- Containers and container orchestration platforms
- Serverless services
- Cloud APIs
- Cloud-based AI/ML services
- Cloud monitoring and logging platforms
- Third-party cloud services and subprocessors
The policy applies to employees, contractors, administrators, developers, suppliers, and other authorized users who access or manage cloud environments.
3. Cloud Security Principles
The organization shall apply the following principles:
- Business need – Cloud services shall be used for legitimate and approved business purposes.
- Risk-based selection – Cloud services shall be evaluated based on security, privacy, availability, dependency, and business risks.
- Least privilege – Users and services shall receive only the access necessary to perform authorized activities.
- Strong authentication – Appropriate authentication controls, including MFA, shall be implemented for administrative and other sensitive access.
- Secure configuration – Cloud resources shall be configured according to approved security requirements.
- Shared responsibility – Responsibilities between the organization and cloud provider shall be understood and documented.
- Encryption – Sensitive information shall be protected using appropriate encryption controls.
- Monitoring and logging – Security-relevant cloud activities shall be logged and monitored according to risk.
- Resilience – Critical cloud services shall have appropriate backup, recovery, and continuity arrangements.
- Continuous review – Cloud environments shall be periodically reviewed for security, compliance, configuration, access, and risk.
4. Cloud Service Identification and Approval
Before a cloud service is introduced into the organization’s environment, the responsible owner shall evaluate:
- Business purpose
- Service provider
- Type of cloud service
- Information to be processed
- Information classification
- Personal/customer data involved
- Geographic/data-location requirements
- User and administrative access
- Integration with internal systems
- Security requirements
- Availability requirements
- Business criticality
- Supplier dependency
- Subprocessors
- Regulatory and contractual requirements
- Exit and migration requirements
The service shall be approved according to the organization’s defined technology procurement, supplier management, and risk management processes.
Unapproved cloud services shall not be used to store or process restricted organizational or customer information.
5. Cloud Risk Assessment
Cloud services shall be assessed according to the organization’s information-security risk methodology.
The assessment should consider:
| Risk Area | Example Considerations |
|---|---|
| Information | What information is stored or processed? |
| Access | Who can access the cloud environment? |
| Privilege | Are administrative or production privileges required? |
| Availability | What happens if the service becomes unavailable? |
| Confidentiality | What would happen if information were exposed? |
| Integrity | Could unauthorized changes affect business operations? |
| Privacy | Is personal data processed? |
| Supplier | What dependency exists on the cloud provider? |
| Location | Where is information stored or processed? |
| Subprocessors | Does the provider rely on other organizations? |
| Compliance | Are regulatory or contractual requirements applicable? |
| Exit | Can information and services be migrated if required? |
Cloud risks shall be incorporated into the organization’s risk management process where appropriate.
6. Shared Responsibility Model
The organization shall understand and document the applicable cloud shared-responsibility model.
Depending on the service model, security responsibilities may be divided between the cloud provider and the organization.
For example:
Cloud Provider may be responsible for:
- Physical data-center security
- Underlying infrastructure
- Hardware
- Certain foundational network and platform controls
Organization may be responsible for:
- Identity and access management
- User accounts
- Security configurations
- Application security
- Data protection
- Encryption configuration
- Logging and monitoring
- Vulnerability management
- Secure development
- Backup configuration
- Security of customer-managed resources
The organization shall not assume that the cloud provider automatically protects all aspects of the organization’s environment.
7. Cloud Architecture and Secure Design
Cloud environments shall be designed according to applicable security requirements.
Where appropriate, the architecture shall include:
- Network segmentation
- Private networking
- Secure administrative access
- Restricted internet exposure
- Security groups/firewall controls
- Application-level security controls
- Encryption
- Centralized logging
- Monitoring and alerting
- Backup and recovery
- High availability
- Secure secrets management
- Vulnerability management
- Secure deployment processes
Security requirements shall be considered during cloud architecture and significant cloud design changes.
8. Identity and Access Management
Access to cloud environments shall be controlled through approved identity and access mechanisms.
The organization shall:
- Use individual user accounts wherever practical.
- Prohibit unnecessary shared administrative accounts.
- Apply least privilege.
- Implement role-based access where appropriate.
- Enable MFA for administrative and sensitive access.
- Restrict privileged access.
- Review access periodically.
- Remove access when no longer required.
- Disable accounts for terminated or unauthorized users.
- Control service accounts and machine identities.
- Maintain appropriate records of privileged access.
Administrative access shall be limited to authorized personnel.
9. Privileged Access
Privileged cloud access shall be subject to enhanced controls.
Where appropriate:
- Administrative roles shall be separated from standard user roles.
- Privileged access shall require MFA.
- Privileged permissions shall be limited.
- Production access shall be restricted.
- Administrative activities shall be logged.
- Temporary or just-in-time access should be used where technically feasible.
- Privileged access shall be periodically reviewed.
For example, a developer may have access to development resources but should not automatically receive unrestricted production administrator privileges.
10. Cloud Configuration Security
Cloud resources shall be securely configured according to approved baselines.
Configuration controls may include:
- Disable unnecessary services.
- Restrict public access.
- Restrict open network ports.
- Apply secure security-group/firewall rules.
- Enable encryption.
- Enable appropriate logging.
- Secure storage buckets.
- Protect management interfaces.
- Configure secure authentication.
- Remove unused resources.
- Apply secure database configurations.
- Apply appropriate backup settings.
- Maintain configuration consistency.
Security configuration standards shall be reviewed periodically and when significant technology changes occur.
11. Data Protection
Information stored or processed in cloud environments shall be handled according to its classification and applicable security requirements.
The organization shall consider:
- Data classification
- Data minimization
- Encryption
- Access restrictions
- Data retention
- Backup
- Data location
- Data transfer
- Data deletion
- Customer contractual requirements
- Privacy requirements
Restricted or sensitive information shall not be moved to a cloud service without appropriate authorization and risk assessment.
12. Encryption
Appropriate encryption shall be implemented for sensitive information based on risk and applicable requirements.
Where applicable:
- Data at rest shall be encrypted.
- Data in transit shall be protected using secure communication protocols.
- Encryption keys shall be appropriately protected.
- Access to key-management services shall be restricted.
- Key rotation shall be performed where required.
- Cryptographic configurations shall be reviewed periodically.
Encryption requirements should consider the sensitivity and business importance of the information.
13. Secrets and Credential Management
Passwords, API keys, tokens, private keys, database credentials, cloud credentials, and other secrets shall not be stored in:
- Source-code repositories
- Public files
- Application source code
- Unprotected spreadsheets
- Chat messages
- Public documentation
- Container images
- Unsecured configuration files
Where practical, approved secrets-management capabilities shall be used.
Access to secrets shall follow least-privilege principles and shall be monitored according to risk.
Secrets shall be rotated when compromise is suspected or when required by organizational standards.
14. Logging and Monitoring
Security-relevant cloud activities shall be logged and monitored according to risk.
Logging may include:
- Authentication events
- Privileged activities
- Administrative changes
- Network security events
- Configuration changes
- Data-access events
- Security alerts
- Application events
- API activity
- Failed authentication attempts
- Security-control changes
Logs shall be appropriately protected against unauthorized modification or deletion.
Monitoring capabilities shall be proportionate to the criticality of the cloud environment.
15. Cloud Vulnerability Management
Cloud environments shall be included in the organization’s vulnerability-management process where applicable.
The organization shall consider:
- Operating-system vulnerabilities
- Container vulnerabilities
- Application vulnerabilities
- Cloud configuration weaknesses
- Exposed services
- Vulnerable dependencies
- Insecure APIs
- Unsupported software
- Misconfigured security controls
Identified vulnerabilities shall be assessed according to risk and remediated or otherwise treated in accordance with the organization’s vulnerability-management process.
16. Cloud Application Security
Applications deployed to cloud environments shall follow applicable secure-development requirements.
Security considerations may include:
- Secure coding
- Authentication
- Authorization
- Input validation
- API security
- Dependency management
- Secrets management
- Security testing
- Code review
- Vulnerability scanning
- Container security
- Secure CI/CD pipelines
Security requirements shall be considered throughout the application lifecycle.
17. Network Security
Cloud networks shall be designed and configured to minimize unauthorized access.
Where appropriate, controls shall include:
- Network segmentation
- Firewalls
- Security groups
- Network access controls
- Private endpoints
- Restricted administrative interfaces
- VPN or equivalent secure access
- Web application firewalls
- DDoS protection
- Restricted outbound connectivity where appropriate
Internet exposure shall be limited to services that require it.
18. Backup and Recovery
Critical cloud systems and information shall have appropriate backup and recovery arrangements.
The organization shall determine, based on risk:
- What must be backed up
- Backup frequency
- Retention period
- Backup protection
- Backup encryption
- Recovery objectives
- Recovery responsibilities
- Recovery testing requirements
Backups shall be protected from unauthorized access and unauthorized modification.
Recovery procedures shall be tested where required by business continuity and risk requirements.
19. Availability and Resilience
Critical cloud services shall have appropriate availability and resilience controls based on business requirements.
These may include:
- Multi-zone or equivalent architecture
- Redundancy
- Automated recovery
- Backup systems
- Monitoring
- Capacity management
- Disaster recovery arrangements
- Alternative service arrangements
- Cloud-provider continuity capabilities
Critical cloud dependencies shall be documented where appropriate.
20. Cloud Supplier Security
Cloud providers shall be managed through the organization’s supplier-management process.
Depending on risk, the organization may review:
- Security certifications
- SOC reports
- Independent assurance
- Penetration-testing information
- Security architecture
- Incident-management arrangements
- Business continuity
- Data locations
- Subprocessors
- Contractual security requirements
- Privacy requirements
- Service availability
- Security incident notification
- Exit and data-deletion arrangements
A cloud provider’s certification or assurance report shall not automatically eliminate the organization’s responsibility for assessing its own cloud configuration and usage.
21. Subprocessors and Data Location
Where cloud providers use subprocessors that may process organizational or customer information, the organization shall evaluate the applicable risks and contractual requirements.
The organization shall consider:
- Subprocessor identity
- Processing purpose
- Information involved
- Data location
- International transfers
- Security controls
- Privacy requirements
- Notification of material changes
- Contractual protections
Applicable privacy and contractual requirements shall be incorporated into supplier management.
22. Cloud Change Management
Significant changes to cloud environments shall follow the organization’s change-management process.
Examples include:
- New cloud provider
- New production environment
- Major architecture changes
- New internet exposure
- New administrative access
- New data processing
- Data-location changes
- Major IAM changes
- New integrations
- New subprocessors
- Migration between cloud services
- Changes to encryption architecture
- Changes to backup/recovery architecture
Security impact and risk shall be considered before significant changes are implemented.
Emergency changes shall be documented and reviewed retrospectively where appropriate.
23. Cloud Security Incident Management
Security incidents involving cloud services shall be managed through the organization’s incident-management process.
Potential incidents include:
- Compromised cloud accounts
- Unauthorized administrative access
- Exposed storage
- Accidental public exposure
- Credential compromise
- Unauthorized data access
- Cloud configuration compromise
- Malware
- Ransomware
- Denial-of-service attacks
- Cloud-provider security incidents
- Unauthorized changes to production resources
Where a cloud provider is involved, the organization shall coordinate with the provider according to contractual and incident-response requirements.
24. Cloud Security Testing
Cloud environments shall be subject to appropriate security testing based on risk.
Testing may include:
- Vulnerability scanning
- Configuration assessments
- Penetration testing
- Application security testing
- IAM reviews
- Network security testing
- Container security testing
- Cloud security posture assessments
- Backup/recovery testing
Testing shall be performed within authorized scope and in accordance with cloud-provider rules and contractual requirements.
25. Cloud Access Review
Cloud access shall be reviewed periodically based on risk and organizational requirements.
The review should verify:
- User still requires access.
- User is authorized.
- Appropriate role is assigned.
- MFA is enabled where required.
- Privileged access remains justified.
- Production access remains necessary.
- Former users have been removed.
- Service accounts remain necessary.
- Excessive permissions are identified and addressed.
Evidence of access reviews shall be retained according to the organization’s record-retention requirements.
26. Cloud Security Monitoring and Review
Cloud security shall be monitored continuously or periodically according to risk.
The organization shall consider:
- Security alerts
- Access activity
- Configuration changes
- Vulnerabilities
- Threat intelligence
- Incidents
- Availability
- Capacity
- Compliance requirements
- Security-assurance changes
- Cloud-provider changes
The effectiveness of cloud security controls shall be reviewed periodically.
27. Cloud Resource Inventory
The organization shall maintain appropriate visibility of cloud resources.
Depending on the environment, this may include:
- Cloud accounts/subscriptions
- Virtual machines
- Containers
- Databases
- Storage
- Network resources
- IAM identities
- APIs
- Serverless functions
- Security services
- Production environments
- Development environments
Unused or unidentified resources shall be investigated and removed or formally approved where appropriate.
28. Environment Separation
Development, testing, staging, and production environments shall be separated according to risk and business requirements.
Where appropriate:
- Production data shall not be unnecessarily copied to development environments.
- Production administrative access shall be restricted.
- Development credentials shall not be reused in production.
- Security configurations shall be appropriate for each environment.
- Changes shall follow the organization’s change and release processes.
29. Cloud Asset Ownership
Cloud resources shall have identifiable ownership.
The organization should maintain information such as:
- Resource/application name
- Business owner
- Technical owner
- Environment
- Business purpose
- Data classification
- Criticality
- Cloud provider
- Security requirements
- Review status
Ownership shall be reviewed when significant organizational or technology changes occur.
30. Cloud Exit and Portability
For critical cloud services, the organization shall consider how services and information could be recovered, migrated, or discontinued.
Where relevant, the organization shall consider:
- Data export capability
- Data portability
- Backup availability
- Alternative providers
- Migration dependencies
- Contract termination requirements
- Data deletion
- Credential revocation
- Service dependencies
- Recovery time requirements
The level of exit planning shall be proportionate to the criticality and dependency of the cloud service.
31. Roles and Responsibilities
Management
Management shall:
- Approve this policy.
- Provide appropriate resources.
- Ensure significant cloud risks are addressed.
- Review significant risks and exceptions.
Information Security / ISMS Function
Responsible for:
- Defining cloud security requirements.
- Supporting cloud risk assessments.
- Monitoring security risks.
- Reviewing security controls.
- Coordinating security incidents.
- Supporting internal audits.
Cloud/IT Team
Responsible for:
- Secure cloud configuration.
- IAM implementation.
- Network security.
- Logging and monitoring.
- Backup and recovery.
- Vulnerability management.
- Configuration management.
Application/Development Teams
Responsible for:
- Secure application development.
- Secure deployment.
- Dependency management.
- Secrets management.
- Application-level access controls.
- Addressing identified vulnerabilities.
Business/System Owners
Responsible for:
- Defining business requirements.
- Approving access.
- Identifying information handled.
- Reviewing business and security risks.
- Confirming continued business need.
Users
Users shall:
- Protect credentials.
- Use approved cloud services.
- Follow security requirements.
- Report suspected security incidents.
- Not bypass established security controls.
32. Exceptions
Any exception to this policy shall be:
- Documented
- Justified
- Risk assessed
- Approved by the appropriate authority
- Time-bound where appropriate
- Periodically reviewed
Exceptions shall not be used as a permanent substitute for implementing appropriate security controls.
33. Records and Evidence
Depending on the organization’s environment, evidence may include:
- Cloud service inventory
- Cloud risk assessments
- Supplier assessments
- Cloud architecture diagrams
- IAM/access reviews
- Privileged-access reviews
- Security configuration assessments
- Vulnerability reports
- Penetration-test reports
- Cloud logs
- Security alerts
- Incident records
- Backup/recovery test results
- Change records
- Security monitoring records
- Cloud-provider assurance reports
- Contracts and security addenda
- Subprocessor assessments
- Data-location assessments
- Exception/risk-acceptance records
Secrets, passwords, private keys, tokens, and other credentials shall not be stored as audit evidence.
34. AWS SaaS Example
Consider a SaaS startup hosting its customer-facing application on AWS.
The environment may include:
- Amazon ECS/EC2 for application workloads
- Amazon RDS for databases
- Amazon S3 for object storage
- AWS IAM for access management
- AWS KMS for encryption keys
- AWS CloudTrail for audit logging
- Amazon CloudWatch for monitoring
- AWS WAF for web protection
- AWS Security Hub/GuardDuty where appropriate
The organization should establish:
Identity
- Named administrative accounts
- MFA
- Least-privilege IAM roles
- Restricted production access
Data
- Encryption at rest
- TLS for data in transit
- Restricted S3 access
- Appropriate database access controls
Monitoring
- CloudTrail enabled
- Security events monitored
- Administrative activity reviewed
- Alerts investigated
Resilience
- RDS backup configuration
- Recovery procedures
- Appropriate availability architecture
- Periodic recovery testing
Application Security
- Secure CI/CD
- Dependency scanning
- Container security
- Vulnerability management
- Secrets stored using an approved mechanism
The objective is not simply to demonstrate that the organization uses AWS. The organization should be able to demonstrate how AWS is securely configured and operated for its particular business and risk environment.
35. Startup-Friendly Implementation Model
A startup does not need to create excessive cloud-security documentation.
A practical implementation can begin with:
Level 1 — Visibility
Maintain:
- Cloud provider inventory
- Cloud asset inventory
- Application ownership
- Data classification
- IAM users/roles
Level 2 — Basic Security
Implement:
- MFA
- Least privilege
- Secure configurations
- Encryption
- Logging
- Backup
- Vulnerability management
Level 3 — Operational Security
Add:
- Continuous monitoring
- Security alerts
- Access reviews
- Configuration reviews
- Incident response
- Recovery testing
- Change management
Level 4 — Mature Cloud Security
For higher-risk environments, add:
- Cloud security posture management
- Infrastructure-as-Code security
- Automated compliance checks
- Centralized security monitoring
- Privileged access management
- Continuous vulnerability management
- Advanced threat detection
- Automated remediation where appropriate
- Cloud resilience and exit testing
The appropriate level should be determined by risk rather than company size alone.
36. Relationship With Other ISMS Documents
This policy should operate together with other ISMS processes and records, including:
| Document | Relationship |
|---|---|
| Information Security Policy | Establishes overall security direction |
| Risk Assessment | Identifies cloud-related risks |
| Risk Treatment Plan | Defines treatment actions |
| Statement of Applicability | Records applicable controls |
| Asset Register | Records cloud assets |
| Supplier Register | Records cloud providers |
| Critical Supplier Register | Identifies critical cloud providers |
| ICT Dependency Register | Records critical cloud dependencies |
| Access Control Policy | Defines access requirements |
| Vulnerability Management Procedure | Manages cloud vulnerabilities |
| Incident Response Procedure | Handles cloud security incidents |
| Backup Policy | Defines backup requirements |
| Business Continuity Plan | Addresses cloud service disruption |
| Change Management Procedure | Controls significant cloud changes |
| Secure Development Procedure | Protects cloud-hosted applications |
| Cloud Risk Assessment | Provides detailed cloud-specific risk evaluation |
37. ISO 27001 Connection
Cloud security should be implemented as part of the organization’s overall ISMS and risk-management process.
Relevant ISO/IEC 27001:2022 Annex A areas may include controls concerning:
- Information security policies
- Roles and responsibilities
- Access control
- Identity management
- Authentication
- Privileged access
- Information classification
- Supplier relationships
- ICT supply-chain security
- Cloud services
- Configuration management
- Information deletion
- Data leakage prevention
- Logging
- Monitoring
- Vulnerability management
- Backup
- Network security
- Secure development
- Change management
- Incident management
- Business continuity
The organization should determine applicable controls through its risk assessment and risk treatment process and document applicability in the Statement of Applicability.
This policy itself should not be treated as evidence that a control is operating. Auditors will generally look for evidence that the requirements are actually implemented and maintained.
38. Internal Audit Checklist
An auditor may ask:
- Are all significant cloud services identified?
- Are cloud services approved?
- Has cloud risk been assessed?
- Is the shared-responsibility model understood?
- Are cloud administrators identified?
- Is MFA enabled for sensitive/privileged access?
- Is least privilege implemented?
- Are production privileges restricted?
- Are cloud configurations securely managed?
- Is sensitive information encrypted?
- Are secrets securely managed?
- Are security logs enabled?
- Are security events monitored?
- Are vulnerabilities managed?
- Are cloud backups configured?
- Has recovery been tested where required?
- Are cloud suppliers assessed?
- Are subprocessors reviewed where relevant?
- Are data locations understood?
- Are cloud changes controlled?
- Are incidents managed?
- Are cloud access reviews performed?
- Are critical cloud dependencies documented?
- Are cloud risks periodically reassessed?
- Is appropriate evidence available?
39. Final Cloud Security Audit Trail
A mature cloud-security process should create a traceable chain:
Business Requirement
↓
Cloud Service Identified
↓
Information & Data Identified
↓
Cloud Risk Assessment
↓
Supplier / Provider Assessment
↓
Security Requirements
↓
Architecture & Secure Configuration
↓
IAM & Access Controls
↓
Encryption & Data Protection
↓
Logging & Monitoring
↓
Vulnerability & Configuration Management
↓
Backup & Recovery
↓
Security Testing
↓
Incident Management
↓
Periodic Access & Security Review
↓
Risk Reassessment
↓
Continual Improvement
40. Final Principle
Cloud security is not simply about choosing a trusted cloud provider.
The organization must be able to demonstrate:
What cloud services do we use? → What information do they handle? → Who can access them? → What could go wrong? → What controls protect them? → How do we monitor them? → How do we recover from failure? → How do we verify that the controls continue to work?
For an ISO 27001 ISMS, the strongest evidence is therefore not just a cloud-provider certificate. It is the combination of risk assessment, secure configuration, access control, operational monitoring, security evidence, testing, incident handling, recovery, and periodic review.