Why your hotel's IT network is a PCI DSS and GDPR liability – and how to fix it

The shared network problem

When a hotel's IT infrastructure is designed – or more often, assembled over time – the default tendency is to connect everything to the same network. A single router, a managed switch, maybe a few Wi-Fi access points. Guests connect to it. Reception connects to it. The POS terminal connects to it. The NVR for CCTV connects to it. It's simpler to install, easier to manage day-to-day and cheaper upfront.

It's also a compliance failure and a significant security risk.

The core problem is reachability. On a flat network – one without proper segmentation – any device can potentially communicate with any other device. A guest on the hotel Wi-Fi can attempt connections to the property management system (PMS). A compromised device on the PMS network can reach the payment terminals. An attacker who gets a foothold anywhere on the network has a path to everything else.

PCI DSS and GDPR both impose requirements that a flat hotel network cannot satisfy. Understanding exactly what each regulation requires – and why the architecture is the problem, not a technical detail – is what allows you to fix it properly rather than just apply patches.

PCI DSS and hotels: what it requires in practice

PCI DSS – the Payment Card Industry Data Security Standard – applies to any organisation that stores, processes or transmits cardholder data. If your hotel takes card payments at reception, in the restaurant or at the spa, PCI DSS applies. The current version, PCI DSS v4.0, has tightened several requirements that are directly relevant to hotel network architecture.

The most important concept in PCI DSS for hotels is the Cardholder Data Environment (CDE) – the systems that store, process or transmit card data, and any systems connected to them. The size of your CDE determines the scope of your compliance obligations. A large, poorly segmented CDE means more systems to audit, more controls to maintain and more exposure if something goes wrong.

Network segmentation is the primary tool for controlling CDE scope. PCI DSS doesn't mandate segmentation – technically you can be compliant without it – but without segmentation, your entire network is in scope. In practice, for a hotel, that's unmanageable. Segmentation isolates the payment environment to a tightly controlled network segment, keeping everything else out of scope.

PCI DSS v4.0 also requires:

• Multi-factor authentication (MFA) for all access into the CDE – including administrative access to payment systems and POS management interfaces
• Annual penetration testing of the network segmentation controls, specifically to verify that the CDE is genuinely isolated
• Documented network diagrams showing all connections into and out of the CDE
• Firewall rules reviewed at least every six months

Common failures in UK hotels include POS systems running Windows 10 or earlier (sometimes Windows 7) that are no longer receiving security patches, shared administrative credentials for payment systems, and payment terminals sitting on the same VLAN as guest Wi-Fi. None of these pass a PCI DSS assessment – and all of them represent real breach risk.

It's worth being clear about what's at stake. If your hotel suffers a payment card breach and is found to be non-compliant with PCI DSS at the time, you're liable for the cost of the forensic investigation, potential fines from your acquiring bank, and the fraudulent transactions made on cards stolen from your systems. Cyber insurers are increasingly requiring evidence of PCI compliance before they'll underwrite the relevant risk. Non-compliance is expensive in both directions.

GDPR obligations for guest data on your network

GDPR covers personal data – any information that identifies or can identify a living individual. For a hotel, that scope is wide: guest names, email addresses, phone numbers, booking history, stay preferences, loyalty programme data and, in some contexts, payment card tokens. All of it is personal data. All of it carries GDPR obligations.

The relevant GDPR requirement for network architecture is Article 32: the obligation to implement appropriate technical and organisational measures to protect personal data against unauthorised access. "Appropriate" is assessed in the context of the risk. A hotel that holds thousands of guest records, processes card payments and provides public Wi-Fi access is a high-risk environment. The bar for "appropriate" is correspondingly higher than it would be for a small business with minimal data holdings.

The guest Wi-Fi dimension of GDPR is often underestimated. If your hotel provides guest Wi-Fi and logs browsing activity – even for network management purposes – that logging creates data processing obligations. You need a lawful basis for it, guests need to be informed, and the data needs to be secured and retained only as long as necessary. A captive portal that collects an email address for Wi-Fi access is collecting personal data – it needs a privacy notice, a lawful basis (usually consent or legitimate interests, depending on how it's used) and appropriate retention limits.

Network security failures become GDPR failures the moment personal data is exposed. If an attacker accesses your PMS through an unsegmented network and exfiltrates guest records, that's a personal data breach. Under GDPR, you're required to report it to the ICO within 72 hours of becoming aware of it, notify affected individuals if the risk to them is high, and document everything. The reputational and financial consequences of a reportable breach are significant – and the cause is often network architecture that could have been fixed before any of it happened.

What proper network segmentation looks like

Proper segmentation for a hotel divides the network into separate VLANs (Virtual Local Area Networks) – logically isolated segments that cannot communicate with each other except through controlled, explicitly permitted paths. The minimum architecture for a hotel looks like this:

• Guest Wi-Fi VLAN – untrusted, internet access only, with per-client isolation enabled so guests can't reach each other's devices. No path to any internal systems.
• PMS and operations VLAN – for the property management system, front desk computers, reservations and hotel operations. Restricted access, no connection to guest Wi-Fi.
• Payment/POS VLAN (CDE) – the most restricted segment. Payment terminals, POS systems and any system that touches card data. Inbound connections only from explicitly permitted sources. MFA required for administrative access. This is the segment that defines PCI DSS scope.
• CCTV and physical security VLAN – NVRs, cameras and access control systems on their own isolated segment. These devices often run outdated firmware and should not have any network path to operational systems.
• Management VLAN – for network infrastructure management: switches, access points, routers and firewalls. Strictly restricted, accessible only to authorised IT personnel.

Traffic between VLANs is controlled by the firewall. The default rule is deny-all. Permitted paths – for example, allowing the PMS VLAN to reach the payment gateway via HTTPS – are explicit, logged and reviewed. Guest Wi-Fi has no permitted path to anything internal, full stop.

This architecture doesn't require exotic or expensive hardware. Most enterprise-grade switches and access points support VLAN segmentation. The investment is in design and correct configuration – not hardware that can't do the job.

The CCTV and smart lock problem

CCTV systems and electronic door locks deserve a specific mention because they're frequently overlooked in hotel network security reviews – and they present distinct risks.

CCTV NVRs (network video recorders) are notorious in the security community for poor default configurations: factory-set admin passwords that are never changed, web interfaces exposed to the internet, outdated firmware that isn't patched and, in some cases, active vulnerabilities that have been public for years. On a flat hotel network, a compromised CCTV system gives an attacker a foothold on the same network as your PMS and payment terminals.

Smart lock systems and electronic key card infrastructure often have their own management interfaces. Some communicate over the hotel network. If that network isn't segmented, a compromise of the lock management system is also a network access problem.

The answer is the same: put CCTV on its own VLAN, put lock management on its own VLAN, change default credentials, keep firmware updated and treat them as untrusted endpoints that should not have network access to anything they don't need to reach to do their job. CCTV needs to reach the NVR. The NVR does not need to reach the PMS.

How to get from here to compliant

If your hotel currently runs a flat or minimally segmented network, the path to compliance follows a consistent sequence.

Start with a network audit. Map what's on the network: every device, every connection, every system. This often produces surprises – equipment that was installed and forgotten, integrations that are no longer active, access points with default configurations. You can't segment a network you haven't fully mapped.

Then assess your PCI scope. Which systems touch card data? Which systems are connected to those systems? The scope you identify is the compliance obligation you're working to reduce. If the scope is your entire network, segmentation is the priority – it limits the CDE to the systems that need to be there and removes everything else from scope.

Design the VLAN architecture before you touch anything. The design should reflect your specific environment: how many properties, what PMS you run, how your payment processing works, what physical security systems you have. A generic template isn't enough – the architecture needs to be right for your operation.

Implement segmentation during a low-occupancy window, with a rollback plan. Mis-configured segmentation can take systems offline, so this is not work to do on a Friday afternoon in peak season. Test each segment in isolation before connecting it to the rest of the network. Verify that guest Wi-Fi genuinely cannot reach internal systems – test it, don't assume it.

Then address the supporting controls: MFA on PMS and payment system access, individual credentials for staff rather than shared accounts, a documented offboarding process, patching schedules for all systems including POS and NVRs, and penetration testing of the segmentation controls at least annually.

Document everything. PCI DSS requires network diagrams and documented firewall rules. GDPR requires a record of processing activities and the technical measures in place. The documentation isn't bureaucracy – it's evidence that you've done the work, and it matters when an assessor or regulator asks.