A county writes WLAN security policy once, then never revisits it after major controller and WPA3 upgrades. Which lifecycle action is missing?
Select an answer to reveal the explanation.
Short Explanation
Policy isn't a time capsule. After big WLAN upgrades, schedule a review cycle—create, approve, communicate, then update—so the paper matches the air.
Full Explanation
A county that writes WLAN security policy once and never revisits it after major controller and WPA3 upgrades is missing security policy lifecycle management—periodic review and update when technology, threats, or operations change. Static policy drifts from the live estate: new management planes, cipher suites, and threat models appear while the approved text still describes yesterday's architecture. Deleting all logs so policy never needs updates destroys accountability evidence and does not keep policy current. Freezing policy language permanently after first approval guarantees that enforcement and documentation diverge. Outsourcing policy ownership to a random social media account removes municipal accountability and chain of approval. Lifecycle management includes both scheduled reviews and event-driven updates after significant architecture or threat changes, with recorded approvals for each revision. Exam caveat: lifecycle is not only an annual rubber stamp; material platform changes such as WPA3 adoption or controller migration should trigger out-of-cycle policy updates. Operational check: place the WLAN policy on a review calendar, open an out-of-cycle update after the controller and WPA3 changes, diff policy statements against actual SSID and management-plane settings, remediate gaps, and record approval of the revised version in the official repository.