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

To meet the article 10: processing of personal data relating to criminal convictions and offences requirement, you must only process criminal-offence data under the control of an official authority or where EU or Member State law explicitly authorizes it with appropriate safeguards, and you cannot keep a comprehensive criminal convictions register unless you are under official authority. (Regulation (EU) 2016/679, Article 10)

Key takeaways:

• Treat criminal convictions/offences data as a restricted data class with a legal “permissioning” gate before collection or use. (Regulation (EU) 2016/679, Article 10)
• If you cannot point to the specific Union/Member State law authorizing your processing and the safeguards you apply, stop or redesign the processing. (Regulation (EU) 2016/679, Article 10)
• “Comprehensive registers” of convictions are generally out of scope for private entities; avoid building them through aggregation. (Regulation (EU) 2016/679, Article 10)

Article 10 is one of the fastest ways to fail a GDPR review because it is less about generic privacy hygiene and more about a hard legal constraint: criminal convictions and offences data (and related security measures) is only lawful to process in narrow conditions. The operational problem is predictable. Business teams want background checks, fraud prevention signals, trust-and-safety triage, or screening workflows. Data can enter through third parties (screening providers), user-submitted information, customer HR files, case management notes, or support tickets. Without a strict intake gate, the organization can drift into processing that has no valid authorization path under Article 10.

For a CCO or GRC lead, the goal is speed and defensibility. You need a clear role-and-scope decision, a documented legal basis path, and controls that prevent accidental creation of a “comprehensive register” through aggregation across systems. You also need evidence that the controls operate: approvals, data maps, system configurations, and vendor/third-party contract terms where applicable.

This page gives requirement-level implementation guidance you can hand to privacy ops, product, HR, security, and procurement to operationalize Article 10 quickly. (Regulation (EU) 2016/679, Article 10)

Requirement in plain English (what Article 10 demands)

Article 10 restricts processing of personal data about criminal convictions and offences (and related security measures) to two situations:

1. processing occurs under the control of official authority, or
2. processing is authorized by Union or Member State law that also provides appropriate safeguards for data subject rights and freedoms. (Regulation (EU) 2016/679, Article 10)

It also adds a specific prohibition: any comprehensive register of criminal convictions may be kept only under the control of official authority. (Regulation (EU) 2016/679, Article 10)

Practical interpretation for operators

• You cannot treat “legitimate interest” as a universal permission slip for criminal-offence data. Article 10 adds a separate authorization constraint even where you have an Article 6 basis. (Regulation (EU) 2016/679, Article 10)
• You must be able to answer: “What law authorizes this processing, and what safeguards does that law require or imply?” If you cannot, the processing is not defensible under Article 10. (Regulation (EU) 2016/679, Article 10)
• “Comprehensive register” risk is often accidental: teams centralize case notes, flags, and screening results into an internal database. Over time, that becomes a de facto convictions register.

Regulatory text

Excerpt (verbatim): “Processing of personal data relating to criminal convictions and offences or related security measures based on Article 6(1) shall be carried out only under the control of official authority or when the processing is authorised by Union or Member State law providing for appropriate safeguards for the rights and freedoms of data subjects. Any comprehensive register of criminal convictions shall be kept only under the control of official authority.” (Regulation (EU) 2016/679, Article 10)

What the operator must do from this text

Use the excerpt as a control gate with two required outcomes:

1. Permissioning decision (pre-processing): confirm your processing is either under official authority control or is explicitly authorized by applicable law, and record which condition you rely on. (Regulation (EU) 2016/679, Article 10)

2. Register-avoidance design: prevent building or maintaining a comprehensive convictions register unless you are under official authority control. This typically means limiting aggregation, limiting fields, and limiting access and retention in any system that could become a “register.” (Regulation (EU) 2016/679, Article 10)

Who it applies to (entity + operational context)

Entities

• Controllers deciding to collect or use criminal-offence data for hiring, fraud, safety, or compliance workflows. (Regulation (EU) 2016/679)
• Processors that handle such data on behalf of controllers (for example, screening providers, case management platforms, HR SaaS, trust-and-safety outsourcers). Even if you are “just a processor,” you need to ensure instructions are lawful and implement appropriate controls. (Regulation (EU) 2016/679)

Operational contexts where Article 10 shows up

• Employment screening and background checks (HR, contingent workforce, third-party staffing).
• Fraud/AML-like screening or adverse media workflows when they capture offence allegations or outcomes.
• Trust & Safety / platform moderation where reports include allegations of criminal conduct.
• Physical security and incident management systems where reports reference offences.
• Customer due diligence in regulated industries if conviction data is collected.

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

Step 1: Build an Article 10 scope inventory

Create a register that answers, for each processing activity:

• controller/processor role
• data sources (user, employee, third party, public record)
• systems of record and downstream recipients
• whether data includes convictions/offences or “related security measures”
• retention and access model
  This aligns with the practical need to avoid scope ambiguity and anchor control design. (Regulation (EU) 2016/679)

Output: Article 10 role-and-scope register (living document).

Step 2: Install a “legal authorization” gate before collection

For each in-scope activity, require a documented decision that states:

• the Article 6 basis used for the processing activity, and
• the Union/Member State law that authorizes the Article 10 processing, plus
• the safeguards you apply to protect rights and freedoms. (Regulation (EU) 2016/679, Article 10)

If you cannot identify the authorizing law, treat the processing as blocked pending redesign or legal review. This is the fastest way to prevent drift.

Operational pattern: add a mandatory checkpoint in intake workflows (privacy review, security review, HR process change, third-party onboarding).

Step 3: Design controls to avoid a “comprehensive register”

Treat “register risk” as an architecture problem:

• Minimize fields: store only what is necessary for the decision you must make.
• Split storage: keep conviction/offence data out of general CRM/support tooling where it spreads.
• Access restrictions: narrow access to named functions (HR ops, compliance, legal) with role-based access.
• Retention limits: define event-based deletion (for example, after hiring decision finalization) unless the authorizing law requires longer retention. (Regulation (EU) 2016/679, Article 10)

Practical test: if you can run a single query and list many individuals with conviction entries across time, your design is trending toward a register.

Step 4: Control third parties that introduce criminal-offence data

If a third party provides screening or case services:

• contractually define whether they are a controller, processor, or separate controller for parts of the workflow
• require documented processing instructions and data handling restrictions
• ensure data transfers to your systems are limited to the minimum necessary outputs
  Your procurement workflow should flag “criminal-offence data involved” as a special intake category.

Step 5: Operationalize an SOP with owners, triggers, and approvals

Write a requirement-specific operating procedure that includes:

• owners: Privacy/Legal decision owner; system owner; HR or Trust & Safety owner
• triggers: new background check provider; new hiring region; new case tool; new fraud ruleset; product feature collecting reports
• approvals: documented sign-off for the authorization path and safeguards
  This converts Article 10 from policy text into repeatable execution. (Regulation (EU) 2016/679, Article 10)

Step 6: Evidence cadence and exception handling

Define how you will:

• review the scope register (on change triggers)
• sample access logs or permission groups for systems containing Article 10 data
• track and remediate exceptions (unauthorized intake, misrouted tickets, over-retention)
  Retain an “evidence packet” each cycle with decision records and control outputs. (Regulation (EU) 2016/679)

Required evidence and artifacts to retain

Keep artifacts that prove both legality and operational control:

1. Article 10 role-and-scope register (activities, systems, owners).
2. Authorization decision records tying each activity to the relevant Union/Member State law and documented safeguards. (Regulation (EU) 2016/679, Article 10)
3. Data flow map for in-scope systems (source → processing → sharing → retention).
4. SOP / runbook with triggers, approvals, and exception handling.
5. Access control evidence (role definitions, access reviews, screenshots/exports of permission groups).
6. Retention configuration evidence (system settings, deletion jobs, retention schedules).
7. Third-party documentation (data processing terms, instructions, subprocessor lists where relevant, intake risk review).

If you use Daydream to manage compliance operations, store these artifacts as a requirement-aligned evidence packet so audits do not become a scavenger hunt.

Common exam/audit questions and hangups

Expect reviewers to probe these areas:

• “Show me where criminal convictions/offences data exists.” If your data map is incomplete, they will assume broader spread.
• “What law authorizes your processing under Article 10?” This is the critical hangup. Your answer must be specific to the jurisdictions in scope. (Regulation (EU) 2016/679, Article 10)
• “How do you prevent creating a comprehensive register?” They will look at aggregation, access breadth, and retention. (Regulation (EU) 2016/679, Article 10)
• “Which third parties touch this data, and under what role?” अस्प role confusion (controller vs processor) creates immediate follow-ups. (Regulation (EU) 2016/679)

Frequent implementation mistakes (and how to avoid them)

1. Mistake: treating Article 10 as “special category data” handling only.
   Fix: implement the legal authorization gate; security controls alone do not satisfy the “authorized by law” condition. (Regulation (EU) 2016/679, Article 10)

2. Mistake: storing raw background check results in HRIS/ATS indefinitely.
   Fix: store a minimal decision outcome where possible, restrict access, and enforce retention aligned to the authorization basis and necessity. (Regulation (EU) 2016/679, Article 10)

3. Mistake: allowing support tickets and free-text notes to become a shadow convictions database.
   Fix: add ticket classification, redaction guidance, and restricted fields for sensitive allegations; route to a controlled case system.

4. Mistake: unclear third-party role definitions.
   Fix: document controller/processor determinations per workflow and ensure contracts and actual data flows match.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement page, so this section is omitted by design.

Operationally, the risk is binary: if you cannot show you meet one of Article 10’s conditions, the processing itself is on shaky ground. That creates downstream exposure in HR, trust and safety, fraud ops, and third-party screening programs. (Regulation (EU) 2016/679, Article 10)

Practical 30/60/90-day execution plan

No fixed-duration implementation timeline is stated in the provided sources, so treat this as a staged plan you can compress or extend based on scope.

First 30 days (triage + stop the bleed)

• Identify all processing activities that may involve convictions/offences data (HR, Trust & Safety, Security, Fraud).
• Stand up the Article 10 role-and-scope register and name owners for each system.
• Implement an interim intake rule: no new collection or new third-party onboarding involving conviction data without privacy/legal approval tied to Article 10.

Days 31–60 (controls + documentation)

• Build and publish the Article 10 SOP (triggers, approval workflow, exception handling).
• Update access controls for in-scope systems; restrict free-text where possible.
• Define retention rules and implement deletion or archival controls in the highest-risk systems.

Days 61–90 (prove operation + vendor hardening)

• Run an access review for in-scope systems and retain evidence.
• Complete third-party reviews and contract updates for any provider touching conviction/offence data.
• Produce the first “evidence packet” bundle: scope register, decision records, access review output, and retention settings exports.

Frequently Asked Questions

Does Article 10 ban background checks?

Article 10 does not create a blanket ban, but it restricts processing to cases under official authority control or where Union/Member State law authorizes it with safeguards. You need a documented authorization path before you run or store background check results. (Regulation (EU) 2016/679, Article 10)

Can we rely on consent to process criminal convictions data?

Article 10’s text focuses on processing under official authority control or authorized by law with safeguards. If your approach depends on consent, validate with counsel whether applicable Member State law authorizes the processing and what safeguards apply, then document that basis. (Regulation (EU) 2016/679, Article 10)

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

The GDPR text does not define a technical threshold in the provided excerpt, so treat “comprehensive register” risk as any system intentionally designed, or effectively used, to compile conviction histories broadly across individuals. Avoid aggregation, limit fields, and keep retention tight. (Regulation (EU) 2016/679, Article 10)

We receive user reports alleging criminal conduct. Is that in scope?

If the report contains personal data relating to criminal offences or related security measures, treat it as in scope for Article 10 controls. Route it into a controlled case workflow, restrict access, and document your authorization basis where applicable. (Regulation (EU) 2016/679, Article 10)

What should a processor do if the controller instructs them to store conviction data without clear authorization?

Escalate and require written instructions that document the controller’s authorization basis and safeguards, then limit processing to what is necessary to perform the service. Keep your own role-and-scope and evidence trail to show you assessed the instruction. (Regulation (EU) 2016/679, Article 10)

How do we operationalize this across many systems without slowing the business?

Make Article 10 a routing and gating problem: tag the data class at intake, require a short approval record that cites the authorizing law and safeguards, and enforce system-level controls (access, retention, field restrictions). Use a tool like Daydream to keep the register, approvals, and evidence packets linked to the requirement so teams execute consistently.