A Cloud Security Assessment: Scope, Timeline and What You Get at the End

A cloud security assessment is worth commissioning only if it answers three questions: what risks the environment carries today, which of them to fix first, and who does what by when. This article sets out what the review covers, what a finding record looks like, how severity is assigned, how the engagement runs and what documents arrive at the end.

When to schedule one

Cloud environments are rarely misdesigned on day one. They drift: a firewall rule opened during an incident and never closed, a service account granted broad permissions to hit a deadline, a staging environment built from an old image and never cleaned up. After a few quarters nobody holds the whole picture. Common triggers are finishing a migration or consolidating scattered accounts, a change of key operations staff, a customer questionnaire the team cannot answer with evidence, an incident that raises the question of where else the same root cause lives, and any plan to move sensitive data into a shared environment.

One distinction matters up front. This is not a penetration test and not an automated configuration scan. It is a structured review across the whole estate, performed with controlled read access, ending in an ordered list of work with named owners.

What the review covers

Scope is agreed in writing before access is granted, naming the accounts, projects, regions and workloads that are in and out. The nine areas below are the usual frame for AWS, Google Cloud or hybrid environments.

Identity and permissions

Compare what each principal was granted against what it actually does.

• Top-level administrative accounts: how many, who holds them, whether multi-factor authentication is enforced; IAM policies using wildcards; keys never rotated.
• When someone is disabled in the internal directory, do their cloud permissions disappear.

Network exposure and public surface

What an outsider can see, and how far that diverges from what the operations team believes is exposed.

• Databases and management ports such as SSH or RDP reachable from broad address ranges; object storage allowing anonymous read or write.
• DNS records pointing at deleted resources; non-production environments holding real data.

Encryption and key custody

Encryption at rest is now the default, so the harder question is who controls the keys.

• Provider-managed versus customer-managed keys; who may use a key and who may schedule its deletion.
• Rotation policy; encryption in transit between internal components; where TLS private keys live.

Logging and detection coverage

Logs matter only if they exist when needed and suffice to reconstruct a sequence of events.

• Control-plane, data access, DNS and flow logs: which exist, how long they are kept, and whether the destination is beyond the reach of a compromised administrative account.
• A reconstruction test on a past administrative action: who did it, when, and from where.

Backup and restore verification

The review looks for restore evidence rather than backup schedules.

• Backed-up systems compared with critical systems; whether copies live in a separate account or region, whether any is immutable, and who can delete them.
• When a complete system was last restored successfully and how long it took.

Patching and vulnerability posture

The process matters more than a vulnerability list at a point in time.

• What share of servers and containers is covered by scanning; who builds the base machine and container images and whether they are scanned before release.
• Elapsed time from a critical patch being available to it running in production; components past end of support; application dependencies.

Secrets handling

Reviewed across the lifecycle: created where, travelling where, readable by whom, revoked how.

• Full source history rather than the current branch; environment variables in CI; configuration baked into container images.
• Whether a central secrets store exists, what share of applications uses it, and how long a full rotation takes.

Third-party and CI/CD access

The shortest path into production usually runs through the delivery toolchain and through vendors granted access some time ago.

• An inventory of external integrations holding permissions, and whether each is narrowly scoped with a caller verification condition.
• Who can change pipelines and whether a second approver is required; what self-hosted runners run as; whether contractor access is time-bound.

Configuration drift

Whether the running environment matches the one described in code, and how long a divergence survives unnoticed.

• The share of resources created through infrastructure as code; how many manual production changes happened last quarter.
• Whether drift detection exists; organisation-level guardrails; resources carrying no owner tag.

What a finding record looks like

A finding is usable only if the recipient can verify and fix it without calling the reviewer back. The minimum structure: a stable finding ID for tracking across retests; a title describing the observed condition; the affected resources; evidence with a collection timestamp; the specific impact; the conditions required to exploit it; a severity with the reasoning stated so it can be argued; a durable recommendation plus an interim mitigation; a verification step; and owner and due date fields left blank until handover.

An illustrative record follows; the resources and situation are invented:

• ID: IAM-04
• Title: The programmatic key used by the release pipeline service account has never been rotated and carries write access across all production object storage.
• Evidence: key listing with creation and last-used timestamps; the text of the attached policy.
• Impact and exploitation conditions: the key value alone is enough, with no particular network position required, and the holder can overwrite or delete data in every production bucket.
• Severity: Critical, because permissions are broad, unrestricted by source, and production data is in scope.
• Recommendation: replace the long-lived key with federated identity issuing short-lived credentials; narrow the policy; add a source condition.
• Verification: the service account lists no long-lived keys; a test write to an out-of-scope bucket is denied.

How severity is assigned

Severity should rest on three factors that can be argued in the open: how easily the condition can be exploited, how far the consequences reach, and how sensitive the data involved is. It is assigned to the situation in this environment, not to the class of issue: a publicly readable bucket of marketing material and a publicly readable bucket of database exports do not belong at the same level.

Level	Meaning	Typical finding	Expected response
Critical	Leads to unauthorised data or administrative access with no special preconditions	Administrative credentials in source control	Fix immediately
High	Requires one further condition but the blast radius stays wide	Management port exposed with weak authentication	Next release cycle
Medium	Materially increases the damage when another incident occurs	Missing data access logs	Current quarter
Low	Deviates from good practice with limited direct impact	Missing owner tags	Routine cleanup

The response column is a starting point for negotiation, not a rule. At handover each rating is reviewed with the operations team; where a compensating control already exists, the level can be lowered and the reason recorded in the finding itself.

From findings to a remediation plan

A report of several hundred lines with no plan attached will sit unread. The transition should look like this:

1. A technical review with the operations team to remove false positives and add missing context.
2. Grouping findings that share a root cause; thirty records about excessive permissions are usually one problem with how permissions are granted.
3. Assigning owners by name, not by department.
4. Splitting work into three waves: configuration changes that can ship now, items for the next release, and architectural changes needing their own project.
5. Flagging anything that needs a maintenance window with a rollback path, then agreeing a verification step per item and the retest date.

Timeline

Duration depends on the number of accounts and environments and on how quickly read access arrives. The engagement moves through preparation, where scope, confidentiality terms and access are settled; collection of configuration, policy and logs plus short interviews with the operations, development and infrastructure teams; analysis, where every suspected issue is re-verified before it becomes a finding; an interim review of draft high-severity items; handover, where severities, owners and the phased plan are agreed; and a retest after remediation. Anything critical is reported the moment it is found.

What you get at the end

The output should serve three audiences: leadership, the engineers doing the work, and whoever tracks progress.

• A short executive summary without jargon, stating the main risks in business terms.
• The full technical report in the structure above, with an evidence appendix transferred as agreed, since the appendix is itself sensitive material.
• A tracker as a spreadsheet or tickets, plus current-state diagrams of accounts, networks and main data flows.
• The phased remediation plan, plus a list of open questions that fell outside the agreed scope.

Limits worth stating

An assessment is a snapshot, bounded by the agreed scope and by the data the organisation grants access to. It does not prove the environment has never been compromised, it does not replace penetration testing or code review, and it is not a certification audit.

Where obligations around data, storage location or retention arise, record them in the report as questions for legal counsel, accompanied by the technical facts they need to form a view. Engineering describes the current state; legal conclusions belong to qualified professionals.

How HiTechCloud can help

HiTechCloud is an AWS partner and a Google Premier Partner, with in-country infrastructure and an engineering team based in Vietnam. Within this topic we can take on:

• Reviewing the current state across the nine areas above on AWS, Google Cloud or hybrid environments.
• Delivering a report using the finding structure described here, with evidence and a verification step for each item.
• Working with your operations team on the phased remediation plan and implementing the technical items.
• Retesting after remediation and setting up the tracking that keeps the environment from drifting back.

If you need a picture of your environment based on data rather than recollection, get in touch and we can scope the review to your estate.