GDPR and your IT infrastructure: a practical compliance checklist

Where IT infrastructure intersects with GDPR

UK GDPR – retained EU law under the Data Protection Act 2018, as amended post-Brexit – places specific obligations on how personal data is stored, accessed, transmitted and ultimately deleted. While the UK GDPR is substantially similar to the EU version, UK businesses should work to the UK regime rather than assuming full equivalence.

Two articles are most directly relevant to IT infrastructure. Article 25 requires data protection by design and by default – meaning privacy considerations must be built into systems from the outset, not bolted on later. Article 32 requires that organisations implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk.

What counts as "appropriate" isn't defined in prescriptive terms – which is either flexible or frustrating, depending on your perspective. The following checklist covers the areas where infrastructure decisions have the most direct compliance implications.

Data mapping: understanding what you hold and where

You can't secure what you don't know you have. Before assessing technical controls, you need a clear picture of where personal data sits across your systems.

That means mapping the flow of personal data through your infrastructure: which systems hold it, in what form, for how long and who has access. In practice, this often reveals data living in places nobody expected – email archives, test databases containing copies of production data, shared drives with no access controls, third-party integrations that were set up years ago and forgotten.

The data map doesn't need to be a complex project. A clear record of your systems, the categories of personal data each handles and the legal basis for processing is the foundation everything else builds on. Your IT team needs to be involved in producing it, not just the legal or compliance function.

Access controls and the principle of least privilege

Article 32 explicitly references access control as a relevant technical measure. The principle is straightforward: users and systems should have access only to the personal data they need to perform their function – nothing more.

In infrastructure terms, this means more than having a password policy. It means structuring Active Directory or LDAP groups so that permissions are tied to roles, not individuals. It means implementing role-based access control (RBAC) across your line-of-business systems, not just your network. It means reviewing those permissions regularly – because roles change, people leave, and access that was granted for a specific project often quietly persists indefinitely.

Privileged accounts deserve particular attention. Domain administrators, database administrators and anyone with elevated system access represent a higher risk if credentials are compromised. Privileged access management (PAM) controls – time-limited access, separate admin accounts, multi-factor authentication on all privileged sessions – are appropriate measures for most organisations handling significant volumes of personal data.

Multi-factor authentication (MFA) for all remote access and for access to systems containing personal data is now a baseline expectation, not an advanced measure.

Encryption: at rest and in transit

Article 32 specifically names encryption as an example of an appropriate technical measure. The two contexts are distinct and both matter.

Encryption at rest protects data when a device or storage medium is physically compromised. For endpoints, that means full-disk encryption – BitLocker on Windows devices, FileVault on Mac. For databases containing personal data, column-level or tablespace encryption adds a further layer. For cloud storage, verify that encryption at rest is enabled (most providers do this by default, but confirm rather than assume, and understand who controls the keys).

Encryption in transit protects data as it moves between systems. TLS 1.2 is the current minimum; TLS 1.3 is preferable and should be enforced where possible. All web applications handling personal data should use HTTPS – HTTP is not acceptable for any endpoint that transmits personal data. Internal service-to-service communication should be encrypted, not just external-facing traffic.

Check your TLS configuration using a tool like SSL Labs. Weak cipher suites and outdated protocol support are common findings in infrastructure audits – and straightforward to remediate once identified.

Logging, monitoring and audit trails

If something goes wrong – a breach, an unauthorised access event, a data loss incident – your ability to understand what happened depends on having logs that captured the relevant activity. Logging is both a detective control and an audit requirement.

At minimum, your infrastructure should log who accessed what personal data, when, from where and with what result. That means enabling audit logging on databases, file servers and key business applications, not just network perimeter devices. Authentication events, including failures, should be logged. Administrative actions – changes to permissions, bulk data exports, account creation and deletion – should be captured.

Log retention needs deliberate thought. For GDPR audit trail purposes, 12 months is a sensible minimum for most organisations. Logs themselves may contain personal data – IP addresses, usernames, access patterns – and need to be managed accordingly.

Larger organisations should consider a Security Information and Event Management (SIEM) platform to aggregate, correlate and alert on log data. Without centralised log management, reviewing logs after an incident is difficult and time-consuming. For SMEs without a dedicated security team, a managed SIEM service via your MSP is a practical option.

Data retention and secure deletion

UK GDPR's storage limitation principle requires that personal data isn't kept longer than necessary for the purpose it was collected. This is frequently where documented policies and actual infrastructure practice diverge.

A written retention policy is necessary but not sufficient. The infrastructure has to enforce it. That means automated retention rules applied at the system level – not relying on individuals to manually delete records. Most CRM platforms, email systems and document management tools support automated retention policies; the question is whether they're configured.

Backup data is the area most commonly overlooked. Backups contain personal data, and that data doesn't disappear just because it's in a backup set. If your live systems have deletion policies, your backup retention schedules need to align – or you need a clear process for honouring deletion requests even against backup data. This is technically challenging, but ignoring it doesn't make it compliant.

When data reaches the end of its retention period, or when storage media is decommissioned, secure deletion matters. For digital storage, NIST 800-88 provides guidance on media sanitisation methods appropriate to different media types. For physical media – hard drives, tapes, USB devices – engage a certified data destruction provider and retain the certificate of destruction. Don't rely on deleting files or reformatting drives: data recovery from inadequately wiped media is routine.

Third-party and vendor management

Article 28 of UK GDPR requires that where you engage a processor – any third party that handles personal data on your behalf – you must have a written Data Processing Agreement (DPA) in place. This isn't optional, and the absence of a DPA is a clear compliance gap.

In infrastructure terms, processors include your cloud providers, your MSP, any SaaS platform that processes personal data (CRM, HR systems, email marketing tools, helpdesk software), and any third party with remote access to your systems. Work through your supplier list systematically. Many larger vendors have standard DPAs; smaller suppliers may need to be asked directly.

A DPA signed at contract stage isn't enough on its own. You should periodically review the security posture of vendors with access to significant volumes of personal data. That means asking for SOC 2 reports, ISO 27001 certificates or equivalent assurance – not just accepting verbal reassurance. For critical suppliers, include security obligations and audit rights in the contract from the outset.

Sub-processors – the third parties your vendors use – also need to be on your radar. Your cloud provider's DPA should address sub-processing; make sure you understand where your data actually sits geographically, particularly post-Brexit where data transfers outside the UK require appropriate safeguards.

Breach detection and response readiness

UK GDPR requires notification to the Information Commissioner's Office (ICO) within 72 hours of becoming aware of a personal data breach that poses a risk to individuals. That window is tight – tight enough that discovering a breach and then beginning to build a response process isn't viable.

Detection capability comes first. If you can't detect a breach in a reasonable timeframe, the 72-hour clock may start running well before you know it. Endpoint detection and response (EDR) tools, intrusion detection on network perimeter devices and the log monitoring described above all contribute to earlier detection. Many breaches are discovered weeks or months after the initial compromise – often by third parties rather than the organisation itself.

Your incident response process should be documented and tested before you need it. At minimum: who is notified internally, who makes the decision to notify the ICO, who drafts the notification, who contacts affected individuals if required. The process should name roles, not just job titles, and should have been walked through at least once so that people know what's expected of them under pressure.

Keep a record of all security incidents, including those that don't meet the notification threshold. The ICO expects organisations to demonstrate that they're managing incidents systematically, not just reporting the ones that become unavoidable.