What is Data Protection Impact Assessment?

Why It Matters

An impact assessment is the moment a deployment stops being a procurement decision and becomes a described system. It asks what the tool does, whose data it processes, what the risks are to those people, and what reduces them. Done properly it is the document that a works council, a regulator, or an employment tribunal reads first, because it is the only one that explains the system rather than selling it.

For screening tools the assessment is expected before the tool goes live rather than after. Regulators in the UK audited recruitment AI providers and published recommendations rather than fines, which is a signal about where scrutiny is heading: the expectation is documentation first.

What It Covers

Purpose and necessity. What decision the system influences, and why a person’s data has to be processed to make it.

Data and flow. Which fields are read, where they come from, how long they are kept, and where they are processed, including any model endpoint or vendor environment outside your jurisdiction.

Risk to individuals. Unfair outcomes, opaque rejections, exposure of sensitive attributes, and the consequences of an error for someone’s employment prospects.

Mitigations. Criteria written in advance, evidence attached to judgements, a reviewer who can disagree, retention limits, and the measurement that shows whether the risk is actually reduced.

Where It Breaks

The first failure is a vendor-written assessment. A supplier can describe its model and cannot describe your process, your criteria, or the roles the tool screens. Those are the parts a regulator asks about.

The second is describing the model rather than the deployment. The same screening engine used to rank 400 applicants for a warehouse role and to shortlist three finalists for a regulated position carries different risk, and an assessment that ignores the use case is describing a product rather than a system.

The third is writing it once. A new criteria set, a model upgrade, or a new requisition type changes the risk picture, and the assessment has to be revisited on the same cadence as the system changes.

The fourth is having no owner. An assessment with no named person responsible for its mitigations is a document, and the mitigations quietly stop being true.

How Flytebit Handles It

We build the assessment from the running system rather than from the vendor’s description: the criteria version, the fields read, the reviewer step, the retention period, and the measured outcomes are all available as facts rather than assertions, so the document describes what the deployment actually does. It is revisited whenever the criteria, model, or roles change. The industry application is on our HR & Workforce Technology page, and the control design is our AI governance and risk work.