A county runs vulnerability scans on rapidly changing cloud citizen apps only once per year. Risk and change rate are both high. What should leadership conclude about the assessment strategy?
Select an answer to reveal the explanation.
Short Explanation
Apps that reinvent themselves every sprint do not get a once-a-year checkup like a museum exhibit. If risk and change are high, speed up the testing rhythm—and check that your strategy still fits reality.
Full Explanation
Assessment strategies must be validated against current risk, system criticality, and rate of change. Annual-only vulnerability scanning of rapidly changing cloud citizen apps leaves long windows where new services, APIs, and misconfigurations go untested despite high risk and high churn. Leadership should conclude the cadence is inadequate and adjust frequency—or adopt continuous testing approaches—so the strategy remains fit for purpose.
Asserting annual scanning is always sufficient if a policy mentions continuous improvement confuses aspirational wording with actual test rhythm. Believing high-churn cloud apps need less testing because vendors patch everything ignores tenant configuration errors, app code the city owns, and integration flaws outside the vendor’s patch cycle. Declaring strategy validation unnecessary after the first annual scan freezes a stale plan while the citizen-facing estate keeps evolving.
Exam caveat: cadence follows risk and change rate; “annual everywhere” is a common trap on Domain 6 strategy items. Operational check: classify citizen apps by deploy frequency and data sensitivity, set scan or continuous-assessment intervals accordingly, review the strategy at least when major cloud releases land, and evidence that findings still close within municipal SLAs between annual calendar milestones.