What Makes a Security Control Mandatory in the Government of Canada?
\"Mandatory\" is a real category with real force — but it does not come from the control catalogue, and that misunderstanding costs teams months
Ask five people on a Government of Canada project which controls are mandatory and you will get five answers. Ask where the obligation comes from and the room goes quiet.
The word gets used as if it were a property of a control — as if somewhere in the catalogue there were a column marked mandatory that settles the argument. There is no such column. "Mandatory" is real, it has real force, and it comes from somewhere else entirely.
A control is not mandatory because it appears in a catalogue. It is mandatory because a policy instrument compels the outcome, or because your department decided it was.
The Catalogue Does Not Make Anything Mandatory#
Start with the document most teams point at. The Cyber Centre's Medium-impact profile — the successor to the Protected B / Medium / Medium profile most practitioners know — states its own status in its overview:1
The suggested controls and activities in this profile constitute a starting point and need to be tailored to the business, technical, and threat and risk context of each department's business activities and supporting information systems.
ITSP.10.033-01 — OverviewThe title of the publication is Suggested organizational security and privacy control and activity profile. The word is in the name. Organizational authorities "can use this profile as a reference to create organization-specific profiles" — a reference, to build from.1
The catalogue beneath it, ITSP.10.033, is a menu of controls and assurance activities.2 Neither document reaches into your department and requires anything. What they do is give you a defensible, threat-informed place to start so that you are not selecting controls from first principles.
Where the Obligation Actually Starts#
Three sources, and they behave differently.
Scroll sideways to see the full diagram →
1. Policy instruments#
The Directive on Security Management and its mandatory procedures are the floor. Appendix B — titled, plainly, Mandatory Procedures for Information Technology Security Control — requires departments to:3
Define, document, implement and maintain security controls to meet departmental IT security requirements, in accordance with departmental practices.
Directive on Security Management, Appendix B § B.2.3Read that carefully, because it is the hinge of this whole subject. The directive does not hand you a control list. It obliges your department to produce one and to meet it. Beneath B.2.3 sit specific compelled outcomes — identification and authentication to an appropriate level of assurance, access limited to users screened at the appropriate level and with a need for access — expressed as results the department must achieve, not as catalogue identifiers.3
So the policy layer mandates outcomes. Translating an outcome into control identifiers is your department's job, and the catalogue is what you translate with.
2. Your departmental profile#
This is where the word acquires its everyday meaning, and the GC cloud profile defines it exactly:4
A security control profile is a set of IT security controls that an organization establishes as minimum mandatory requirements for their information systems.
Government of Canada Security Control Profile for Cloud-Based GC Services § 1.1An organization establishes. Once your department has selected and tailored its profile and signed it, those controls are mandatory for systems in scope — not because the Cyber Centre said so, but because your department did. That is a real obligation with a real owner, and it is the one a project team actually runs into.
The practical consequence: a project cannot tailor away a control its department has locked. It can ask the department to change the profile, and it can seek acceptance of the risk of not meeting it. Those are different conversations with different people.
3. Service-specific mandated baselines#
Some workloads carry an additional, genuinely externally-set baseline. Cloud is the clearest case. The GC cloud profile "identifies the baseline security controls that must be implemented by CSPs and GC departments and agencies" for Protected B / medium integrity / medium availability cloud services.4 The control list itself now lives in the Cyber Centre's Medium Cloud Control Profile, published as Annex B of ITSP.50.103 — Appendix A of the older document has been replaced by it.45
If you are assessing a cloud-based service, check that list. It is the closest thing in the Canadian landscape to a control set handed to you rather than chosen by you.
Mandatory, Tailored, Inherited — Two Questions, Not One#
The common table sets these three side by side as if they answered the same question. They do not, and conflating them is how controls quietly go unassessed.
Two independent questions:
| Question | Answers |
|---|---|
| Is it required? | Mandatory (locked by policy or the departmental profile) · Tailorable (the project may scope it in or out with justification) |
| Who implements it? | System-specific (you build it) · Inherited (a shared platform provides it) · Hybrid (both) |
A control can be mandatory and inherited. That is the normal case for physical security, personnel screening and enterprise authentication. Inheritance changes who builds and who produces evidence. It does not change whether the control is required, and it does not remove your obligation to confirm that what the provider delivers actually meets your requirement.
Managing Them Without Drowning#
Four moves, in order of how much time they save.
Claim inheritance deliberately. Physical protection, personnel screening (PS-2 covers position risk designation, PS-3 the screening itself) and enterprise identity are usually delivered centrally. Record them as inherited, import the provider's evidence, and record the one thing that makes the claim defensible: confirmation that the provider's parameter values meet yours.
Resolve parameters before you build. A mandatory control with an unfilled bracket is not yet a requirement — nobody can implement it and no assessor can test it. Audit records retained for how long. Account lockout after how many attempts. Settle these at profile time.
Compensate rather than ignore. Where a control cannot be met as written, an alternative safeguard delivering equivalent protection is a legitimate, catalogue-sanctioned answer. What makes it defensible is the written argument that the alternative achieves the control's objective — not the existence of the alternative.
Where it still cannot be met, make it a risk decision. GC practice is not an informal waiver. It is a documented residual risk accepted by the person with the authority to accept it, recorded in the authorization package and carried in the plan of action and milestones. The authorization decision is where that lands.
Where CtrlFort Fits#
The reason "which controls are mandatory" is hard to answer on most projects is that the answer lives in four places at once — a policy instrument, a departmental profile spreadsheet, a cloud baseline, and somebody's memory of a decision made in a workshop.
CtrlFort Assess holds the framework and its controls as the objects the assessment is built on, so the control set a system is being judged against is a single, inspectable thing rather than a reconciliation exercise. Control Intelligence carries, for each control, the objective, the assessment criteria, the expected evidence and the assurance activities to perform — which is where an obligation and its origin stay attached to the control itself. Because requirements, controls, evidence and determinations are separate linked objects, the chain from a policy requirement through to a determination stays traceable, and the assessment intelligence architecture keeps it consistent across every system assessed against the same profile.
Deciding what your department makes mandatory is a human judgment, and it should be. What the platform removes is the part where nobody can say what was decided.
Final Thoughts#
"Mandatory" is not a property you look up. It is an obligation somebody created — a policy writer, a departmental security authority, a cloud baseline — and every one of those obligations has an owner you can name and a document you can cite.
Teams that can name the source move quickly, because they know which arguments are worth having and with whom. Teams that cannot end up treating a suggested profile as law, which is slower, more expensive, and no safer.
Previous: Choosing the Right Controls · Next: Control Parameters in ITSP.10.033
Frequently Asked Questions#
Are the controls in ITSP.10.033-01 mandatory?#
Not on their own. ITSP.10.033-01 is titled a suggested profile and states that its controls "constitute a starting point and need to be tailored to the business, technical, and threat and risk context" of each department. It becomes mandatory for your systems at the point your department adopts and signs a profile derived from it.
Can a project team remove a mandatory control?#
No — not unilaterally. A control locked by a departmental profile can only be changed by the authority that set the profile. What a project can do is propose a compensating control, or document non-implementation as a residual risk and seek acceptance from the authorizer. Both routes are recorded; neither is a quiet deletion.
Does inheriting a control from a shared platform make it someone else's problem?#
It moves the implementation and the evidence, not the accountability. ITSP.10.033 warns explicitly that matching control identifiers do not imply matching protection, and that parameters must be examined before a common control is treated as adequate. You still confirm the provider's values meet your requirement.
What is mandatory for cloud-based services specifically?#
The GC cloud profile identifies baseline controls that must be implemented for Protected B / medium integrity / medium availability cloud services. The control list is now the Cyber Centre's Medium Cloud Control Profile, published as Annex B of ITSP.50.103, which replaced Appendix A of the original profile document.
Is "mandatory" the same as "high priority"?#
No, and mixing them causes trouble. Mandatory describes the source of an obligation. Priority describes the order in which you address gaps, which comes from risk. A mandatory control with a trivial gap can reasonably wait behind a tailorable control with a serious one.
References#
- Suggested organizational security and privacy control and activity profile — Medium impact (ITSP.10.033-01) ↩Canadian Centre for Cyber Security · https://www.cyber.gc.ca/en/guidance/cyber-security-privacy-risk-management/suggested-organizational-security-privacy-control-activity-profile-medium-impact-itsp10033-01
- Security and privacy controls and assurance activities catalogue (ITSP.10.033) — Concepts and structure ↩Canadian Centre for Cyber Security · https://www.cyber.gc.ca/en/guidance/cyber-security-privacy-risk-management/itsp10033/concepts-structure
- Directive on Security Management, Appendix B — Mandatory Procedures for Information Technology Security Control ↩Treasury Board of Canada Secretariat · https://www.tbs-sct.canada.ca/pol/doc-eng.aspx?id=32611
- Government of Canada Security Control Profile for Cloud-Based GC Services ↩Treasury Board of Canada Secretariat · https://www.canada.ca/en/government/system/digital-government/digital-government-innovations/cloud-services/government-canada-security-control-profile-cloud-based-it-services.html
- Guidance on the Security Categorization of Cloud-Based Services (ITSP.50.103) ↩Canadian Centre for Cyber Security · https://www.cyber.gc.ca/en/guidance/guidance-security-categorization-cloud-based-services-itsp50103