Something made someone ask the question
- Something failed, or nearly did, and nobody is confident it will not happen again.
- The environment was inherited, or the people who built it have gone.
- A customer, insurer, investor or regulator is asking questions about it.
- A regulation, standard or customer security requirement applies, and nobody has checked the infrastructure against it.
- Growth is coming and nobody knows whether the architecture will take it.
- A second opinion is wanted before committing to a large change.
Against platform best practice and the well-architected principles
Compute and workloads
Sizing, scaling behaviour, redundancy, patching, single points of failure.
Storage and data
Durability, encryption, retention, backup coverage, and whether restores have ever been tested.
Network
Segmentation, exposure to the internet, traffic controls between tiers, DNS and certificate handling.
Identity and access
Who and what can do what, privilege scope, shared credentials, joiner-mover-leaver reality.
Security controls
Encryption in transit and at rest, secrets handling, vulnerability exposure, detection coverage.
Observability and audit trail
Whether you can tell what happened, who did it, and when, after the fact.
Resilience
Failure domains, recovery objectives, and whether the environment can actually meet them.
Governance and operations
Change control, infrastructure as code coverage, drift, documentation, ownership.
Regulatory and standards alignment
Where it applies — the technical controls a regulation or standard requires, checked against what is configured: DORA, NIS2, GDPR, ISO 27001, BSI C5, PCI DSS, SOC 2.
The configuration, not a questionnaire
Self-assessment tools ask your team what is in place. We read the environment: infrastructure code, resource and platform configuration, access policies, network rules, logging and alerting, and the deployment path — supported by conversation with the people who run it.
That distinction matters twice over. It surfaces the problems nobody knows about, which the questionnaire cannot. And it lets us discard the findings that are technically true but irrelevant to how your system is used, so the report contains real risks instead of a tool’s output.
Ranked by risk and effort together, not by severity label
What it is
What it puts at risk in practice
How much effort it takes to fix
What the result of fixing it will be
Then they are grouped, because a logging gap, a weak audit trail and an incident-response gap are usually one missing capability rather than three problems.
You get a report you can hand to a board, and a list your engineers can start on the same week. Where a finding is a deliberate, reasonable trade-off, we say so and leave it.
The lines we will not blur
Not a penetration test
We assess configuration, controls and design, not live exploitation. Where the review shows testing is warranted, we say so.
Not a certification or attestation
We assess your infrastructure against what a regulation or standard requires technically, and show you the gaps and the evidence. But compliance also covers policies, contracts, processes and people, and only an accredited body can certify it. Our work is what you do before that, and what makes it go quickly.
Not FinOps
Obvious cost problems get flagged; spend analysis and optimisation is a separate engagement.
The ways in
Full audit
The whole environment, across every area above.
Focused audit
One dimension in depth: security posture, resilience and recovery, access and governance, or readiness against a named regulation or standard.
Pre-change review
An architecture or a plan reviewed before you build or commit to it.
Audit and remediate
The review, then we implement the plan with your team.
Book an audit
Give us read access to your environment and a conversation with whoever runs it. You will get a report you can act on.
- A written report: findings, evidence, business impact, effort and expected result for each
- A prioritised remediation plan, grouped by underlying cause
- Current-state architecture documentation, which most environments do not have
- A walkthrough with your team, and answers to what they ask afterwards
- A re-assessment baseline, so the next review measures progress rather than starting again