GDPR Art.10 & Art.11: Criminal Convictions Data and Processing Without Identification (2026)

Post #441 in the sota.io EU Cyber Compliance Series

Art.10 and Art.11 are among GDPR's most practically misunderstood provisions. Art.10 imposes strict-access rules on criminal conviction data that parallel — but differ from — the Art.9 special category regime. Art.11 is the counterpart that limits controllers' obligations when identification is genuinely impossible: a controller who cannot identify the data subject has no duty to acquire identifying information just to enable rights requests.

This guide is part of the GDPR Chapter I series: Art.1-4 Scope → Art.5 Principles → Art.6 Lawful Bases → Art.7 Consent Conditions → Art.9 Special Categories → Art.10 & Art.11 (this guide).

Part 1: Art.10 — Criminal Convictions and Offences

The Scope of Art.10

Art.10 covers processing of personal data relating to:

1. Criminal convictions — a court judgment finding a person guilty of a criminal offence
2. Offences — data relating to alleged criminal acts, even without conviction (charges, investigations, suspicions)
3. Related security measures — probation orders, parole conditions, electronic monitoring

The Article reads: "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."

The Two-Door Rule

Unlike Art.9 (which provides ten exceptions), Art.10 has exactly two pathways:

There is no Art.10 equivalent of Art.9(2)(a) explicit consent. A data subject cannot consent their way around Art.10. If you are not acting under official authority and no specific national or Union law authorises your processing, Art.10 prohibits it regardless of consent.

What Art.10 Does NOT Cover

Art.10 does not apply to:

• Fully anonymised data — aggregated crime statistics in a public report
• Information about your own offences shared voluntarily — but collection and storage of that disclosure may still engage Art.10
• Civil matters — debt defaults, county court judgments in the UK, breach of contract — these are not criminal conviction data
• Disciplinary decisions — internal HR sanctions, professional body sanctions (unless they parallel criminal conviction proceedings)

Recital 19 clarifies that Art.10 "should relate only to activities that are criminal in nature, under the applicable legal system." Administrative sanctions without criminal character do not automatically fall within Art.10, though Recital 50 notes that further processing of criminal conviction data must have a legal basis under Art.10.

Why No Legitimate Interests Pathway?

Unlike Art.9(2)(g) (public interest) and other special category exceptions, Art.10 has no self-executing exceptions and no proportionality balancing. The legislative history indicates the EU legislator deliberately closed the legitimate-interests door. Recital 50 says further processing is only compatible with Art.6(1) if authorised by Art.10 — meaning you cannot run a legitimate interests assessment (LIA) and argue your interest in processing conviction data outweighs the data subject's interests.

This was confirmed in enforcement practice: in 2022, the French CNIL fined a company for processing job applicants' conviction data without legal basis — the company had argued general Art.6(1)(f) legitimate interests sufficed. The CNIL held Art.10 requires specific legal authorisation that Art.6(1)(f) cannot provide.

Member State Law Implementations

UK Post-Brexit Note: The UK GDPR Art.10 mirrors EU GDPR Art.10 but operates alongside the Rehabilitation of Offenders Act 1974. A conviction is "spent" after a specified period — and once spent, the individual can legally deny it exists in most employment contexts. Asking about spent convictions (except for ROA-exempt roles) is both an Art.10 violation and an ROA violation.

Developer Scenarios

Background Check APIs (Checkr, Sterling, TrustID)

B2B SaaS that integrates background check providers sits directly in Art.10 territory. The background check provider processes conviction data as a processor under your instruction (Art.28 DPA required). Your organisation, as controller, must have an Art.10 basis:

class BackgroundCheckController:
    PERMITTED_BASES = {
        "employment_regulated_sector": {
            "description": "Regulated sector role (financial services, healthcare, childcare)",
            "legal_basis": "Art.10 + Member State employment law",
            "examples": ["FCA-regulated roles (UK)", "BaFin-regulated roles (DE)"]
        },
        "official_authority": {
            "description": "Processing by or under control of official authority",
            "legal_basis": "Art.10 direct",
            "examples": ["Police vetting", "Court administration", "Prosecution service"]
        },
        "national_law_specific": {
            "description": "Specific national law provision",
            "legal_basis": "Art.10 + named statute",
            "examples": ["§24 BDSG (DE)", "Art.8(IV) Loi 78-17 (FR)", "s.55 DPA 2018 (IE)"]
        }
    }
    
    def validate_basis(self, role_type: str, member_state: str) -> dict:
        """Returns permitted basis or raises ComplianceError."""
        if role_type not in self.PERMITTED_BASES:
            raise ComplianceError(
                f"No Art.10 basis found for role_type='{role_type}' "
                f"in {member_state}. Processing prohibited."
            )
        return self.PERMITTED_BASES[role_type]
    
    def log_processing(self, subject_id: str, basis: str, purpose: str, 
                       member_state: str, legal_reference: str) -> None:
        """Art.30 RoPA entry for Art.10 processing."""
        self.ropa.log({
            "article": "Art.10 GDPR",
            "subject_id_hash": hash(subject_id),
            "basis": basis,
            "purpose": purpose,
            "member_state": member_state,
            "legal_reference": legal_reference,
            "timestamp": datetime.utcnow().isoformat(),
        })

Insurance and Financial Services

Insurance underwriters may process conviction data for risk assessment in most EU member states under sector-specific laws. The 6th Anti-Money Laundering Directive (6AMLD) and national AML laws often permit processing conviction data for KYC/AML purposes. This is Art.10 processing under Union law (6AMLD) or Member State law.

AML_PERMITTED_PROCESSING = {
    "6AMLD": {
        "permitted": ["conviction data for AML screening", "PEP status + criminal association"],
        "legal_ref": "Directive (EU) 2018/1673 (6AMLD)",
        "safeguards": ["Proportionality test", "Purpose limitation to AML", "Retention limits"]
    },
    "CRR_EU": {
        "permitted": ["Fit and proper assessments for key function holders"],
        "legal_ref": "Regulation (EU) 575/2013 + EBA Guidelines EBA/GL/2021/06",
        "safeguards": ["Role-necessity test", "DPO consultation advised"]
    }
}

SaaS Platforms — User-Generated Content

A SaaS platform that allows users to post content may receive posts that reference criminal convictions — e.g., a legal tech forum where users discuss their own past convictions. Receiving and storing this data may constitute processing of Art.10 data:

• Passive receipt of user disclosure: If users voluntarily post their own conviction data in a public forum, the platform processes it. No Member State law authorises this generally.
• Moderation decisions: Flagging or moderating posts about convictions is still processing.
• Recommended approach: Treat user-disclosed conviction data as Art.10 data. Minimise what you retain. Do not cross-reference or index it. Configure your search to exclude conviction references from searchable content if possible.

Domain Registrars and Hosting Providers

ICANN policies and national cybercrime laws sometimes require hosting providers and registrars to process data about illegal activity (including criminal offences) for abuse management. The legal basis is Union or Member State law (e.g., the NIS2 Directive Art.20-23 incident reporting, national cybercrime statutes). This is a narrow, specific pathway — it does not authorise general conviction data processing.

Art.10 Compliance Checklist

• Identify all data fields that constitute criminal conviction or offence data in your schema
• Map the specific Art.10 basis (official authority OR named Union/Member State law) for each processing activity
• Confirm Art.6 basis is consistent with Art.10 authorisation (no standalone Art.6(1)(f) for Art.10 data)
• Update RoPA (Art.30) to record Art.10 category and specific legal reference
• Ensure Art.28 DPA with background check providers covers Art.10 data explicitly
• Verify retention limits match the authorising law's requirements
• For employment background checks: confirm role falls within national law exemption
• For UK processing: confirm Rehabilitation of Offenders Act 1974 treatment of spent convictions

Part 2: Art.11 — Processing Not Requiring Identification

The Principle

Art.11 addresses a practical reality of modern data processing: controllers often hold data in a form where they cannot identify the individual behind it — anonymised logs, aggregated analytics, hashed pseudonyms — and they should not be required to build identification infrastructure solely to satisfy GDPR rights requests.

Art.11 has two provisions:

Art.11(1): If the purposes of processing do not require identification of a data subject, and the controller cannot or does not need to identify the data subject, the controller "shall not be obliged to maintain, acquire or process additional information in order to identify the data subject for the sole purpose of complying with this Regulation."

Art.11(2): Where Art.11(1) applies and the controller can demonstrate inability to identify the data subject, the data subject rights under Art.15-20 shall not apply — except where the data subject provides additional information enabling identification, in which case the rights revive.

What Art.11 Is NOT

Art.11 is not a GDPR opt-out. It does not mean:

• Processing outside GDPR scope (fully anonymised data is outside GDPR entirely — Art.11 applies to pseudonymised/identifiably-hard-to-link data that is still personal data)
• Permission to refuse all rights requests — only rights that genuinely cannot be fulfilled without identification
• Permission to avoid Art.5, Art.6, Art.13/14, or Art.32 obligations — these apply regardless

EDPB Opinion 5/2019 clarifies that Art.11 has a narrow scope: it applies where the controller "cannot by any reasonable means identify the data subject." The standard is proportionality — a controller must use reasonable technical and organisational measures, not exhaustive investigative efforts.

The Anonymisation vs Pseudonymisation vs Art.11 Spectrum

Understanding where your data sits on this spectrum determines your obligations:

Recital 26 is critical: "The principles of data protection should therefore not apply to anonymous information, namely information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable." But it also says controllers must take into account "all the means reasonably likely to be used" to identify the person — including external datasets, linkage attacks, and inference.

The Re-identification Risk Test

Whether data is truly Art.11-eligible depends on re-identification risk. The WP29 Opinion 05/2014 on Anonymisation Techniques identifies three key re-identification risks:

1. Singling out: Can you isolate an individual in a dataset based on their attributes?
2. Linkability: Can you link two records about the same person in the same or different datasets?
3. Inference: Can you deduce a value about a person based on other attributes?

class AnonymizationRiskChecker:
    """
    Assesses re-identification risk for GDPR Art.11 / Recital 26 compliance.
    Returns risk level: LOW (Art.11 potentially applicable) / MEDIUM / HIGH.
    """
    
    HIGH_RISK_SIGNALS = [
        "direct_identifiers_present",      # name, email, national_id
        "combination_unique_in_population", # ZIP + DOB + gender uniquely identifies 87% US population (Sweeney 2000)
        "external_dataset_linkage_possible",# public records, LinkedIn, social media
        "ip_address_not_hashed",            # IP = personal data (CJEU C-582/14 Breyer)
        "device_fingerprint_stored",        # canvas fingerprint, browser fingerprint
        "location_granularity_high",        # GPS coordinates ≤100m radius
    ]
    
    MEDIUM_RISK_SIGNALS = [
        "ip_hashed_key_retained",           # SHA-256(IP) but key still exists
        "user_agent_stored",                # can narrow to small population
        "session_id_long_lived",            # persistent session IDs linkable over time
        "rare_attribute_combination",       # very specific job title + company + city
    ]
    
    LOW_RISK_SIGNALS = [
        "ip_hashed_key_destroyed",          # no means of reversal
        "only_aggregate_counts",            # k>=5 group minimum
        "differential_privacy_applied",     # epsilon ≤ 1.0
        "generalised_attributes",           # age_group not age, region not city
    ]
    
    def assess(self, data_schema: dict) -> dict:
        present_high = [s for s in self.HIGH_RISK_SIGNALS if data_schema.get(s)]
        present_medium = [s for s in self.MEDIUM_RISK_SIGNALS if data_schema.get(s)]
        present_low = [s for s in self.LOW_RISK_SIGNALS if data_schema.get(s)]
        
        if present_high:
            risk = "HIGH"
            recommendation = "Full GDPR applies. Art.11 NOT applicable. Implement full rights infrastructure."
        elif present_medium and not present_low:
            risk = "MEDIUM"
            recommendation = "Pseudonymised but re-identification possible. Art.11 marginal. Assess key retention."
        elif present_low and not present_high:
            risk = "LOW"
            recommendation = "Art.11 potentially applicable. Document risk assessment. Retain for rights requests."
        else:
            risk = "MEDIUM"
            recommendation = "Mixed signals. Conduct full anonymisation assessment per WP29 05/2014."
        
        return {
            "risk_level": risk,
            "high_risk_factors": present_high,
            "medium_risk_factors": present_medium,
            "low_risk_factors": present_low,
            "recommendation": recommendation,
            "art11_applicable": risk == "LOW",
            "assessment_standard": "WP29 Opinion 05/2014 + EDPB Opinion 5/2019"
        }

Developer Scenarios

Analytics with Hashed IPs

A SaaS platform logs page views with SHA-256(user_ip + daily_salt). The daily salt is rotated and not retained after rotation. Is Art.11 applicable?

• If the salt is permanently deleted: Yes, re-identification is infeasible. Art.11(1) applies — no obligation to maintain additional info. Art.15-20 rights cannot be fulfilled and are suspended under Art.11(2).
• If the salt is retained (even temporarily): No. SHA-256 is reversible with the salt. Full GDPR applies. You have pseudonymised data, not Art.11-eligible data.

Practical recommendation: Build an explicit salt rotation and deletion audit trail. Without provable deletion of the salt, you cannot claim Art.11 status.

Server Access Logs

Apache/nginx access logs typically include:

• Client IP address — personal data (CJEU C-582/14 Breyer)
• Timestamp
• Request path
• User agent string

Raw logs are NOT Art.11 eligible (IP is directly present). Options:

# Non-compliant: raw IP stored
log_entry = {"ip": "192.168.1.100", "path": "/dashboard", "ts": "2026-04-18T16:00:00Z"}

# Compliant option 1: Anonymise at collection (Art.11 potentially applicable)
import hashlib, secrets
SALT = secrets.token_bytes(32)  # Generate fresh, store securely, then DELETE after retention period
log_entry = {
    "ip_hash": hashlib.sha256(b"192.168.1.100" + SALT).hexdigest()[:16],  # truncated
    "path": "/dashboard",
    "ts": "2026-04-18T16:00Z"  # hour-granularity reduces precision
}

# Compliant option 2: Mask the last octet (IPv4) — reduces but doesn't eliminate re-id risk
# 192.168.1.100 → 192.168.1.0 (still personal data per DPA guidance but lower risk)

Rights Requests Against Art.11 Data

When a data subject submits a Subject Access Request (SAR) under Art.15, and you hold only Art.11-eligible data (no means to identify them), Art.11(2) says the rights don't apply. However:

1. You must still respond to the SAR — you cannot simply ignore it.
2. Your response should explain: "We are unable to identify you in our records based on the information provided. Under GDPR Art.11(2), if you can provide additional information that would enable us to identify your data, we can then fulfil your request."
3. If the individual provides additional information (e.g., their full name + email + account ID), you must attempt to locate and fulfil their request.
4. You cannot refuse to help if the data subject's provided information genuinely enables identification.

class SARHandler:
    def handle_request(self, sar: SubjectAccessRequest, db: DataStore) -> SARResponse:
        # Attempt identification
        candidate_records = db.find_by_provided_info(
            name=sar.name,
            email=sar.email,
            account_id=sar.account_id
        )
        
        if not candidate_records and self.is_art11_processing(db):
            return SARResponse(
                status="CANNOT_IDENTIFY",
                message=(
                    "We were unable to locate your personal data based on the information provided. "
                    "Our data processing uses anonymisation techniques that prevent us from identifying "
                    "you in our records. Per GDPR Art.11(2), if you can provide additional information "
                    "that enables your identification, please resubmit your request with that information."
                ),
                art11_invoked=True,
                legal_basis="GDPR Art.11(2)"
            )
        
        # If identified: full Art.15-20 obligations apply
        return self.fulfil_sar(candidate_records, sar)

Art.10 vs Art.11: The Intersection

There is one intersection worth noting: conviction data in anonymised or Art.11 datasets. If you hold statistics about crime rates (fully anonymised) or anonymised research data on recidivism, this may not be Art.10 data at all — because it is not personal data. But if your "anonymised" dataset is vulnerable to singling out or linkage attacks that could reveal an individual's convictions, you may have both an Art.10 problem (the data was never truly Art.10-exempt personal data) and a re-anonymisation risk.

Connecting Art.10 and Art.11 to Your RoPA

Your Record of Processing Activities (Art.30 RoPA) should capture:

For Art.10 processing:

• Category: "Criminal conviction/offence data (Art.10 GDPR)"
• Legal basis: Art.10 + specific Union/Member State law reference
• Safeguards: as required by the authorising law
• Retention: as per authorising law

For Art.11 processing:

• Note: "Data held in non-identifiable form under Art.11(1). Re-identification infeasible as of [assessment date]."
• Risk assessment reference: WP29 05/2014 anonymisation assessment
• Note: "Data subject rights under Art.15-20 suspended per Art.11(2) absent subject-provided identification"

Key Takeaways for Developers

Art.10:

1. Criminal conviction data requires Art.10 basis — official authority OR specific national/Union law. No exceptions via consent or LIA.
2. Background check integrations need explicit Art.10 basis mapped to your jurisdiction and sector.
3. User-generated content disclosing conviction data is still Art.10 processing — minimise and do not index.
4. UK: Rehabilitation of Offenders Act 1974 adds a second compliance layer for spent convictions.

Art.11:

1. Full anonymisation (Recital 26) puts data outside GDPR entirely. Art.11 applies to a narrower zone: pseudonymised data where re-identification is genuinely infeasible.
2. The key question is whether you retained the means to reverse the pseudonymisation. If yes: full GDPR, not Art.11.
3. When Art.11 applies, you must still respond to rights requests — you explain inability to identify and invite the subject to provide identification.
4. Run a formal anonymisation assessment (WP29 05/2014) before relying on Art.11. Document it.

See Also

• GDPR Art.9: Special Categories — The parallel Article for sensitive data categories
• GDPR Art.5: Six Principles — Storage limitation principle relevant to Art.11 data
• GDPR Art.30: Records of Processing Activities — How to document Art.10 and Art.11 processing in your RoPA
• GDPR Art.35: DPIA — When Art.10 processing triggers mandatory DPIA
• GDPR Art.83: Administrative Fines — Enforcement consequences for Art.10 violations