Step 8 — Authorization Is Not the End: Continuous Monitoring and Ongoing Assurance
An authorization describes a system at a moment. Systems do not stay at that moment — and the decision is only as current as what you know
An authorization is a statement about a system as it was, on evidence as it was, under conditions as they were. All three decay.
The question is not whether your authorization becomes stale. It is whether you find out before someone else does.
Authorization is maintained, not achieved. Steps 1 through 7 produce something perishable, and this step is what keeps it alive.
That is not a slogan; in the Government of Canada it is a requirement. The Directive on Security Management tells departments to:
Evaluate and maintain authorization throughout the information system's operational life cycle.
Directive on Security Management, Appendix B § B.2.6.5Throughout.6 Not at the start, and not every three years.
Three Things That Decay#
Scroll sideways to see the full diagram →
| What decays | How | Who usually notices |
|---|---|---|
| The system | Deployments, configuration changes, new integrations, new data types | Operations — sometimes |
| The evidence | A log extract from eighteen months ago proves nothing about today | Almost nobody |
| The threat | A control adequate against last year's threat may not be adequate now | Security — if asked |
Most programs monitor the first, occasionally refresh the second, and revisit the third only after an incident.
What Continuous Monitoring Actually Watches#
NIST's definition is short, and the operative word is ongoing:
Maintaining ongoing awareness of information security, vulnerabilities, and threats to support organizational risk management decisions.
NIST SP 800-137To support decisions.1 Monitoring is not a dashboard for its own sake; it exists so the authorizer's decision stays informed after it was made. Concretely:
- Control stateFor controls that can be observed automatically — configuration, access, patch level
- Evidence freshnessAgainst the validity window set per control type in Step 3
- The POA&MMilestones met, slipped, or silently re-dated
- Material changeAnything crossing the threshold that would have changed the assessment
- Conditions and expiryThe authorization's own obligations, and its date
- IncidentsAnd what they say about the controls that were supposed to prevent them
ITSP.50.105 frames it the same way — monitoring exists to determine whether the service is still operating within its authorization parameters.3
Triggers for Reassessment#
Event-driven, not calendar-driven. A three-year cycle guarantees the assessment is stale for two years and eleven months of it.
| Trigger | Why it matters |
|---|---|
| Material architecture change | The boundary or the components moved |
| New data type, or higher categorization | The profile may no longer fit |
| Change of hosting model or provider | The inheritance list is now wrong |
| Significant incident | A control the authorization relied on demonstrably failed |
| Expiry of a relied-upon attestation | The independent evidence has lapsed |
| Breach of an authorization condition | The signature's terms no longer hold |
| A change to the control catalogue itself | The requirements moved under you |
Ongoing Authorization#
The shift from periodic re-authorization to a standing authorization sustained by monitoring evidence. NIST RMF treats it as the destination of the monitor step.2
Be honest about the precondition. Ongoing authorization only works if the monitoring is real — if control state is actually current, evidence actually refreshed, conditions actually tracked. A program that cannot produce current control state has not earned ongoing authorization. It has simply stopped re-checking and called it a policy.
Control Drift#
Nobody decides to weaken a control. A firewall rule is added for a migration and never removed. An exception granted for a quarter becomes permanent. A service account accumulates entitlements one ticket at a time.
Drift is the normal behaviour of operated systems, and it is why monitoring exists. The controls the authorization relied on are not the controls running eighteen months later unless something is watching the difference.
When Something Drifts#
ITSP.50.105 names three responses when a service moves outside its authorization parameters: implement temporary measures to protect the business activity, update the controls to correct the deficiency, or accept the new level of residual risk — and if the risk remains unacceptable, the authorizer may revoke the authority to operate.3
That last sentence is the one worth reading twice. An authorization is a live decision that can be withdrawn, not a certificate with an expiry date.
Where CtrlFort Fits#
The staffing problem above is the case for tooling, and it is why CtrlFort Assess treats assurance as a state rather than a date.
Every determination carries the evidence it rests on, so what was reviewed and when is a fact of the record rather than a memory. Accepted risks carry review dates, so an acceptance that has quietly aged is visible on the risk register before an incident makes it visible. And because a system, its controls, its evidence and its findings are linked objects, a change to one of them — a new component, a new catalogue — is a change to something the results are attached to, which is what lets the assessment intelligence architecture trace which determinations a change touches.
The authorizer still decides what to do. CtrlFort makes sure they find out first.5
The Series, in One Page#
| Step | The job | Post |
|---|---|---|
| — | Understand the discipline | What Is SA&A? |
| — | Get the words right | SA&A Terminology |
| — | Understand why decisions matter | Assessments Don't Reduce Risk |
| — | Know what evidence must be | Defensible Evidence |
| 1 | Categorize and draw the boundary | Scope |
| 2 | Select and tailor the controls | Profile and Tailoring |
| 3 | Collect the evidence | Evidence Collection |
| 4 | Judge each control | Control Effectiveness |
| 5 | Turn findings into risk statements | Finding to Risk |
| 6 | Write the report and the plan | SARs and POA&Ms |
| 7 | Make the decision | Authorization Decisions |
| 8 | Keep it alive | This post |
Final Thoughts#
Every step before this one produced a decision that was true on a date. This step is the only one that keeps it true.
Previous: Step 7 — Authorization Decisions · Start of series: What Is Security Assessment and Authorization?
Frequently Asked Questions#
How long does an authorization last?#
As long as the system stays within the parameters it was authorized under — its boundary, its conditions, its evidence and its period. Not a fixed term. When any of those change materially, the authorization needs to be revisited.
What changes require a reassessment?#
Material architecture change, a new data type or higher categorization, a change of hosting or provider, a significant incident, expiry of a relied-upon attestation, breach of a condition — and a change to the control catalogue itself.
What is the difference between continuous monitoring and ongoing authorization?#
Monitoring is the activity: watching control state, evidence, conditions and change. Ongoing authorization is the outcome: a standing decision sustained by that monitoring instead of by periodic re-assessment. The second depends entirely on the first being real.
Does a control catalogue change trigger a reassessment?#
Yes. When the requirements move — as they did on 31 March 2026 with ITSP.10.033 — an authorization assessed against the previous catalogue is assessed against a superseded requirement set. The size of the delta varies; the need to look does not.
References#
- NIST SP 800-137 — Information Security Continuous Monitoring for Federal Information Systems and Organizations ↩National Institute of Standards and Technology · https://csrc.nist.gov/pubs/sp/800/137/final
- 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
- 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
- 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
- Directive on Security Management, Appendix B § B.2.6.5 ↩Treasury Board of Canada Secretariat · https://www.tbs-sct.canada.ca/pol/doc-eng.aspx?id=32611