Landing zone & account architecture
Multi-account or multi-subscription design with clear blast-radius boundaries, centralised logging, and service control policies that make dangerous actions impossible rather than discouraged.
Loading page content
Executive summary
Cloud breaches rarely begin with a novel exploit. They begin with an over-permissive role, a public bucket, an unrotated key or an exposed management interface. This engagement secures the control plane structurally — guardrails enforced at organisation level, least privilege as the default state, and misconfiguration caught in the pipeline rather than in production.
Cloud breaches almost never begin with a novel exploit. They begin with an over-permissive role, a public storage bucket, an unrotated key in a repository, or a management interface exposed to the internet. The control plane is the attack surface.
We secure it structurally. Guardrails are enforced at the organisation and policy level rather than requested in a wiki page. Identity is designed with least privilege as the default state, not the aspiration. Misconfiguration is caught in the pipeline, before it reaches production.
And critically, the controls are built so that the fastest path for a developer is also the compliant one — because any security design that makes delivery slower will eventually be bypassed.
Common cloud failure modes
Each capability below is a discrete workstream with its own owner, deliverables and definition of done.
Multi-account or multi-subscription design with clear blast-radius boundaries, centralised logging, and service control policies that make dangerous actions impossible rather than discouraged.
Least-privilege role design, elimination of long-lived keys in favour of workload identity federation, and continuous detection of permission creep.
CSPM deployment tuned to your risk model, with findings prioritised by exploitability and routed directly to the owning team rather than a shared inbox.
Policy-as-code enforcement in CI, drift detection, pipeline hardening and secrets management so that misconfiguration fails the build instead of reaching production.
Cluster hardening to CIS benchmarks, admission control, network policy, image provenance and runtime detection for containerised workloads.
Encryption and key management strategy, bucket and database exposure control, data residency enforcement, and tokenisation where regulation demands it.
Each benefit is stated with the commercial consequence attached, because a capability without a consequence is a feature list.
Long-lived credentials eliminated in favour of workload identity federation, and standing administrative access removed.
Removes the single most frequently exploited cloud entry vector rather than mitigating it.
Policy-as-code enforcement in CI with drift detection, so dangerous configuration cannot reach production.
Misconfiguration caught at the pull request, where remediation cost is close to zero, not after production deployment.
Controls co-designed with your platform team and rolled out in report-only mode first, each with a supported alternative path.
Prevents the exception-creep that quietly dismantles most cloud security programmes.
Posture management tuned to your risk model and routed to the owning team rather than a shared inbox.
Converts an unread dashboard into closed findings.
Phases overlap deliberately — design begins before assessment closes, so the programme does not stall waiting for a document to be signed off.
Weeks 1–2
Enumerate every account, subscription, project, cluster and identity — including the ones no longer on anyone's list.
Weeks 2–5
Benchmark against CIS and cloud-provider well-architected security pillars, with manual review of identity and network design.
Weeks 5–8
Target landing zone, guardrail policies, identity model and pipeline controls, specified as code your platform team can review.
Weeks 8–20
Phased rollout with your platform engineers, starting in non-production, with rollback plans for every guardrail.
Ongoing
Drift monitoring, quarterly entitlement review and continuous benchmark reassessment as the estate grows.
Named artefacts, listed in the statement of work. If it is not on this list, we will tell you before you sign rather than after.
Sector constraints change the delivery approach more than they change the obligations. These are the sectors this methodology is built around.
Fixed fee for defined scopes, retainer for ongoing services. We do not price advisory work on time and materials, because that misaligns our incentive with your outcome.
3–5 weeks
Organisations needing a clear read on cloud exposure
Commercial basis: Fixed fee
8–20 weeks
Organisations remediating and restructuring a cloud estate
Commercial basis: Fixed fee per workstream
Rolling
Platform teams wanting ongoing specialist capacity
Commercial basis: Monthly retainer
Every proposal states what is included, what is not, and what would trigger a change request. If the scope we recommend is smaller than the one you asked for, we will say so.
One implementation, cross-mapped. Each framework below links to its own obligations and control domains.
Specific answers about scope, timeline and what we will and will not do.
Ask a practitioner directly. First responses come from the person who would run your engagement, within one business day.
Ask a questionTurn data protection law into working product behaviour.
We map where personal data actually lives, rebuild consent and rights flows into your product, and leave you with a privacy programme that survives an audit and a board question.
Explore capabilityDefensible security, built around how your business actually loses money.
Threat-led security strategy, architecture and control design that prioritises the handful of scenarios that would genuinely hurt you — not a generic checklist of 300 controls.
Explore capabilityOne operating model for privacy, security, risk and AI accountability.
We design the committees, policies, decision rights and reporting lines that let trust obligations be managed as one programme instead of four competing ones.
Explore capabilityCombining capabilities reduces cost — the second framework typically lands at about half the price of the first.