Why does the revised FADP increase the compliance risk for organisations that use profiling or automated decision-making?

Why profiling raises compliance exposure under the revised FADP

The revised FADP makes profiling and automated decision-making riskier because it increases the transparency burden and strengthens the individual’s ability to question outcomes. That matters most where a decision influences legal position, access, eligibility, pricing, or other significant effects, because opaque logic is no longer just a governance weakness, it becomes a direct compliance problem.

For organisations, the key shift is that the compliance burden now sits on the quality of explanation and the ability to respond, not just on whether the processing exists. If the organisation cannot clearly describe the data used, the purpose, and the recipients, it is exposed to notice failures and challenge failures at the same time.

What changes when automated decisions are involved

Profiling by itself can create compliance pressure, but automated decision-making increases it because the organisation must be ready to justify the decision path and support intervention where the law requires it. In practice, that means the workflow needs to be understandable enough for internal review and defensible enough for external scrutiny.

The compliance risk rises further when the organisation treats a model or rules engine as a black box. If staff cannot explain the inputs, the logic category, or the downstream use of the result, the organisation may struggle to prove that its notices, governance controls, and challenge process are effective. The issue is not only the decision itself, but whether the business can evidence control over it.

That is why EU General Data Protection Regulation (GDPR) is often the closest external reference point for automated decision governance, even though the legal regimes are not identical. The practical lesson is the same: decision logic must be traceable enough to support notice, review, and accountability.

Where compliance failures usually appear in practice

The highest-risk failure mode is not the use of profiling itself, but the combination of opacity, weak ownership, and weak exception handling. If the organisation cannot show who owns the workflow, who approved the use case, and who can override an outcome, the control environment will look thin even before a complaint arrives.

Another common failure is scope drift. A workflow may start as low-impact personalisation, then evolve into eligibility scoring, fraud triage, or prioritisation decisions without the notices, review rights, or governance controls being updated. That kind of drift creates a mismatch between what the organisation says it is doing and what the processing actually does.

For organisations with broader data-governance obligations, the same visibility problem appears in vendor and platform oversight. SOC 2 Trust Services Criteria (AICPA) can help frame the control expectation around processing integrity and privacy-oriented governance, while NIST SP 800-53 Rev 5 Security and Privacy Controls offers a control vocabulary for access, auditability, and privacy-relevant oversight.

Risk and Threat Considerations

Opaque profiling and automated decisions create both privacy exposure and governance exposure because they can hide data use, limit effective challenge, and make it harder to prove lawful handling. The risk is not only regulatory enforcement, but also business decisions being made on data or logic that cannot be defended under scrutiny.

Failure mechanism: The organisation cannot reliably explain the decision basis, identify the recipient or downstream use, or support challenge and review, so notices, governance, and appeal handling all fail together.

Impact: Complaints, remediation, delayed launches, forced workflow redesign, and heightened scrutiny of the surrounding processing activity can follow, especially where the outcome has legal or significant effect.

Practitioner Guidance

What to prioritise: Treat every profiling or automated decision workflow as a governed decision product, not a back-end analytics feature. The first task is to identify which workflows produce significant effects and therefore need stronger notice, review, and challenge handling.

What to verify: Confirm that the organisation can show the data categories used, the purpose, the recipient set, the decision logic owner, and the review path for contested outcomes. If any of those are unclear, the compliance gap is already material.

Common mistake: Teams often document the model or rules engine, but not the user-facing explanation or escalation path. That leaves the organisation technically aware of the workflow while still failing the operational requirement to answer challenge questions.

Practitioner takeaway: The real compliance test is whether the organisation can defend the decision lifecycle end to end, from notice to challenge to human review, before a regulator or affected individual asks for it.

Related resources from NHI Mgmt Group

• How should organisations scope automated decision-making technology for compliance in consequential decision processes?
• Why do automated decision-making systems create extra compliance risk under MODPA?
• Why do cross-border data transfers and automated decision-making create compliance risk under Law 25?
• How should organisations structure ESG reporting so it supports risk management and decision-making rather than becoming a compliance exercise?