ITSP.10.033 is the current CCCS publication for security categorization and control profiles. It replaces the day-to-day rhythm many teams still call “ITSG-33.” This guide is written for the practitioner who has to make the switch land in real projects — inside real assessor conversations, on real ATO timelines.
1 · Why the guide exists
Every Government of Canada delivery team eventually meets the same three questions from an assessor: what is your boundary, what is your categorization, and where is your evidence? This guide turns those questions into a repeatable delivery pattern, backed by the same artifacts you can open from this site: the SoS, the TRA, and the SSP.
2 · What changed from ITSG-33
The most important change is orientation: ITSP.10.033 assumes shared-service infrastructure (CCCS Medium cloud, enterprise identity, enterprise SIEM) and treats system-level teams as consumers of those services, not builders of everything from scratch. Control-profile references also anchor to the NIST SP 800-53 family, so the language your assessor uses lines up with the language every commercial partner already uses.
- Control catalogue — family-and-number references to NIST SP 800-53, not the ITSG-33 “class” groupings.
- Inheritance is explicit — state which control is provided by which service, with the service's own authorization identifier.
- Continuous monitoring is elevated — the ATO decision is now inseparable from an evidenced monitoring plan.
- AI systems get first-class treatment — model-risk artifacts sit inside the SA&A package, not beside it.
3 · The SA&A lifecycle
The five phases have not changed in name: initiate, categorize, select, implement, assess & authorize, followed by continuous monitoring. What has changed is the density of artifacts each phase produces — and the expectation that all of them trace back to a single SSP.
Artifact map
| Phase | Primary artifact | Owner | Assessor lens |
|---|---|---|---|
| Initiate | Concept & scope memo | Business owner | Boundary sanity |
| Categorize | Statement of Sensitivity (SoS) | Business owner + privacy | Injury statements |
| Select | Control profile + tailoring statement | System security officer | Profile fit |
| Implement | SSP + SRTM + evidence store | Delivery team | Control statements |
| Assess | TRA + assessment report | Independent assessor | Residual risk |
| Authorize | ATO letter | DSO | Risk acceptance |
| Monitor | Continuous monitoring plan | Sec ops | Drift & renewal |
4 · Categorization & the SoS
Categorization is the anchor: everything else in the SA&A package inherits from it. The Statement of Sensitivity is where you record it, along with the injury statements that justify the choice.
The most common mistake at this stage is choosing a categorization from convenience rather than injury. If the injury statement in §5 of the SoS does not read like it would motivate the categorization on its own, the categorization is wrong.
5 · Control selection & tailoring
Start from the control profile that matches the categorization — typically the Medium profile for Protected B systems. Tailor down only with an explicit justification, and tailor up whenever the TRA surfaces a scenario the profile does not cover. The tailoring statement is a first-class artifact; the assessor will read it before they read the SSP.
6 · Building the SSP
The System Security Plan is the single artifact that tells an assessor what the system is, where its authorization boundary lies, and how every applicable control is implemented. The starter template on this site is scaffolded family-by-family so you can expand each family into a control-level statement without having to invent the structure.
7 · Assessment & the SRTM
The System Requirements Traceability Matrix (SRTM) is where each control statement in the SSP is tested. Every row records the control id, the implementation summary from the SSP, the assessment method, the evidence location, and the pass/fail with residual risk. An assessor should be able to reproduce every result from the evidence store alone.
8 · Authorization & the DSO
The Departmental Security Officer grants the authorization on the strength of the SSP, the TRA, and the SoS — not on the strength of the assessor's opinion. Sections 7 and 8 of the TRA exist precisely to give the DSO a defensible residual-risk statement.
9 · Continuous monitoring
An ATO expires. A continuously monitored system does not. Section 7 of the SSP captures the monitoring plan: activity, cadence, owner, evidence source. Drift is inevitable; the question the DSO asks is how quickly do you detect it.
10 · Worked examples
Chapters 10a – 10c walk two full SA&A packages: a Microsoft 365 tenant inherited from an existing enterprise ATO, and an internal AI project handling Protected B data. Both examples are cross-referenced with the starter templates on this site.
11 · Traps & anti-patterns
- Boundary drift — the TRA scope no longer matches the SSP boundary.
- Copy-pasted control statements — the same paragraph appears under multiple controls, betraying that no one has thought about the specifics.
- Categorization by convenience — the injury statements read like they were reverse-engineered from the categorization.
- Silent inheritance — the SSP assumes a service is authorized without naming the ATO.
- Monitoring theatre — the continuous monitoring plan lists activities that produce no evidence anyone reviews.
12 · Where to go next
Open the three starter templates on this site — they are structured to be filled in during a workshop with the business owner, the system owner, and the security lead. The SoS should be first; the TRA and the SSP follow from it.