The exam-readiness checklist

Complete means you can also say how you know it is complete. That covers how you find systems, when you last did, and what that process would miss.

The inventory exists but is maintained by hand, so its completeness rests on people remembering to add things.

This is what separates an inventory from a list. It is also the first thing that makes an inventory defensible against the suggestion it was assembled recently.

The inventory is a spreadsheet whose version history only goes back as far as the current file.

Applied, not just written: you can point at things you decided were out of scope and say why.

The definition exists in policy but no out-of-scope decision was ever recorded, so in practice scope is whatever people happened to register.

Third-party models still sit in your risk framework. You need the documentation you were given, and a record of what you asked for and did not get.

Vendor models are in the inventory but the diligence lives in procurement, unlinked to the model record.

Ownership that survives reorganisations and departures, with the handover recorded when it moves.

Owners are named but were assigned once at registration and never revisited.

The decision itself: who approved, on what date, against which version of the evidence.

The approval is an email thread, and the model has been revalidated twice since, so the thread no longer describes what is running.

Questions raised by the second line, the answers they got, and how each was closed. Include the ones that changed the outcome.

Minutes record that a committee reviewed and approved, with no trace of what was contested.

Independence as an organisational fact you can evidence, not an assertion in the policy.

In small teams the same person built and reviewed, and the compensating controls were never written down.

Conditional approval is common and sensible. What examiners look for is the follow-through.

Conditions were tracked in a project plan that closed when the project did.

A governance process that approves everything invites an obvious question. A recorded rejection or material restriction is the strongest single piece of evidence you can hold.

Things were informally discouraged before they reached the committee, so the record shows only approvals.

Materiality thresholds, performance drift, a change in use. Evidence of the assessment happening, including the times it concluded no action.

Triggers are defined in policy, but only ever documented when they resulted in a revalidation.

Retraining, changed settings, a changed input, a new version. Dates must have been recorded at the time.

Changes live in the ML platform's logs, which nobody has mapped to the evidence record.

Stated in advance is the operative part. A materiality judgment made after the fact cannot be tested.

Materiality is decided case by case by the same team that made the change.

The clean months make the exception months credible. They show the baseline was being watched.

Only breaches are escalated and retained; passing results are overwritten by the next run.

The finding, the decision, the fix and the date it closed. They should read as one connected story.

Findings go to an issues register that records closure dates but not what was actually done.

Including the things procured on a departmental card and the copilots embedded in software you already bought. Especially those.

The MRM inventory covers models; nobody owns an inventory for the rest, because it is out of MRM scope.

A named owner, a named framework, and a written rationale. Together they are the answer to "who is accountable for this if not model risk".

Everyone assumes it sits with someone else: model risk says out of scope, operational risk says it is a model, and it falls between them.

The action, the input it acted on, the authority under which it acted, and whether a human could have stopped it.

Application logs exist and are retained for 30 days, which is shorter than the gap between an incident and the exam that asks about it.

Instances where a human reviewed, and what they decided. Showing that one could intervene is not enough.

A human-in-the-loop step exists but approves in bulk, and nothing distinguishes a considered approval from a reflexive one.

The most valuable document in this whole section: a reasoned decision, made at the time, about how you would govern something the guidance left to you.

The position is defensible but was formed in the week the request arrived, and the document says so.

Not "our policy forbids editing". The record itself must be built so that someone else can check it.

Governance lives in tools where anyone with edit rights can revise history, and the audit log is administered by the same team.

Independent verification is the difference between evidence and assertion. If checking your record requires believing your systems, an examiner is weighing your word.

Integrity rests on database permissions and a vendor's assurances, both of which are assertions.

Exam cycles run to years. Log retention frequently runs to weeks, and the two are rarely set by the same people.

Retention was set for operational cost, and no one has checked it against the supervisory horizon.

The practical test. If it only makes sense when your team narrates it, it is not a record. It is a presentation.

Evidence is spread across four systems and coheres only in the head of the person who assembled it.

A dry run against a real request list, done cold. Every item above is a hypothesis until someone tries to produce it under time pressure.

Readiness is assumed from the existence of the tooling, never rehearsed.