Cloud Compliance Gap Assessment: A Repeatable Checklist for SOC 2, ISO 27001, and NIST

Overview

A cloud compliance checklist is most useful when it connects three things: the control objective, the way your organization implements it, and the evidence that demonstrates operation. Listing policies or cloud services alone does not show that a control is designed appropriately or working consistently.

Use this assessment as an internal screening tool, not as a certification or legal conclusion. SOC 2, ISO 27001, and NIST publications have different structures, terminology, and assessment expectations. A single operational control may support several framework outcomes, but the mapping should be validated against the specific scope, criteria, contract, or regulation that applies to your organization.

Begin by defining the assessment boundary:

• Identify products, environments, accounts, regions, and data stores in scope.
• Record critical business processes and dependencies, including cloud providers and important vendors.
• List applicable customer commitments, internal policies, and regulatory obligations.
• Set an evidence period, such as the previous quarter or the period leading to an audit.
• Assign an owner for each control and a separate reviewer where practical.

For a broader process, use the compliance gap assessment checklist alongside this cloud-focused review.

Checklist by scenario

1. Governance, scope, and risk

• Is there an approved information security program with defined responsibilities?
• Are cloud assets, services, data classifications, and system owners recorded?
• Has the organization documented its risk assessment method and risk acceptance process?
• Are identified risks tracked with owners, due dates, treatment decisions, and review status?
• Do policies address acceptable use, access control, incident response, change management, and business continuity?

These activities commonly support governance and risk themes across SOC 2, ISO 27001, and NIST-oriented programs. Evidence may include a system inventory, information security policy, risk methodology, risk register, committee minutes, and approved risk exceptions. A risk register template guide can help standardize scoring and follow-up.

2. Identity and access management

• Is access granted through a documented request and approval process?
• Are privileged accounts separated from ordinary user accounts where appropriate?
• Is strong authentication required for administrative and other sensitive access?
• Are permissions based on job responsibilities and reviewed on a defined schedule?
• Are joiner, mover, and leaver events connected to timely access changes?
• Are service accounts documented, restricted, monitored, and periodically reviewed?

Useful evidence includes access listings, approval tickets, authentication settings, privileged-role reports, terminated-user samples, and review sign-offs. Check the access review checklist when testing this area.

3. Cloud configuration and infrastructure security

• Are baseline configurations defined for accounts, networks, storage, operating systems, and managed services?
• Are public exposure, unrestricted firewall rules, unused ports, and risky permissions detected and reviewed?
• Is encryption configured for data in transit and at rest according to documented requirements?
• Are secrets stored in an approved secrets-management mechanism rather than source code or tickets?
• Are infrastructure changes approved, tested, and traceable to a person or automation identity?
• Are backups protected, tested, and aligned with recovery objectives?

Evidence can include configuration reports, infrastructure-as-code reviews, vulnerability findings, backup logs, restoration test records, and change tickets. For a deeper technical review, use the cloud configuration audit checklist.

4. Logging, monitoring, and incident response

• Are security-relevant events collected from identity, cloud control planes, endpoints, applications, and networks as appropriate?
• Are logs protected from unauthorized alteration and retained according to documented requirements?
• Do alerts have owners, severity definitions, escalation paths, and response targets?
• Is there a documented process for triaging, containing, investigating, and closing incidents?
• Are exercises or reviews used to test incident procedures and capture improvements?

Evidence may include log-source inventories, alert rules, sample investigations, incident records, tabletop notes, and post-incident action items. Continuous compliance monitoring is more useful when it measures both technical status and operational response; see continuous compliance monitoring metrics.

5. Secure development and change management

• Are code changes reviewed before release, with emergency changes documented afterward?
• Are development, test, and production environments separated to an appropriate degree?
• Are dependencies, images, and application vulnerabilities scanned and triaged?
• Are security requirements included in design and release workflows?
• Are deployment permissions limited and pipeline activity logged?

Evidence includes pull requests, pipeline records, vulnerability tickets, release approvals, environment permissions, and exception records.

6. Resilience, privacy, and third-party dependencies

• Are recovery priorities, backup responsibilities, and continuity procedures documented?
• Are cloud providers and critical vendors assessed according to risk?
• Do contracts address security responsibilities, incident communication, data handling, and service obligations where relevant?
• Are personal data flows, retention rules, and deletion processes documented?
• Is a privacy impact assessment or similar review completed when processing creates material privacy risk?

Security compliance and privacy compliance overlap, but they are not interchangeable. Maintain separate evidence for privacy decisions, data inventories, processing purposes, and individual-rights workflows. For vendor-specific work, pair this review with a documented vendor risk assessment and the applicable contract requirements.

Scoring the cloud compliance gap

Use a simple five-point scale for each checklist item:

• 0 — Not addressed: No control, owner, or reliable evidence exists.
• 1 — Planned: The need is recognized, but implementation has not started or is not repeatable.
• 2 — Partially implemented: The control exists in some systems, teams, or situations.
• 3 — Implemented: The control is defined, assigned, and operating within the stated scope.
• 4 — Demonstrated: The control is operating consistently, supported by recent evidence, and reviewed for effectiveness.

Calculate a category score by dividing points earned by the maximum possible points. Do not treat the result as a compliance percentage or certification probability. Use it to compare categories, identify concentration of risk, and decide where evidence collection or remediation should begin.

Prioritize gaps using impact, likelihood, scope, and effort. A control affecting production administrator access, sensitive data, or incident detection usually deserves earlier attention than a low-impact documentation improvement. Record the rationale in the risk register rather than relying on an unexplained numerical score.

What to double-check

• Scope accuracy: Confirm that inventories include temporary accounts, secondary cloud regions, disaster-recovery environments, and managed services.
• Shared responsibility: Separate what the cloud provider operates from what your organization must configure, monitor, or document.
• Evidence quality: Prefer dated, attributable records that show the control operated. A policy without operating evidence may demonstrate intent but not execution.
• Exceptions: Check that exceptions have an owner, business justification, expiry or review date, compensating measures, and approval.
• Control language: Avoid claiming that one checklist item satisfies an entire framework requirement. Validate the detailed criteria and audit scope.
• Data handling: Confirm that logs, backups, support tools, and test environments are included in data-flow and retention decisions.

Common mistakes

A frequent mistake is treating a cloud provider's assurance report as evidence that every customer control is complete. Provider documentation can support certain inherited controls, but your configurations, identities, applications, processes, and customer commitments still require separate review.

Another mistake is collecting screenshots without context. Evidence should identify the system, time period, responsible owner, and control being demonstrated. Excess evidence can also create review overhead; select representative samples and document the sampling method.

Teams also lose audit readiness when remediation is disconnected from risk management. A failed scan, overdue access review, or missing backup test should become a tracked issue with a decision and due date. Finally, avoid mapping controls once and never revisiting them. Framework versions, architecture, vendors, regulations, and business processes can change the meaning of the original assessment.

For related policy work, review the information security policy checklist and policy review schedule.

When to revisit

Reassess the cloud compliance gap at least before major planning or audit-readiness cycles, and sooner when the underlying environment changes. Trigger a focused review after a new cloud account, region, application, data type, identity platform, or critical vendor is introduced. Also reassess after a security incident, significant architecture change, material control failure, or change to customer or regulatory obligations.

A practical cadence is to perform lightweight monitoring continuously, review high-risk controls monthly or quarterly, and complete a broader assessment on a planned cycle. At each review:

1. Update the system, data, vendor, and control inventories.
2. Reconfirm framework scope and applicable commitments.
3. Refresh evidence requests and test a representative sample.
4. Re-score open gaps and close items only when operating evidence exists.
5. Move unresolved risks into the risk register with owners and review dates.
6. Record changes so the next assessment starts with a reliable baseline.

Use this checklist before seasonal planning cycles and whenever workflows or tools change. That habit turns a one-time cloud compliance gap assessment into a practical control-management routine and gives security, engineering, privacy, and audit teams a shared view of what is working, what is missing, and what should happen next.