Article 22: Automated individual decision-making, including profiling

Article 22 requires you to prevent people from being subject to decisions that are based solely on automated processing (including profiling) when those decisions have legal effects or similarly significant effects, unless a valid exception applies. Operationally, you need an inventory of in-scope decisions, a gating review to confirm whether a decision is “solely automated,” and a tested path for human intervention where required. (Regulation (EU) 2016/679, Article 22)

Key takeaways:

• Build and maintain a register of automated decisions and profiling that can significantly affect individuals.
• Put a “solely automated + significant effect” gate into product, risk, and change-management workflows before launch or model changes.
• Retain defensible evidence: decision logic, role/scope, approvals, exceptions, and ongoing monitoring outputs.

Article 22 is one of the fastest ways to get surprised in a privacy exam because teams often treat it like a “privacy notice” topic instead of an operational control topic. The work is not abstract. You must know which customer, employee, applicant, or user decisions are made without meaningful human involvement and whether the outcome meaningfully changes someone’s situation (for example, access, eligibility, pricing, or similar high-impact outcomes). If you cannot answer that quickly, you will struggle to prove compliance.

For most organizations, the practical challenge is scope: automated processing shows up in product rules engines, fraud tooling, identity verification, creditworthiness scoring, HR screening, support automation, and third-party decisioning APIs. Article 22 also intersects with third parties because a controller can be accountable even if the “automation” is provided by an external service integrated into your workflow.

This page is written for a Compliance Officer, CCO, or GRC lead who needs to implement Article 22 controls with clear owners, repeatable steps, and audit-ready artifacts, anchored to the core requirement text. (Regulation (EU) 2016/679, Article 22)

Regulatory text

GDPR Article 22(1) excerpt: “The data subject shall have the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly significantly affects him or her.” (Regulation (EU) 2016/679, Article 22)

What the operator must do with this text (practical reading):

1. Identify “decisions.” You need a concrete list of outcomes your organization determines about an individual (approve/deny, block/allow, set a rate, assign a risk tier, etc.).
2. Determine if the decision is “based solely on automated processing.” If the system decides and no human meaningfully reviews before the outcome is applied, treat it as in scope for Article 22 controls.
3. Determine if the decision produces legal effects or similarly significant effects. If it can materially change someone’s circumstances, rights, or access in a meaningful way, treat it as high-risk and subject to strict gating.
4. Implement a right “not to be subject.” In practice, this means you must design your process so that in-scope use cases are either avoided, brought under a valid exception with additional safeguards, or redesigned to include meaningful human involvement before the outcome is finalized. (Regulation (EU) 2016/679, Article 22)

Plain-English interpretation (requirement-level)

Article 22 is a hard stop on running high-impact decisions entirely by machine without a compliant path. Your obligation is not to prove your models are “good.” Your obligation is to prevent an individual from being subjected to an in-scope decision that is purely automated and significant in effect, unless you have a defensible basis and safeguards.

A practical way to translate the requirement for operators:

Question	If “Yes”	What you do next
Does this workflow produce a decision about an identifiable person?	Potential Article 22 scope	Add it to the Automated Decision Register and assign an owner
Is the outcome applied without meaningful human review?	“Solely automated” risk	Add a gate: redesign for human intervention or document an exception path
Can the outcome materially affect the person?	High compliance risk	Require Privacy + Legal + product approval, plus evidence capture

This is why a role-and-scope register matters: you cannot build the right controls until you know whether you are acting as controller or processor for the decision and which systems and third parties are involved. (Regulation (EU) 2016/679, Article 22)

Who it applies to (entity and operational context)

Entity scope

• Controllers that determine the purposes and means of automated processing used to make decisions about individuals.
• Processors that run automated decisioning on behalf of a controller still need operational clarity, because the controller will demand assistance, transparency, and contractual assurances during due diligence and audits. (Regulation (EU) 2016/679)

Operational contexts where Article 22 commonly appears

• Customer onboarding and eligibility decisions (approve/deny an account or service).
• Fraud, abuse, and trust & safety decisions (block access, suspend, restrict features).
• Pricing or offers decisions (dynamic pricing, individualized quotes) when tied to significant effect outcomes.
• Employment and HR decisions (screening, ranking, auto-rejection).
• Third-party decisioning embedded in your workflow (IDV, risk scoring, background screening) where your system treats the third party output as final without human review.

Your scoping rule of thumb: if a system’s output is treated as the final answer for an individual and the person feels the impact, treat it as an Article 22 candidate until proven otherwise. (Regulation (EU) 2016/679, Article 22)

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

1) Create an “Automated Decision & Profiling Register” (single source of truth)

Build a register that captures, per decision/workflow:

• Decision name and business owner
• Product/system(s) involved (rules engine, model, vendor API)
• Data categories used (inputs and derived attributes)
• Whether profiling is involved (segmentation/scoring used to decide)
• Whether the decision is solely automated (yes/no/unknown)
• Whether the effect is potentially legal/significant (yes/no/unknown)
• Controller/processor role determination for the activity (who determines purpose/means)
• Third parties involved and where their outputs are consumed
• Links to DPIA/assessment records, approvals, and monitoring outputs

Operational tip: start with a workshop across product, fraud, HR, and data science. Teams will surface “automatic” decisions you will not find in a data inventory.

This aligns to the control expectation to maintain a GDPR role-and-scope register for the requirement. (Regulation (EU) 2016/679, Article 22)

2) Add a launch/change gate for “solely automated + significant effect”

Add a required check in:

• product launch review,
• model deployment/change management,
• procurement intake for third-party decisioning tools,
• and workflow automation changes.

Gate questions (answered and saved):

1. Does this produce a decision about an individual?
2. Is the decision applied without meaningful human involvement?
3. Could it significantly affect the person?
4. If yes to 2 and 3, what is the design response: redesign to include meaningful human review, or document a valid exception path and safeguards?

You want a “no silent launches” control. Examiners will ask when this is triggered and who has authority to stop a release.

This aligns to defining a requirement-specific operating procedure with named owners, trigger events, and required approvals. (Regulation (EU) 2016/679, Article 22)

3) Define what “meaningful human involvement” means in your org (and enforce it)

Write a short internal standard that clarifies:

• A human must have authority to change the outcome, not just view it.
• The review must be more than rubber-stamping; document what is checked (key features, evidence, policy criteria).
• The review must happen before the decision is applied when the workflow is in scope.

Then implement it:

• Case management queues for flagged decisions
• Required reviewer training (what to look for, when to override)
• Quality checks (spot checks of reviewer actions)

4) Control third-party decisioning dependencies

Where a third party provides a score/recommendation:

• Document whether you treat the third party output as determinative.
• If yes, treat the workflow as solely automated unless your staff performs meaningful review.
• Update due diligence questions: ask the third party to describe decision logic at an appropriate level, test/monitoring outputs you can rely on, and how to support your obligations as controller or processor depending on your role. (Regulation (EU) 2016/679)

This is a place where Daydream fits naturally: you can standardize third-party intake, map which vendors power automated decisions, and collect evidence packets on a recurring cadence without chasing teams across tools.

5) Build the evidence packet and keep it current

For each in-scope decision, retain a living packet (see next section). Update it when:

• model/rules change,
• data inputs change,
• a new third party is added,
• or customer impact changes.

This aligns to retaining auditable evidence packets (decision record, control outputs, exceptions, and remediation) on a recurring cadence. (Regulation (EU) 2016/679, Article 22)

Required evidence and artifacts to retain

Maintain these artifacts in a GRC repository with clear ownership and version history:

Core artifacts

• Automated Decision & Profiling Register (current version + change log)
• Role determination notes (controller vs processor) for each decision context
• Documented “solely automated” assessment for each decision
• Documented “significant effect” assessment rationale

Operational controls evidence

• Operating procedure for Article 22 gate (owners, triggers, approvers)
• Product/change-management tickets showing the gate was completed
• Human review work instructions and training records
• Samples of case reviews showing overrides and rationale (where used)

Third-party artifacts

• List of third parties supporting each automated decision
• Due diligence responses and contract clauses relevant to supporting your processing role (as applicable)
• Records of integration changes that could shift a workflow into “solely automated”

Monitoring and exceptions

• Exception register (if any) with approvals and review cadence
• Control testing results (for example, periodic checks that “human review required” queues are actually used)
• Incident/complaint records tied to automated decision outcomes and remediation steps

Common exam/audit questions and hangups

Expect these questions, and prepare short, evidence-backed answers:

• “List all decisions that are solely automated and significantly affect individuals. Who owns each?”
• “Show me your criteria for ‘solely automated’ and where it is enforced in SDLC/change management.”
• “Where is human intervention performed, and can the reviewer override the system outcome?”
• “Which third parties provide scoring/decisioning inputs, and do you treat them as determinative?”
• “Show an example decision record from intake through outcome, including approvals and monitoring.”

Hangup pattern: teams can describe models but cannot show governance artifacts. Auditors will accept imperfect judgment calls more readily than missing controls and missing evidence.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Inventorying “models” instead of “decisions.”
   Fix: register decisions/outcomes first, then map models and rules that drive them.

2. Mistake: Calling a workflow “human reviewed” because someone can look at a dashboard.
   Fix: require documented pre-decision review with authority to change the outcome and a recorded rationale.

3. Mistake: Ignoring third-party decisioning because “the vendor runs it.”
   Fix: document determinism. If your process accepts the third party output automatically, treat it as your solely automated decision operationally.

4. Mistake: One-time assessment that goes stale after model iterations.
   Fix: tie the Article 22 gate to change management so it re-runs on material changes.

Enforcement context and risk implications

No public enforcement case sources were provided for this requirement in the supplied source catalog, so this page does not list specific cases. Treat Article 22 as a high-scrutiny area in any supervisory inquiry because it connects directly to individual impact and rights. Your defensibility rests on scoping discipline, documented decision logic, and evidence that controls run in production, not in policy binders. (Regulation (EU) 2016/679, Article 22)

Practical execution plan (30/60/90-day)

Use this as an operator’s rollout sequence. Adjust the pacing to your release cycle and audit calendar.

First 30 days (stabilize scope and ownership)

• Assign an Article 22 control owner (privacy or GRC) and decision owners (product/fraud/HR).
• Stand up the Automated Decision & Profiling Register with an initial pass from key teams.
• Define internal criteria for “solely automated” and “significant effect,” and publish a one-page standard.
• Identify any workflows that appear to be solely automated with significant effect and pause expansion until gating is in place. (Regulation (EU) 2016/679, Article 22)

By 60 days (put gates into workflows)

• Implement the Article 22 gate in product launch and change management tickets.
• Implement or formalize meaningful human review for flagged workflows (queue + reviewer authority + job aid).
• Update third-party intake questionnaires to capture decisioning determinism and supportability evidence.
• Create the evidence packet template and require it for any in-scope decision. (Regulation (EU) 2016/679, Article 22)

By 90 days (prove it runs; make it auditable)

• Run a control test: sample recent changes/releases and confirm the Article 22 gate executed with approvals.
• Run a production test: sample human-reviewed cases and confirm real overrides occur with documented rationale.
• Clean up the register: remove duplicates, ensure role determinations are recorded, link each decision to its artifact packet.
• Set a recurring cadence to refresh the register and evidence packets, and track exceptions to closure. (Regulation (EU) 2016/679, Article 22)

Frequently Asked Questions

Does Article 22 apply to every use of AI or machine learning?

No. Article 22 is triggered by a decision about an individual that is based solely on automated processing and has legal or similarly significant effects. Start by inventorying decisions and assessing whether meaningful human involvement exists. (Regulation (EU) 2016/679, Article 22)

What counts as “based solely on automated processing” in practice?

Treat a workflow as “solely automated” if the outcome is applied without a person performing a real review before the decision takes effect. If a human only monitors aggregate metrics or can’t override, that typically won’t qualify as meaningful involvement. (Regulation (EU) 2016/679, Article 22)

If a third party provides the risk score, is it still our automated decision?

If your system uses the third party output as the final determinant, you effectively run a solely automated decision in your process, even if the score is computed elsewhere. Document determinism and add human review or an exception path with safeguards where needed. (Regulation (EU) 2016/679, Article 22)

Do we need a separate policy for Article 22?

You need more than policy text. Create a short standard and an operating procedure tied to product/change management, plus a decision register and evidence packets that show the control runs in production. (Regulation (EU) 2016/679, Article 22)

How do we operationalize this across multiple teams without slowing releases?

Put a lightweight gate into existing release and change workflows: a small set of questions, required approvers for in-scope decisions, and a reusable evidence packet template. Automate reminders and evidence collection in your GRC tool where possible. (Regulation (EU) 2016/679, Article 22)

What should we expect during an audit?

Auditors typically ask for an inventory of in-scope automated decisions, proof of the gating process, and samples showing meaningful human review and override capability. Your fastest path is a maintained register with linked tickets, approvals, and monitoring records. (Regulation (EU) 2016/679, Article 22)