The Upgrade Nobody Flagged
A system holding controlled unclassified information has an authorization with annual assessment and quarterly scanning. In March the team migrates to a new cloud region, replaces its commercial database with an open-source one, and enables a public API for mobile clients. No change request reaches the security team; the migration is documented only in an operations wiki. The June scan surfaces four new high findings against the API. The authorization package still describes the old architecture, and the annual renewal is due in August. The program manager wants to let the August cycle catch it and points out that no incident has occurred.
1. Was this a significant change? Apply the criteria rather than the labels used internally.
Read the worked answer
Yes - three times over. Significant change is judged by effect on security posture, not by whether anyone filed paperwork:
- New hosting environment and region changes who provides the underlying controls, what the shared responsibility split is, and where the data resides.
- Database platform replacement changes hardening baselines, patching, configuration management, and possibly encryption and logging behavior.
- New public API adds an externally reachable interface, new authentication and authorization paths, and new boundary surface - and it is already producing high findings.
Any one of these warrants a change assessment; together they make the current authorization package an inaccurate description of the system. The absence of a change request is evidence that the change process failed, not evidence that the change was minor.
2. What must happen before the August renewal, and can the system keep operating in the meantime?
Read the worked answer
Before renewal: update the boundary and SSP to describe the current architecture; re-assess the affected control families - at minimum boundary protection, access control, system and communications protection, configuration management, and risk assessment, plus any privacy or data-location controls tied to the new region; analyze and remediate or formally accept the four high findings; update the POA&M; and produce assessment results the AO can act on. If the change is significant enough to invalidate the existing authorization, the reauthorization decision should not wait for the calendar.
Continued operation is defensible only with the AO's awareness and documented interim risk mitigation - for example restricting the API behind authentication and rate limiting, prioritizing the high findings, and setting a decision date. 'No incident has occurred' is not a risk argument; it is a statement about luck and detection capability.
3. Where did continuous monitoring fail, and what would you change?
Read the worked answer
Continuous monitoring was running on a schedule but was not connected to anything that changes. Scans and annual reviews happened; architecture change did not flow into them.
The specific gaps: no security review step in the change management process; no inventory of external interfaces or cloud regions feeding the monitoring metrics; no mechanism to trigger a significant-change determination; and monitoring reports that tracked vulnerability counts without tracking whether the system still matched its documented boundary.
Changes worth making: make security sign-off a gate in change management for boundary, platform, and interface changes; maintain an automated asset and architecture inventory with drift detection; require a documented significant-change determination with AO notification; and add boundary, interface, and hosting changes to the recurring monitoring report so the AO sees posture changes, not just scan results.