Article 22 automated decisions are personal decisions made solely by automated processing, including profiling, that have legal or similarly significant effects. The GDPR restricts such decisions unless a lawful exception applies. Organisations should identify these workflows, add meaningful human review where required, and check bias, explainability, and appeal routes before deployment.
What Article 22 automated decisions mean in practice
Article 22 sits at the point where automation becomes a rights issue, not just a workflow design choice. It matters when a decision is made solely by automated processing and produces legal or similarly significant effects for the person concerned.
That means the central question is not whether software helps make a decision, but whether a human meaningfully participates in the final determination. When the automated step is the whole decision, Article 22 becomes relevant even if the logic is embedded inside a broader platform, scoring model, or rules engine.
Why these decisions are sensitive
Automated decisions of this kind can be difficult to challenge because the affected person may not see how the outcome was reached or what data drove it. The risk is not only error, but also opaque decision-making at scale, where a flawed model or rule can affect many people in the same way.
For that reason, organisations should treat the decision path itself as part of the privacy and governance surface. The issue is not limited to the model, it also includes the data used, the thresholds applied, the presence or absence of review, and whether appeal routes are actually usable.
What organisations need to examine
The first task is to identify where sole automation is being used in high-impact decisions, such as eligibility, access, pricing, screening, or adverse selection. A workflow can fall into Article 22 even if the automation is only one part of a longer process, so it is important to map where the final decision is truly made.
Then the organisation should determine whether an exception is being relied on and whether the surrounding safeguards are real in operation, not just documented on paper. Meaningful human review, transparency to the individual, and the ability to contest the decision are the practical controls that determine whether the process is defensible.
The GDPR itself is the core reference point for this area, and the EU General Data Protection Regulation (GDPR) remains the authoritative text for the underlying legal obligations.
Bias, explainability, and reviewability
Article 22 is often discussed alongside bias because automated systems can reproduce skewed training data, proxy variables, or design choices that disadvantage some groups. Explainability matters here because a decision that cannot be explained well enough to review is hard to govern, even before you reach a legal challenge.
Reviewability is the practical test. If a person can press “approve” after the system has already made the substantive call, that may not be enough to count as genuine human involvement. The review must have the ability to change the outcome and must be supported by enough context to do so responsibly.
Risk and Threat Considerations
Automated decisions create concentrated exposure when a single logic path or model influences many outcomes at once. The most common failure pattern is not a dramatic breach, but systematic error, hidden bias, or an appeal process that exists in theory but does not work in practice.
Failure mechanism: Poor data quality, biased features, weak oversight, or over-reliance on model output can turn a workflow into a high-scale unfairness or compliance failure.
Impact: Individuals can receive unjustified adverse decisions, organisations can lose trust and face regulatory exposure, and downstream remediation can become difficult once the process is embedded across multiple teams or products.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, while GDPR and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| GDPR | Article 22 Automated Individual Decision-Making | Article 22 directly governs solely automated decisions with legal or similar effects. |
| Recommendation — Map high-impact automated decisions, verify lawful basis or exception, and add meaningful human review where required. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential and access governance supports accountability for systems that make sensitive decisions. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Automated decisions need auditable traces for review, contestability, and post-decision analysis. | |
| AU-12 — Audit Record Generation | Decision workflows require records that preserve how a result was produced and reviewed. | |
| Recommendation — Control access to decision systems and review privileges that can alter automated outcomes. Review decision logs to confirm inputs, rule paths, overrides, and exception handling. Generate logs for model inputs, scoring steps, human interventions, and final outcomes. | ||
| ISO/IEC 27001:2022 | A.5.34 — Privacy and protection of PII | Automated personal decisions depend on privacy governance for personal data processing and review. |
| Recommendation — Apply privacy controls to personal data used in automated decision workflows. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Decision logic embedded in applications needs secure, reviewable implementation to limit hidden failure modes. |
| Recommendation — Design decision workflows so business logic, overrides, and error paths are explicit and testable. | ||
Practitioner Guidance
Governance implication: Treat Article 22 workflows as controlled decision systems, not routine automation. The key operational question is whether the organisation can prove where human judgment sits, how exceptions are handled, and how the affected person can challenge the result.
Practitioner note: The safest implementation posture is to design the review path before launch, not after the first complaint. If the workflow cannot support a genuine override, it should be redesigned rather than labelled as human-reviewed.
Related resources from NHI Mgmt Group
- What should privacy teams do when AI systems use personal data for automated decision-making under GDPR Article 22?
- How can organisations keep automated access decisions current over time?
- What breaks when automated decisions rely on batch reconciliation?
- Who is accountable when automated KYC decisions fail an audit?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org