GDPR compliance: the parts a small company actually has to do

GDPR compliance means being able to show that personal data you hold is processed lawfully, for stated purposes, with appropriate security, for no longer than needed, and that people can exercise their rights over it. The regulation is principles-based, which is why two companies of the same size can arrive at very different — and both defensible — programmes.

What is not optional is accountability: you must be able to demonstrate compliance, not merely assert it. In practice that turns a set of principles into a set of records, and the records are what an inquiry starts from.

The GDPR compliance obligations that produce records

• A record of processing activities: what you process, why, on what lawful basis, who you share it with, how long you keep it, and where it goes.
• A privacy notice that matches what the record says — not a template describing a different company.
• Lawful basis for each purpose, decided and written down, with a legitimate interests assessment where that is the basis.
• Data processing agreements with every processor, and diligence that they are adequate.
• A retention schedule that is actually applied, not merely published.
• A process for handling rights requests within the deadlines.
• Breach detection and a 72-hour notification decision, with the reasoning recorded even when you decide not to notify.
• A DPIA where processing is likely to be high risk.

What small companies over-build and under-build

Over-built: policy libraries. A twelve-document policy set for an eight-person company is a maintenance burden that will be out of date within a year, and no regulator asked for it.

Under-built: the processing record and the supplier chain. Most small companies cannot say quickly which third parties hold their customers’ data, and that is the first question in an incident. The same gap turns into a contractual problem the first time an enterprise customer sends a due diligence questionnaire.

Transfers out of the EEA or UK are the obligation most often missed entirely, because they happen invisibly through ordinary SaaS. If a supplier stores or supports data outside the region, that is a transfer, and it needs a lawful mechanism such as standard contractual clauses plus an assessment of the destination.

One obligation has a clock attached rather than a review cycle. A data breach must be assessed for risk to the people affected and, above a low threshold, reported within seventy-two hours of awareness.

A proportionate order of work

1. Map what you process, starting from the systems that actually hold personal data.
2. Write the lawful basis against each purpose, and fix the ones that do not hold up.
3. Update the privacy notice so it matches the map.
4. List your processors, get the agreements in place, and note where data goes.
5. Set retention periods per category and implement at least the ones that are automatable.
6. Write down how rights requests will be handled, and test it once with a fake request.
7. Decide who makes the breach notification call, and make sure they can be reached at the weekend.

Documentation with a review date and an approver is the practical form GDPR accountability takes. Ettex Docs keeps the notice, the assessments and the agreements with their approvals and revision history, so a question about what the policy said in March is answered from the document rather than from memory. Ettex does not make an organisation compliant — the processing decisions are the organisation’s.

Two obligations generate almost all the day-to-day work. A data subject access request has a statutory deadline and arrives without warning, so the process has to exist before the first one. And where you rely on an information security standard as evidence of your measures, iso 27001 certification is what makes that claim checkable by a customer rather than asserted.

Two pieces of evidence get asked for first in any assessment. Standard contractual clauses cover transfers to processors outside the region, and a record of processing activities has to be derivable from your information asset register rather than maintained as a separate list that drifts.