A regional transit agency asks for "strong Wi-Fi security" but has not written business goals for ops tablets versus public rider Wi-Fi. What should the security professional do first when forming WLAN security requirements?
Select an answer to reveal the explanation.
Short Explanation
"Strong security" is a vibe, not a requirement. Nail what the ops tablets need and how guest Wi-Fi must stay split—then pick gear. Shopping for toys first is how you get expensive misalignment.
Full Explanation
When a regional transit agency asks for "strong Wi-Fi security" without written business goals distinguishing operations tablets from public rider Wi-Fi, the security professional should first translate business and technical objectives into measurable WLAN security requirements before selecting products. Uptime for operations tablets, isolation of public guest access, regulatory constraints, and authentication strength are examples of outcomes that drive requirements. Buying the highest-end WIPS appliance first and inventing requirements later reverses the requirements engineering process and often yields expensive misalignment. Copying a neighboring city's SSID names is not a requirements baseline; names do not encode authentication, encryption, segmentation, or monitoring expectations. Deferring all requirements until after antennas and channel plans are finalized prioritizes RF design over security outcomes and leaves policy and procurement without a target. Exam caveat: CWSP Domain 1 stresses deriving security requirements from objectives and stakeholders, then choosing technology—not shopping first. Operational check: facilitate a short workshop that documents ops versus guest objectives, produce a requirements list with measurable controls (for example, 802.1X for ops, guest isolation, logging retention), and only then map those requirements to candidate architectures.