What is GDPR Compliance?

Back to learning

GDPR compliance is the work of meeting the General Data Protection Regulation's requirements for personal data. For web services, that means knowing what personal data is collected, why it is processed, who receives it, where it moves, how long it is kept, and how people can exercise their rights.

This page is general technical education, not legal advice. GDPR obligations depend on the organisation, the processing activity, the people affected, each party's role, and the countries involved. No technical control can guarantee compliance by itself. The practical job is to keep system behaviour aligned with the organisation's privacy decisions.

Start With Personal Data and Purpose

GDPR work starts with a real data map. A website or application may collect obvious personal data such as names, emails, account IDs, order details, support messages, and payment-related identifiers. It may also process operational data that can relate to a person in context: IP addresses, cookie IDs, device identifiers, login events, request paths, analytics IDs, bot scores, and fraud signals.

Those data types do not all carry the same risk, but they should not be ignored just because they live in telemetry rather than the main database. A failed-login log tied to an account, a WAF event containing a request path, or an analytics event with a persistent identifier may still matter for privacy review.

Each processing activity needs a purpose and an appropriate lawful basis. Consent is one possible basis, but it is not the only one. Contract, legal obligation, legitimate interests, and other bases may be relevant depending on the activity. The important operational point is specificity. If a log exists for security monitoring, say that. If the same data is later reused for marketing or product analytics, that is a different use and should be reviewed.

Minimisation follows from purpose. Collect the fields needed for the job, keep sensitive values out of general logs, redact secrets, and avoid turning every incident sample into a permanent dataset. Retention should also follow purpose. "Keep everything forever" is convenient during debugging but hard to defend. "Delete everything immediately" may break incident response, fraud review, billing, or legal duties.

Processors, Subprocessors, and Data Movement

Modern web services use many vendors. Hosting, CDN, DNS, WAF, bot management, analytics, payment, email, support, monitoring, log storage, and fraud tools may all process personal data. GDPR distinguishes between controllers and processors, and processors may use subprocessors. Those roles affect contracts, instructions, security obligations, assistance with rights requests, and breach handling.

Vendor review should be tied to actual data flows, not just procurement records. Which fields does the vendor receive? Is payload data sampled? Are IP addresses enriched with geolocation or reputation? Are logs forwarded to a SIEM, object store, or support tool? Who can access production data for support?

Data residency and transfer questions sit in the same map. Selecting an EU cloud region may not be enough if backups, logs, support access, edge processing, or analytics exports move data elsewhere. International transfers need appropriate review and safeguards for the circumstances. Engineering teams do not need to invent the legal mechanism, but they do need to know where the data actually goes.

Security, Logging, and Monitoring

GDPR expects appropriate security for personal data, but "appropriate" is contextual. A public marketing page, a healthcare portal, a payment workflow, and an administrator console do not need identical controls. Common measures include access control, encryption, secret handling, vulnerability management, backup protection, and review of privileged access.

Security telemetry creates a real tension. Teams need logs and monitoring to detect credential stuffing, scraping, account takeover, API abuse, DDoS pressure, and unauthorised access. Privacy work requires minimisation, access control, retention limits, and clear purpose. Good audit logging records the actor, action, target, time, source, result, policy, and route where needed, while keeping passwords, tokens, cookies, payment details, and unnecessary payload content out of broad telemetry.

Logs should be queryable during an incident and protected like production data. Limit who can search them, record sensitive log access, forward only needed fields, and set retention by use case. Security evidence is useful only when it can be trusted and explained without creating a larger privacy problem.

Rights and Incident Response

GDPR gives individuals rights that may include access, correction, erasure, restriction, objection, portability, and information about processing. Handling those rights is an operational workflow. Teams need identity verification, data discovery, vendor coordination, exception handling, and evidence that a request was completed or lawfully limited. Security logs may not always be deleted on request if there is a stronger reason to retain them, but that decision should be recorded and reviewed.

Incident response also needs preparation. Teams should be able to identify affected systems, data classes, users, vendors, time periods, containment steps, and evidence. GDPR breach notification rules can be time-sensitive, so the first hours of an incident are the wrong time to discover that logs are missing, vendor contacts are unclear, or no one knows which edge and monitoring systems received the relevant data.

GDPR compliance for web services is therefore less about a single banner or policy page and more about controlled operations: data maps, lawful purpose, minimisation, vendor governance, security controls, logging discipline, transfer review, rights handling, and incident readiness. The system has to match the statement the organisation is prepared to stand behind.