Is my small business GDPR-ready?

Under the Data Protection (Charges and Information) Regulations 2018, controllers processing personal data must pay an annual fee to the ICO (tiered £40/£60/£2,900 by size) unless an exemption applies. Non-payment is itself an enforceable offence — the ICO runs a dedicated team issuing monetary penalties to non-payers — so it's treated here as a clear, standalone fail rather than a 'nice to have'.

UK GDPR's accountability principle (Article 5(2)) requires you to be able to demonstrate compliance. A statutory Data Protection Officer (Article 37) is only mandatory for large-scale or public-authority processing, but every organisation still needs clear ownership — a named person responsible for policies, records of processing (Article 30) and responding to the regulator.

Articles 13 and 14 require you to give individuals specified 'privacy information' at the point you collect their data: who you are, what you're doing with it, your lawful basis, retention periods, who you share it with, and their rights. For most small businesses this is satisfied by a clear, accurate, accessible privacy notice — its absence is a direct breach of the transparency principle, which is why it's a standalone fail here.

Article 6 sets out six lawful bases; you must identify and document the appropriate one for each processing activity before you begin, and you can't simply swap bases later. Special-category data (health, biometrics, etc.) needs an additional Article 9 condition. The basis you choose also changes which individual rights apply — e.g. the right to erasure and portability bite differently under consent vs contract vs legitimate interests.

The Privacy and Electronic Communications Regulations (PECR) sit alongside UK GDPR and govern electronic marketing. The default for email/SMS marketing to individuals is prior opt-in consent, with a narrow 'soft opt-in' exception for existing customers about similar products. Consent must meet the GDPR standard (freely given, specific, unbundled) and every message must offer a simple opt-out — PECR breaches are a common source of ICO fines.

Article 32 explicitly names encryption as an example 'appropriate measure'. In practice the baseline is TLS on every page that transmits personal data, with modern protocol versions (TLS 1.2/1.3), legacy protocols (1.0/1.1) disabled, a valid certificate and HSTS to prevent downgrade. Our passive and in-depth scans observe exactly these, so a weak or missing TLS configuration directly contradicts a 'yes' here.

Article 32 requires a level of security appropriate to the risk; running software with known, exploitable CVEs falls below that bar and is a frequent root cause in ICO enforcement cases. Our in-depth scan fingerprints internet-facing services and flags known vulnerabilities, so a detected CVE is citable evidence against a 'we're fully patched' claim.

Exposing data stores (MySQL, PostgreSQL, MongoDB, Redis) or remote-admin services (RDP, SSH, VNC) directly to the internet dramatically enlarges the attack surface and is a recurring cause of mass personal-data exposure. Our exposure and in-depth scans enumerate open ports, so a sensitive service reachable from outside contradicts a claim that admin/database access is restricted.

These are the 'organisational' half of Article 32 plus the integrity-and-availability principle (Article 5(1)(f)): least-privilege access, MFA on accounts that touch personal data, and tested backups to recover from ransomware or loss. None of this is visible to an external scan — it's self-declared, and a CE Plus-style audit or an ICO investigation would test it on your actual systems.

The right of access (Article 15) requires you to confirm whether you process someone's data and provide a copy, normally within one month (extendable by two for complex requests) and usually free. Meeting it in practice depends on knowing your data map — every system, inbox, spreadsheet and backup where personal data sits — which is why an up-to-date record of processing (Article 30) makes the right achievable rather than panic-inducing.

Beyond access, individuals have rights to rectification (Article 16) and erasure (Article 17, the 'right to be forgotten'), plus restriction, objection and portability in defined circumstances. These aren't absolute — erasure can be refused where you have an overriding legal obligation to keep the data — but you must recognise a request (in any format), respond within the statutory deadline, and document your reasoning.

A 'personal data breach' (Article 4(12)) covers any breach of security leading to accidental or unlawful destruction, loss, alteration, or unauthorised disclosure of/access to personal data — so it includes a lost laptop or a misdirected email, not just hacking. Detection depends on logging and monitoring proportionate to your risk, plus staff who can recognise and escalate an incident; you can't meet the reporting clock for something you never noticed.

Article 33 requires notifying the ICO of a notifiable breach 'without undue delay and, where feasible, not later than 72 hours' after becoming aware, unless it's unlikely to risk people's rights and freedoms; Article 34 adds a duty to tell affected individuals when the risk is high. Even where you decide not to report, you must record the breach and your reasoning. A short, written incident plan naming roles and the ICO's reporting route is what turns the 72-hour duty from a crisis into a checklist.

The data-minimisation principle (Article 5(1)(c)) requires personal data to be adequate, relevant and limited to what's necessary for your stated purpose. It pairs with purpose limitation (Article 5(1)(b)): data collected for one reason shouldn't be quietly repurposed. Minimising at the point of collection is also the cheapest security control there is — data you never hold can't be breached.

The storage-limitation principle (Article 5(1)(e)) forbids keeping personal data in identifiable form longer than necessary. In practice that means a retention schedule per data type, with secure deletion (or anonymisation) at the end — including in backups and archives. Over-retention is a common finding in ICO audits and needlessly increases both breach exposure and subject-access workload.

Article 28 requires a binding contract (a Data Processing Agreement) whenever a processor handles personal data for you, mandating specific terms: processing only on documented instructions, confidentiality, Article 32 security, sub-processor controls, assistance with rights and breaches, and deletion/return at the end. You remain the accountable controller for your processors' failings, so due diligence and the DPA aren't optional paperwork — they're how liability is managed.

Chapter V restricts transfers of personal data outside the UK unless covered by 'adequacy' regulations (the EU, and others the UK recognises) or an appropriate safeguard such as the International Data Transfer Agreement / the UK Addendum to the EU SCCs, often supported by a transfer risk assessment. Many SaaS tools host or support data abroad, so this frequently applies even to small businesses — the provider's documentation usually states which mechanism they rely on.