<img src="https://secure.intelligence52.com/795135.png" style="display:none;">
Velocity Blog

GDPR Best Practices: 8 Actions Enterprise IT Teams Can Start This Week

By Anthony Lamoureux
Privacy counsel reviewing an enterprise notice

GDPR Best Practices: 8 Actions Enterprise IT Teams Can Start This Week

Privacy counsel reviewing an enterprise notice

The GDPR best practices that matter most right now are a current record of processing activities under Article 5(2), data protection by design under Article 25, proportionate security controls under Article 32, risk-based DPIAs, breach readiness built around the 72-hour notification duty, and documented transfer safeguards. The EDPB frames these as the backbone of demonstrable accountability, not optional extras.


TL;DR:

  • Build the processing record function by function, capturing purposes, data categories, recipients, transfers, retention periods, and security measures; update it whenever systems or vendors change.
  • Publish a separate notice for each purpose at onboarding, web forms, and physical handover points, naming its lawful basis, sharing, retention, and rights contact.
  • Breach workflows should log every incident and notify the regulator within 72 hours when the risk test is met, then inform affected people if risk is high.
  • Assess new technology, large scale processing, special category data, and consequential automated decisions for DPIA needs; consult the regulator if mitigation leaves high residual risk.
  • Map every cross border flow, including remote access by traveling staff and overseas contractors, and use approved safeguards plus added protections when residual risks remain.

Velocity-smart
Keep Physical IT Data in ServiceNow
Smart Collect runs natively in ServiceNow, keeping asset state and audit data in your tenant without a parallel database or data sync.
Visit Velocity Smart

Table of Contents

1. Top GDPR best practices checklist

Each item below maps a legal duty to a concrete starting action for this week.

  1. Map your processing. Build or refresh your record of processing activities under Article 30, starting with a data-mapping sprint across business units.
  2. Embed privacy by design. Apply Article 25 thinking to every new system or feature before launch, not after a complaint.
  3. Right-size your security. Select technical and organisational measures under Article 32 proportionate to the risk, with encryption and access control as a baseline.
  4. Prepare for breaches now. Draft a detection-to-notification workflow that can meet the 72-hour duty described in EDPB breach guidelines.
  5. Run DPIAs on high-risk projects. Screen new technology, large-scale processing and automated decisioning for mandatory assessment.
  6. Check every cross-border data flow. Confirm lawful transfer mechanisms wherever data leaves its home jurisdiction.
  7. Tighten supplier contracts. Insert processor obligations and audit rights into every new and renewed agreement.
  8. Keep governance visible. Maintain policies, training logs and decision records that an inspector could review without notice.

2. Data mapping and the record of processing activities

A record of processing activities (ROPA) is the single document regulators ask for first, and the ICO recommends building it function by function rather than system by system. Each entry needs to capture:

  • The purpose of the processing and the categories of personal data involved.
  • Recipients, including any processors or group companies that receive the data.
  • Whether data moves outside the country or region, and on what basis.
  • Retention periods and the rationale behind them.
  • A summary of the security measures protecting that category of data.

Start with a short questionnaire sent to business unit leads, followed by workshops with IT and HR to resolve gaps. Electronic templates beat spreadsheets for version control, and the record only earns its keep if it stays linked to change control, so every new system or vendor triggers an update rather than a yearly scramble.

3. Lawful basis and transparency in your privacy notices

Every processing purpose needs its own lawful basis, documented at the point of decision rather than reconstructed later when a regulator asks. Consent, contract, legal obligation and legitimate interests are not interchangeable, and mixing them inside one vague notice is a common failure point.

A privacy notice that satisfies Articles 12 to 14 should cover:

  • What is collected and why, in language a non-specialist reader understands.
  • The lawful basis relied on for each distinct purpose.
  • Who the data is shared with and for how long it is kept.
  • Contact details for exercising data subject rights.

Publish notices at every meaningful touchpoint: onboarding, web forms and physical handover points such as equipment collection desks. One test works for all of them: can a reader explain, after one pass, what happens to their data, why, and who to contact?

4. Data protection by design and by default under Article 25

Article 25 turns privacy from a compliance afterthought into a design requirement, and the EDPB guidelines on Article 25 expect it applied from the planning stage, not bolted on before release.

  • Run lightweight threat modelling on any new system that touches personal data.
  • Default to data minimisation: collect only the fields a process genuinely needs.
  • Use pseudonymisation where identity is not required for the task at hand.
  • Set default access permissions and role-based access control to the narrowest useful scope.
  • Add a data protection checkpoint to procurement and vendor-selection checklists.

Pro Tip: Build an Article 25 question into your change-approval form so no feature reaches production without a documented privacy check.

5. Security measures and breach readiness under Article 32

Article 32 does not list one fixed set of controls; it asks for measures proportionate to the risk the processing actually carries. In practice that means:

  • Encryption of data at rest and in transit for anything sensitive or large-scale.
  • Access control and logging tied to individual accounts, not shared credentials.
  • Continuous monitoring capable of surfacing anomalies quickly.
  • A tested recovery process that restores availability after an incident.

A breach must typically reach the supervisory authority within 72 hours of the organisation becoming aware of it, according to ICO breach guidance, which means detection speed matters as much as the controls themselves.

The incident flow that satisfies both the ICO and EDPB breach guidelines runs: detect, contain, assess risk, notify the regulator within 72 hours if the risk test is met, then inform affected individuals if the risk is high. Every incident gets logged internally, even the ones that never cross the notification threshold.

6. DPIAs and risk-based assessments

A data protection impact assessment becomes mandatory, according to EDPB guidance, whenever processing is likely to result in high risk to individuals. Common triggers include new or untested technology, large-scale processing of personal data, processing of special category data, and automated decision-making with legal or similarly significant effects.

  1. Describe the processing. Set out the purpose, scope and context in plain terms.
  2. Test necessity and proportionality. Confirm the processing is the least intrusive route to the goal.
  3. Build a risk register. Score likelihood and severity for each identified risk to individuals.
  4. Record mitigations and the final decision. Note residual risk and who approved it, with a review date.

Consult the supervisory authority before proceeding when residual risk remains high after mitigation, and keep the whole assessment on file as evidence of the decision process.

7. International transfers and Chapter V safeguards

Chapter V applies once personal data crosses outside the data’s home jurisdiction to a third country, and EDPB guidance on international transfers sets three cumulative criteria for when that counts as a transfer rather than ordinary processing. Where it applies, organisations need an adequacy decision or an appropriate safeguard: Standard Contractual Clauses, Binding Corporate Rules, an approved code of conduct or certification, or, in narrow cases, a specific derogation.

  • Map every cross-border data flow, including remote access from staff travelling abroad.
  • Flag edge cases where support staff or contractors access systems from another country.
  • Put SCCs or BCRs in place wherever a formal transfer mechanism is required.
  • Add supplementary measures, such as encryption or restricted access, where a transfer tool alone leaves residual risk.

Firms handling remote access or distributed support teams can find practical detail on avoiding unintended offshore exposure in this guide to preventing offshore data transfers.

8. Accountability, governance and third-party contracts

Article 5(2) makes accountability a standalone obligation: being compliant is not enough if you cannot show how. Inspectors expect to see:

  • Written policies covering the core obligations, kept current and version-controlled.
  • A named owner, whether a formal DPO or an internal lead, accountable for the programme.
  • Training logs showing who completed what, and when.
  • Supplier contracts carrying processor obligations, security guarantees and audit rights.
  • Records of key decisions, including DPIA outcomes and risk acceptances.

Review supplier contracts periodically rather than only at renewal, and build data protection requirements into procurement templates so new vendors are screened before a contract is signed, not after.

9. Monitoring, training and continuous improvement

Controls decay without maintenance. Set a review cadence for the ROPA and any live DPIAs, run targeted training for teams handling higher-risk data, and rehearse incident response with tabletop exercises rather than waiting for a real breach to test the plan.

  • Review the ROPA and open DPIAs on a fixed schedule, not ad hoc.
  • Track incident counts, time to contain and training completion as recurring metrics.
  • Run periodic penetration testing against systems holding personal data.

Pro Tip: Track data-protection KPIs alongside existing ITSM metrics so privacy performance sits in the same dashboard your IT operations team already reviews.

10. Why physical IT workflows deserve the same rigour

Physical IT device handoffs with custody records

Data protection programmes often stop at digital systems and leave physical handover, the laptop swap, the loaned device, the returned peripheral, undocumented. When ROPA entries and DPIA outcomes are linked directly to ITSM records and the CMDB, every asset movement carries its own audit trail automatically, which removes a recurring source of audit friction.

Teams running multi-site rollouts benefit most from prioritising controls that scale the same way across every location and every physical handover point.

— Anthony

This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.

FAQ

What are the seven basic principles of GDPR?

The principles are lawfulness, fairness and transparency; purpose limitation; data minimisation; accuracy; storage limitation; integrity and confidentiality; and accountability. Accountability requires controllers to demonstrate compliance with the other six, as set out in Article 5(2).

What are the basic GDPR rules organisations must follow?

Organisations must establish a lawful basis for processing, keep records of their activities, apply appropriate security measures and respect data subject rights. They must also notify the supervisory authority of qualifying breaches within 72 hours, under ICO guidance.

What are the eight data protection principles under older UK law?

The GDPR itself sets out six core principles, listed above. Some organisations still reference an older eight-principle framework from prior UK data protection law, but current GDPR compliance should be measured against the six principles in Article 5.

What are the six data protection principles of GDPR?

They are lawfulness, fairness and transparency; purpose limitation; data minimisation; accuracy; storage limitation; and integrity and confidentiality, with accountability sitting alongside them as the evidencing duty. Each principle shapes a specific control, from privacy notices to retention schedules.

Sources

Anthony Lamoureux
Share LinkedIn X Email

See what Smart Collect® could save you

Model your savings in two minutes, or book a 60-minute workshop to pressure-test the numbers against your estate.

Smart Locker Buyer's Guide

Nine smart locker suppliers, compared on the things that actually differ.

Architecture, economics, ServiceNow integration and a twelve-question buyer's checklist. Every claim traced to the supplier's own published material.

Method and sources published in full, so you can check us.