Protected B Data Explained: Meaning, PBMM & Compliance

Protected B Data: What It Is, Why It Matters, and How to Handle It

Why this matters right now

If your organization processes data on behalf of a federal department, acts as a subcontractor, or manages commercially sensitive personal information under federal oversight, you are likely handling Protected B information. The problem is that most organizations don't know it, and even fewer have the operational controls in place to prove it.

The Government of Canada's cloud security standard, the Protected B, Medium Integrity, Medium Availability profile, known as PBMM and now officially designated as the CCCS Medium Cloud Control Profile, defines exactly what technical and operational controls are required to lawfully handle this category of data. Non-compliance isn't just a policy risk. It can mean contract loss, structural data breach liability, and significant harm to the individuals whose information you hold.

This article gives you a plain-language, technically precise walkthrough of the federal classification system, the PBMM requirements, data residency rules, and a practical readiness checklist that can help inform next steps to consider.

What is Protected B information?

Protected B is a Government of Canada security classification for sensitive information whose unauthorized disclosure could reasonably be expected to cause serious injury to an individual, organization, or business, for example medical records, financial details, or income tax data. It sits above Protected A and must be handled under the stricter PBMM (CCCS Medium) security profile.

Canada's data sensitivity classification system

The Government of Canada separates sensitive information into two distinct categories based on the nature of the data and what its compromise would harm: Protected (harming individual or organizational interests) and Classified (harming the national interest). Within these categories, the Public Services and Procurement Canada (PSPC) define specific sensitivity tiers.

To win and maintain federal contracts, organizations must match the data tier they handle with the correct organizational screening, physical worksite zone, and personnel clearance:

Key point: Protected B is by far the most commonly encountered sensitivity level in commercial government contracting, and the one most likely to be mishandled. While it requires the same base personnel clearance (Reliability Status) as Protected A, the infrastructure security goals (PBMM) required to house it are significantly stricter.

What qualifies as Protected B?

The Public Services and Procurement Canada defines Protected B as information whose compromise could reasonably be expected to cause serious injury to individuals. In practice, this may include:

• Medical, psychological, and mental health records
• Income, tax, and audited financial statements
• Personnel evaluations, background checks, and disciplinary records
• Information about ongoing legal proceedings or criminal investigations
• Financial account numbers and routing details
• Biometric identifiers and government issued IDs (SIN, passports)
• Information subject to solicitor-client privilege
• Records that could enable targeted identity theft or corporate fraud

For any organization processing personal data under federal jurisdiction, employee records, payroll data, corporate tax submissions, and proprietary commercial files fall squarely into this category.

Important Note: This checklist is designed as a general data classification for information purposes only. It does not constitute a formal audit, legal advice, or an official data classification. To protect your privacy, all selections are processed entirely within your local browser and are never transmitted or stored externally.

The PBMM standard explained

PBMM stands for Protected B / Medium Integrity / Medium Availability. It is the Government of Canada's baseline cloud security profile for systems that handle Protected B data. The Canadian Centre for Cyber Security (CCCS) renamed this profile to the CCCS Medium Cloud Control Profile. The term "PBMM" remains widely used across industry, procurement documentation, and legacy references, but the underlying control set now lives under the CCCS Medium designation as outlined in Annex B of ITSP.50.103.

The profile is defined under the Direction on Service and Digital and operationalized through the CCCS ITSG-33 Security Control Catalogue, specifically through Annex 4A, Profile 1 and the CCCS Medium Cloud Control Profile.

The three components of the name describe what you are protecting against:

01 - Protected B (Confidentiality) The confidentiality classification. Ensures only authorized individuals with a verified "need-to-know" can access the data. Strict encryption in transit and at rest, multi-factor authentication, and tamper-resistant audit logging are core requirements.

02 - Medium Integrity Data must remain accurate, complete, and unmodified from its authorized state. Controls include cryptographic checksums, mandatory change management workflows, and immutable audit trails for all data modifications.

03 - Medium Availability Systems must be reasonably available to authorized users when needed, typically mapping to a 99.9% uptime baseline. Redundancy, automated backups, and documented disaster recovery paths are required but at a moderate operational tier, rather than a continuous, mission-critical safety tier.

Note: PBMM is a risk-based profile, not a single static certification. Formally processing Protected B data on behalf of a federal department requires an Authority to Operate (ATO), which relies on a comprehensive assessment of security controls.

Accelerating Subcontracts: The Simplification Window

Managing a supply chain under PBMM baseline controls often scares away lean teams due to the administrative overhead of sponsoring new vendors. However, CSM Section 2.4.1 (Option 1) provides an administrative shortcut for organizations working with sole proprietors or tiny, localized technical teams:

• The Sponsorship Shortcut: If the subcontracted work is executed exclusively on-site at a cleared government facility or your own authorized business location, you can request and hold the personal security screening (Reliability Status) for that individual resource directly under your corporate envelope.
• The Catch: Under this option, Protected B data can never be transferred, processed, or stored at the subcontractor's personal or corporate location. If they require remote access from their own environment, they must undergo a formal, multi-layered Organization Screening process instead.

What PBMM actually requires from your systems

The authoritative PBMM control set is defined in ITSG-33 Annex 4A, Profile 1 and the CCCS Medium Cloud Control Profile. These controls are drawn from the ITSG-33 Security Control Catalogue and align with the NIST 800-53 framework. At a high level, true PBMM compliance demands:

• Identity and Access Management (IAM): Enforced multi-factor authentication (MFA) for all users, with phishing-resistant MFA mandated for privileged administrative access. Role-Based Access Control (RBAC) must enforce the principle of least privilege, backed by a centralized identity provider with real-time audit logging of all authentication events.
• Cryptographic Controls: Alignment with the Cyber Centre's specific standard ITSP.40.111 (Cryptographic algorithms for UNCLASSIFIED, PROTECTED A, and PROTECTED B information). This requires TLS 1.2 or higher for all data in transit and validated AES encryption (128-bit key length or higher) for data at rest, utilizing rigorous key management structures that separate key custody from data storage locations.
• Logging and Monitoring: Comprehensive, centralized audit trails retained for a minimum of two years. Security information and event management (SIEM) integration to correlate logs, detect anomalous access patterns, and alert on unauthorized changes.
• Network Segmentation: Workloads must be logically or physically isolated using modern Zero Trust Architecture (ZTA) principles, micro-segmentation, and strict boundary protection mechanisms such as external traffic inspection.
• Vulnerability Management: Regular automated vulnerability scanning, with strict remediation SLA windows (e.g., critical patches applied within 5 days; high-severity patches within 10 days) and formalized exception documentation.
• Incident Response: A fully documented and regularly tested incident response plan containing explicit data breach notification protocols that align with the Privacy Act and, where applicable, PIPEDA or provincial equivalents.

The Shared Responsibility Trap: Using a hyperscale cloud provider that holds a federal authorization (such as AWS Canada or Microsoft Azure Canada) does not automatically make your application or workload PBMM-compliant. Under the GC Cloud Operationalization Framework, the shared responsibility model dictates that the provider secures the foundational infrastructure, while you are entirely responsible for configuring, deploying, and maintaining the security controls of everything built on top of that infrastructure.

Complementary Readiness Framework: The Cross-Sector CRGs

In addition to the PBMM control catalogue, the Cyber Centre published 36 Cross-Sector Cyber Security Readiness Goals (CRGs) in October 2024. These are foundational, outcome-oriented goals designed primarily for critical infrastructure operators, mapped to the NIST CSF 2.0 framework and the MITRE ATT&CK matrix.

The CRGs are not the PBMM control set itself, and implementing them alone does not satisfy a PBMM assessment. However, they provide a practical starting point for organizations that are early in their security maturity journey, covering foundational areas like asset inventory, phishing-resistant authentication, vulnerability management, and incident response readiness. Organizations preparing for PBMM alignment will find significant overlap between the CRGs and the broader ITSG-33 control requirements, making the CRGs a useful readiness benchmark on the path toward full compliance.

Data residency: where your data must live

Canadian data residency rules for Protected B data are strict and frequently misunderstood. The Government of Canada's cloud procurement rules and the Direction on Service and Digital mandate a clear boundary: Protected B data processed on behalf of the Government of Canada must be stored and processed within Canada.

Navigating the "Sovereign Operations" Dilemma

To maintain true compliance, data residency must extend past where data sits on a hard drive. Organizations must account for several operational layers:

1. Cloud Regions: Your primary data footprint must stay within Canadian borders (e.g., using ca-central-1 for AWS or Canada Central / Canada East for Azure). This is likely a non-negotiable procurement requirement.
2. Backup and Replication Boundaries: Offsite backups, cold storage, and disaster recovery replication targets must also remain within Canada. If an automated failover switches to a US-based data centre during an outage, you are likely out of compliance.
3. The Support Access Loophole: If a software-as-a-service (SaaS) vendor or cloud provider routes your technical support ticket to engineers located outside of Canada, and those engineers can view Protected B data in plaintext during troubleshooting, this may constitute a cross-border data exposure event that conflicts with your compliance obligations. Organizations may implement technical mitigations such as Customer-Managed Keys (CMK), Hold Your Own Key (HYOK) architectures, and Just-In-Time (JIT) conditional access windows to ensure data remains opaque to external administrators.
4. Sovereign Operations: True sovereign compliance requires that the personnel with high-level administrative access to the underlying systems are located within Canada and have been vetted to the Government of Canada's Enhanced Reliability Status or higher.

The USA PATRIOT Act and CLOUD Act risk

Even when data is geographically stored in Canadian data centres, it can remain subject to US extraterritorial legal demands if the infrastructure provider is a US-incorporated entity or subsidiary under the US CLOUD Act. Within Canadian federal procurement, the preferred mitigation is implementing cryptographic controls that ensure the cloud provider never holds plaintext keys. This is designed to ensure that only the data owner can respond to a lawful access request, significantly narrowing the provider-level access vector.

Protected B readiness checklist

Use the interactive checklist below to benchmark your organization's current posture against PBMM baselines. Mark each of the 20 controls as Yes, Partial, or No. Your score updates live and your progress is saved in your browser.

Important Note: This checklist is designed as a general readiness benchmark for information and planning purposes only. It does not constitute a formal audit, legal advice, or an official Authority to Operate (ATO) determination. To protect your privacy, all selections are processed entirely within your local browser and are never transmitted or stored externally.

What happens when you're not compliant

The penalties for non-compliance with Protected B handling mandates can be swift and material. For federal contractors, failing a Contract Security Program (CSP) audit or experiencing a data spill can result in default clauses, contract termination, and long-term disqualification from future federal procurements.

For private-sector organizations handling Protected B data, the Personal Information Protection and Electronic Documents Act (PIPEDA) requires that any breach of security safeguards creating a "real risk of significant harm" to an individual be reported to the Office of the Privacy Commissioner (OPC) and that affected individuals be notified. For federal institutions, equivalent breach reporting obligations exist under the Treasury Board's Policy on Privacy Protection, which applies the same "real risk of significant harm" threshold. In either case, because Protected B data includes health, tax, and legal records, any unauthorized compromise almost automatically meets the threshold for significant harm, which can potentially expose the organization to severe legal liability, class-action exposure, and catastrophic reputational fallout.

Note: The Government of Canada launched a formal review of the Privacy Act in April 2026, with proposals to enshrine mandatory breach notification directly into the statute. Organizations should monitor this review for legislative changes that may formalize obligations currently held at the policy level.

Anatomy of a Security Enforcement Action

If an audit or investigation reveals unmitigated vulnerabilities or out-of-boundary workflows, the Contract Security Program deploys a standardized enforcement protocol that impacts your operational runway:

1. The Suspension Trigger: Canada can issue a formal suspension letter via email to the organization's Company Security Officer (CSO), detailing the reasons for the suspension. At this point, the organization's suspension may impact its ability to continue working on existing procurement instruments, compete for new opportunities, or be considered for new procurements.
2. The 30-Day Fix Window: Unless otherwise notified, the organization has 30 calendar days to submit a written response outlining the corrective measures it is taking to address the concerns and maintain a valid organization clearance.
3. The Revocation Consequence: If the organization's response does not address or mitigate the reasons for the suspension, or if no response is provided, Canada may proceed to issuing a revocation letter. Upon revocation, personnel reliability statuses and security clearances issued under the organization's registration can be administratively closed out, immediately prohibiting eligibility to perform work on contracts requiring organization security clearances. The impact on active contracts is determined at the discretion of the contracting authorities and the client department.

A Pragmatic Informational 90-Day Compliance Roadmap

Achieving PBMM alignment does not require an endless, multi-year IT overhaul. By breaking the requirements down into an ordered, phased sequence, organizations can build a verifiably compliant architecture systematically.

Phase 1: Days 1–30 | Data Discovery & Classification Mapping

Locate all data stores across your network. Map your workflows to identify where federal or commercially sensitive data is captured, processed, or transferred. Audit every third-party SaaS tool to confirm written Canadian data residency and isolate any unapproved file-sharing systems.

Phase 2: Days 31–60 | Enforce Identity Boundaries & Cryptographic Baselines

Implement mandatory MFA across all entry points, and issue physical hardware tokens to administrators. Deploy AES encryption (128-bit key length or higher) at rest across all endpoints, databases, and backup volumes, ensuring configurations match ITSP.40.111. Restrict administrative support access vectors to ensure no cross-border data exposure occurs.

Phase 3: Days 61–90 | Establish Centralized, Tamper-Proof Auditing

Configure a centralized logging architecture that streams event data into a secure SIEM. Enforce object-locking mechanisms on log repositories to ensure access histories cannot be overwritten or altered. Run a live tabletop simulation of your incident response plan to ensure regulatory breach notification timelines can be met on demand.

Frequently asked questions