What comes next
Sequencing questions are hard for a specific reason: the wrong answers are not wrong activities. They are real governance work, correctly described, belonging to a different stage. Knowing what a DPIA is will not get you through them — you need to know what each activity depends on, and what depends on it. This page is that dependency map.
The question behind every sequencing item
Not "which of these is good practice?" — all of them are. It is "which of these makes the others possible?" Every correct answer on this page is the option the other options depend on.
The planning sequence
The five steps most likely to be put in order, and the reason each one precedes the next. Steps can repeat and can overlap; the general order does not change.
-
1 Determine the business problem
Nothing downstream can be judged without it. "Is this the right model?" and "is this proportionate?" are both unanswerable until you can say what the system is for. A team that starts anywhere else is optimising against a target nobody has written down.
Wrong answer built from it: Starting with a capability ("we should use an LLM") or with data you happen to hold. Both are solutions in search of a problem, and both produce a system that fits no assessed purpose.
-
2 Determine the specific use cases
The intended purpose is what fixes the legal classification. The same model is prohibited, high-risk or minimal depending entirely on what it is used for — so until the use case is specific, no legal analysis is even possible.
Wrong answer built from it: Treating the use case as a restatement of the business problem. "Reduce hiring cost" is a business problem; "rank applicants for a shortlist" is a use case, and it is the second one that triggers Annex III.
-
3 Identify the laws that apply
Law constrains what may be built at all. It can rule the project out, force a different design, or add duties that change the cost — and every one of those findings is cheaper before the build than after it.
Wrong answer built from it: Putting legal review after design "so there is something concrete to review". By then the constraint that would have changed the design has already been designed around.
-
4 Identify gaps and risks in the use cases
Now that the purpose is fixed and the legal envelope is known, you can ask where this use case fails — who it could harm, where it is weakest, what the law leaves you exposed on.
Wrong answer built from it: Confusing this with the formal impact assessment. This is scoping risk in the use case; the DPIA or FRIA is a separate instrument with its own trigger, owner and timing.
-
5 Identify the data the system will need
Data comes last of the five, because what you need follows from the purpose and from what the law permits. Deciding data first quietly decides the use case for you.
Wrong answer built from it: The instinct that data is the foundation, so it must come first. It is the foundation of the build, not of the plan — and it is the step most often moved to the front in a wrong answer.
The phases, and the gate that closes each
A stem usually tells you which phase you are in. What it does not tell you is what the phase has to produce before the next one may start — and that gate is normally the answer.
| Phase | What it decides | The gate that closes it | Too early here |
|---|---|---|---|
| Planning | Whether to build this at all, for what purpose, under which laws. | An approved use case with its legal classification and a named owner. | Model selection, data collection, procurement commitments. |
| Design | What the system must do, to what standard, with what safeguards built in. | Documented design decisions and their rationale, recorded as they are made. | Performance tuning, deployment planning, user training. |
| Development | Data sourcing and verification, training, testing, evaluation against the thresholds design set. | Evidence the system met its fairness and performance thresholds, dated before launch. | Anything that assumes the thresholds have been met. |
| Implementation | Whether the organisation is ready, then deploy, then monitor and maintain. | A readiness assessment — the checkpoint between "built" and "in use". | Nothing is too early here; the risk runs the other way. Monitoring, incident routes and human oversight must be in place BEFORE go-live, not added after. |
Which stage does this activity belong to?
Every row is an activity that turns up as a distractor at the wrong stage. The third column is the mistake the item is designed to catch.
| Activity | Belongs to | Offered as | Why the order holds |
|---|---|---|---|
| Build an inventory of AI already running | Before everything | A later audit step | You cannot govern what you cannot see. An inventory and a named accountable owner precede policies, training and assessments — all three attach to systems somebody has listed. |
| Write the AI policy library | After the inventory and the owner | The first act of a new governance programme | Policies written before you know what you govern describe a programme that does not exist. Reliably an attractive wrong answer to "what should you establish FIRST?". |
| Data lineage analysis | Before any data work | Part of data cleaning | Where the data came from, where it goes and which laws control that path can rule out the processing entirely. Cleaning data you may not lawfully hold is wasted work. |
| Clean data, handle outliers and missing values | Development, after lineage and lawfulness | The first data step | It is the first step technically, which is exactly why it is offered first. It is not the first step in governance. |
| Exploratory analysis for insights and relationships | Development | A planning activity | Genuinely valuable and genuinely later. It presumes you already hold the data lawfully. |
| DPIA / FRIA | Before the processing or the first use begins | A pre-launch sign-off | Both are ex ante. A DPIA run the week before launch has already missed the design decisions it was supposed to influence. |
| Conformity assessment | Before market placement | Before deployment | Provider-side and market-facing. The deployer never performs it, and it happens before the system is available, not before a particular customer switches it on. |
| Readiness assessment | End of development, before implementation | A repeat of testing | Testing asks whether the system works. Readiness asks whether the organisation is ready to run it — support, oversight, rollback, training, monitoring. |
| Shadow / parallel running | Late development into pre-launch | Post-launch monitoring | Running alongside the existing process on live inputs without acting on the output. The point is to observe real-world behaviour while the blast radius is still zero. |
| Establish continuous monitoring | Before go-live | A maintenance activity added once the system is bedded in | The single most common late-placement error. Drift, degradation and irregular decisions start on day one; the mechanism has to exist by then. |
| Change management and internal adoption planning | Implementation | The engineers’ job | Right stage, wrong owner — and stems exploit that. Match the activity to the actor the stem names, not just to the phase. |
| Post-market monitoring and incident reporting | After placing on the market | The same thing as performance monitoring | A distinct provider duty under the AI Act with its own reporting obligations, not merely an internal dashboard. |
Six tie-breakers when two answers are both defensible
These are what to reach for when you have eliminated two options and the remaining pair both look right. They are ordered by how often they decide it.
-
1. Stop the harm before you explain it
If the stem says a live system is actively harming users, the first action is protective — suspend, roll back, take it out of the decision path. Root-cause analysis, notification and remediation are all correct and all second. Any option that leaves the harm running while you investigate is wrong however sensible it sounds.
-
2. Visibility before control
Inventory and accountability precede policy, training and assessment. This is why "appoint an owner and list what exists" beats four richer-sounding options in a standing-up-governance stem.
-
3. Law before build
Where a legal question could stop the project, it is answered first. Amy’s doctors’ notes cross three jurisdictions — so the first step is finding out where the data came from and what governs its movement, not cleaning it.
-
4. Purpose before data
The use case fixes the classification, the classification fixes the duties, and the duties fix what data you may use. Any option that settles data before purpose has the dependency backwards.
-
5. Match the actor, not only the stage
When a stem names who is doing the asking — engineers, the ethics board, procurement, the DPO — the answer is the activity that party is actually competent to own. Several options will be right for the stage and wrong for the person.
-
6. Prefer the step that unblocks the others
When two answers are both correct and both timely, choose the one the other depends on. If A is impossible without B, B is the next step.
Five sequences that are not the general life cycle
Each of these has its own order, and each is tested. Mixing one into another is a reliable way to lose a mark.
AI incident response
Contain → assess severity and scope → notify (internally, then regulators, affected people and integrated third parties as required) → remediate → review and feed back into the controls
Identify third-party tools integrated into your system in advance — if an incident hits, you may owe those parties notice, and you cannot work out who they are mid-incident.
Release readiness (high-risk provider)
Meet the Art. 9–15 requirements → conformity assessment → EU declaration of conformity → CE marking → register in the EU database → place on the market → post-market monitoring
Registration precedes market placement. Reversing those two is the standard wrong ordering.
Adaptation ladder (deployer)
Prompt engineering → retrieval augmentation → fine-tuning → training a model from scratch
Lightest first. The exam rewards the least invasive technique that meets the need, and reaching for fine-tuning where a prompt would do is the error.
Third-party procurement
Define the need and classification → due diligence on the vendor → negotiate contractual terms and evidence rights → sign → onboard with monitoring → ongoing review
Every term you will ever want — audit rights, incident notice, data use restrictions, model-change notice — is negotiable before signature and nearly impossible after.
Data pipeline
Lineage and lawfulness → quality and representativeness → cleaning and preparation → splitting → training → evaluation
The governance question sits at the front of a pipeline whose technical steps start at "cleaning".
How these items are built
Every distractor is a good idea
That is the design. Sequencing items rarely contain a bad activity — they contain four good activities and one correct dependency. If you are choosing on quality you are answering the wrong question.
"Also required" is not "required next"
Several options may be things that must happen before deployment. Only one is the thing that must happen at the point the stem freezes the story.
The technically first step is not the governance first step
Cleaning data, choosing a model, building a prototype — all correct starting points for the engineering, all offered to see whether you will start there.
Steps repeat; the question asks about this pass
Risk assessment happens in planning, again at design, again on material change. The stem tells you where you are standing.
The one-line version
Purpose fixes the law, the law fixes the design, the design fixes the data. Work down that chain and the ordering answers itself; any option that reverses a link in it is the distractor, no matter how good the activity is on its own.
Test yourself
5 questions on what is above, with every option explained. Your score is kept in this browser and shown on your dashboard, and saved to your account if you are signed in.
A team has agreed the business problem its new AI system will solve. Which step comes next?
- AIdentify the data the system will need to be trained.
- BDetermine the specific use cases the system will serve.
- CIdentify the gaps and risks arising in each use case.
- DIdentify the laws and regulations that will apply.
Related: Which assessment, and who owes it · A worked example, end to end · Exam technique · Roles, and how they change