Cloud Configuration Audit Checklist: Logging, Encryption, Backups, and Least Privilege

Overview

This checklist is best used as an operational baseline, not as a one-time project artifact. Most cloud incidents and audit findings do not come from exotic failures. They come from simple drift: a log source that stopped forwarding, a storage bucket created without default encryption, a backup job that silently failed, or a role that accumulated more permissions than anyone intended.

If you manage infrastructure in AWS, Azure, GCP, or a mixed environment, the exact service names will differ, but the review logic stays consistent. The goal is to answer five recurring questions:

• Are security-relevant events being logged and retained?
• Is sensitive data encrypted at rest and in transit, with key management that matches risk?
• Can critical systems and data be restored from reliable backups?
• Do identities, roles, and service accounts follow least privilege?
• Can you show evidence of all of the above during an internal review or external audit?

That last point matters. A good cloud security configuration checklist should not only tell you what to inspect. It should also tell you what proof to save. Screenshots, exported settings, policy files, ticket links, backup reports, and exception approvals are often what separate a mature control from an informal good intention.

For teams building a broader governance program, this technical review also connects naturally with policy and risk documentation. Your operating standards should align with your documented controls, and your exceptions should feed your risk register. If you need to tighten those surrounding processes, see the Information Security Policy Checklist: Core Policies Every Growing SaaS Company Needs and the Risk Register Template Guide: How to Score, Prioritize, and Review Cyber Risks.

What to track

Use this section as the working core of your cloud configuration audit checklist. For each control area, track both the configuration itself and the evidence that proves it is working.

1. Logging

Your logging review should confirm coverage, integrity, retention, and usefulness. It is not enough to have logs enabled somewhere in the environment. You need to know whether the right events are captured and whether the records are available when needed.

Track these logging checks:

• Administrative activity logging is enabled for cloud accounts, subscriptions, and projects.
• Authentication events are captured, including failed sign-ins, MFA events, and privileged access use where available.
• Network and perimeter logs exist for firewalls, load balancers, gateways, and security groups or equivalent controls.
• Storage access logging is enabled for sensitive buckets, blobs, and file services where supported and justified.
• Database and application audit logs are enabled for systems that handle sensitive or regulated data.
• Security tool alerts flow into a central monitoring or ticketing process.
• Retention periods are defined and match business, legal, and audit needs.
• Time synchronization is consistent enough that investigations can reconstruct activity across systems.
• Access to logs is restricted and monitored.
• Log deletion or modification protections are in place where the platform supports them.

Evidence to collect:

• Exported logging configuration or policy settings
• Retention settings by log source
• Sample events showing successful collection
• Alert routing screenshots or workflow records
• Exception records for systems not currently covered

Common issues: teams often discover that logs are enabled for the control plane but not for high-risk data services, or that retention exists in the default tool but no one has verified how long logs are actually searchable.

2. Encryption

Encryption reviews should cover both technical settings and key management practices. A checkbox that says encryption is enabled is a weak conclusion if nobody knows which key was used, who can access it, or whether older systems are excluded.

Track these encryption checks:

• Default encryption at rest is enabled for object storage, block storage, managed databases, and snapshots.
• TLS is enforced for administrative access, APIs, and customer-facing endpoints.
• Older protocols and weak ciphers are disabled according to your standards.
• Secrets are stored in approved secret management tools rather than configuration files or code repositories.
• Key rotation expectations are defined for customer-managed keys where applicable.
• Access to encryption keys is limited to approved roles and logged.
• Data exports, backups, and replication targets remain encrypted.
• Certificate inventory exists, with expiration monitoring and renewal ownership assigned.

Evidence to collect:

• Storage and database encryption settings
• TLS and certificate configuration records
• Key policy or access policy exports
• Secrets management screenshots or configuration evidence
• Exception approvals for legacy systems

Common issues: snapshot encryption can lag behind primary storage settings, and teams may encrypt production databases while forgetting test copies, exports, and downstream analytics stores.

3. Backups and recoverability

Backup reviews should focus on restoration confidence, not just job completion. Many environments technically have backups while lacking proof that a meaningful recovery is possible within the required timeframe.

Track these backup checks:

• Critical systems and data sets have defined backup coverage.
• Backup schedules match recovery objectives and business impact.
• Backup success and failure alerts are monitored.
• Retention periods are documented and consistently applied.
• Backups are stored separately enough to reduce the impact of deletion, ransomware, or account compromise.
• Backup repositories are access-controlled and protected from casual modification.
• Restores are tested on a defined cadence.
• Recovery procedures are documented, current, and assigned to owners.
• Dependencies such as keys, configuration files, images, and infrastructure definitions are included in recovery planning.

Evidence to collect:

• Backup policy or schedule documentation
• Recent job reports and failure logs
• Restore test records with dates, scope, and outcomes
• Recovery runbooks
• Exception records for workloads not yet covered

Common issues: restore tests often validate a single file or one development system, while critical production dependencies remain untested. That gap matters in audits and in incidents.

4. Least privilege

Least privilege is usually where cloud environments drift the fastest. New projects launch quickly, vendors request temporary access, engineers add service permissions to solve delivery problems, and old roles stay in place because no one is fully sure what will break.

Track these least privilege checks:

• Administrative roles are limited to named users or tightly controlled groups.
• Privileged access is reviewed on a recurring schedule.
• Shared accounts are eliminated or tightly controlled if they cannot be removed.
• Service accounts and machine identities have scoped permissions and clear owners.
• Unused roles, stale users, and dormant keys are identified and removed.
• Break-glass or emergency access exists, is protected, and is reviewed after use.
• Role assumptions, escalations, and privileged sessions are logged.
• Temporary access has expiration dates.
• Production access is more restricted than development and test access.
• External vendors have only the access required for the service they provide.

Evidence to collect:

• Role and group membership exports
• Access review records
• Service account inventories
• Privileged access procedures
• Approval tickets for elevated access

For a deeper operational review of user and privileged access, pair this article with the Access Review Checklist: User Access, Privileged Access, and Joiner-Mover-Leaver Controls.

5. Cross-cutting items to track every cycle

In addition to the four core domains, track a small set of meta-variables that make recurring reviews more useful:

• Control owner for each workload or platform area
• Date last reviewed
• Evidence location
• Open exceptions
• Related risk register entry
• Remediation target date
• Framework mappings such as SOC 2, ISO 27001, NIST, PCI DSS, or HIPAA if relevant

If your team is trying to reduce duplicate audit preparation, this is where evidence structure matters. A single logging or backup review can often support multiple frameworks when documented consistently. The Control Mapping Guide: How to Reuse Evidence Across SOC 2, ISO 27001, HIPAA, and PCI DSS is a useful companion for that work.

Cadence and checkpoints

The right cadence depends on environment size, change rate, customer requirements, and regulatory obligations. In practice, most teams benefit from mixing lightweight monthly checks with deeper quarterly reviews.

Monthly checkpoints should be short and operational. Focus on obvious drift and control failures:

• New cloud accounts, projects, subscriptions, or environments created since the last review
• Logging failures, retention changes, or missing high-value sources
• Backup job failures and overdue restore tests
• New admin roles, stale keys, or emergency access activity
• Certificate expirations and encryption exceptions

Quarterly checkpoints should be broader and evidence-driven:

• Review complete control coverage across key systems
• Reconcile asset inventory against logging, backup, and encryption coverage
• Validate that exceptions are still justified and approved
• Test one or more restores for critical systems
• Review role design for over-permissioning and privilege creep
• Update screenshots, exports, and evidence packages for audit readiness

Before an audit or customer review, avoid rebuilding everything from scratch. Instead, confirm that your latest monthly and quarterly records are complete, current, and easy to navigate. This is often the difference between continuous compliance monitoring and a reactive scramble.

A practical way to run the process is to assign one owner per control family, one reviewer for quality, and one central location for evidence. Many teams fail here because evidence is spread across chat threads, personal drives, and ticket comments. Keep a stable folder or system of record with a naming convention such as:

• Control area
• Environment
• Review date
• Reviewer
• Status
• Exception reference

If your broader documentation set is still maturing, align this review cycle with your formal policy review calendar. The Policy Review Schedule: How Often to Update Security and Privacy Policies can help synchronize technical checks with governance expectations.

How to interpret changes

A recurring checklist becomes valuable when it helps you distinguish normal operational change from risk-significant drift. Not every change is a problem. The point is to understand what changed, why it changed, and whether the control posture improved, weakened, or simply shifted.

Treat these changes as higher priority:

• A decrease in log source coverage for critical systems
• Shorter retention without clear approval
• Unencrypted new storage locations or snapshots
• Backup failures affecting production systems
• Restore tests that fail or are repeatedly deferred
• Growth in privileged identities without matching business justification
• Service accounts with broad wildcard permissions
• Long-lived temporary access that never expires

Treat these changes as review items rather than automatic findings:

• New services introduced during a planned architecture change
• Temporary exceptions tied to migration work
• Modified retention because of documented legal or cost considerations
• Key management design changes with approved architecture review

When a change appears, document it in plain language:

1. What changed?
2. Which systems or data are affected?
3. Was the change expected and approved?
4. Does it create a gap against policy, baseline, or framework requirement?
5. Is remediation needed, or is this an accepted exception?

This step is often where a cloud audit controls review either becomes useful or remains superficial. An exported configuration file proves little if nobody interprets the operational impact. Good reviewers connect the setting to business risk. For example, a failed backup job on a low-value test system may be noted and deferred; the same failure on a production database containing customer records should likely trigger immediate remediation and possible incident review.

Framework context can also shape interpretation. If you process payment data, backup, logging, and access controls may need to support PCI DSS requirements. If you handle health information, similar checks may tie into a HIPAA compliance checklist. If you support regulated financial entities, resilience expectations may be higher. Relevant companions include the PCI DSS 4.0 Requirements Checklist, the HIPAA Compliance Checklist for Cloud Hosting, SaaS, and IT Service Providers, the DORA Compliance Checklist for ICT Providers and Financial Services Vendors, and the NIS2 Compliance Checklist: What IT and Security Teams Need to Implement Now.

When to revisit

Revisit this checklist on a monthly or quarterly cadence, but do not wait for the calendar if your environment changes in ways that affect control coverage. The most useful trigger for an extra review is not time alone. It is a material shift in assets, identities, data flows, or recovery assumptions.

Run an out-of-cycle review when:

• You launch a new cloud account, region, subscription, or production environment
• You adopt a new managed service that stores, processes, or transmits sensitive data
• You change your identity provider, access model, or privileged access process
• You rework network architecture, logging pipelines, or SIEM ingestion
• You change backup tooling or recovery objectives
• You complete a migration that may have introduced new storage locations, snapshots, or service accounts
• You onboard a high-impact vendor with cloud access
• You experience an incident, near miss, or failed audit test
• You enter a new compliance scope such as SOC 2, ISO 27001, PCI DSS, HIPAA, DORA, or NIS2

To make the review practical, use this five-step routine:

1. Export the current inventory. Start with accounts, subscriptions, projects, storage locations, databases, backup jobs, identities, and privileged roles.
2. Compare against the previous cycle. Focus on new assets, removed assets, changed settings, and expired exceptions.
3. Check the four baseline areas. Confirm logging, encryption, backups, and least privilege for each in-scope system.
4. Record evidence and decisions. Save settings, note findings, assign owners, and open remediation tickets where needed.
5. Update related governance records. Refresh your risk register, policy exceptions, and control mapping notes so the technical review feeds the broader compliance program.

This is also a good point to review any public-facing privacy and data handling statements if your cloud architecture changes the way personal data is stored or processed. For that adjacent work, see the Privacy Notice Compliance Checklist: Website, Product, and Employee Privacy Disclosures.

A sound cloud security configuration checklist is not meant to replace deeper engineering reviews or formal audits. Its purpose is simpler and more durable: give your team a repeatable way to verify baseline controls, notice drift early, and preserve evidence before someone urgently asks for it. If you revisit it consistently, the checklist becomes less of a document and more of an operating habit.