A city payments kiosk SSID may process cardholder data and sits near HIPAA-adjacent clinic check-in devices. What should security policy authors do first?
Select an answer to reveal the explanation.
Short Explanation
Regulations don’t care that it’s “just Wi-Fi.” Translate PCI and clinic-adjacent rules into plain WLAN policy: who can join, how it’s encrypted, how it’s segmented. A café template and a privacy banner won’t satisfy auditors—or residents.
Full Explanation
When a city payments kiosk SSID may process cardholder data and sits near HIPAA-adjacent clinic check-in devices, security authors must first map applicable PCI-DSS and HIPAA-adjacent constraints into explicit, enforceable WLAN security policy language for that SSID. Translating regulatory expectations into encryption, segmentation, logging, and exception rules makes the wireless edge auditable instead of relying on tribal knowledge. Civic payment and health-adjacent workflows demand that mapping before AP profiles are cloned from an unrelated guest network.
Copying a consumer café Wi-Fi policy and pasting the city logo does not capture cardholder or clinic constraints. Declaring wireless out of scope because wired PCI exists ignores that the kiosk traffic still traverses 802.11. Allowing any encryption suite as long as a captive portal shows a privacy banner confuses notice with cryptographic and segmentation control.
Exam caveat: “HIPAA-adjacent” devices may not make the SSID a full covered entity system by themselves, but policy still must reflect the stricter applicable controls rather than the weakest café default. Operational check: produce a policy matrix that lists PCI/HIPAA-relevant controls per SSID, have compliance review it, and verify the controller profile for the kiosk SSID implements the stated encryption and segmentation requirements.