What the DPA 2018 Does with Criminal-Offence Data

Criminal-offence data is not just another awkward category of personal data. An employer, landlord or app cannot collect it because a checkbox says "we might need this". Article 10 of the UK GDPR adds a separate control layer, and the Data Protection Act 2018 supplies many of the routes through it.

What counts as criminal-offence data?

The category covers personal data about criminal convictions and offences, plus related security measures. A conviction is the obvious example, but the category is wider than a neat list of convictions in a court record.

It can include allegations, investigations, prosecutions, cautions and other information about suspected or alleged offending, depending on what the data says and how it is used. A record saying that someone was arrested is not the same thing as a conviction, and treating those facts as interchangeable is a particularly nasty way to make a database sound more certain than it is.

Section 11(2) of the Data Protection Act 2018 expressly includes data about the alleged commission of offences and proceedings for offences committed or alleged to have been committed, including sentencing. The ICO uses "criminal offence data" as a convenient label, although that is not the phrase used by the UK GDPR itself.

The practical point is that the label follows the information, not the table it happens to sit in. A free-text incident note can qualify just as readily as a column named conviction_status.

Article 10 puts a second lock on processing

Start with the ordinary UK GDPR rules. You still need a lawful basis under Article 6, such as legal obligation, public task, legitimate interests or consent where consent is genuinely appropriate. You still need a specified purpose, data minimisation, accuracy, security and a retention period that can be defended.

Then add Article 10. Processing criminal-conviction and offence data is allowed only under the control of official authority, or when authorised by UK law that provides appropriate safeguards for the rights and freedoms of data subjects.

That second test is why "we have consent" is not a universal answer. Consent might provide an Article 6 lawful basis, but it does not by itself create the Article 10 authorisation that the processing needs.

You need both layers: an Article 6 lawful basis and either official authority or a relevant legal authorisation for the criminal-offence processing.

Section 10 tells you where the DPA fits

Section 10 of the 2018 Act connects Article 10 to Schedule 1. For ordinary, non-law-enforcement processing under the UK GDPR and Part 2 of the Act, Schedule 1 provides the domestic-law conditions that can authorise particular processing.

Schedule 1 contains conditions for purposes including:

Employment, social security and social protection;
health or social care, public health and research;
statutory and government purposes, and administration of justice;
preventing or detecting unlawful acts and preventing fraud;
protecting the public against dishonesty;
safeguarding children and individuals at risk;
legal claims, judicial acts and data manifestly made public by the person concerned.

The exact condition matters. "This is useful for risk management" is not a statutory condition, and stretching a condition past its wording is not made safer by adding a longer privacy notice.

Some conditions also require the organisation to justify why it cannot give the person a choice and obtain explicit consent. Others require an appropriate policy document. The condition is not a general permission slip for anything vaguely related to safety.

Law enforcement is a different part of the Act

The rules above concern general processing under the UK GDPR and Part 2 of the DPA 2018. A competent authority processing personal data for law-enforcement purposes generally falls under Part 3 instead.

That distinction matters for a police force, but it can also matter for a public body that holds a criminal-record register. The legal regime depends on the organisation's role and the purpose of the processing, not simply on whether the database contains convictions.

Do not mix Part 2 and Part 3 when designing a system or writing a privacy notice. The principles and safeguards overlap in places, but the statutory gateways are different.

Some conditions require an appropriate policy document

An appropriate policy document explains how the organisation meets the data protection principles and how it handles retention and erasure for the relevant processing. It is an internal accountability document, not merely a public-facing privacy notice.

For the conditions that require one, it should identify:

the Schedule 1 condition being relied upon;
the procedures used to comply with the data protection principles;
the retention and deletion policies;
the retention period for the particular data;
the person responsible for the processing and the review arrangements.

The ICO says the document must normally be retained for at least six months after the relevant processing stops. It also expects organisations to keep related records showing the lawful basis, the criminal-offence condition and whether the retention and deletion policies were followed.

A policy document does not make an unlawful purpose lawful. It records the safeguards around a processing condition that already has to fit the facts.

What the common routes look like in practice

Employment and recruitment

An organisation checking criminal records for a role normally needs more than a general "background checks" sentence in its recruitment notice. It needs an Article 6 basis, an Article 10 route, and a reason the information is necessary for that particular role.

For criminal-record certificates, the Disclosure and Barring Service framework is usually central. The organisation should not casually keep the whole certificate forever just because it might be useful later. The purpose, the role, the access controls and the retention period all need to line up.

Preventing fraud and unlawful acts

A fraud-prevention service may have a stronger argument than a retailer collecting convictions for vague "customer safety" reasons, but it still has to identify the relevant condition and keep the processing proportionate. Matching a person to an allegation, sharing a false positive or retaining an old result can cause real harm.

Accuracy is not a clerical detail here. A criminal-offence record that is wrong, stale or missing its context can change whether somebody gets housing, work, insurance or access to an account.

Safeguarding

Safeguarding conditions can permit processing where it is necessary to protect children or adults at risk. That does not mean every suspicion should be copied into every system. The data still needs a defined purpose, restricted access and a process for correcting or challenging mistakes.

A quick detour: a DBS certificate is not a general-purpose database extract

It is tempting to treat a criminal-record certificate as a permanent credential: receive it, scan it, attach it to the employee record, and forget about it. That is usually the wrong mental model.

The information was obtained for a particular decision and context. Reusing it for a different purpose may need its own justification, and storing it indefinitely creates a larger breach and insider-risk target. The sensible design is often to record the decision, the level and date of the check, and the narrow facts needed to operate the process, rather than keeping every document by default.

Criminal-offence data is not automatically special-category data

Article 10 is separate from Article 9. Criminal-offence data does not automatically become special-category data merely because it is sensitive or damaging. But the same record can contain both kinds of information, for example a conviction alongside information about health, religion or sexual life.

When that happens, the organisation has to satisfy both sets of rules. It also needs to avoid the reverse mistake: Article 10 does not make ordinary personal data harmless just because it is not in an Article 9 category.

What a defensible implementation records

For each use of criminal-offence data, write down the decision before the data starts flowing. At minimum, the record should cover:

the purpose and the specific data fields needed;
the Article 6 lawful basis;
the Article 10 route, including the exact Schedule 1 condition or official-authority basis;
any required appropriate policy document;
who can access the data and how disclosures are controlled;
how accuracy, challenge, correction and deletion work;
the retention trigger and the event that ends retention.

Write the retention rule as an event, not a feeling. "Keep while relevant" is difficult to test. "Delete six months after the recruitment decision unless an active legal duty requires longer retention" is something a system can enforce and an auditor can examine.

The awkward cases are where the law matters most

The Act does not turn every criminal-record question into a simple yes or no. Processing can depend on the role, the source of the information, the purpose, the safeguards and whether the organisation is acting under a specific legal function. The same data may be justified for one decision and excessive for another.

That is the useful engineering interpretation: model criminal-offence data as a high-risk data flow with a named legal route, not as a string that happens to need extra encryption. Encryption, access control and audit logs are necessary safeguards, but they cannot repair a purpose that was never authorised in the first place.

The statutory starting points are section 10, section 11 and Schedule 1 of the Data Protection Act 2018. The ICO's criminal-offence-data guidance is useful for applying those provisions, although the ICO currently says that guidance is under review following changes made by the Data (Use and Access) Act.