Public-sector organizations don't hesitate to move to the cloud because they doubt the technology. They hesitate because they have to answer to auditors, residents, and elected officials, and "we think it's secure" is not an answer any of them will accept. The bar is proof: that data stays in the country, that access is controlled and logged, that a breach would be contained and detected, that every control maps to a recognized standard. Meet that bar and cloud adoption is straightforward. Fail to plan for it and even a technically sound migration gets stuck in review for a year.
The way through is to build the compliance in from the first resource, not bolt it on before go-live. That's what a PBMM-aligned Azure landing zone does. We built one for the Town of Ajax — a Protected B–compliant municipal foundation under Ontario data rules — and the pattern has since been adopted by other Ontario municipalities. Here's what goes into it and why each piece matters.
What PBMM actually means
PBMM stands for Protected B, Medium Integrity, Medium Availability — the security control profile the Government of Canada uses for systems handling sensitive information whose compromise could cause serious harm to an individual or organization. It draws on the ITSG-33 catalogue of controls and has become the practical benchmark for public-sector cloud in Canada, well beyond the federal departments it was written for. Municipalities, agencies, and crown corporations increasingly hold themselves to it because it's specific, recognized, and defensible.
"Protected B" is the data classification most public-sector workloads fall into: not classified national-security material, but sensitive personal and operational information — resident records, financial data, internal communications — that carries real consequences if exposed. The "Medium/Medium" part sets expectations for integrity and availability: the system must resist tampering and stay reliably up, but doesn't require the extreme measures of life-safety or national-security systems.
The value of designing to PBMM isn't the label. It's that PBMM turns a vague requirement — "be secure and compliant" — into a concrete, auditable set of controls you can build against and later point to.
Data residency comes first
For Canadian public-sector workloads, nothing else matters if the data leaves the country. So the first decision in the landing zone is regional: everything is provisioned in Canadian Azure regions, and policy is used to prevent deployment anywhere else. This isn't a preference you document and hope teams follow — it's a guardrail that refuses to create a resource in the wrong region.
That single constraint, enforced rather than requested, resolves the question that residents and auditors ask first. And because it's enforced by policy in the landing zone, it stays true as the environment grows, without anyone having to police it by hand.
The control layers
A PBMM-aligned landing zone is built in layers, each answering a category of controls. For Ajax, these were the load-bearing pieces:
Identity and access. Azure AD (Entra ID) as the single identity source, with role-based access control granting the least privilege each role needs and nothing more. Administrative access is separated, conditional, and logged. The principle throughout: every action is attributable to a person, and access is granted by role, not by exception.
Network security. A segmented network topology with an Azure Firewall and Palo Alto appliances controlling traffic between zones and to the outside world. Public exposure is the exception, not the default — most workloads sit in private subnets and are reached through controlled paths. Segmentation means a problem in one area can't move laterally into the rest of the environment.
Data protection and recovery. Azure Backup and Site Recovery for resilient, tested recovery, so "Medium Availability" is a capability you've verified rather than a hope. Encryption at rest and in transit is on by default, with keys managed and access to them logged.
Policy and governance. Azure Policy and Blueprints encode the PBMM controls directly into the platform, so compliant configuration is the default and drift is flagged automatically. This is the layer that keeps the environment compliant over time — the controls aren't a snapshot taken at go-live, they're continuously enforced.
Threat detection and response. Microsoft Defender and Sentinel provide continuous monitoring, threat detection, and a central place to investigate and respond. "Medium Integrity" requires not just prevention but detection — knowing quickly if something is wrong — and this layer delivers it.
Each layer maps to specific control families in the PBMM profile. That mapping is the point: when the auditor arrives, you're not reconstructing what you did — you're walking them through controls that were designed in from the start.
Why "compliant by design" beats "compliant by audit"
There are two ways to arrive at a compliant environment. You can build what's convenient and then spend months in remediation, chasing findings, retrofitting controls, and re-testing — the expensive, demoralizing path most organizations know too well. Or you can encode the controls into the foundation so that the environment is compliant the day it's built and stays that way as it grows.
The second path is what a landing zone makes possible, and it changes the economics of public-sector cloud entirely. Compliance stops being a gate you dread at the end of the project and becomes a property of the platform. New workloads inherit the controls automatically. Audits become a matter of showing evidence that already exists rather than assembling it under deadline. And the security posture is genuinely stronger, because controls that are enforced by the platform can't be quietly skipped by a team in a hurry.
Compliance retrofitted is a project that never quite ends. Compliance designed in is a property you stop thinking about.
A model that travels
One of the most useful things about building to a recognized profile is that the work is reusable. Because the Ajax landing zone was built as code, aligned to a standard rather than to one organization's idiosyncrasies, it became a model other Ontario municipalities could adopt rather than a one-off. The same controls, the same data-residency guarantees, the same auditable mapping — reused, not rebuilt.
That's the quiet advantage of doing it properly. A landing zone designed to PBMM isn't just a secure environment for one organization; it's a reference implementation for a whole class of public-sector organizations facing the same requirements. The first one is the hard one. After that, you're adapting a proven pattern.
Where to start
If you're a public-sector organization weighing a cloud move, the sequencing advice is simple: decide on your compliance target before you provision anything, and build the landing zone to it. PBMM is the sensible default for Canadian public-sector workloads — specific enough to build against, recognized enough to defend. Getting it right at the foundation is dramatically cheaper than retrofitting it later, and it's the difference between a cloud program that clears review and one that stalls in it.
Deop builds secure, compliant Azure landing zones for Canadian public-sector organizations — data-resident, PBMM-aligned, and auditable by design. See the Town of Ajax landing zone or explore our services.