A cloud security assessment is more than a configuration scan. A practical checklist helps organisations review access, compliance requirements, policy enforcement, network exposure, logging and security monitoring. The findings provide a clearer view of security gaps and the actions needed to strengthen cloud governance and resilience.
Individual settings matter, but they must work together across identities, services and environments. This checklist explains the main areas to review, what evidence to collect and how to turn assessment findings into practical security decisions.
Start by creating an inventory of human and service identities across each cloud environment. Apply role-based access control so permissions reflect users’ responsibilities, then enforce least privilege for users, roles and services. Privileged access should use multi-factor authentication, time limits and approval controls where appropriate.
The assessment should review:
Disable or amend accounts that no longer have a business purpose. For service identities, confirm that permissions are limited to the tasks they need to perform. Check that secrets are stored in approved services rather than embedded in scripts, application code or infrastructure configuration.
Review access against current responsibilities rather than relying only on the original approval. A person’s role may have changed while their cloud permissions remained unchanged. Record exceptions with an owner, business reason and review date so that elevated access does not become permanent by default.
Cloud security assessments should connect technical controls with the obligations that apply to the organisation’s data and services. GDPR, PCI DSS and ISO 27001 address different requirements, so they should not be treated as interchangeable.
Start by mapping each cloud workload to its data classification, business purpose and applicable requirements. For example, identify systems that store or process payment card data before assessing the relevant PCI DSS controls. This creates a traceable link between business activity, compliance requirements and cloud configuration.
For each requirement, record:
Cloud provider assurance reports can support this review, but they do not replace oversight of the organisation’s own configuration, access decisions and operating procedures. Document which responsibilities remain with the provider and which sit with the organisation.
Policy as code represents selected security requirements as machine-readable rules that can be tested against cloud infrastructure. A rule might identify a storage resource with public access or a deployment missing an approved security setting. Integrating these checks into infrastructure-as-code workflows can help teams identify misconfigurations before they reach production.
Policy as code does not remove the need for governance. Rules must have an owner, reflect approved requirements and be reviewed when services, architectures or compliance scopes change. Keep test results as evidence and record how exceptions are approved.
Review how cloud resources communicate with one another and with external networks. Inspect firewalls, security groups, virtual networks, routes and public endpoints. Confirm that inbound and outbound rules match documented business requirements.
A database containing sensitive information, for example, should not accept direct connections from the public internet unless there is a clearly justified and controlled requirement. Trace permitted connections between public-facing applications, internal services and sensitive data stores.
The assessment should also consider:
Network controls should support a broader zero-trust approach. Access should be assessed using identity, device and context rather than assuming that internal traffic is safe. Segmentation can limit movement between workloads if an account or system is compromised.
Review workload security alongside network controls. Scan virtual machines, containers and applications for known vulnerabilities, then prioritise findings according to exposure, exploitability, data sensitivity and business impact. A vulnerability in an internet-facing workload handling sensitive information may require earlier action than an isolated issue with limited operational impact.
Bring audit and security events from cloud accounts, networks, workloads and applications into a central analysis point. Provider-specific services such as AWS CloudTrail, Azure Monitor and Google Cloud Audit Logs can provide important records, while centralisation helps analysts correlate activity across services.
Confirm that relevant sources are connected, timestamps are consistent and failed ingestion generates an alert. Missing records can create gaps in investigations and reduce the evidence available for governance or regulatory reviews.
Define what the organisation needs to monitor. Depending on the environment, this may include:
For example, a new administrator role followed by unusual API calls and a storage policy change may require investigation as a related sequence rather than as three separate events.
Protect log integrity by restricting who can alter or delete records. Separate logging administration from routine cloud operations where practical, then set retention periods according to investigation needs, internal policy and applicable requirements.
Monitoring should produce actionable alerts. Each alert should have a severity, owner and response procedure. Test coverage by generating controlled events, such as a denied access attempt, and confirming that the activity reaches the intended analysis workflow.
An assessment is valuable when its findings lead to decisions and measurable remediation. Record the affected asset, business function, exposure, evidence, remediation owner and target date for each significant finding.
Prioritise findings according to business impact and exposure rather than technical severity alone. Agree how residual risk can be accepted, who has authority to approve it and when the decision must be reviewed.
Retest relevant controls after remediation. A closed finding should have evidence showing that the configuration, access path or monitoring control now works as intended. Review the assessment after major changes to architecture, ownership, data processing or security controls.
The frequency of assessment should reflect the sensitivity and rate of change in the environment. Organisations handling sensitive data or making frequent cloud changes may need more regular reviews than environments with limited change activity.
CyberOne’s Managed Extended Detection and Response service can support organisations that need ongoing threat detection and response alongside cloud security assessment activity. Using Microsoft Security capabilities such as Microsoft Sentinel and Microsoft Defender, the service can help teams analyse alerts, investigate activity and coordinate response across connected environments.
Consider a managed service when cloud activity generates more alerts than internal teams can investigate effectively, or when assessment findings need to connect to day-to-day security operations. The appropriate approach will depend on the organisation’s cloud architecture, existing controls, internal capacity and security priorities.