ISO 27001 गेस्ट WiFi: एक कंप्लायंस प्राइमर

ISO 27001 Guest WiFi: A Compliance Primer Purple Technical Briefing Podcast — Episode Script Approximate runtime: 10 minutes | Voice: UK English, senior consultant tone --- SEGMENT 1: INTRODUCTION AND CONTEXT (approx. 1 minute) Welcome to the Purple Technical Briefing. I'm your host for today's episode, and we're diving into a topic that sits at the intersection of network operations and information security governance: guest WiFi and ISO 27001 compliance. If you're an IT manager, a network architect, or an ISO 27001 lead auditor at a hotel group, a retail chain, a stadium, or a public-sector organisation, this episode is built for you. We're not going to cover ISO 27001 from scratch — you know the standard. What we are going to do is give you a precise, practical map of how your guest WiFi deployment fits into your Information Security Management System, which controls apply, what your risk assessment needs to document, and critically, what evidence you need to produce when the auditor walks through the door. Guest WiFi is one of those areas that organisations consistently underestimate from a compliance perspective. It feels like a commodity service — plug in some access points, hand out a password, done. But from an ISMS standpoint, it is a live information asset that touches your network boundary, your supplier relationships, your data protection obligations, and your legal exposure. Let's unpack that properly. --- SEGMENT 2: TECHNICAL DEEP-DIVE (approx. 5 minutes) Let's start with the control mapping. ISO 27001:2022 restructured its Annex A controls, and several of them apply directly to guest WiFi. The most critical cluster sits in the Technology Controls section — that's Annex A clause 8. Control A.8.22 — Segregation of Networks — is your foundational requirement. This control mandates that groups of information services, users, and systems be segregated on networks. For guest WiFi, this translates directly to VLAN isolation. Your guest network must be logically and, where appropriate, physically separated from your corporate network, your payment processing environment, and any IoT or operational technology segments. If an auditor finds that guest traffic can reach internal file shares or management interfaces, that is a clear nonconformity against A.8.22. Control A.8.20 — Networks Security — requires that networks be managed and controlled to protect information in systems and applications. For guest WiFi, this means documented firewall rules, access control lists, and a network security policy that explicitly addresses the guest segment. You need to be able to show the auditor a current network diagram with the guest VLAN clearly labelled, and the firewall ruleset that governs what that segment can and cannot reach. Control A.8.21 — Security of Network Services — addresses third-party network service providers. Most organisations running guest WiFi are using a managed service provider, a cloud-based captive portal platform, or an ISP-provided solution. Each of those is a supplier relationship that needs to be governed. You need service level agreements that include security requirements, and you need evidence of periodic supplier review. This is where vendor SOC 2 Type II attestations become genuinely useful — we'll come back to that. Control A.8.15 — Logging — requires that event logs be produced, stored, protected, and analysed. For guest WiFi, this means logging connection events, authentication attempts, and session data. Now, there is a tension here with GDPR and data minimisation principles, particularly in the UK and EU. You need to log enough to satisfy your security monitoring obligations, but not so much that you are retaining personal data beyond what is necessary. Your logging policy should explicitly address the guest WiFi scope, define retention periods, and document the legal basis for any personal data captured. Control A.8.23 — Web Filtering — requires that access to external websites be managed to protect systems from malware infection and to prevent access to unauthorised web resources. For guest WiFi, this typically means deploying DNS-based filtering or a cloud web proxy that blocks known malicious domains, command-and-control infrastructure, and, depending on your sector, categories of inappropriate content. A hotel operator serving a family audience has different filtering obligations than a conference centre serving enterprise delegates, but both need a documented policy and evidence that the filtering is active and reviewed. Moving to the Organisational Controls — Annex A clause 5 — two controls are particularly relevant. Control A.5.14 — Information Transfer — governs the rules, procedures, and controls for the transfer of information. If guests are using your network to transfer files, access cloud services, or conduct business, you need an Acceptable Use Policy that is presented to them at authentication — typically via the captive portal — and accepted before access is granted. That acceptance event needs to be logged as evidence. Control A.5.31 — Legal, Statutory, Regulatory, and Contractual Requirements — requires that you identify and document all relevant legal and regulatory obligations. For guest WiFi, this includes GDPR or UK GDPR if you are capturing any personal data at authentication, the Investigatory Powers Act if you are in the UK and may be required to retain communications data, and sector-specific regulations such as PCI DSS if your guest network is in scope for cardholder data. Now, the risk assessment. ISO 27001 is a risk-based standard, which means you cannot simply implement controls and call it done. You need to document a formal risk assessment for the guest WiFi asset. That assessment should identify threats — unauthorised access to internal systems, malware propagation from guest devices, data interception on the wireless medium, denial of service, and reputational damage from misuse of your network. For each threat, you assess likelihood and impact, determine your risk treatment — whether that is mitigate, accept, transfer, or avoid — and document the residual risk. The Statement of Applicability must reference the guest WiFi risk assessment as the justification for including or excluding specific Annex A controls. Let's talk about WPA3 and authentication standards. The IEEE 802.11ax and 802.11be generations of WiFi hardware support WPA3, which provides Simultaneous Authentication of Equals — SAE — replacing the older Pre-Shared Key handshake. For a guest network where you are using a shared passphrase, WPA3-Personal with SAE provides forward secrecy, meaning that even if the passphrase is compromised, historical session traffic cannot be decrypted. For enterprise deployments where you want per-user authentication, WPA3-Enterprise with IEEE 802.1X and EAP-TLS provides certificate-based authentication that maps directly to ISO 27001 identity management controls. The choice between these two models depends on your user population and your operational complexity tolerance. Now, vendor SOC 2 attestations. If you are using a cloud-managed guest WiFi platform — and most organisations are — that vendor's SOC 2 Type II report is a critical piece of your supplier assurance evidence. A SOC 2 Type II report covers the Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy, over an audit period of typically six to twelve months. When you are building your ISO 27001 supplier assurance file, the vendor's SOC 2 Type II report, combined with a completed supplier security questionnaire and a data processing agreement, gives you a defensible evidence pack for control A.8.21. Purple, for instance, carries SOC 2 alignment that directly supports this downstream ISMS requirement — meaning you can reference their attestation in your own audit evidence rather than conducting a full bespoke security assessment of the platform. --- SEGMENT 3: IMPLEMENTATION RECOMMENDATIONS AND PITFALLS (approx. 2 minutes) Let me give you the four implementation decisions that most organisations get wrong. First: scope creep in the risk assessment. Organisations either scope the guest WiFi too narrowly — treating it as out of scope because it is just for visitors — or too broadly, attempting to apply every possible control regardless of relevance. The correct approach is to scope it as an information asset that is in scope for the ISMS, conduct a proportionate risk assessment, and document your control selection rationale in the Statement of Applicability. Second: inadequate network segmentation. I have seen guest VLANs that are technically separate but share a firewall zone with internal systems, or where the management interface of the wireless controller is accessible from the guest segment. Segmentation needs to be verified with a penetration test or at minimum a network access review, and that verification needs to be documented as audit evidence. Third: ignoring the captive portal as an access control mechanism. The captive portal is not just a branding exercise. It is the point at which you present your Acceptable Use Policy, obtain consent for data processing, and create the authentication log that serves as evidence for multiple ISO 27001 controls. If your captive portal is not logging acceptance events with timestamps and session identifiers, you have a gap that an auditor will find. Fourth: treating supplier assurance as a one-time exercise. SOC 2 reports expire. ISP contracts change. Cloud platform terms of service are updated. Your supplier assurance programme needs to include annual review of vendor security attestations, and that review needs to be documented. Set a calendar reminder for when each vendor's SOC 2 report period ends and request the updated report proactively. On the question of session timeouts: ISO 27001 does not prescribe specific timeout values, but your risk assessment should document the rationale for whatever value you choose. A session timeout of eight hours is common in hospitality, but a conference centre running a one-day event might set a shorter timeout to ensure that credentials are not shared across attendees. The key principle is that the timeout policy is documented, risk-justified, and consistently implemented. Purple's platform, for example, allows you to configure and enforce session timeout policies centrally, with the configuration state exportable as audit evidence. --- SEGMENT 4: RAPID-FIRE Q&A (approx. 1 minute) Let me run through the questions I get most frequently from IT managers preparing for ISO 27001 certification. Does guest WiFi have to be in scope for our ISMS? If it processes, stores, or transmits information that falls within your ISMS scope, yes. If guests authenticate using any personal data, or if the network connects to any systems that are in scope, it must be included. Can we exclude guest WiFi from the Statement of Applicability? You can exclude controls, but you must document the justification. Excluding A.8.22 Segregation of Networks for a guest WiFi deployment would require a very compelling argument that the auditor is unlikely to accept. What is the minimum viable evidence pack for a guest WiFi audit? Network diagram showing VLAN segregation, firewall ruleset, captive portal configuration with acceptable use policy text, authentication log sample, risk assessment entry, and vendor SOC 2 report or equivalent assurance document. How does GDPR interact with ISO 27001 for guest WiFi? GDPR is a legal requirement that feeds into control A.5.31. Your privacy notice, data processing agreement with your WiFi platform vendor, and data retention policy are all ISO 27001 evidence items as well as GDPR compliance artefacts. They serve double duty. --- SEGMENT 5: SUMMARY AND NEXT STEPS (approx. 1 minute) To bring this together: guest WiFi is not a peripheral concern for your ISMS — it is a live network boundary with real risk exposure and a clear set of applicable ISO 27001:2022 controls. The controls that matter most are A.8.22 for network segregation, A.8.20 for network security management, A.8.21 for supplier assurance, A.8.15 for logging, A.8.23 for web filtering, A.5.14 for acceptable use, and A.5.31 for legal compliance. Your immediate next steps: first, confirm that guest WiFi is explicitly included in your ISMS scope statement. Second, add a guest WiFi entry to your risk register with documented threats, likelihood, impact, and treatment decisions. Third, build your evidence pack — network diagram, firewall rules, captive portal configuration, logging policy, and vendor SOC 2 report. Fourth, schedule an annual supplier assurance review for your WiFi platform provider. If you are deploying or upgrading your guest WiFi infrastructure, Purple's platform is built with these compliance requirements in mind — SOC 2 aligned, with centralised policy management and exportable configuration evidence that feeds directly into your ISMS documentation. Thank you for joining the Purple Technical Briefing. For the full written guide, architecture diagrams, and worked examples, visit the Purple resource centre. Until next time.