Continuous Monitoring That Monitors Nothing
A system received a three-year authorization 18 months ago. Its continuous monitoring plan specifies monthly vulnerability scans, quarterly configuration baselines checks, annual control assessments of 30% of controls, and monthly review of audit logs. In practice: scans run monthly but results are reviewed only when someone remembers; configuration checks have not run in nine months because the tool's license lapsed; the annual 30% assessment was skipped last year; and audit logs are collected but reviewed quarterly at best. Meanwhile, the system's boundary changed - a new API integration with a partner agency went live four months ago without a security review. The authorizing official's office is preparing for an oversight review and has asked the system owner to certify that continuous monitoring is functioning as designed.
1. Can the system owner certify that continuous monitoring is functioning as designed? What are the specific deficiencies and their consequences?
Read the worked answer
No. The owner cannot truthfully certify functioning-as-designed monitoring. Each gap has a distinct consequence:
- Scans run but unreviewed: scanning without analysis produces no risk information. The control is nominally executed but ineffective; vulnerabilities may persist unmitigated with no record of risk decisions.
- Configuration checks lapsed nine months: this is a complete failure of the configuration-management monitoring control, and it means drift has gone undetected across the period, including any changes tied to the new integration.
- Skipped annual assessment: the plan's coverage commitment was not met, so the evidence base for the authorization is now stale and the claimed 30% annual coverage is false.
- Audit logs reviewed quarterly instead of monthly: detection latency for security events is extended threefold, weakening incident response.
- Unreviewed boundary change: the API integration is the most serious gap. A new connection to a partner agency changes the system boundary, may introduce new data flows and trust relationships, and was never assessed. The authorization decision did not contemplate this configuration.
Certifying would misrepresent the security posture to the authorizing official. The correct response is to report the deficiencies, assess the integration, and propose remediation and reauthorization actions.
2. What should the system owner do before the oversight review, and what does this situation imply about the authorization's validity?
Read the worked answer
Before the review, the owner should: (1) immediately assess the new API integration - data flows, authentication, authorization, encryption, and partner responsibilities - and document it as a boundary change requiring authorization review; (2) restore configuration checking, even temporarily with an alternate tool, and run a baseline comparison to detect drift; (3) review the backlog of unreviewed scan results and log data, triaging for exploitable findings; (4) document each lapse with dates, cause, and corrective action; and (5) prepare an honest status report to the authorizing official rather than a certification.
The situation implies the authorization is no longer fully supported by evidence. A three-year authorization is premised on continuous monitoring providing ongoing assurance; when monitoring lapses and the boundary changes without review, the assumptions underlying the authorization are invalidated. The authorizing official should consider whether to require a significant change review, issue an interim authorization with conditions, or suspend the authorization pending remediation. The owner's obligation is to surface this proactively - the oversight review will find it regardless, and proactive disclosure preserves credibility and enables a controlled response.