Step 7 — Authorization Decisions: ATOs, IATOs, Risk Acceptance and Sign-Off
The mechanics of the decision itself — who signs, what they are signing, what conditions attach, and what an authorization does not mean
The package arrives. Somebody has to sign — or not. This post is about that moment, mechanically: who may sign, what the options are, what conditions can attach, and what the signature actually commits the signer to.
Why decisions matter is in Part 3. Who owns a risk afterwards is in the risk register. This is the signature itself.
An authorization is not permission. It is a person taking responsibility for a specific system, as described, on specific evidence, for a specific period.
Who Is Allowed to Sign#
Someone senior enough to carry the consequence, and independent enough not to be approving their own delivery.
A senior Federal official or executive with the authority to authorize (i.e., assume responsibility for) the operation of an information system … at an acceptable level of risk to agency operations (including mission, functions, image, or reputation), agency assets, individuals, other organizations, and the Nation.
CNSSI 4009-2022, via the NIST glossaryAssume responsibility for.1 ITSG-33 frames the authorizer's role identically — accepting the risks of relying on the system.2 In practice this is usually the business executive who owns the service, not the head of IT security.
Delegation is common and legitimate. It moves the signature. It does not move the accountability: a delegated authorizer signs on behalf of someone who still carries it.
The Three Decisions#
| Decision | Means | Used when |
|---|---|---|
| Authorize | Operate, accepting the residual risk as described | The risk is within appetite and the evidence supports it |
| Authorize with conditions | Operate, provided specific obligations are met by specific dates | The risk is acceptable if named actions happen |
| Deny | Do not operate until specified remediation is complete | The risk exceeds appetite, or the evidence does not support a decision |
The second is the most useful and the most abused. Conditions must be specific, dated and owned, or they are decoration. "Continue to improve access management" is not a condition. "Deploy the access review tool and complete the first review by 31 January, owner: Director of IT Operations" is.
Time-Bound Authorizations#
A time-limited authorization is a real instrument with a real failure mode: the expiry date passes, nobody notices, and the system operates unauthorized.
ATO and IATO: Whose Vocabulary?#
The section Part 2 set up.
ATO — authorization to operate — and IATO — interim authorization to operate — are NIST Risk Management Framework and FedRAMP terms.3 ITSG-33 speaks of authorization and authority to operate. The interim construct has no standard Canadian instrument, though departments do issue time-limited approvals under local names.
This matters practically. A Canadian reader who learned "IATO" from an American source will not find it in their departmental template, and a department that borrows the term without defining it will find that three people mean three things by it. Use your department's vocabulary, define it in the methodology, and treat the American terms as translations.
Risk Acceptance Is Not Authorization#
| Risk acceptance | Authorization | |
|---|---|---|
| Scope | One specific risk | The whole system, all its residual risk |
| Signer | The risk owner | The authorizer |
| Can exist without the other? | Yes — a risk can be accepted on an authorized system | Yes — a system can be authorized with several risks formally accepted |
Accepting a risk is a decision inside the system. Authorizing is a decision about the system. The risk register tracks the first; the authorization record holds the second.
What the Signature Commits You To#
Scroll sideways to see the full diagram →
Read the commitment aloud: the signer accepts the residual risk as described in the SAR, for this system inside its boundary, under these conditions, for this period, on this evidence as of the assessment date.
Every qualifier is a limit. A new component outside the boundary, a condition past its date, evidence that has aged out — each one means the signature no longer covers what is actually running. This is why the SAR's scope and limitations sections matter, and why Step 8 exists.
When the Answer Is No#
Denial is legitimate, and its rarity is itself a finding about a program.
If no system has ever been denied, either the estate is exceptional or the decision is a formality. An authorizer who has never said no has never really been asked.
Withdrawal is the same power exercised later: when a condition is breached or the risk changes materially, an authorization can be revoked. ITSP.50.105 says so directly — if residual risk remains unacceptable after remediation, authorizers may revoke the authority to operate.4 Revocation is not failure. It is the mechanism working.
Where CtrlFort Fits#
The authorization decision is the one part of SA&A that must remain entirely human, and the one most often recorded in an email that nobody can find a year later.
CtrlFort Assess keeps the decision human and keeps the record. Risk acceptances are made and signed by the people who hold the roles, with a review date recorded so a stale acceptance stays visible rather than lapsing — and the residual risk accepted is the rated risk from the assessment, linked, not a retyped number.
What CtrlFort does not do is recommend the decision. It assembles the package, shows the authorizer the chain from framework through evidence to residual risk — the five questions — and records what was chosen. The signature is theirs. The assessment intelligence architecture is built on the principle that humans decide, and this is the decision it most means.5
Final Thoughts#
Three options, not one. Conditions with owners and dates. A record in the authorizer's own words. And a mechanism that notices when the period ends.
Previous: Step 6 — Security Assessment Reports and POA&Ms · Next: Step 8 — Continuous Monitoring and Ongoing Assurance
Frequently Asked Questions#
Do Canadian departments issue ATOs?#
They issue authorizations. ATO is the RMF and FedRAMP name for the same decision. The term has crept into Canadian usage informally; use it if your department does, but define it, and know that ITSG-33 does not use it.
What is an IATO, and is it a Canadian concept?#
An interim authorization to operate — a time-limited approval pending remediation, from the American frameworks. Canada has no standard equivalent, though departments issue time-limited approvals under their own names. If you use one, the expiry needs an owner.
What is the difference between accepting a risk and authorizing a system?#
Acceptance is about one risk, signed by its owner. Authorization is about the whole system and all its residual risk, signed by the authorizer. A system can be authorized with several risks formally accepted inside it.
Can an authorization be revoked?#
Yes. When a condition is breached or the risk changes materially, the authorizer can withdraw it pending remediation. A program that has never revoked or denied an authorization should ask whether the decision is real.
References#
- Authorizing Official — glossary entry, citing CNSSI 4009-2022 ↩National Institute of Standards and Technology · https://csrc.nist.gov/glossary/term/authorizing_official
- 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
- NIST SP 800-37 Rev. 2 — Risk Management Framework for Information Systems and Organizations ↩National Institute of Standards and Technology · https://csrc.nist.gov/pubs/sp/800/37/r2/final
- ITSP.50.105 — Guidance on cloud security assessment and authorization ↩Canadian Centre for Cyber Security · https://www.cyber.gc.ca/en/guidance/guidance-cloud-security-assessment-and-authorization-itsp50105
- Policy on Government Security ↩Treasury Board of Canada Secretariat · https://www.tbs-sct.canada.ca/pol/doc-eng.aspx?id=16578
- Directive on Security Management, Appendix B § B.2.6.4 ↩Treasury Board of Canada Secretariat · https://www.tbs-sct.canada.ca/pol/doc-eng.aspx?id=32611