A cloud application can be working exactly as expected while its security configuration is failing quietly. A storage location may be public. A former employee’s credentials may still work. Backups may complete successfully without producing a usable recovery.
None of those problems necessarily interrupts the business—until someone exploits them or a disruption exposes them.
Effective cloud configuration requires two answers: What should we configure, and how will we prove it works? A setting is a starting point. Evidence that it protects the business is the real objective.
This checklist gives business owners, IT managers, and technical teams a practical security baseline. It is not a compliance certification or a substitute for workload-specific requirements. Use it to establish ownership, close obvious gaps, and make verification part of normal operations.
Start With Responsibility, Not Settings
Cloud providers protect underlying infrastructure, but customers still have responsibilities for identities, data, access, and configuration. The boundary varies by service. A managed database reduces some operational work; it does not decide which employees should access customer records.
Before reviewing controls, identify who approves access, who implements changes, and who responds when something goes wrong. An outsourced provider may perform the work, but the business still needs an accountable owner.
The UK National Cyber Security Centre’s cloud platform guidance emphasizes secure defaults, automated controls, and regular testing. Treat those principles as an operating discipline—not a deployment milestone.
The Seven-Point Cloud Configuration Checklist
1. Inventory the Environment and Assign Owners
You cannot consistently secure resources you do not know exist. Begin with the full cloud estate, including older projects, experimentation environments, and resources created outside the central IT team.
- Configure: Maintain an inventory of accounts, subscriptions, projects, and deployed resources.
- Assign: Record each workload’s owner, business purpose, environment, and data sensitivity.
- Separate: Establish boundaries between production, development, and testing, with only necessary access between them.
Verify: Review the inventory for unowned resources and missing classifications. Using an approved test identity, confirm that development permissions do not allow production administration.
For example, a development reporting tool should not inherit unrestricted access to a production customer database simply because both belong to the same company.
2. Secure Human and Application Access
Identity is a major control point in the cloud. Strong network boundaries cannot compensate for an overprivileged account that an attacker can use legitimately.
- Configure: Require multifactor authentication, preferably phishing-resistant methods where supported.
- Limit: Grant only necessary permissions and separate privileged administration from everyday work.
- Replace: Prefer workload identities and temporary credentials over embedded, long-lived application keys.
- Remove: Disable unused identities and revoke unnecessary permissions.
Verify: Test whether an ordinary user can perform an administrative action; the attempt should fail. Inspect how applications obtain credentials, including deployment pipelines and scheduled jobs. Review inactive accounts and privileged assignments.
AWS example: AWS IAM guidance recommends federation and temporary credentials for people, IAM roles for workloads, and phishing-resistant MFA where possible. Other platforms have their own identity mechanisms; apply the principle, not an assumed equivalent setting.
3. Limit Public Exposure
Public access should reflect an approved business requirement, not a convenient default. A public website may need internet access; its database and administrative interface usually need different restrictions.
- Configure: Keep storage and internal services private unless public access is explicitly approved.
- Restrict: Limit administrative and database connectivity to authorized users, systems, and access paths.
- Document: Give firewall exceptions an owner, justification, and review date.
Verify: Test reachability from outside the trusted environment using authorized testing methods. Check both network connectivity and application authorization. A reachable login page and publicly readable data are different findings.
Amazon S3 example: Review applicable S3 Block Public Access controls, not just an individual bucket policy. Centralized restrictions can help prevent unintended exposure as new resources are created.
4. Protect Data and Secrets
Encryption matters, but so does controlling who can decrypt information or retrieve the credentials protecting it.
- Configure: Verify encryption in transit and at rest for relevant services and data flows.
- Restrict: Limit access to encryption keys and secret stores.
- Separate: Keep passwords, tokens, and private keys out of application code and deployment templates.
- Maintain: Inventory secrets, monitor their use, and establish procedures for updating and revoking them.
Verify: Inspect deployed settings rather than relying only on templates. Confirm that an unauthorized identity cannot retrieve a secret. Check repositories and pipeline output for accidental exposure without copying sensitive values into tickets.
Microsoft’s operational security practices reinforce these principles: protect secrets, enforce least privilege, and encrypt data in transit and at rest.
5. Configure Logging—and Test the Response
A logging service being enabled does not prove that the right events are collected or that anyone will act on them.
- Collect: Capture administrative activity and security-relevant application and data-access events.
- Protect: Centralize logs and restrict modification or deletion.
- Retain: Set retention around business, investigation, and applicable legal requirements.
- Route: Assign actionable alerts to a named responder with an escalation path.
Verify: Generate a harmless event, such as an approved test configuration change, and confirm it reaches the central log store. Separately test an alert condition and confirm the responsible team receives enough context to investigate.
CISA recommends centralized logging and alerts for high-risk events. Avoid collecting secrets or unnecessary sensitive data in the process.
AWS caution: CloudTrail’s default 90-day management-event history is not a permanent audit archive. Configure a trail for an ongoing record and explicitly select the event coverage required for your environment.
6. Prove Recovery Works
A successful backup job proves that a process completed. It does not prove that the business can resume operations.
- Define: Set acceptable downtime and data loss—your recovery time objective and recovery point objective.
- Protect: Restrict backup deletion and use immutable or otherwise protected copies where appropriate and supported.
- Restore: Recover representative workloads in an isolated test environment.
- Validate: Check application behavior, data integrity, permissions, and required dependencies.
Verify: Record the actual recovery time, the recovered data point, and functional test results. A restored database is insufficient if the application cannot authenticate or complete a business transaction.
CISA’s ransomware guidance emphasizes protected backups and recovery preparation. Translate that into a repeatable test, not just a written recovery plan.
7. Prevent Configuration Drift
Even a secure environment can deteriorate through emergency changes, manual adjustments, and new deployments.
- Standardize: Keep approved configuration baselines in version control, using infrastructure as code where practical.
- Review: Require appropriate review before infrastructure changes reach production.
- Detect: Use policy enforcement and continuous assessment to identify deviations.
- Remediate safely: Test automated corrections before allowing them to change production resources.
Verify: Introduce a safe deviation in nonproduction and confirm that detection works, ownership is clear, and remediation restores the intended configuration.
Microsoft’s cloud security benchmark guidance supports standardized baselines, infrastructure as code, and continuous configuration monitoring. Automation should reduce repeat mistakes without creating untested production changes.
Turn Findings Into an Actionable Work Plan
Keep a simple worksheet for every finding. Record:
- Resource and owner: What is affected, and who is accountable?
- Required setting: What should the configuration be?
- Evidence: Which test result or configuration record demonstrates effectiveness?
- Exception: Why is a deviation allowed, who approved it, and when does approval expire?
- Remediation deadline and last tested: When will the gap close, and how current is the evidence?
Prioritize exposed sensitive data and excessive privileged access first. Next, address logging and recovery gaps that could leave you unable to investigate or restore operations. Then expand baseline enforcement and automation.
This is a starting order, not an absolute rule. Active exploitation, critical business dependencies, or contractual obligations may change priorities.
Make Verification Part of Normal Operations
Repeat checks after significant changes and on a documented, risk-based schedule. Retest exceptions, confirm responders are still responsible, and update recovery tests as applications evolve.
Start with one critical workload. Assign its owner, work through all seven areas, and require evidence for every completed item. Then extend the process across the environment.
The goal is not a checklist that stays green. It is a cloud environment whose protections remain effective—and a team that can demonstrate why.