Step 1 — Getting the Scope Right: Security Categorization and Assessment Scoping

Categorization decides the profile. The profile decides the control set. The control set decides the assessment scope and the evidence burden. Get the first step wrong and everything downstream is wrong — in a way that does not surface until the report is half-written.

Two questions live inside "getting the scope right", and readers routinely fuse them:

Categorization asks how much injury would a compromise cause? Scoping asks which components are we making that judgment about?

You can answer either correctly and still fail, because they are different questions.

Categorization: How Much Injury#

Injury is assessed against three objectives, and the assessment is per objective, not per system:

A case management system may be Protected B — the Government of Canada marking for information whose compromise could cause serious injury — for confidentiality, and low for availability. Treating one level as "the" level — usually the highest — inflates the control set and the assessment with it. The TBS standard is explicit that the objectives are examined apart:

Separately.⁶ The standard then allows either a single overall category or separate categories per objective — and the second is the one that keeps the control set honest.

ITSP.50.103 sets out the method for cloud services in four steps, and it generalizes: develop an injury table, inventory the business processes and information, assess the injury, then group into business domains.⁴ The Statement of Sensitivity many departments produce is the record of that work.⁵

The Authorization Boundary#

The authorization covers a system, and somebody has to say where the system stops.

Two halves.¹ Everything inside is assessed, or explicitly inherited from something that was. Everything outside is a dependency: relied on, not controlled, authorized elsewhere or not at all.

The boundary is not a network diagram. It is a statement of accountability — these components, this owner, this decision.

Drawing It in Practice#

The hard cases are the same everywhere, and there is no universal answer. There is a question that settles each.

What You Can Inherit#

Inheritance is how an assessment stays finite. If a hosting platform has been assessed and authorized, systems on it inherit those controls rather than re-evidencing them.²

Two conditions. The inherited control must actually be provided by the platform for your system — not merely available. And the responsibility split must be written down, control by control, because "the platform handles that" is the sentence most often said and least often true.

The cloud version of this — provider versus consumer responsibility — is walked through in Cloud Security Assessment and Authorization.

Scope Creep and Scope Denial#

The second is worse. A creeping scope wastes time. A denied scope produces a signature on a system that does not exist.

What "Done" Looks Like#

Step 1 is complete when four things exist:

1. A categorizationPer objective, recorded, approved by someone with business authority
2. A boundary diagramSeen and agreed by the system owner, the assessor and the operators
3. An inheritance listWhat is inherited, from what, and where that thing's authorization lives
4. A profile decisionThe control profile that follows from the categorization — the input to Step 2

If any is missing, Step 2 will be built on sand. Departmental accountability for all four sits with the department under the Policy on Government Security,³ not with the assessor.

Where CtrlFort Fits#

Scope drifts because it lives in a diagram someone drew in month one and nobody opened in month three. Components get added, an integration goes live, and the assessment keeps running against the boundary as it was.

In CtrlFort Assess a system is a linked object with a hierarchy, not a picture. Solutions and components roll up to the system; controls, evidence and findings attach to it; and the risk register uses the same hierarchy, so a risk raised against a component reaches the right owner without anyone re-deciding whose system it was. A finding is raised against something that has a place in that structure — which is what lets "that is out of scope" be answered by the record rather than by memory.

Everything downstream — the tailored controls in Step 2, the evidence in Step 3, the results in Step 4 — attaches to that same system object, which is how the assessment intelligence architecture keeps an authorizer's view of a system consistent from categorization to decision.

Final Thoughts#

Get the categorization approved and the boundary drawn before you collect a single artifact. Everything after Step 1 is cheaper to do right than to redo.

Previous: What Makes Assessment Evidence Defensible? · Next: Step 2 — Profile Selection and Control Tailoring

Frequently Asked Questions#

What is the difference between categorization and classification?#

Classification labels information — Protected B, Secret. Categorization rates the injury to the business activity if a system's confidentiality, integrity or availability were compromised. Classification feeds categorization; it does not replace it, because a system holding Protected B data may still be low for availability.

Can one system have different levels for confidentiality and availability?#

Yes, and most do. The objectives are assessed independently. Collapsing them to the highest level inflates the control set for no security benefit.

What belongs inside the authorization boundary?#

Every component the authorizer is taking responsibility for. The practical test: if it fails or is compromised, is this the authorization that covered it? If yes, it is inside. If another authorization covers it, it is a dependency.

Can we inherit controls from a cloud provider?#

Yes, for the controls the provider actually implements for your service — evidenced by their attestation, with a scope and period you have checked. The controls you configure remain yours. The split is written down per control, or it will be argued about per finding.

References#

1. Authorization Boundary — glossary entry, citing CNSSI 4009-2022 ↩National Institute of Standards and Technology · https://csrc.nist.gov/glossary/term/authorization_boundary
2. ITSG-33 Annex 2 — Information System Security Risk Management Activities ↩Canadian Centre for Cyber Security · https://www.cyber.gc.ca/en/guidance/annex-2-information-system-security-risk-management-activities-itsg-33
3. Policy on Government Security ↩Treasury Board of Canada Secretariat · https://www.tbs-sct.canada.ca/pol/doc-eng.aspx?id=16578
4. ITSP.50.103 — Guidance on the security categorization of cloud-based services ↩Canadian Centre for Cyber Security · https://www.cyber.gc.ca/en/guidance/guidance-security-categorization-cloud-based-services-itsp50103
5. ITSG-33 Annex 1 — Departmental IT Security Risk Management Activities ↩Canadian Centre for Cyber Security · https://www.cyber.gc.ca/en/guidance/annex-1-departmental-it-security-risk-management-activities-itsg-33
6. Directive on Security Management — Appendix J: Standard on Security Categorization ↩Treasury Board of Canada Secretariat · https://www.tbs-sct.canada.ca/pol/doc-eng.aspx?id=32614