What Is PBMM? The CCCS Medium Profile Explained

PBMM Explained: What Cloud Teams Actually Need to Know

The Government of Canada's cloud security profile isn't a checkbox. Here's what it actually demands from your team.

If you're searching "PBMM," you've probably been told your cloud deployment needs to be compliant with it, and now you're trying to figure out what that actually means. You're not alone. PBMM is one of the most frequently referenced and least clearly understood requirements in Canadian government IT. I felt lost when I was first introduced to it, and then gained an understanding after years of the SA&A process.

This article is written for cloud architects, DevOps leads, security engineers, and IT managers who already understand what Protected B data is and need to know what the PBMM security profile requires of their systems, and just as importantly, where the line falls between their responsibilities and their cloud provider's.

What PBMM actually stands for and what it's called now

PBMM stands for Protected B / Medium Integrity / Medium Availability. For security professionals, this directly relates to the CIA triad (Confidentiality, Integrity, Availability).

It describes a security categorization profile: the data is Protected B (moderate sensitivity - serious injury to individuals if compromised), the integrity requirement is medium (data must remain accurate and unmodified), and the availability requirement is medium (systems must be reasonably available, typically 99.9% uptime with defined recovery objectives).

An important terminology update: the Canadian Centre for Cyber Security (CCCS) has officially renamed this profile to CCCS Medium. You'll see this reflected in recent documentation from AWS, Microsoft, Google, and the CCCS itself. The underlying requirements haven't changed. It's the same ITSG-33 control profile, but the naming convention has been updated to better align with the CCCS assessment framework. In practice, most people in the GC ecosystem still say "PBMM", so both terms will be used in this article.

The profile is operationalized through ITSG-33 (IT Security Risk Management: A Lifecycle Approach, Annex 3 - Security Control Catalogue), which provides the specific security controls that must be implemented. The CCCS publishes the CCCS Medium Cloud Profile Recommendations as a detailed control mapping. The controls are derived from NIST SP 800-53, adapted for the Canadian federal context, and organized into families covering access control, audit and accountability, system and communications protection, incident response, and more.

The CCCS assessment: how cloud providers get qualified

Before you can deploy Protected B workloads to a cloud platform, that platform's relevant services must be assessed by the CCCS. This is not a self-attestation. It's a government-led evaluation with three distinct components, each conducted by a different GC entity. The full process is documented in ITSM.50.100 - Cloud Service Provider Information Technology Security Assessment Process.

Component 1: Supply Chain Integrity (SCI). The CCCS Supply Chain Integrity team assesses risks related to the cloud provider's ownership structure, geographic presence, and product/service supply chain. This evaluates whether the provider's corporate relationships introduce risks to the confidentiality or integrity of GC data.

Component 2: Physical and Personnel Security. Public Services and Procurement Canada (PSPC), through the Contract Security Program, verifies the provider's organizational security clearance, physical security of facilities, and personnel security screening. This ensures that individuals with access to Protected B environments hold appropriate security clearances and that physical infrastructure meets GC standards.

Component 3: Technical Cloud Security Assessment. The CCCS assesses the cloud services against the relevant GC Cloud Control Profiles - CCCS Medium (the baseline PBMM profile) and, where applicable, the Protected B High Value Asset (PBHVA) overlay. The provider must demonstrate evidence of compliance for each control in the profile.

All three components must be completed before a CSP's services are eligible for Protected B workloads. The resulting assessment report is made available to departments, typically through portals like AWS Artifact or the SAP Trust Centre, and departments rely on these reports as part of their own Authorization to Operate (ATO) process.

The major providers with CCCS Medium assessments in Canadian regions include AWS (162 services assessed in Canada Central and Canada West), Microsoft Azure, Google Cloud, and SAP Sovereign Cloud for Canada. The list of assessed services is not static. Providers continuously add services, and the CCCS updates its assessments accordingly.

The shared responsibility model: where most teams get it wrong

This is the single most important concept in PBMM compliance, and the one most frequently misunderstood: using an assessed cloud provider does not make your workload compliant.

The shared responsibility model means the cloud provider is responsible for security of the cloud - the physical infrastructure, the hypervisor, the network fabric, the hardware.

You are responsible for security in the cloud - the operating systems you deploy, the applications you build, the data you store, the access controls you configure, and the monitoring you implement.

The CCCS assessment confirms that the provider has met its obligations. It says nothing about whether you've met yours.

To make this concrete, here are examples of controls that fall squarely on your side of the shared responsibility line, regardless of which assessed CSP you use:

Identity and access management. Your cloud provider offers IAM services. You configure them. If you're not enforcing multi-factor authentication on all accounts with access to Protected B data, separating privileged from standard accounts, and reviewing access quarterly, your workload is non-compliant, even on an assessed platform.

Encryption key management. AWS KMS, Azure Key Vault, and GCP Cloud KMS all provide key management services. But you decide the key policies, the rotation schedule, and whether key custody is properly separated from data storage. Using a provider's default encryption without configuring key management to meet ITSG-33 requirements is a common gap.

Audit logging and retention. CloudTrail, Azure Monitor, Cloud Audit Logs - all available, none configured to PBMM standards out of the box. You need comprehensive audit trails retained for a minimum of two years, tamper-protected so that administrators with access to the data cannot modify or delete the logs that record their access, and actively monitored with alerting for anomalous patterns.

Network segmentation. You design the VPC, the subnets, the security groups, the network ACLs. The CSP provides the constructs. You implement zero-trust principles, segment workloads logically, inspect external traffic, and ensure Protected B workloads are isolated from lower-sensitivity environments.

Incident response. The CSP will respond to incidents in its infrastructure. Your incident response plan, your breach notification procedures, your testing cadence, those are yours. And PBMM requires that they exist, that they're documented, and that they've been tested.

A useful benchmark from a recent Coalfire assessment of AWS's Landing Zone Accelerator against the PBHVA overlay: roughly 71 percent of in-scope controls were supported by the AWS side of the shared responsibility model. The remaining 29 percent were entirely on the customer side. That 29 percent is where most compliance failures occur.

PBHVA: when PBMM isn't enough

The CCCS has introduced a second control profile that sits above the baseline CCCS Medium profile: the Protected B High Value Asset (PBHVA) overlay. This is a relatively recent development and one that most organizations are not yet tracking.

The PBHVA overlay is designed for workloads that the GC identifies as high-value assets. These are systems that support the delivery of services at a national scale or that handle particularly significant volumes of sensitive information. Think payroll systems covering the entire federal public service, large-scale benefit delivery platforms, or national-scale identity management systems.

The overlay adds enhanced integrity and availability controls on top of the CCCS Medium baseline. As of its most recent iteration, the PBHVA overlay consists of approximately 137 controls - 68 carried over from CCCS Medium and 69 additional controls selected from the ITSG-33 catalogue, based on NIST SP 800-53 Revision 5. The additional controls focus on areas like redundancy, failover, data integrity verification, and enhanced monitoring.

Not every Protected B workload requires PBHVA. But if your department has identified the system as a high-value asset, the PBHVA overlay controls become a contractual and compliance requirement. AWS was the first CSP to complete a PBHVA assessment (2024), followed by Google Cloud and SAP Sovereign Cloud for Canada. The number of providers with PBHVA assessments is growing, but it remains a smaller set than the CCCS Medium baseline.

If you're building a new system and aren't sure whether PBHVA applies, the question to ask your departmental security authority is: "Has this system been designated as a high-value asset?" If yes, you need to design for the overlay from the start. Retrofitting PBHVA controls onto a system designed only for CCCS Medium is significantly more expensive than building for it upfront.

Common mistakes that catch teams off guard

These are the compliance gaps that show up most frequently in practice, not because teams are careless, but because the requirements are easy to misread.

"Our provider is assessed, so we're compliant." Already covered above, but worth stating plainly: this is the single most common misconception. The provider's assessment covers their controls. Your workload has its own control requirements, and you need your own evidence of compliance.

Backup replication outside Canada. Your primary data sits in ca-central-1 or Canada Central. Your disaster recovery target could be configured to replicate in us-east-1. Every copy of Protected B data must reside in Canada, including backups, replicas, and snapshots. This extends to any automated cross-region replication that may be enabled by default in some services.

SaaS applications in the workflow. Your IaaS/PaaS environment is locked down. But your team uses a SaaS ticketing system, a SaaS HR platform, or a SaaS code repository that processes Protected B metadata. If those services haven't been assessed and don't offer Canadian data residency, you have a compliance gap, even if the core infrastructure is clean.

Support access from outside Canada. Your provider's support engineers or supporting vendors may be located globally. If they can access your Protected B environment - even temporarily, even read-only, even for troubleshooting - that constitutes a cross-border data access issue. Mitigations include contractual restrictions on where support is delivered from, personnel security screening for anyone with access, and technical controls such as customer-managed encryption keys that prevent the provider from accessing plaintext data. If you can't confirm that all three layers are in place, this will likely result in a security gap.

Treating the ATO as a one-time event. An Authority to Operate is not a point-in-time certification that you earn and forget. PBMM compliance requires continuous monitoring, periodic reassessment, and evidence that controls remain effective over time. Systems change, teams change, threats change, and your compliance posture must keep pace.

Ignoring the 29 percent. The customer-side controls - access management, logging configuration, network segmentation, incident response planning - are where auditors spend their time, because they're where gaps actually live. The provider's assessment summary is a given. Yours is what gets scrutinized.

Getting started: what to do on Monday

If you're staring down a PBMM compliance requirement and aren't sure where to start, here's a pragmatic sequence.

First, confirm your security categorization. The CCCS provides specific guidance in ITSP.50.103 - Guidance on Security Categorization of Cloud-Based Services. Is your workload actually PBMM, or has it been designated as a high-value asset requiring the PBHVA overlay? This determines which control profile you're building against, and getting it wrong means rework later.

Second, verify that every cloud service you're using has been assessed by the CCCS. Check the provider's compliance page and the CCCS assessment reports, not just the provider's marketing materials. If a specific service isn't on the assessed list, you either can't use it for Protected B workloads or you need to implement compensating controls and document them.

Third, map your customer-side responsibilities. Use the provider's shared responsibility documentation as a starting point and walk through each ITSG-33 control family. For each control, answer: is this the provider's responsibility, my responsibility, or shared? Then verify that you have evidence of implementation for every control on your side. Tools like AWS Audit Manager's CCCS Medium framework can help automate evidence collection against the control profile.

Fourth, build for auditability from the start. Structured, queryable logs. Automated evidence collection. Configuration-as-code so your environment's compliance posture is reproducible and verifiable. Organizations that build this in from day one spend a fraction of the effort on ongoing compliance compared to those that retrofit it.

For departments undertaking the full SA&A process, the CCCS publishes ITSP.50.105 - Guidance on Cloud Security Assessment and Authorization, which outlines the assessment methodology and authorization decision framework. Security findings identified during the SA&A process are typically documented in a Security Management Action Plan (SMAP) or a Plan of Action and Milestones (POA&M), which track remediation timelines and risk acceptance decisions. An ATO with managed findings can be the norm, not the exception.