Why a cloud infrastructure assessment comes first
Most DevOps and cloud problems are not caused by a lack of tools. They come from an environment that grew organically: accounts created for one project and reused for another, pipelines copied between repositories, dashboards nobody trusts, and a handful of people who know where the sharp edges are. Proposing a target architecture before understanding that history is how consultancies produce confident but wrong plans.
The Assess phase exists to replace assumptions with evidence. We look at what you actually run, how changes reach production, how failures are noticed, and how much of the setup is reproducible. The output is a written findings report that your CTO, head of platform and engineers can read, challenge and act on. It is the first of four phases described on the How we work page.
What we look at
We scope the audit to your situation, but most assessments cover the same areas across AWS, Azure and Kubernetes.
Cloud accounts and networking
Account and subscription structure, VPC or VNet layout, public exposure, DNS, load balancers and egress paths. We look for flat networks, forgotten public endpoints and environments that share blast radius.
Identity and access
IAM roles, Azure RBAC assignments, long-lived credentials, break-glass access and how engineers authenticate. Over-broad permissions and unrotated keys are among the most common findings.
Infrastructure as code
What share of the estate is defined in Terraform or similar, how state is stored and locked, how modules are versioned, and how much drift exists between code and reality. If your platform began as console work, our guide on moving from ClickOps to Terraform on AWS describes the usual path.
CI/CD pipelines
Build and deploy flow, test coverage in the pipeline, secret handling, approval gates, rollback options and how long a change takes to reach production. See our CI/CD pipeline service for how we usually fix what we find.
Kubernetes and containers
Cluster version and upgrade practice, node pools, resource requests and limits, network policies, ingress, image provenance and workload security settings.
Observability and operations
Metrics, logs, traces, alert quality, on-call rotation, incident history, backups and restore testing. We pay particular attention to whether alerts map to user impact, and whether anyone has ever restored from backup.
How the assessment works in practice
We separate observation from judgement. First we collect facts using read-only tooling and short interviews. Then we interpret them.
For infrastructure code and configuration, automated scanners give a fast first pass. For example, a read-only scan of a Terraform repository and a container image might look like this:
## Static analysis of Terraform for misconfigurations (no cloud access needed)
checkov -d ./infrastructure --framework terraform --compact
## Scan a container image for known vulnerabilities
trivy image --severity HIGH,CRITICAL registry.example.com/app:latest
## Confirm what is actually running in the cluster
kubectl get pods --all-namespaces -o wide
kubectl top nodes
Scanner output is a starting point, not a finding. A flagged open security group might be a deliberate public load balancer. We verify each result against how the system is meant to work before it enters the report, which keeps the report credible and short.
Interviews are equally important. Engineers will tell us that a particular deploy script is never run on Fridays, or that one cluster is not upgraded because nobody is sure what depends on it. That kind of knowledge never appears in a scan.
What you receive
The main artefact is a written findings report. A typical structure:
| Section | What it contains |
|---|---|
| Executive summary | Overall position, the few issues that matter most, recommended next step |
| Scope and method | Accounts, repositories and teams reviewed, what was not reviewed |
| Findings register | One row per finding: area, evidence, severity, effort, recommended action |
| Quick wins | Low-effort changes your team can make immediately |
| Structural issues | Larger problems that need design work, usually input to the Plan phase |
| Suggested sequence | Proposed order of work and dependencies |
Each finding follows the same pattern: what we saw, where we saw it, why it matters, how confident we are, and what we recommend. Severity reflects likely impact on security, reliability, cost or delivery speed, and effort is stated relative to your team, not as a generic estimate.
You also get a walkthrough session, so questions are answered while the context is fresh. If you want a lightweight benchmark before engaging, the DevOps maturity assessment gives a quick self-scored view.
What we need from you
- Read-only access to the in-scope cloud accounts, repositories and pipeline tooling.
- A technical point of contact who can unblock access and answer questions.
- Time with the engineers who build and run the platform, plus any recent incident write-ups.
- Honest context: known problems, planned migrations, compliance obligations and upcoming launches.
We do not need production data, and we will tell you if a finding would require touching it.
Timing and decision points
Duration depends on scope: more accounts, clusters and teams mean more to inspect. We give an expected duration in writing after scoping, and tell you early if the scope changes.
There are three decision points. At scoping, you approve what is in and out. At the walkthrough, you challenge findings and we correct anything that is wrong. At the end, you choose whether to act alone, continue to planning, or stop.
How to verify the quality of an assessment
A good assessment is checkable. Ask for these:
- Evidence for every finding: a resource ID, file path, query or screenshot you can reproduce.
- A stated scope and its gaps: what was not reviewed is as important as what was.
- Prioritisation that reflects your business: a payment system and an internal tool should not share a severity scale.
- Recommendations you can act on without us: specific enough for your team to start Monday.
- Disagreement handled openly: findings your engineers dispute should be revised or marked as contested, not defended.
Be wary of reports that are mostly scanner output, contain no interviews, or end with a single large rewrite as the answer.
When you may not need this phase
If you already have a recent, trusted review and a clear direction, you can skip straight to planning. If you have one narrow problem, such as an unreliable pipeline, a focused engagement on CI/CD or Kubernetes may be more efficient. The assessment earns its place when the estate is large, poorly documented, or the team has changed since it was built. To discuss scope, book a consultation.