A draft municipal WLAN policy lists a single vendor's product SKUs instead of security outcomes. Which rewrite best follows high-level policy practice?
Select an answer to reveal the explanation.
Short Explanation
Policy should say "staff get enterprise auth and strong encryption," not "buy SKU-12345." Outcomes travel across refresh cycles; SKUs go end-of-life.
Full Explanation
A draft municipal WLAN policy that lists a single vendor's product SKUs instead of security outcomes should be rewritten to require enterprise-grade authentication and encryption for staff WLAN access in technology-neutral language. High-level policy practice states required results so architecture can evolve without rewriting governance every refresh cycle. Requiring purchase of only one branded AP model forever is a procurement preference, not a security outcome, and it conflates policy with a bill of materials. Requiring staff to memorize the vendor price list has no relationship to confidentiality, integrity, or availability of the wireless service. Disabling encryption to avoid vendor lock-in debates abandons the primary control the policy exists to mandate and is never an acceptable rewrite. After outcomes are clear, a separate architecture standard may name approved platforms under change control without elevating SKUs into the council-facing policy. Exam caveat: naming products in lower-tier standards is acceptable after policy outcomes are set; the policy tier itself should remain outcome-focused. Operational check: replace SKU-centric sentences with outcome statements, move product lists into a versioned architecture standard, verify auditors can map each policy outcome to implemented controls without needing a single vendor name, and re-approve the cleaned policy through the municipal process.