A model is a software artefact. That is the premise behind this template: a spreadsheet or calculation file that feeds a decision deserves the same disciplines as a CRM system, even though it sits outside the application portfolio and has no vendor. The reasoning is set out in the article Model Risk and EUC, from Blind Spot to Control. This is the instrument that goes with it.
The template does three things that make a control framework usable. First, it determines the risk class, so that the weight of scrutiny scales with what goes wrong if the outcome is incorrect. It then sets out, per discipline, the test questions that belong to that class, along with the evidence you should expect. And at the end it produces a coverage picture and a list of open points you can carry into a report or into follow-up.
Use it per artefact. Your assessment stays in your own browser; nothing is sent to a server. Export to Word if you want to keep or share the file.
Enter the artefact you are assessing
Step 1. Determine the risk class
The weight of the framework should scale with what goes wrong if the outcome is incorrect. Six questions determine the class; that class then determines which of the 35 test questions apply.
Step 2. The control framework
Seven disciplines, 35 test questions. Each question states the evidence you should expect and from which risk class the question applies. A question that does not apply to your class stays visible but does not count; mark it as met anyway if you want to be stricter than the class requires.
Change management
Without change management, nobody knows which version held the truth at the moment the decision was made. That is not primarily a control problem but a reconstruction problem: last quarter's outcome can no longer be recalculated.
Documentation
The test is not whether documentation exists but whether someone else can take over the model. Models that depend on one person collapse the moment that person leaves, and on average that happens sooner than the model gets replaced.
Segregation of duties and access
In a spreadsheet, segregation of duties almost always disappears: the same person builds, enters data, calculates, and presents. That is acceptable as long as it is a deliberate decision with a visible compensating measure, and unacceptable as long as nobody has noticed it.
Reference data and parameters
A rate typed directly into a formula is untraceable the moment it changes. The silent failure in this discipline is not a wrong calculation but an outdated figure that stays in place for years.
Input
Almost every reconstruction of a model error ends at the input, not at the formula. A model that silently processes incorrect input is more dangerous than one that makes calculation errors, because the outcome still looks plausible.
Output
The outcome travels further than the model. The moment the figure lands in a presentation, the assumptions have fallen away. What you secure here determines whether the recipient can weigh the figure or can only take it on faith.
Validation
This is the discipline that is almost always missing outside the financial sector, and it is the only one that can catch failures in the other six. Validation is not checking whether the sum is right but establishing whether the model still gives the right answer to the right question.
Step 3. The result
Coverage counts only the questions that apply to your risk class. Questions marked N/A do not count in the denominator; unrated questions do, because a question that goes unanswered does not produce coverage.
| Discipline | Applicable | Met | Partial | Not met | Open | Coverage |
|---|---|---|---|---|---|---|
| 1. Change management | 0 | 0 | 0 | 0 | 0 | |
| 2. Documentation | 0 | 0 | 0 | 0 | 0 | |
| 3. Segregation of duties and access | 0 | 0 | 0 | 0 | 0 | |
| 4. Reference data and parameters | 0 | 0 | 0 | 0 | 0 | |
| 5. Input | 0 | 0 | 0 | 0 | 0 | |
| 6. Output | 0 | 0 | 0 | 0 | 0 | |
| 7. Validation | 0 | 0 | 0 | 0 | 0 | |
| Total | 0 | 0 | 0 | 0 | 0 |
Open points
Nothing assessed yet.
Appendix A. Four standards tracks and the coverage gap
Where do the standards this framework rests on come from, and why is there still a gap? Click a chip in the framework above for the explanation per standard.
| Track | Frameworks | Covers | Does not cover |
|---|---|---|---|
| Regulatory oversight | ECB Guide to internal models, Solvency II Articles 120 to 125, PRA SS1/23, SR 11-7 and SR 26-2 | All seven disciplines, including independent validation and a mandatory model inventory. | Applies only to banks and insurers licensed for an internal model. Outside that, no equivalent exists. |
| Spreadsheet and EUC | ICAEW Twenty Principles (revised 2024), FAST Standard 02c (2019), EuSpRIG | Build quality down to cell level: separating input, processing and output, an explanatory sheet, no hardcoding, version control and backup, testing, built-in checks, protected sections. | The organisational half: who approves, who validates, who owns it. |
| Generic software and IT | ISO/IEC/IEEE 12207:2017, ISO/IEC 25010:2023, COBIT, ITGC | Exactly that organisational half: lifecycle, configuration management, change management, logical access, IT operations. | In practice, it is not applied to a spreadsheet. The file is not in the application portfolio, so it falls outside the IT auditor's scope. |
| Artificial intelligence | ISO/IEC 42001:2023, NIST AI RMF 1.0, the EU AI Act (including Article 10) | The same seven disciplines, but only for systems that learn or infer. | Deterministic calculation models fall outside it by definition, no matter how much weight the outcome carries. |
The conclusion is not a regulatory vacuum but a coverage problem. The strictest requirements sit with the sector that already saw the risk, the sharpest build standards lack an owner, the broadest frameworks look past the file, and the newest frameworks exclude precisely the most common model type. Outside the financial sector, you control a model not because you must, but because it is sensible. This template is the bridge: the seven disciplines of a software artefact, applied to a model, with a reference per discipline to the framework that already governs it.
Appendix B. The model inventory
This framework assesses one artefact. The question that comes before that is which artefacts you actually have. Without an inventory, you assess the models you happen to know about, and those are rarely the riskiest. Ten columns are enough to get started.
| Column | What you record |
|---|---|
| Model name and version | The current version, matching what is stated in the file. |
| Purpose and decision | Which question the model answers and which decision the outcome serves. |
| Owner | Who is responsible for the outcome. A role, not a department. |
| Administrator | Who may make changes and who is the designated backup. |
| Risk class | A, B, or C, with the date of the latest classification. |
| Input sources | Which systems or reports feed the model. |
| Recipients of the output | Who receives the figure, and whether it leaves the organisation. |
| Last validation | Date, performed by, and the status of the findings. |
| Next review | Derived from the risk class. |
| Location | Where the file is stored, and where the version archive is stored. |
Start from the outcomes, not the files: go through the past year's reports and decisions and ask, for every figure, where it came from. What you find then is the real portfolio.
One framework per model is manageable. A hundred models is not.
This template assesses one artefact and gives you a file per model. If you want the inventory, the classification, the review schedule, and the follow-up of findings in one place, Modelio in the Audirium suite does that. Modelio is in the beta programme.