A practical cloud misconfiguration checklist mapped to ISO 27017 controls, helping SaaS teams fix audit findings and secure AWS and Azure environments.
ISO 27017 is useful because it forces clarity around shared responsibility and cloud control expectations without turning cloud security into an endless tool discussion. This checklist is designed to help teams verify that cloud controls are not only configured, but also operating and provable.
For every checklist item, use the same three-part test. If the answer fails any part, treat it as not ready.
This is usually the number one audit focus because weak cloud identity controls create the fastest path to major incidents.
| Control | What auditors see most | What to check | Evidence |
|---|---|---|---|
| MFA enforced for privileged roles | MFA is enabled for some admins, not all. | Require MFA for cloud console admins, CI/CD admins, key vault admins, and identity admins. Control and monitor break-glass accounts. | MFA enforcement export and admin role membership with review sign-off. |
| Least privilege for cloud roles | Too many Global Admin or Owner accounts. | Use role-based access by function, approval for elevated access, and quarterly privileged access reviews. | Role assignment export, access review record, and stale admin removal tickets. |
| No shared admin accounts | Shared admin@company accounts or poorly governed root access. | Use named admin accounts, lock down root accounts, and document any unavoidable shared access through vault plus approval. | Root account control summary and any shared-account exception with expiry. |
This is where the classic open-port audit findings come from, especially when teams leave troubleshooting rules behind for months.
Public storage and overly shareable files are among the fastest ways to lose buyer trust. These findings are often simple but expensive.
| Control | What to verify | Evidence |
|---|---|---|
| Public object storage is intentionally controlled | Enforce public access block where possible, tie storage to identities or roles, eliminate anonymous access to sensitive storage, and review settings periodically. | Public access block settings, storage policy screenshots, and periodic review records. |
| File sharing links are governed | Restrict anonymous sharing for confidential data, require specific-person links, and use expiry on external sharing. | Sharing configuration export and quarterly external sharing review record. |
Logs existing is not the same as the control operating. This is one of the most common evidence traps in cloud audits.
These are quiet gaps that often sit unnoticed until an audit or incident forces attention.
| Control | What to verify | Evidence |
|---|---|---|
| Encryption at rest | Enable encryption for databases, storage, and backups in scope. Document encryption requirements in standards. | Service configuration proof and policy reference. |
| Key management discipline | Store keys in KMS, Key Vault, or HSM where appropriate, limit key-admin roles, and define rotation plus break-glass procedures. | Key vault role export, access review, and rotation records where implemented. |
| Secrets are not in code or pipelines | Use a secrets manager, enable secret scanning, rotate high-risk tokens, and apply least privilege to CI/CD variables. | Secret scanning settings and a remediation ticket example. |
This is where auditors ask the painful question: who approved this change, and how do you know it stayed consistent afterwards?
Shared responsibility becomes real here. Poorly governed vendor access is one of the most common audit and incident triggers in cloud environments.
| Control | What to verify | Evidence |
|---|---|---|
| Vendor access is time-bound and approved | Approval required, expiry date required, permissions scoped, session logging used where feasible, and quarterly access review performed. | Vendor approval records, review sign-offs, and sanitized session logs where available. |
| Subprocessors are documented and reviewed | Critical vendors are tiered, annual reviews occur, renewal dates are tracked, and missing assurance becomes an exception with expiry. | Vendor register export, review notes, and exception records. |
Auditors do not just want to hear that backups exist. They want restore proof with validation.
If you want audits to move faster, build one quarterly cloud evidence pack containing the proof auditors ask for most often.
Fix those first and you will usually remove a huge amount of audit pain.
Cloud audit findings often come from small defaults that no one revisited, not from dramatic design failures. That is why the best cloud security programs are not one-time configuration projects. They are operating systems with review cadence, evidence, and ownership.
When the controls in this checklist are configured, operating, and provable, cloud audits become faster and much easier to control.