Getting Into PBMM: The Core Requirements, and What To Expect Entering the Process
Most conversations we have about Protected B start in the wrong place. A provider holding a FedRAMP authorization asks how much of their control evidence transfers, and everyone leaves thinking this is a security assessment with some paperwork attached. Fast-forward six to nine months later and the entry submission’s progression has not been hindered by a control at all, but by a lack of contract to attach the assessment to, the support model does not satisfy Canadian clearance requirements, the underlying hyperscaler was never assessed at the level the provider needs, or some combination of the aforementioned issues.
Here we introduce you to each mandatory checkpoint (or “gates”) for submission of a Government of Canada Protected B submission under the CCCS Medium Cloud Profile, commonly referred to as PBMM, roughly in the order the gates appear. Fortreum works on both sides of this process, advising providers ahead of submission and performing the 3PAO assessment itself, so what follows is drawn from both vantage points.
Know who does what
Four (4) organizations impact the submission’s path and they are easy to confuse.
CCCS, the Canadian Centre for Cyber Security, is the closest analogue to the FedRAMP PMO. They review packages and produce a risk report that goes to departments, who then decide for themselves whether to authorize an offering. They are not issuing you an authorization.
PSPC, Public Services and Procurement Canada, handles procurement and contracts. This is more akin to centralized procurement rather than every agency running independently. PSPC is where the requirement that an assessment be performed originates. They also happen to own the physical and personnel security checks.
SSC, Shared Services Canada, is the other procurement route and focuses on enterprise Cloud Service Providers (CSPs). The closest US comparison is what the FedRAMP Joint Authorization Board (JAB) was attempting for government-wide use prior to being disbanded.
There is also a supplier background function, referred to as Supply Chain Integrity in the published guidance, that reviews company ownership, geolocation, business practices and corporate history, including things like prior bankruptcies. There is no FedRAMP analogue and nothing you can prepare for it in a control workbook.
No Contract, no assessment
This is the gate nobody expects, and it stops most speculative entries cold.
You need an established contract with PSPC or SSC, or you need to be actively responding to an active Request for Proposal (RFP). Those are the two (2) organizations holding contract vehicles. If you have neither a contract nor a live RFP, CCCS will not accept you. There is no path where you get assessed first and go looking for buyers afterward.
If you are coming through an RFP, the sequence is that the department down-selects the vendors it prefers, then works with CCCS on a “light” gap assessment to see which providers look viable. At this same gate, the supplier background checks happen. If both come back with no issue, you get a kickoff.
Before the “real” assessment begins, CCCS works through the Services Workbook with the submitting organization (the CSP, in this case) to determine appropriate scope of the system and the requirements to be leveraged. That document describes in detail the services you are proposing, the underlying Infrastructure as a Service (IaaS) services in use, and your sub-processors (i.e., external service providers that do not come from your IaaS provider). There is also an architecture design review during the kickoff. Only once the Services Workbook is completed by the CSP to the satisfaction of CCCS can the assessment path be determined.
Worth knowing: Sub-processors are where CCCS focuses hardest. Unlike FedRAMP, they do not require your sub-processors to be FedRAMP-authorized; however, CCCS needs to know exactly who they are and where they are physically and logically located.
The eligibility gates
Some prerequisites are disqualifying rather than just inconvenient.
Data MUST sit in Canadian data centers. Data sovereignty rules apply to EVERYTHING, including the management plane. You cannot run a Canadian offering from a US management plane. You MUST retain a FedRAMP-authorized third-party assessment organization (3PAO). Engaging a 3PAO that is not FedRAMP-authorized will invalidate the assessment. You need current compliance documentation, within one year: the ISO 27001 full report and certificate, the ISO 27017 full report and certificate, and the SOC 2 Type 2 full report and certificate. All three (3) reports and all three (3) certificates.
The one (1) gate that stops SaaS providers cold in their tracks is the hyperscaler requirement. If your offering is hosted on an IaaS or Platform as a Service (PaaS) provider, that provider must already have been assessed at the same level you are seeking. That assessment can have happened previously or be running concurrently with yours, but it cannot be absent: you cannot be first through the door on someone else’s platform. If you own the data center and operate your own IaaS or PaaS, you can absolutely progress, but you are taking responsibility for the full stack from the ground up. The PSPC physical inspection and every infrastructure-layer control land on you rather than being inherited, and your timeline and evidence burden should be planned accordingly.
There is no equivalent to FedRAMP’s showstopper control list. The closest thing to a hard stop is data residency, which is exactly why sub-processors get the scrutiny they do. FIPS-compliance comes up and is treated similarly to how it is handled under FedRAMP. Lack of FIPS-compliance would not stop CCCS finishing a review, but it would likely result in a very high finding for the department to consider.
As of August 2026, the FedRAMP recognition path is not being accepted
The documented process describes three (3) paths.
Standard is a full assessment against the ITSG-33 controls. FedRAMP recognition allows for 3PAO reuse of FedRAMP assessment testing results when combined with a gap assessment on the security controls Canada requires that are not included in the FedRAMP baseline scope. Legacy is the “old” approach and is being phased out. The reason is practical rather than preferential: Legacy assessments predate the current Medium Cloud Profile and template set, so their results do not map cleanly onto today’s Controls Workbook. CCCS ends up re-baselining those providers onto the current process anyway (more on that below), which means a Legacy assessment consumes review effort without producing a result CCCS can compare across providers or carry into the annual refresh cycle.
As of August 2026, the Cyber Centre is not accepting the recognition path, coinciding with FedRAMP’s introduction and move to a primary path of FedRAMP 20x.
To be clear about sourcing, this is guidance Fortreum has received directly through conversation. It is not yet reflected in the published program documents. Confirm the position with your own Cyber Centre point of contact before making a decision on it.
The rationale is easy to follow. Recognition consumed four FedRAMP artifacts: the SSP, the test case procedures with 3PAO findings from Security Assessment Report (SAR) Appendix B, the annual assessment controls selection worksheet, and the Plan of Action & Milestones (POA&M). Under the Consolidated Rules for 2026 (CR26), FedRAMP retires SSPs and POA&Ms completely and moves to machine-readable Key Security Indicators (KSIs), so two (2) of the four (4) will soon cease to exist. Recognition also required an authorized Rev 5 baseline, and new Rev 5 applications close in June 2027 with existing ones sunsetting by the end of 2028. Without knowing the future, some form of recognition may return as FedRAMP 20x rules, requirements, and guidelines settle and there is a stable artifact set to recognize.
Practically, CSPs should budget for a full assessment rather than a gap assessment. The FedRAMP work is not wasted as the Medium Cloud Profile is still deliberately aligned to the FedRAMP baseline and the collected evidence will still map to the requirement(s). What is unavailable today is the “shortcut” that lets a 3PAO test ONLY the deltas.
Clearances, and the reciprocity nobody mentions
This is the part I would raise on the FIRST call as it drives organizational design rather than documentation.
The rule is that anyone acting as a privileged user maintains a clearance one level above the information they can reach. In practice that means Secret for both PBMM and PBHVA. Not Reliability, which is the level most people assume and which covers general access to protected information. Secret is a materially longer and more invasive process, PSPC grants it, and it is not something to start once the 3PAO work is already underway.
THIS is the part that changes the staffing conversation. Due to the system requirement to be maintained inside a Canadian data center, the default assumption is that clearance goes to a Canadian citizen. But if someone is working from the US, clearance reciprocity CAN be leveraged. Canada holds reciprocity with a number of other countries as well, though validation gets harder the further you go from the obvious ones. What you need is a bilateral agreement between Canada and the other country, and NATO, Five Eyes and Israel are the straightforward cases.
That is a VERY different answer from “you have to hire Canadians.” If your platform engineers are US-based and already cleared, there is a route. If they are in a country without a bilateral agreement, there is not. That is an architecture problem rather than an HR one: either a cleared support tier or technical controls that probably keep uncleared staff out of the data plane.
On the physical side, PSPC sends a point of contact to physically inspect the data center and check access to the racks and servers. Those checks are performed by PSPC, not your 3PAO, which is why the Physical and Environmental Protection and Personnel Security families come off your 3PAO’s plate. Note that Maintenance and Media Protection do not. Those are still yours to evidence even though they are conventionally handled during a data center review.
How the control assessment actually works
Your 3PAO completes the Cloud Security Controls Workbook, recording Observations, Evidence and an Assessment Decision for each control, plus mitigation measures and the prior year’s result. There is no penetration testing or vulnerability scanning in scope. CCCS keeps the focus on security control requirements. This is a meaningfully different exercise from a FedRAMP assessment even though the control lineage is shared.
The Assessment Decision matters more than people expect, because Inherited sits alongside Met, Not Met and Not Applicable. Inheritance from the underlying hyperscaler is real and supported, but it is not automatic. The applicability columns do not tell you what is inheritable, and an Inherited decision still requires Observations and Evidence behind it. If you have not collected your hyperscaler’s assessment artifacts, Inherited is not an answer, it is a gap with a friendlier label.
Evidence from a US instantiation can be used where a control is genuinely common, though evidence from the Canadian region is preferred wherever it is available.
There are two (2) control-level notes that come up constantly. CM-8 requires asset details including NetBIOS name and baseline configuration name, which is leftover 2014 language. For clarity, what is needed is the ability to uniquely identify devices. How you do that is yours to define and your 3PAO’s to validate. IA-2(12) covers PIV card acceptance and there is no PIV-equivalent in Canada. Privileged users must use hardware tokens, and the specifics get negotiated with the procurement group.
When the workbook and SAR are complete, they go to you. At this time, you will deliver them to CCCS. CCCS performs its own risk calculation on the findings and produces the risk report that departments consume.
What to expect after the first assessment
Everyone is being re-baselined onto the new process right now, so expect a full assessment. Going forward the model is a core set of controls, every failure from the previous year, and roughly a third of the remainder annually, so the full profile is covered across three years- very close to how FedRAMP handles it.
In regards to adding services, the process works through the refresh cycle. Also, a process called abridgement is specifically designed for adding services and/or changes outside of a refresh, but CCCS has run very few and generally directs providers to fold new services into the next refresh instead.
One (1) expectation to set internally: there is no FedRAMP Marketplace equivalent. No public documentation hub, no published listing of what to expect. What exists is the template set, meaning the SAR, Services Workbook and Controls Workbook, plus two PDFs describing the process at a high level. Much of what you need comes from your Cyber Centre point of contact directly, which is also why the most consequential change we know about right now, the recognition path, reached us in conversation rather than in a revised document.
What I would sequence differently
Most providers we talk to arrive in roughly the reverse of this order: they engage a 3PAO, start populating a controls workbook, and then discover the contract, hyperscaler and clearance gates several months in. The sequence below is the one we would recommend instead, in priority order.
1. Secure the contract or the live RFP first, because without one there is no assessment to schedule.
2. Start Secret clearances for privileged users as early as the contract allows and work out which of your existing staff can come through reciprocity before you assume you need to hire.
3. Confirm your hyperscaler’s Canadian assessment level before committing to a timeline and get your sub-processor list clean before the Services Workbook review, because that is where the early scrutiny lands.
4. Treat the assessment components as parallel tracks with different counterparties, because that is what they are.
5. Confirm current requirements with your Cyber Centre point of contact rather than assuming a published process document is current. On a program still settling and taking dependencies on a US program mid-transition, the document and the practice are not going to stay in sync.
If you are weighing a Canadian expansion, Fortreum can help on either side of the process, depending on where you are. On the advisory side, we walk your current authorization boundary against the CCCS Medium profile, tell you specifically what carries, what does not, and where your support model is going to run into the clearance requirements, and help you get the Services Workbook, sub-processor inventory and supporting documentation in shape before kickoff. On the assessment side, as a FedRAMP-authorized 3PAO, we perform the Cloud Security Controls Workbook assessment and produce the SAR that goes to CCCS. Fortreum assesses cloud services against FedRAMP, GovRAMP, SOC, ISO and Canadian Protected B requirements.
