Cloud Security
Cloud adoption moved faster than the governance around it. We assess what you have actually deployed, close what migration left open, and leave you with an operating model that survives the next migration.
- Typical duration
- 3–6 weeks
- Primary audience
- Both
- You leave with
- A cloud estate whose security posture is a design decision, not a residue of how the migration happened.
Three phases, start to finish.
- 01 Estate and threat review What is actually deployed, who can reach it, and where the data ends up — assessed against the threats that apply to your workloads rather than a generic benchmark run at the account root. Account, subscription and project inventory reconciled against what you think you run Identity, privilege and attack-path analysis, including cross-account and federated roles Data residency and sovereignty checked against your Canadian obligations
- 02 Architecture and controls The boundaries, the identity model and the guardrails — designed with your platform team in the room, so what we leave is something they already know how to operate. Landing zone, network segmentation and data-boundary design Preventive guardrails in policy-as-code rather than a wiki page of rules Kubernetes, container and pipeline hardening against CIS and provider baselines
- 03 Governance and operating model Who decides, who reviews, and what happens when a team wants a new service switched on. The part most cloud security work skips, and the reason posture decays six months later. Service approval and exception process sized to how your teams actually ship Ownership, review cadence and drift detection with named owners Control mapping reused as evidence for ISO 27001, SOC 2 and CMMC
Where cloud security actually goes wrong
Almost no estate we review was designed insecurely. It was designed once, correctly, and then twenty teams shipped against it for three years. The account count grew, a second provider arrived through an acquisition, an emergency permission was widened at 2am and never narrowed, and the boundary that made sense at migration stopped describing anything real.
That is why this engagement starts with what is deployed rather than with a benchmark. A CIS scan run at the account root tells you which knobs are in the wrong position. It does not tell you that a federated role in your build account can assume its way into production, which is the finding that matters.
What we review
- Estate reconciliation. Every account, subscription and project, checked against what you believe you run. The gap is routinely double digits.
- Identity and privilege paths. Cross-account roles, federated access, service principals and the assume-role chains between them.
- Data boundaries and residency. Where data physically lands, which regions your providers replicate to, and what that means under PIPEDA and any provincial or sector rules that apply.
- Network and exposure. What is reachable from the internet, what is reachable from a compromised workload, and the difference between the two.
- Kubernetes, containers and pipelines. RBAC, admission control, image provenance and the CI credentials that quietly hold more than the workloads do.
The operating model is the deliverable
Most cloud security work stops at a remediation list, which is why posture decays within six months of the report. The third phase of this engagement is the part that lasts: who approves a new service, how an exception is granted and when it expires, who owns each account, and what detects drift when someone does the reasonable thing under deadline pressure.
The control set is written against the ISO 27001 Annex A and SOC 2 Trust Services Criteria references it satisfies, so the same work is evidence in your next audit rather than a second project.
A cloud estate should have a security posture because someone designed one, not because of how the migration happened to go.
Cloud Security: the questions we get asked.
Which cloud platforms do you cover?
AWS, Microsoft Azure and Google Cloud, including the Kubernetes and container layers on each. Most estates we review are more than one of them, which is usually where the identity and data-boundary problems live.
Is a cloud security review the same as a cloud penetration test?
No. A review reads the configuration, the identity model and the governance around them. A penetration test attacks the deployed environment from outside and inside. They answer different questions, and estates that have never had either usually want the review first — it is cheaper and it finds more.
Can you help with data residency for Canadian organisations?
Yes. Where data physically lands, which regions your providers replicate to, and what that means under PIPEDA and any provincial or sector rules that apply to you, are part of the estate review rather than an add-on.
Does this work count towards ISO 27001 or SOC 2?
It should, and we map it so it does. The control set implemented here is written against the Annex A and Trust Services Criteria references it satisfies, so the evidence is reusable rather than produced twice.
Other lines of work
All servicesTell us what triggered the search. We will scope to that.
We reply to every assessment request within one business day.