SA&A Terminology Explained: Controls, Findings, Risks, SARs, POA&Ms and ATOs
The vocabulary of security assessment — what each term means, what it does not, and where Canadian and American usage part ways
An assessor writes "finding". The system owner reads "risk". The executive reads "problem we must fix now". Three people, one word, and a meeting spent disagreeing about vocabulary instead of about the system.
Precision here is not pedantry. It is what lets a finding survive challenge, a risk reach the right owner, and an authorization mean what it says.
Every term in SA&A names a different thing, owned by a different person. Blur two of them and you have moved a decision without noticing.
The Control Layer#
| Term | Means | Does not mean |
|---|---|---|
| Control | A safeguard that prevents, detects or mitigates risk | A policy that describes one |
| Control enhancement | An added capability on top of a base control, numbered (01), (02)… | A separate control |
| Assurance activity | A task that increases confidence a control is properly implemented | A control |
| Control statement | The requirement, split into lettered parts A., B., C. | One requirement |
The last row matters more than it looks. A control with four lettered parts is four things to evidence, and "partially met" without a letter is not a finding anybody can act on.2
The third row is a deliberate change in the current Canadian catalogue:
We refer to assurance-related "controls" as activities, rather than controls.
ITSP.10.033An assurance activity — an engineering task, a documentation requirement, an assessment task — is something you do to gain confidence.1 A control is something the system has. Writing "control not met" against an assurance activity describes the wrong kind of thing.
The Assessment Layer#
Scroll sideways to see the full diagram →
| Term | Means |
|---|---|
| Evidence | An artifact: a configuration export, a log extract, a record, a demonstration |
| Observation | What the assessor noticed, before judging it against anything |
| Finding | A judgment that a control, or part of one, does not meet its requirement |
| Weakness | The specific deficiency a finding describes |
| Assessment procedure | How an assessor checks a control — examine, interview, test |
The chain runs evidence → observation → finding. An observation is not yet a finding; it becomes one only when measured against a requirement. Reporting observations as findings is the fastest way to lose a system owner's trust.
On assessment procedures: NIST publishes them in SP 800-53A.4 Canada does not have a centrally published equivalent — ITSP.10.033 says it lays a foundation for developing them — so departments define their own.
The Risk Layer#
| Term | Means |
|---|---|
| Threat | Something that could exploit a weakness |
| Vulnerability | The weakness itself, as exploitable |
| Inherent risk | Risk before any control is credited |
| Residual risk | Risk that remains after controls are credited |
| Risk statement | The risk in words: what is wrong, what it exposes, what could follow, for whom |
A finding lives in the assessment layer; a risk lives here. Converting one into the other is a skill in its own right, and we cover it in Step 5. The scoring — how dangerous, how exposed, what remains — is in our residual risk model.
The Document Layer#
- System security plan (SSP)What the system is and how its controls are meant to work
- Security assessment report (SAR)What the assessor found, and what risk remains
- Plan of action and milestones (POA&M)What will be fixed, by whom, by when
- Authorization packageAll of the above, assembled for the decision
SSP describes intent. SAR describes reality. POA&M describes commitment. The package carries them to the person who decides.
The Decision Layer#
| Term | Means |
|---|---|
| Authorization | A decision by a senior official to operate a system, accepting its residual risk |
| Authorizer | The person who makes it — and carries it |
| Risk acceptance | Agreeing to carry one specific risk. Narrower than authorization |
| Conditions | Obligations attached to an authorization, each with an owner and a date |
Authorization is a decision, not a document. You can accept one risk without authorizing a system, and you can authorize a system while several risks remain formally accepted.
Canadian and American Usage#
This is the section that earns the post. Most glossaries online are RMF- and FedRAMP-flavoured — FedRAMP being the US federal cloud authorization program — and they quietly mislead a Canadian reader.
| Concept | ITSG-33 / GC usage | NIST RMF / FedRAMP usage |
|---|---|---|
| The decision | Authorization | Authorization, ATO |
| The decider | Authorizer, senior official | Authorizing Official (AO) |
| Control catalogue | ITSP.10.033 | SP 800-53 Rev. 5 |
| Assessment procedures | Defined by each department | SP 800-53A Rev. 5 |
| Assurance obligations | Assurance activities, in the catalogue | Folded into controls |
| Time-boxed approval | No standard instrument | IATO, P-ATO |
| Baseline selection | Control profile | Baseline plus overlays |
The American decision is defined with unusual directness:
Official management decision given by a senior Federal official or officials to authorize operation of an information system and to explicitly accept the risk to agency operations … based on the implementation of an agreed-upon set of security and privacy controls.
CNSSI 4009-2022, via the NIST glossaryRead ATO as the RMF name for what ITSG-33 calls authorization.3 The idea is identical. The word is not — and a Canadian who learns "IATO" from an American blog will not find it in their departmental template. The catalogue-level differences are in ITSP.10.033 vs NIST SP 800-53.
Where CtrlFort Fits#
Vocabulary drifts when it lives in people's heads. Three assessors, three templates, three meanings of "partially met" — and by the third assessment nobody can compare results across systems.
CtrlFort Assess holds the vocabulary in the structure. A control, a finding, a risk and a decision are different objects with different fields, so a finding cannot be filed as a risk by accident and an assurance activity cannot be graded like a control. The chain in Figure 1 is how the platform is built, not a diagram of good intentions.
That is why this glossary is also the map of what CtrlFort tracks: each layer is a linked object, every result points back to the evidence it rests on, and the assessment intelligence architecture keeps the terms meaning the same thing on the hundredth assessment as on the first.
Final Thoughts#
Get the words right and most of the arguments in an assessment disappear, because they were never about the system. They were about which layer a sentence belonged to.
Previous: What Is Security Assessment and Authorization? · Next: Assessments Don't Reduce Risk. Decisions Do.
Frequently Asked Questions#
What is the difference between a finding and a risk?#
A finding says a control does not meet its requirement. A risk says what that could cost the organization, to whom, and how badly. The first is the assessor's judgment about a safeguard; the second is a statement an owner can decide about. One finding can produce several risks, and several findings can collapse into one.
Do Canadian departments issue ATOs?#
They issue authorizations. ATO is NIST RMF and FedRAMP vocabulary for the same decision, and it has crept into Canadian usage informally. Use it if your department does — but know that ITSG-33 does not, and that the interim IATO has no standard Canadian equivalent.5
Is a POA&M the same as a risk register?#
No. A POA&M tracks one assessment's remediation commitments. A risk register holds every risk the organization is managing, from every source, for the life of the system. Teams often run both and duplicate; our risk register post draws the line.
Who writes the SAR?#
The assessor. It records what they found and what risk remains, addressed to the authorizer. The system owner contributes control responses and the POA&M; they do not write the assessment of their own system.
References#
- ITSP.10.033 — Security and privacy controls and assurance activities catalogue ↩Canadian Centre for Cyber Security · https://www.cyber.gc.ca/en/guidance/cyber-security-privacy-risk-management/itsp10033
- 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
- Authorization to Operate — glossary entry, citing CNSSI 4009-2022 ↩National Institute of Standards and Technology · https://csrc.nist.gov/glossary/term/authorization_to_operate
- NIST SP 800-53A Rev. 5 — Assessing Security and Privacy Controls in Information Systems and Organizations ↩National Institute of Standards and Technology · https://csrc.nist.gov/pubs/sp/800/53/a/r5/final
- 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