The Exception That Outlived Its Owner
A bureau's legacy case-management system serves 3,200 users and runs on a database version the vendor stopped supporting 14 months ago. The system owner requests a 12-month exception to the encryption-at-rest requirement, arguing no supported patch exists. The ISSO recommends denial and proposes network segmentation plus database activity monitoring as a compensating set. The bureau CISO signs the exception 'to avoid operational disruption' and tells the authorizing official the matter is handled. Three weeks later the AO receives the authorization package: the risk assessment still shows encryption-at-rest as not satisfied, no POA&M entry exists, and the exception memo is not referenced anywhere in the package.
1. Who can accept the residual risk created by the unsupported database, and what should the AO do when the package arrives?
Read the worked answer
Risk acceptance for this system belongs to the authorizing official, not the CISO. The CISO can set policy, issue a documented exception under whatever delegated authority exists, and recommend a course of action - but signing an exception memo is not the same as accepting residual risk on behalf of the AO, and a bureau-level official generally cannot do that for a department-level AO.
The AO should refuse to sign the package as submitted, because it is internally inconsistent: an exception exists, but the risk assessment, POA&M, and SSP do not reflect it. The AO should require:
- the exception memo referenced in the package, with its delegation basis and expiry;
- a residual risk statement that describes the compensating controls and what they do and do not mitigate (segmentation does not protect data at rest on stolen media);
- a POA&M item with milestones and an owner, tied to the 12-month horizon;
- confirmation that the ISSO's denial was documented with rationale rather than silently overridden.
Only then does the AO choose among authorize, authorize with conditions, or deny.
2. Beyond this one system, what governance defects does the situation reveal?
Read the worked answer
Several, and they are structural rather than system-specific:
- The exception process is not integrated with the RMF. An exception that never reaches the risk assessment or POA&M is invisible to the AO and to continuous monitoring. Exceptions should be a feeder into, not a bypass around, the authorization package.
- Delegation of authority is unclear. If the CISO believes the matter is 'handled,' either the delegation exists and should be documented and bounded, or it does not and the CISO has exceeded authority. Both are governance failures.
- No expiry or tracking mechanism. A 12-month exception with no register entry will quietly become permanent.
- Dissent is not recorded. An ISSO recommendation overridden without written rationale removes the audit trail the AO needs to weigh risk.
A workable fix is a policy requiring every exception to carry a risk assessment, compensating controls, AO acknowledgement, expiry date, and recurring reporting into the continuous monitoring cycle.