1. Purpose
The Cloud Secure Configuration Standard defines the minimum security configuration requirements for cloud services and cloud-hosted environments used by the organization.
The objective is to reduce security risks caused by:
- Insecure default configurations
- Excessive access privileges
- Public exposure of systems or data
- Weak authentication
- Unnecessary services and ports
- Inadequate logging and monitoring
- Unencrypted information
- Poorly configured storage
- Insecure network controls
- Unmanaged cloud resources
- Configuration drift
The standard establishes a consistent baseline while allowing configuration requirements to be adjusted based on risk, technology, business requirements, and the cloud provider’s shared-responsibility model.
2. Scope
This standard applies to cloud environments and services used to store, process, transmit, develop, monitor, secure, or manage organizational information.
It may include:
- IaaS
- PaaS
- SaaS
- Cloud databases
- Cloud storage
- Virtual machines
- Containers
- Kubernetes
- Serverless services
- Cloud networking
- Identity and access management
- Cloud security services
- Backup services
- Monitoring platforms
- CI/CD environments
- Cloud-hosted applications
- APIs
- Infrastructure-as-Code
- AI/ML cloud services
The standard applies to:
- Production environments
- Development environments
- Test environments
- Staging environments
- Disaster-recovery environments
Configuration requirements should be proportionate to the sensitivity and criticality of each environment.
3. Relationship With Other ISMS Documents
The Cloud Secure Configuration Standard should operate together with:
| Document | Relationship |
|---|---|
| Cloud Security Policy | Defines overall cloud security principles |
| Cloud Services Register | Identifies approved cloud services |
| Cloud Security Risk Assessment | Determines risks requiring treatment |
| Cloud Security Baseline | Defines minimum technical security controls |
| Asset Inventory | Identifies systems and resources |
| Cloud Access Register | Tracks authorized access |
| Vulnerability Management Procedure | Manages vulnerabilities |
| Change Management Procedure | Controls configuration changes |
| Incident Response Procedure | Handles security incidents |
| Backup Policy | Defines backup requirements |
| Supplier Risk Assessment | Addresses cloud-provider risk |
| Security Monitoring Procedure | Defines monitoring requirements |
| Risk Register | Tracks significant risks and treatment |
4. Configuration Security Principles
Cloud configurations should follow these principles:
- Secure by default
- Least privilege
- Deny by default where practical
- Minimize public exposure
- Use strong authentication
- Encrypt sensitive information
- Enable appropriate logging
- Remove unnecessary services
- Separate environments
- Use approved configuration baselines
- Automate configuration where practical
- Monitor for configuration drift
- Document and approve exceptions
- Regularly review configurations
- Apply the shared-responsibility model
5. Cloud Account and Tenant Configuration
Cloud accounts, subscriptions, projects, and tenants should be securely configured.
Minimum requirements should include:
- Unique identification of cloud accounts
- Defined business and technical ownership
- Approved organizational structure
- Separation of production and non-production environments where appropriate
- Strong administrative authentication
- MFA for privileged accounts
- Removal or disabling of unnecessary accounts
- Restrictions on root or equivalent account usage
- Centralized logging where technically possible
- Monitoring of privileged activity
- Appropriate service quotas and limits
- Configuration of security notifications
Cloud accounts should not be created solely for convenience without appropriate ownership and security requirements.
6. Identity and Access Configuration
Cloud IAM should follow least privilege.
The organization should:
- Use named individual accounts
- Avoid shared administrative accounts
- Require MFA for privileged access
- Use role-based access where practical
- Assign only required permissions
- Avoid unnecessary wildcard permissions
- Separate administrative and standard user access
- Review privileged access periodically
- Remove access when no longer required
- Control service accounts and workload identities
- Protect access keys and tokens
- Prefer temporary credentials where supported
Privileged permissions should be granted only where justified by business or technical requirements.
7. Root and Break-Glass Accounts
Cloud root, owner, super-administrator, or equivalent accounts should be tightly controlled.
Requirements should include:
- MFA
- Strong unique credentials
- Restricted operational use
- Secure credential storage
- Documented ownership
- Monitoring where supported
- Periodic review
- Emergency-use procedures
Break-glass accounts should be used only when normal administrative mechanisms are unavailable or during an approved emergency.
Their use should be logged and reviewed.
8. Network Configuration
Cloud networks should be configured according to the organization’s security architecture.
Controls should include, where applicable:
- Network segmentation
- Private subnets for sensitive workloads
- Restricted inbound traffic
- Restricted outbound traffic where appropriate
- Security groups/firewall rules
- Network ACLs or equivalent controls
- Controlled administrative access
- VPN or secure access mechanisms where required
- Restricted management ports
- Network monitoring
- Web application firewall protection for applicable internet-facing applications
- Removal of unused network rules
Internet exposure should be minimized.
For example, a database should not normally be directly accessible from the public internet when private connectivity is technically feasible.
9. Public Exposure
Cloud resources should not be publicly accessible unless there is an approved business or technical requirement.
Public exposure should be assessed for:
- Virtual machines
- Databases
- Storage buckets
- APIs
- Management interfaces
- Kubernetes services
- Container endpoints
- Administrative interfaces
- Monitoring systems
- Development tools
Publicly exposed resources should have appropriate security controls, such as:
- Authentication
- Authorization
- Encryption
- Firewall controls
- WAF
- Rate limiting
- Logging
- Monitoring
- Vulnerability management
10. Storage Configuration
Cloud storage should be securely configured.
Requirements should include:
- Private access by default
- Appropriate access policies
- Encryption
- Versioning where required
- Logging where appropriate
- Controlled sharing
- Restricted anonymous access
- Lifecycle management
- Backup where required
- Data retention requirements
- Secure deletion requirements
Storage containing customer, confidential, or restricted information should not be publicly accessible unless explicitly approved and appropriately protected.
11. Database Configuration
Cloud databases should be configured according to their sensitivity and business criticality.
Controls may include:
- Private network placement
- Strong authentication
- Encryption at rest
- Encryption in transit
- Restricted administrative access
- Database activity logging where appropriate
- Backup
- Point-in-time recovery where required
- High availability where required
- Security patching
- Removal of default accounts where supported
- Secure configuration of database parameters
Production databases should not be directly accessible from unrestricted internet networks.
12. Encryption Configuration
Encryption should be implemented based on information sensitivity and risk.
Where appropriate:
Data at rest
Use encryption for:
- Databases
- Storage
- Backups
- Snapshots
- Logs
- Sensitive configuration data
Data in transit
Use secure protocols such as:
- TLS
- HTTPS
- Secure API communication
- Secure administrative protocols
Weak or obsolete cryptographic protocols should not be used where secure alternatives are available.
13. Encryption Key Management
Encryption keys should be managed securely.
Requirements may include:
- Centralized key management
- Restricted key access
- Separation of key-management privileges
- Key rotation where appropriate
- Monitoring of key usage
- Protection against unauthorized deletion
- Defined key ownership
- Secure recovery procedures
Cloud-managed key-management services should be used where appropriate rather than storing encryption keys directly in application source code.
14. Secrets and Credential Configuration
Passwords, API keys, tokens, certificates, database credentials, and other secrets must not be stored in:
- Source-code repositories
- Public storage
- Application configuration committed to Git
- Container images
- Public CI/CD logs
- Unencrypted files
Approved secrets-management mechanisms should be used.
Examples include:
- AWS Secrets Manager
- AWS Systems Manager Parameter Store
- Azure Key Vault
- Google Secret Manager
- Equivalent enterprise-approved solutions
Secrets should be rotated when required by risk, compromise, personnel changes, or security events.
15. Compute Configuration
Cloud compute resources should be securely configured.
Requirements may include:
- Hardened operating systems
- Removal of unnecessary services
- Secure administrative access
- Endpoint/security monitoring where applicable
- Security patching
- Restricted network access
- Encryption
- Logging
- Time synchronization
- Resource ownership
- Approved machine images
Default credentials must be changed or disabled.
Unused compute resources should be removed or securely decommissioned.
16. Container Configuration
Containers should be securely configured.
Where applicable:
- Use approved base images
- Keep images updated
- Scan images for vulnerabilities
- Avoid running containers as root unless justified
- Minimize installed packages
- Restrict container privileges
- Do not embed secrets in images
- Use trusted registries
- Control image access
- Monitor deployed workloads
- Track image versions
- Maintain SBOM information where appropriate
Container images should be rebuilt when critical security vulnerabilities require remediation.
17. Kubernetes Configuration
Where Kubernetes is used, appropriate controls should include:
- Strong cluster authentication
- RBAC
- Namespace separation
- Restricted privileged containers
- Network policies
- Secure secrets management
- API-server protection
- Audit logging
- Node security
- Image scanning
- Resource limits
- Secure ingress configuration
- Regular cluster updates
Kubernetes administrative access should be restricted to authorized personnel.
18. Serverless Configuration
Serverless services should follow least privilege and secure-by-default principles.
Requirements may include:
- Restricted execution roles
- Secure environment variables
- Secrets management
- API authentication
- Input validation
- Logging
- Monitoring
- Dependency management
- Appropriate network controls
- Controlled invocation permissions
Functions should not receive broad permissions merely because they may need additional permissions in the future.
19. Logging Configuration
Appropriate security logs should be enabled.
Depending on the cloud service, this may include:
- Administrative activity
- Authentication activity
- IAM changes
- Network activity
- Application activity
- Database activity
- Storage access
- Configuration changes
- Security alerts
- Key usage
- API activity
Logs should be:
- Protected from unauthorized modification
- Accessible only to authorized personnel
- Retained according to organizational requirements
- Monitored for relevant security events
- Available for incident investigation where required
20. Monitoring and Alerting
Cloud environments should be monitored for significant security events.
Examples include:
- Privileged access
- Failed authentication
- Suspicious login activity
- Public storage exposure
- Security-group changes
- IAM privilege escalation
- Disabled logging
- Encryption changes
- Security-service changes
- Unexpected geographic access
- Abnormal resource activity
- Malware/security alerts
Monitoring should be proportionate to the risk and criticality of the environment.
21. Vulnerability and Patch Configuration
Cloud workloads should be maintained using an appropriate vulnerability and patch-management process.
The organization should:
- Identify applicable assets
- Scan where technically appropriate
- Monitor relevant vulnerabilities
- Prioritize vulnerabilities based on risk
- Apply security patches
- Test changes where appropriate
- Track exceptions
- Verify remediation
- Reassess significant vulnerabilities
A vulnerability scanner’s severity rating should not automatically determine the organization’s final risk decision.
22. Configuration Management
Cloud configurations should be managed through controlled configuration-management practices.
Where practical, use:
- Infrastructure-as-Code
- Approved templates
- Version control
- Configuration repositories
- Automated deployment
- Peer review
- Change approval
- Configuration scanning
- Drift detection
Examples include:
- Terraform
- AWS CloudFormation
- Azure Bicep
- Google Cloud Deployment Manager or equivalent tooling
Manual configuration should be minimized for critical production environments where automation can provide better consistency and traceability.
23. Infrastructure-as-Code Security
Infrastructure-as-Code should be treated as part of the organization’s software and security supply chain.
Requirements may include:
- Version control
- Code review
- Security scanning
- Restricted repository access
- Protected branches
- Controlled deployment
- Secrets protection
- Change approval
- Traceability to deployment
Infrastructure code should not contain credentials or other sensitive secrets.
24. Environment Separation
Production, staging, development, and test environments should be appropriately separated.
Separation may involve:
- Different cloud accounts
- Different subscriptions/projects
- Separate networks
- Separate databases
- Separate IAM roles
- Separate credentials
- Separate secrets
- Separate deployment pipelines
Production data should not be copied into development or testing environments unless there is an approved business requirement and appropriate protection.
25. Backup Configuration
Cloud backup configurations should reflect business continuity and recovery requirements.
Controls may include:
- Automated backups
- Defined retention
- Encryption
- Access restrictions
- Backup monitoring
- Backup integrity checks
- Recovery testing
- Protection against accidental deletion
- Appropriate geographic/availability-zone resilience
Backup configuration should be aligned with defined RTO and RPO requirements where applicable.
26. High Availability and Resilience
Critical cloud services should be configured according to availability requirements.
Controls may include:
- Multi-AZ deployment
- Redundancy
- Load balancing
- Automated recovery
- Health monitoring
- Database replication
- Failover mechanisms
- Capacity management
High availability should be implemented based on business impact and risk rather than automatically applied to every cloud resource.
27. Cloud Security Services
Applicable cloud-native security services should be enabled and appropriately configured.
For an AWS environment, examples may include:
- AWS CloudTrail
- Amazon CloudWatch
- AWS Config
- Amazon GuardDuty
- AWS Security Hub
- AWS WAF
- AWS KMS
- AWS IAM Access Analyzer
- Amazon Inspector
The organization should determine which services are appropriate based on its architecture and risk assessment.
Simply enabling a security service does not establish effective security; configuration, alert handling, monitoring, and evidence should also be considered.
28. Administrative Access
Administrative access to cloud infrastructure should be restricted.
Requirements should include:
- Named accounts
- MFA
- Least privilege
- Privileged access approval
- Logging
- Periodic access review
- Removal of unnecessary privileges
- Controlled emergency access
Where possible, administrative access should be performed through approved centralized identity mechanisms.
29. Configuration Change Management
Significant cloud configuration changes should follow the organization’s change-management process.
Examples include:
- IAM policy changes
- Firewall changes
- Public exposure changes
- Encryption changes
- Logging changes
- Production architecture changes
- Database configuration changes
- Security-service changes
- Network routing changes
Emergency changes should be documented and reviewed retrospectively.
30. Configuration Baseline
The organization should maintain an approved baseline for important cloud environments.
A baseline may define requirements such as:
| Area | Example Baseline |
|---|---|
| IAM | MFA + least privilege |
| Root account | Restricted + MFA |
| Storage | Private by default |
| Database | No unnecessary public access |
| Encryption | Enabled for sensitive data |
| Logging | Administrative activity enabled |
| Network | Restricted inbound access |
| Secrets | Approved secrets manager |
| Vulnerability | Risk-based scanning |
| Backup | Defined for critical workloads |
| Monitoring | Security alerts enabled |
| Changes | Controlled and traceable |
| Production | Enhanced security requirements |
The exact baseline should be adapted to the organization’s architecture and risk profile.
31. Configuration Compliance Checks
Configuration compliance should be periodically assessed.
Checks may include:
- Public resources
- IAM permissions
- MFA status
- Encryption status
- Logging
- Firewall rules
- Security groups
- Storage permissions
- Database exposure
- Backup configuration
- Security services
- Vulnerability status
- Unsupported resources
- Configuration drift
Automated checks should be used where practical.
32. Configuration Drift
Configuration drift occurs when a deployed environment differs from its approved configuration baseline.
The organization should:
- Detect significant drift.
- Determine whether the change was authorized.
- Assess security impact.
- Correct unauthorized configuration.
- Document approved deviations.
- Update the baseline where justified.
- Record evidence.
Critical production drift should be investigated promptly.
33. Security Exceptions
Exceptions to this standard should be:
- Business or technically justified
- Risk assessed
- Approved by an authorized person
- Documented
- Time-bound where practical
- Assigned an owner
- Reviewed periodically
- Closed when no longer required
Exceptions should not become permanent undocumented deviations.
34. Cloud Configuration Review Frequency
Review frequency should be risk-based.
An illustrative approach is:
| Environment | Example Review |
|---|---|
| Critical production | Continuous/automated + periodic formal review |
| High-risk production | Frequent automated monitoring + periodic review |
| Standard production | Periodic review |
| Development | Periodic review based on risk |
| Test | Periodic review based on risk |
| Temporary environments | Review during creation and before removal |
These frequencies are examples and should be defined by the organization’s risk assessment.
35. AWS SaaS Example
Consider a SaaS startup running its production platform on AWS.
Architecture
- ECS/EC2 for application workloads
- RDS for database
- S3 for object storage
- IAM for identity
- KMS for encryption
- CloudTrail for audit logging
- CloudWatch for monitoring
- WAF for internet-facing application protection
- GuardDuty/Security Hub for security monitoring
Secure configuration
IAM
- MFA for privileged users
- Least-privilege roles
- No shared administrator accounts
- Periodic privileged-access review
Network
- Application exposed through controlled internet-facing components
- Database placed in private subnets
- Restricted security-group rules
- Administrative access restricted
S3
- Block unnecessary public access
- Encryption enabled
- Access controlled through IAM policies
- Logging/monitoring where appropriate
RDS
- Private connectivity
- Encryption enabled
- Automated backups
- Restricted administrative access
- Monitoring enabled
Secrets
Application credentials are stored in an approved secrets-management service rather than GitHub or application source code.
Logging
CloudTrail records relevant administrative activity and CloudWatch supports monitoring and alerting.
Configuration management
Terraform is used to manage infrastructure changes through version control and review.
The resulting evidence could include:
- IAM configuration
- MFA report
- Security-group configuration
- S3 public-access configuration
- RDS configuration
- KMS configuration
- CloudTrail configuration
- Security monitoring configuration
- Terraform repository history
- Configuration scan reports
- Change records
36. Minimum Configuration Evidence
Depending on the environment, evidence may include:
- Cloud configuration reports
- IAM access reports
- MFA reports
- Firewall/security-group configuration
- Storage configuration
- Database configuration
- Encryption configuration
- KMS/key-management records
- CloudTrail/logging configuration
- Monitoring alerts
- Vulnerability reports
- Backup configuration
- Infrastructure-as-Code repositories
- Configuration scan reports
- Change tickets
- Exception approvals
- Periodic configuration-review records
Evidence should demonstrate actual implementation, not merely the existence of a policy.
37. Roles and Responsibilities
CISO / Security Owner
- Own the standard
- Define security requirements
- Review significant exceptions
- Monitor security compliance
Cloud/Infrastructure Team
- Implement secure configurations
- Maintain baselines
- Remediate configuration issues
- Maintain technical evidence
Application/Engineering Team
- Secure application and infrastructure configurations
- Protect secrets
- Follow secure deployment practices
- Address configuration vulnerabilities
IT/IAM Team
- Manage identities and privileges
- Enforce MFA
- Conduct access reviews
Risk/Compliance Team
- Map requirements to risk and ISMS controls
- Review evidence
- Track exceptions and findings
- Support internal audits
Internal Audit
- Independently assess whether requirements are implemented and operating effectively.
38. Common Mistakes
Avoid:
- Treating the cloud provider’s certification as proof that your configuration is secure
- Leaving storage publicly accessible
- Giving developers excessive production permissions
- Using shared administrator accounts
- Storing secrets in Git
- Allowing unrestricted database access
- Disabling logging to reduce cost without risk assessment
- Creating cloud resources without ownership
- Making manual production changes without traceability
- Ignoring configuration drift
- Using identical configurations for development and production without considering risk
- Treating vulnerability-scanner results as the complete risk assessment
- Keeping unused cloud accounts, roles, resources, and credentials
39. Internal Audit Checklist
An auditor may verify:
- Cloud services are identified and approved.
- Cloud resources have defined ownership.
- Production and non-production environments are appropriately separated.
- MFA is enabled for privileged access.
- Least privilege is implemented.
- Root/break-glass accounts are controlled.
- Public exposure is reviewed.
- Storage permissions are appropriately restricted.
- Databases are appropriately protected.
- Encryption is implemented where required.
- Secrets are securely managed.
- Security logging is enabled.
- Security monitoring is operating.
- Vulnerabilities are managed.
- Cloud configurations are subject to change management.
- Infrastructure-as-Code is controlled where used.
- Configuration drift is monitored.
- Backup requirements are implemented.
- Critical workloads have appropriate resilience.
- Security exceptions are documented and approved.
- Configuration reviews are performed.
- Evidence demonstrates actual operation.
40. ISO/IEC 27001 Connection
This standard supports the organization’s implementation of applicable ISO/IEC 27001:2022 information-security controls.
Relevant areas may include:
- Access control
- Configuration management
- Information deletion
- Data masking
- Data leakage prevention
- Logging
- Monitoring
- Vulnerability management
- Network security
- Cryptography
- Secure authentication
- Change management
- Secure development
- Backup
- Redundancy
- Supplier/cloud security
The organization should determine applicability through its risk assessment, risk treatment process, Statement of Applicability, legal/contractual obligations, and business requirements.
This standard should therefore not be treated as a universal checklist requiring every configuration item in every cloud environment.
41. Cloud Secure Configuration Audit Trail
The complete audit trail should demonstrate:
Cloud Service Identified → Business Requirement → Risk Assessment → Configuration Baseline → Secure Configuration → Approval → Deployment → Monitoring → Configuration Review → Drift Detection → Corrective Action → Verification → Evidence
For a significant production change:
Change Request → Security Impact Assessment → Approval → Configuration Change → Validation → Monitoring → Evidence → Review
42. Final Principle
A cloud environment should not be considered secure merely because it is hosted by a reputable cloud provider.
Security depends on how the organization configures, operates, monitors, and controls the cloud environment within the provider’s shared-responsibility model.
The objective is not to make every cloud resource identical. The objective is to ensure that each important cloud service has an appropriate, approved, monitored, and evidence-backed security configuration based on its risk.
Secure configuration = Approved baseline + Least privilege + Restricted exposure + Strong authentication + Encryption + Logging + Monitoring + Vulnerability management + Controlled changes + Continuous review.