What a VPN Covers in a GDPR Data-Protection Review

A cloud database holds personal data, the VPN restricts who can reach it, and someone asks whether that makes the setup compliant. It does not, and the question is the wrong shape. A VPN is one technical access control among several, and a review that stops at encrypted traffic has answered a security question while leaving every data-protection question open. Work the checks below in order, starting before the network rule exists.

Check 1: describe the processing before the tunnel

Write down the purpose, the categories of personal data actually needed, the people allowed to use them, and the intended retention period. Identify the lawful basis you rely on and the route an individual takes to exercise their rights. A restricted IP range cannot answer any of those.

Note that personal data is broader than a list of obvious identifiers. Encrypted or pseudonymised records remain personal data where re-identification is possible, so a database full of hashed identifiers is not automatically out of scope.

Check 2: name the roles

Decide who determines the processing and who acts on that party's behalf, then review the terms between them: documented instructions, confidentiality, security commitments and permitted subprocessors. For a typical cloud arrangement this is the controller-processor agreement, and the Commission's application guidance explains the roles and the required binding act.

A network diagram usually names none of this, which is why the VPN question alone stalls. Roles decide who answers a rights request. They also decide who is accountable when something goes wrong. Draw both boxes before writing a single firewall rule.

Check 3: map where the data actually lives

List primary storage, replicas, backups and administrative access paths. Backups are the usual omission, and an encrypted tunnel does not change where a snapshot sits.

Assess any international-transfer question inside its own framework. A VPN exit country is a routing fact, not a statement about where the provider processes the data. Teams routinely change the tunnel's exit region and believe they changed the transfer. They have changed which address the traffic appears to come from.

Check 4: state what each control accomplishes

An IP allowlist limits which network sources may connect. A VPN protects a defined path and can reduce direct exposure. Neither one should give every person behind the gateway the same database permissions, because the tunnel authenticates a path, not a person.

Use individual authentication and role-based access, and remove access when someone changes role. Then review encryption and key custody, patching, recovery and incident handling alongside the network controls, in the risk-appropriate terms security guidance uses rather than a fixed checklist.

Check 5: keep the evidence

Keep the processing description, the service agreement, the access decisions, the risk assessment and the named owners. Evidence is what turns a design into something reviewable a year later.

Two decisions deserve explicit answers rather than assumptions. A data protection impact assessment is required where processing is likely to result in high risk, and a data protection officer is mandatory only in specified circumstances. Neither follows automatically from storing data in the cloud, and neither is excluded by it.

What the finished review says

A useful review explains why the VPN is present, what it does not cover, and which obligations sit outside it. That is a short document, and it is far more defensible than a claim that the traffic is encrypted.

Have the responsible privacy and security specialists assess the complete arrangement rather than signing off on the tunnel alone.