UK GDPR and Data Protection Compliance Support

Start by finding the data

Almost every compliance problem we encounter traces back to the same root cause: the business does not know what personal data it holds. Data accumulates in mailboxes, in a shared drive nobody has audited, in a CRM, in a spreadsheet on someone's laptop, in an old backup, and in half a dozen SaaS tools signed up for on a company card.

Data mapping fixes that. It is not glamorous work, but it is the foundation for everything else — you cannot write an accurate privacy notice, respond properly to a subject access request, assess a breach or defend a retention practice without it. It also routinely finds data the business should have deleted years ago, which is free risk reduction.

• ✓What categories of personal data you hold, including any special category data
• ✓Where each category physically and logically lives, including in email
• ✓Who has access, internally and among suppliers
• ✓Your lawful basis for each processing purpose
• ✓How long you keep it and what triggers deletion
• ✓Whether any of it leaves the UK, and on what transfer mechanism

Subject access requests without the panic

A subject access request must generally be answered within one calendar month, free of charge, and can arrive by any route — including a comment on social media or a verbal request to a member of staff who does not recognise what it is. Requests from disgruntled former employees are common and are frequently the most demanding.

What makes them manageable is preparation: staff who can recognise a request, a single internal route for logging it, a documented search process across the systems your data map identified, and templates for the response and for common exemptions such as third-party personal data and legal privilege.

• ✓Staff trained to recognise and escalate a request however it arrives
• ✓Central log with the one-month clock started on receipt
• ✓Documented search process covering email, file storage and business systems
• ✓Redaction approach for third-party data and applicable exemptions
• ✓Response templates and a record of what was disclosed and why

Breach reporting and the 72-hour clock

If a personal data breach poses a risk to the individuals affected, it must be reported to the ICO within 72 hours of the organisation becoming aware of it. Where the risk is high, affected individuals must also be told without undue delay.

Two points cause the most trouble. First, the clock starts at awareness, not at the end of the investigation — so a partial report followed by an update is the correct approach, not a delayed complete one. Second, not every incident is reportable, but every incident must be recorded internally with the reasoning, because the ICO can ask to see that record and its absence looks considerably worse than a marginal decision not to report.

• ✓Documented risk assessment to decide whether the reporting threshold is met
• ✓Internal breach register recording every incident and the decision made
• ✓ICO notification process and template with the required content
• ✓Individual notification template for high-risk breaches

Security is a legal requirement, not just good practice

Article 32 requires appropriate technical and organisational measures to secure personal data, taking account of the risk. That is where data protection and cyber security meet: MFA, encryption, access control, patching, backup and staff training are not merely sensible, they are how you evidence compliance with a legal duty.

It is also what the ICO looks at after a breach. Enforcement action frequently turns on whether basic, well-known measures were in place — not on whether the organisation was defeated by something sophisticated.