GDPR and IT security: protecting personal data in practice

01Establish the legal scope and the responsibility for the data

The GDPR’s Article 3 covers processing in the context of an EU establishment. It also covers certain processing by organizations outside the EU related to offering goods or services to people in the Union or monitoring their behavior there. Assess the actual activities rather than using nationality as a shortcut.

Identify whether the organization determines the purposes and means of processing, acts on another organization’s behalf or has different roles for different activities. The controller and processor distinction affects responsibilities. Calling every software supplier a processor without examining its actual use of the data can produce an inaccurate arrangement.

Connect legal responsibility with operational ownership. The business owner should explain why data is needed. The product team should describe where it goes. Security and operations should demonstrate the controls. A supplier can operate infrastructure while the customer still needs to configure account permissions correctly.

Agree who assesses the applicable obligations and handles uncertain cases. Requirements for a data protection officer, impact assessment or international transfer depend on the processing and relevant conditions. Avoid turning a generic vendor checklist into a complete legal conclusion about a particular business.

Create a concise responsibility record for the portal example. Name the owner of customer account data, the people managing the CRM and the contact responsible for the support provider. Include decision authority and escalation. A list of system names is insufficient when nobody can decide what to do after a disclosure.

02Map the processing before choosing controls

Follow a representative customer request across the systems. Record the information collected, purpose, access, recipients, retention and storage locations. Include attachments, exports, logs and notification messages. Free-text fields can contain much more sensitive information than the product team expected when designing the form.

Under GDPR, processing needs an appropriate legal basis and must meet principles including purpose limitation and data minimization. Consent is one possible basis, rather than the automatic answer for every business operation. Establish the basis and required information for the actual purpose before asking developers to add a checkbox.

• Identify the people and data categories involved.
• Explain the purpose and applicable basis for processing.
• Locate copies, recipients and systems receiving the information.
• Set access, retention and deletion responsibilities.
• Record the risks and the evidence behind selected controls.

Challenge information that has no useful purpose. The service portal might need contact details for a response but have no reason to request an identity-document copy during an ordinary enquiry. Removing unnecessary collection can simplify both the customer journey and the control work that follows.

Map informal paths alongside the official application. Staff may download a spreadsheet to answer a question or forward an attachment to an external address. Discuss why those workarounds exist and design a supported process. A policy that ignores the real operating route is unlikely to describe the organization’s actual risk.

Keep the map current when adding features or suppliers. A new chat assistant, analytics service or integration can create a new copy or recipient. Make processing changes part of product review so the inventory remains a working document rather than a snapshot created for one procurement exercise.

03Design access and defaults around the actual task

The European Commission explains data protection by design and default: safeguards belong in the design, and defaults should limit processing to what the purpose requires. Apply that principle to the portal’s roles, visibility and collection settings before release.

Separate everyday work from privileged administration. A support employee may need the current request and account status, while a billing role needs different information. Define the allowed operations and enforce them on the server. Hiding a button in the interface does not establish that a forbidden request will be rejected.

Review access when someone changes roles or leaves. Include service accounts, shared links and temporary supplier access. For the portal, a contractor’s finished support task should not leave an unrestricted account active indefinitely. The review needs enough context to distinguish required ongoing access from a forgotten exception.

Design exports as deliberate operations. Choose which roles may download data, what the export contains and how the action is recorded. A user with access to a single case should not receive every customer record simply because an export endpoint was built around a broad database query.

Test boundaries with different accounts and realistic record identifiers. Check that one customer cannot request another customer’s attachment or search result. Include administrative and background processes in the review. The web-app security checklist provides related engineering context for those checks.

04Select security measures according to risk and verify them

The EDPB’s security guide emphasizes appropriate technical and organizational measures. Security concerns confidentiality, integrity and availability. A record that remains private but is altered incorrectly or cannot be recovered can still cause harm to the person concerned.

For the portal example, protect both customer-facing functions and operational access. Review authentication, administrative permissions, supported software and relevant dependencies. Choose controls according to the data and credible failure scenarios, and record why they are suitable. A product label alone does not show how a service is configured.

Manage encryption keys and recovery access alongside encrypted storage. Pseudonymized data remains personal data when it can be attributed using additional information. Encryption also does not automatically make the dataset anonymous. The appropriate control depends on the processing and the ability to reconnect information to people.

Exercise restoration into a usable environment. A backup job showing success is different from demonstrating that records, attachments and access settings can be restored. Include the people who would operate recovery and inspect the result. The test should reveal missing permissions or dependencies before a real outage.

Use logs deliberately. Retain the information needed to detect and investigate relevant events without recording unnecessary sensitive payloads. Restrict access to the logs and set their retention. A debugging change that copies every customer attachment into a broadly accessible logging platform can undermine the original application controls.

05Control retention, requests and supplier handover

Decide retention by purpose and applicable obligations, then implement it across the copies that matter. The portal database, CRM, exported files and supplier systems may retain the same request differently. Record necessary exceptions and explain how deletion or restriction affects those copies.

A request to erase data needs assessment of applicable conditions and exceptions. It does not mean every record must always be deleted immediately, while a broad statement that all records are needed forever is equally unhelpful. Make the decision traceable and give the operating team a supported execution process.

Prepare an identity-verification and search process for rights requests that avoids exposing another person’s data. Decide which systems must be checked, who reviews the result and how the response is delivered. The Your Europe GDPR guide provides an official overview of rights and processing responsibilities.

Where a supplier is a processor, Article 28 requires an appropriate binding arrangement with specified protections and responsibilities. Review instructions, assistance, subprocessors and return or deletion at service end. The agreement should correspond to the service actually used and the data path recorded in the inventory.

Assess international transfers where relevant, including remote access and onward processing. A European storage region alone does not establish that every part of the arrangement satisfies transfer requirements. Identify the actual destinations and applicable mechanism instead of making a blanket compliance assumption.

Plan a supplier exit before it is urgent. Confirm the usable export, access removal and handling of remaining copies. The data-migration guide discusses related transition planning; privacy controls should continue through migration and retirement of the old system.

06Prepare breach handling before an incident

The EDPB’s breach-notification guidelines distinguish security incidents from personal data breaches and explain the notification decisions. A breach can concern disclosure, alteration or loss of availability. Assess what happened to the information and the consequences for people.

Under Article 33, a controller must notify the competent supervisory authority without undue delay and, where feasible, within 72 hours after awareness, unless the breach is unlikely to create a risk to individuals’ rights and freedoms. A processor must notify the controller without undue delay. Communication to affected people has a separate high-risk test and applicable exceptions.

Document breaches and the notification assessment. Do not wait for perfect information before starting the response or assume that every incident needs the same external communication. Record known facts, uncertainty, containment and the reasoning behind the decision; information can be provided in phases under the relevant conditions.

1. Provide an accessible reporting route and responsible contact.
2. Contain the incident while preserving useful evidence.
3. Identify affected data, people and consequences.
4. Assess notification and communication obligations promptly.
5. Document the decisions and follow corrective work through.

Rehearse an illustrative portal incident: an attachment was accessible to the wrong account. The team needs to identify the access window, affected records and actual exposure, disable the faulty route and assess consequences. A general statement that the platform uses encryption will not answer those questions.

Keep contacts and supplier escalation usable outside normal office hours where the service requires it. Technical containment and legal assessment may proceed together. The practical aim is a response that protects people and produces a defensible record, with decisions made by those who have the relevant responsibility.

07Maintain evidence as the system changes

Keep a short control register with the risk, measure, owner, review trigger and latest evidence. Link it to product and operational work so a finding becomes an owned action. Avoid collecting documents that describe controls nobody can demonstrate in the current environment.

The Commission’s guidance explains that a DPIA is required where processing is likely to result in a high risk to individuals’ rights and freedoms. Assess this before processing starts, considering the relevant authority’s requirements. Where unmitigated high residual risk remains, assess the prior-consultation obligation rather than treating the document as a release formality.

Give employees instructions connected to their real tasks. Show where to report an unexpected disclosure, how to share a case safely and what to do when a customer requests access. Useful training reduces improvisation and connects the policy with the operations people perform each day.

08Questions about GDPR and practical IT security