Article 10: Processing of personal data relating to criminal convictions and offences

To comply with GDPR Article 10, only process personal data about criminal convictions, offences, or related security measures if (a) it is under the control of an official authority or (b) EU or Member State law explicitly authorizes your processing and you apply appropriate safeguards. Operationally, you must identify where this data appears, confirm the legal authorization, restrict access, and prove the safeguards work. ¹

Key takeaways:

• Article 10 is a gating requirement: without official-authority control or explicit legal authorization, you should not process criminal offence data. ¹
• “Appropriate safeguards” must be designed into intake, access, sharing, and retention workflows, not left as policy language. ¹
• If you keep a comprehensive register of criminal convictions, it must be under official-authority control. ¹

Article 10 is easy to misunderstand because it does not behave like a typical “pick a lawful basis under Article 6 and proceed” requirement. It adds a hard constraint on a specific data category: personal data relating to criminal convictions and offences (and related security measures). The constraint is binary. Either your processing is under the control of an official authority, or it is explicitly authorized by EU or Member State law and you can demonstrate safeguards that protect data subjects’ rights and freedoms. ¹

For a CCO or GRC lead, the fastest path to operationalizing Article 10 is to treat it as an intake and scoping control first, then a set of “prove-it” controls second. Intake means you can reliably detect where criminal offence data enters your environment (HR, background screening, KYC/AML-adjacent workflows, trust & safety, fraud, hotline investigations, customer support attachments). “Prove-it” means you can show a regulator or enterprise customer the legal authorization basis, the safeguards you implemented, and evidence they operate across systems and third parties. ¹

Regulatory text

GDPR Article 10 states that processing of personal data relating to criminal convictions and offences or related security measures, when based on an Article 6(1) lawful basis, is permitted only (1) under the control of official authority, or (2) when authorized by Union or Member State law that provides appropriate safeguards for the rights and freedoms of data subjects. It also states that any comprehensive register of criminal convictions must be kept only under the control of official authority. ¹

What the operator must do: translate that text into a gating decision and a control set:

1. Gate: confirm whether you are processing criminal offence data at all, and if yes, whether official authority control or explicit legal authorization exists. ¹
2. Safeguard: implement and evidence safeguards aligned to the processing risk and your operational reality (access control, minimization, retention, disclosure control, auditability). ¹
3. Register control: ensure you do not maintain a “comprehensive register” unless you are operating under official authority control. ¹

Plain-English interpretation (requirement-level)

You may handle criminal conviction/offence data only in narrow circumstances. If you cannot point to an EU/Member State law that authorizes your specific processing (and specifies safeguards) or you are not operating under official authority control, you should treat the processing as prohibited and redesign the workflow to avoid collecting or storing that data. ¹

Article 10 also warns against building your own “shadow criminal records database.” If your business process results in a broad, reusable repository of conviction/offence data about many individuals, that starts to look like a comprehensive register. Article 10 reserves that category for official authority control. ¹

Who it applies to (entity and operational context)

Applies to:

• Controllers deciding to collect, store, analyze, or share criminal conviction/offence data in the EU/EEA context. ²
• Processors handling this data on behalf of a controller (for example, HR platforms, screening providers, case management tools, or hosted trust & safety tooling). Your obligation is operational: you must support the controller’s restrictions and safeguards and not expand processing beyond instructions. ²

Where it shows up in practice (common processing contexts):

• Hiring and worker onboarding (background checks; self-disclosure forms; adverse action documentation).
• Security and fraud investigations (incident records that include allegations or findings of offences).
• Trust & safety / marketplace moderation (reports of theft, assault, or other alleged offences).
• Customer due diligence workflows where teams attempt to store offence-related information in free-text notes.

Third-party angle: this category frequently enters through third parties (screening firms, investigation partners, outsourced support). Your due diligence must confirm whether their processing is authorized and what safeguards they run, because their workflow becomes your risk surface. ¹

What you actually need to do (step-by-step)

Step 1: Make Article 10 scoping a mandatory intake question

Add explicit questions to your privacy intake, DPIA intake, and third-party onboarding:

• “Will this processing involve criminal convictions/offences data or related security measures?”
• “Will we receive it in attachments, free text, case notes, or structured fields?”
• “Which systems will store it and for how long?”

Operator tip: most “surprises” come from unstructured inputs (email forwarding, PDFs, support tickets). Treat unstructured channels as in scope until proven otherwise.

Step 2: Create a role-and-scope register entry (controller/processor, systems, data fields)

Maintain a register for Article 10 processing that includes:

• Your role (controller vs processor) by processing activity
• Data elements (conviction data, alleged offences, charges, sanctions, related security measures)
• Systems of record and downstream recipients
• Third parties involved and transfer points

This is a fast win because it becomes the index for all other evidence you need to keep.

Step 3: Confirm the “permission path” for each use case

For each processing use case, document one of the following outcomes:

• Official authority control (rare for most private-sector firms), or
• Authorized by EU/Member State law with safeguards, or
• Not authorized → redesign to avoid processing

Keep this as a written decision record tied to the use case and system. Article 10 is explicit that authorization must come from Union or Member State law, not internal policy preference. ¹

Step 4: Define “appropriate safeguards” as concrete controls

“Appropriate safeguards” must be specific enough that an auditor can test them. A practical minimum control set:

• Access control: restrict to trained, need-to-know roles; use privileged access where feasible; log access.
• Data minimization: collect only what the authorized use case requires; avoid free-text fields; redact where possible.
• Purpose limitation: block reuse for unrelated decisions (for example, using old offence notes for marketing risk scoring).
• Retention and deletion: define a retention rule per use case; implement deletion workflows and legal hold exceptions.
• Disclosure controls: restrict sharing internally; control onward transfer to third parties; require documented instructions and secure transmission.
• Auditability: maintain case IDs, access logs, and export logs so you can reconstruct who saw what and why.

Tie safeguards to each system that can hold the data, not only to the “primary” platform.

Step 5: Put the workflow into an operating procedure with named owners

Create a short SOP that answers:

• Who approves a new Article 10 use case (DPO/Privacy Counsel/Compliance)?
• What triggers re-review (new country rollout, new third party, new data field, new integration)?
• What to do when criminal offence data arrives unexpectedly (quarantine, redact, delete, or route to authorized channel)
• How to handle data subject requests involving offence data (route to privacy team, verify identity, apply restrictions)

This is where many programs fail: policy exists, but operators in HR, Support, and Trust & Safety keep handling the data ad hoc.

Step 6: Build third-party due diligence and contracting checkpoints

Where a third party processes this data:

• Confirm their role (processor/sub-processor) and your controller instructions.
• Verify they can enforce access restrictions and retention deletion on request.
• Contractually restrict “secondary use” and onward disclosures.
• Ensure you can obtain audit artifacts (logs, deletion confirmations, incident notifications).

If you use Daydream to manage third-party risk, map this as a requirement-specific due diligence module so screenings, case tools, and BPO support providers cannot be onboarded without an Article 10 decision record and safeguard evidence.

Step 7: Evidence operation on a recurring cadence

Pick a cadence that matches your risk profile and volume, then collect:

• A sample of access logs for the roles allowed
• A sample of closed cases showing minimization/redaction
• Proof of deletion execution for items past retention
• Exceptions and remediation tickets

Regulators and enterprise customers test what happened in systems, not what the SOP claims.

Required evidence and artifacts to retain

Keep an “Article 10 evidence packet” per use case/system:

• Role-and-scope register entry (systems, fields, owners, third parties)
• Legal authorization decision record (official authority control or cited Member State/EU legal authorization, plus how safeguards are met) ¹
• Safeguards mapping: control → system implementation (RBAC, logs, retention config, DLP/redaction)
• SOP and training attestations for teams that handle the data
• Third-party due diligence file: security/privacy reviews, processing instructions, sub-processor list (if applicable)
• Operational evidence: access logs, deletion logs, exception register, incident records (if any)

Common exam/audit questions and hangups

• “Show me where criminal offence data exists in your environment, including unstructured locations.”
• “What is the EU/Member State law authorizing this specific processing, and what safeguards does your implementation provide?” ¹
• “Who can access the data? Prove it with role definitions and logs.”
• “Do you maintain a broad register of convictions across individuals? If yes, explain official authority control.” ¹
• “Which third parties receive this data and how do you control onward processing?”

Frequent implementation mistakes (and how to avoid them)

1. Treating Article 6 lawful basis as sufficient. Fix: require an Article 10 gate in intake that asks for official authority control or specific legal authorization. ¹
2. Letting offence data live in free-text notes. Fix: remove fields, add redaction prompts, deploy keyword-based quarantines for inbound attachments where feasible.
3. Building a “comprehensive register” accidentally. Fix: prohibit cross-case aggregation unless official authority control is confirmed; keep case files isolated with strict retention and access. ¹
4. Third parties process it “because they always do.” Fix: put explicit processing instructions and evidence requirements into onboarding; block go-live without them.
5. No operating evidence. Fix: schedule periodic evidence pulls (access, deletion, exceptions) and store them with the decision record.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this page, so you should not assume a safe harbor. Treat Article 10 as high scrutiny in due diligence because it touches sensitive, high-impact decisions (employment, access to services, allegations of wrongdoing). The risk is not only regulatory; it is also reputational and litigation exposure if offence data is mishandled or reused beyond the authorized purpose. ¹

A practical 30/60/90-day execution plan

First 30 days (stabilize and stop surprises)

• Add the Article 10 gate to privacy/DPIA intake and third-party onboarding.
• Run a discovery sprint with HR, Security, Trust & Safety, Support to map where offence data appears.
• Freeze new collections in unstructured systems until a decision record exists.

By 60 days (controls and contracts in place)

• Stand up the role-and-scope register for all identified use cases/systems.
• Publish the SOP with named owners and exception handling.
• Update third-party contracts/instructions for in-scope providers; collect minimum safeguard evidence.

By 90 days (evidence-ready operations)

• Implement system-level controls: RBAC, logging, retention/deletion configuration, redaction where feasible.
• Establish an evidence cadence and store packets by use case.
• Run a tabletop audit: pick one use case and produce the full Article 10 evidence packet end-to-end.

Daydream fit: use it to enforce the intake gate, maintain the role-and-scope register, attach decision records and evidence artifacts, and track third-party exceptions to closure.

Frequently Asked Questions

Does Article 10 mean we can never process criminal conviction data as a private company?

No. Article 10 allows processing when it is authorized by Union or Member State law with appropriate safeguards, or under official authority control. Your job is to document which path applies for each use case. ¹

Is “alleged offence” data covered, or only confirmed convictions?

Article 10 explicitly covers “criminal convictions and offences” and related security measures. If you store allegations or investigation outcomes that relate to offences, treat it as in scope and apply the gate and safeguards. ¹

What counts as a “comprehensive register” of criminal convictions?

Article 10 does not define it in the provided text, so treat it as a risk signal: a broad, reusable repository across individuals that supports searching/aggregation looks like a register. If your workflow trends that way, stop and assess official authority control. ¹

Can our background check provider store conviction results and share them with us?

Potentially, but only if the overall processing is authorized as required by Article 10 and safeguards are in place end-to-end. Contract for strict processing instructions, access controls, retention limits, and auditable deletion support. ¹

Do we need a separate policy just for Article 10?

You need an operating procedure and controls that are testable. A standalone policy can help, but auditors will focus on the decision record (authorization path) and operating evidence (access, retention, disclosures). ¹

What should we do if a customer support agent receives a document containing offence data?

Treat it as an exception event: quarantine the record, restrict access, and route to the approved workflow (or delete/redact if not authorized). Document the exception and the remediation so you can show control operation. ¹

Footnotes

1. Regulation (EU) 2016/679, Article 10

2. Regulation (EU) 2016/679