Who can actually do what
The largest source of real exposure is rarely exotic. It is a role with a wildcard action attached, a long-lived access key in a build script, an administrator group nobody has reviewed since the people in it changed jobs.
Services
Cloud Security
Most cloud exposure comes from configuration nobody revisited: a permissive role, a rule left open for a migration. We review what your accounts actually allow, and make the fix stick.
The account was opened for one project, and then a second team needed somewhere to put a database. Three years on, nobody holds the whole picture: which roles can read production data, which security group still allows the whole internet through because someone needed access one afternoon. Nothing has gone wrong yet. Then an auditor asks, or a customer sends a security questionnaire, and the gaps have to be written down.
Where the exposure is
Most of the risk sits in four places
Findings cluster: who can do what, what is reachable from outside, where the data and the keys sit, and whether anyone would notice.
What the internet can reach
Security groups, ingress rules, public subnets and the load balancer somebody stood up for a demo. The question is not how many rules exist but which paths resolve from outside your estate.
Data, keys and who holds them
Encryption at rest is the easy half, and most estates have it. The harder questions are who can decrypt, how keys rotate, and whether a backup is readable from an account you would never give production access.
Whether anyone would know
Logs switched on in one region but not the next, a trail nobody reads, alerts routed to a mailbox that stopped being monitored when the team reorganised. Ask when an unfamiliar console login was last noticed, and by whom.
A secure account does not stay secure
You can fix everything on a Friday and be wrong again by the following Thursday. A new account gets created for a proof of concept. An exception is granted so a release can go out, and nobody comes back to withdraw it. Someone changes a setting in the console to get past an outage, and the change lives on, outside whatever the templates say.
So the useful output of this work is a set of controls that hold a position without anyone having to remember: policies that refuse a public bucket instead of flagging one afterwards, infrastructure code checked before it merges, drift detection that tells you when the console and the repository disagree. A review describes one day. Guardrails describe every day after it.
The controls we look at
| Area | What gets checked | How it stays fixed |
|---|---|---|
| Identity and access | Wildcard permissions, stale keys, admin group membership | Permission boundaries and access reviews in code |
| Network boundaries | Open ingress, public subnets, exposed endpoints | Deny-by-default rules, reviewed at merge |
| Data and keys | Encryption, key rotation, backup readability | Policy that blocks unencrypted stores |
| Logging and detection | Trail coverage, retention, who gets alerted | Alerts with named owners and runbooks |
| Workload and runtime | Image provenance, patch level, secrets in containers | Scanning in the pipeline, not after deploy |
| Account structure | Blast radius, shared accounts, root use | Organisation policy applied to new accounts |
How an engagement runs
A scan that returns five hundred findings is not a result; it is a spreadsheet that will be ignored by March. A useful result is a short, ordered list of what is reachable, and who is fixing each one.
- 01
Inventory
We start with what exists, which is usually more than the last diagram shows: accounts, subscriptions, regions with something running in them, identities from three different directories. You get an inventory of the estate, with owners named where we could find them.
- 02
Assess
Configuration is compared against a recognised public baseline for your cloud provider, plus whatever your own policy requires on top. The baseline keeps the review arguable: you can see the control it came from rather than take our word for the finding.
- 03
Rank by exposure
A misconfigured role on an account holding customer data outranks a hundred low-severity items on a sandbox. We work out what is reachable and what it would take to reach it. You review the ranked list and can push back on the order.
- 04
Remediate together
Fixes land as pull requests against your infrastructure code, with your engineers reviewing them, because the team that merges a change is the team that will have to live with it. Every change arrives as a diff you approve, not as a ticket we close.
- 05
Guardrails
Then the controls that stop the estate sliding back: organisation policies, checks in the pipeline, drift alerts pointed at a rota rather than a mailbox. Handover includes the runbook for each alert and the decision record explaining what we chose not to enforce.
What buyers ask first
We can give you the evidence behind the answers, and in most cases that is what is missing rather than the words. What we will not do is attest to a control that is not in place. Where a question exposes a real gap, you get the gap, the fix, and an honest note about how long it takes.
Not sure which one you need?
Describe the problem in a paragraph and we will tell you which service applies.