---
title: "The CIO's Readiness Assessment"
slug: "appendix-b-the-cios-readiness-assessment"
kind: "appendix"
order: 24
label: "Appendix B"
letter: "B"
summary: "A scored assessment in five sections, one per property of the framework. Each statement is scored 0 (false), 1 (partly true or true for a pilot only), or 2 (true across the estate and verifiable to…"
words: 848
---

A scored assessment in five sections, one per property of the framework. Each statement is scored 0 (false), 1 (partly true or true for a pilot only), or 2 (true across the estate and verifiable today). Thirty statements, sixty points. The bands at the end map a total to a level in Appendix A. The assessment is designed to be completed by the CIO with the enterprise architect, the CISO and the head of data in one sitting; disagreements about a score are usually the most valuable output.

## Section 1: You own the code

|#|Statement|Score|
|---|---|---|
|1.1|Our engineers can read the complete source of the AI platform we use, including backend services and infrastructure definitions, today.||
|1.2|The license permits us to modify the source and run the modified platform in production.||
|1.3|Our engineers have built the platform from source at least once in the last year.||
|1.4|Our engineers have deployed the platform to an environment we control without vendor hands on keyboards.||
|1.5|The platform that runs in the vendor's cloud is the same code, byte for byte, as the one we can deploy ourselves.||
|1.6|If the vendor ceased to exist tomorrow, the platform would keep running and we could patch it.||

## Section 2: You own the data, in place

|#|Statement|Score|
|---|---|---|
|2.1|AI agents read our systems of record at query time rather than from a copy ingested in advance.||
|2.2|Every connector between an agent and a system of record runs on infrastructure we control.||
|2.3|The credentials connectors use to reach our systems live in a secret store we control, never in an agent or a client.||
|2.4|Tool calls are denied by default and allowed by an explicit, versioned policy table we administer.||
|2.5|Every tool call is written to an audit log we own, with user, agent, tool and decision.||
|2.6|No copy of our institutional data exists in the vendor's infrastructure that we could not delete today.||

## Section 3: You choose the model, and can change it

|#|Statement|Score|
|---|---|---|
|3.1|The model behind any agent can be changed by an administrator in a settings screen without engineering work.||
|3.2|We have switched a production agent's model at least once and measured the result against an evaluation set.||
|3.3|At least two commercial providers and at least one open-weight model are configured and routable.||
|3.4|Routing rules can confine data of a given classification to approved models, and the rules are enforced by the platform.||
|3.5|A fallback chain exists so that a provider outage does not stop our services.||
|3.6|We see model spend by agent, by model and by day, against a cap we set.||

## Section 4: Your clients share one identity

|#|Statement|Score|
|---|---|---|
|4.1|Every client of the platform, web, browser extension, desktop, mobile and terminal, signs in through one hand-off using our institutional identity provider.||
|4.2|No client application, ours or the vendor's, holds an organization-level credential.||
|4.3|A team can build a new application on the platform with institutional single sign-on, roles and organization scoping without writing authentication code.||
|4.4|The sign-in flow exists in one shared component, so a security fix lands in every client at once.||
|4.5|Multi-organization membership, switching and visiting are handled by the shared identity layer, not by individual applications.||
|4.6|An agent's memory, guardrails and approval behaviour are the same on every surface because the components are shared.||

## Section 5: Your agents run inside a harness you can inspect

|#|Statement|Score|
|---|---|---|
|5.1|We can read the harness that runs our agents: the loop, its tools, its limits.||
|5.2|Every run has a step limit and a token budget, and a human can stop it at any time.||
|5.3|Approval modes exist and are set per agent, so consequential actions can require a human.||
|5.4|Agent memory is held in three scopes in our own database, and each person can see and switch off their own.||
|5.5|Code an agent writes runs in a sandbox on our infrastructure with an explicit network boundary.||
|5.6|We have tried to violate a governance rule from the chat window and the infrastructure, not the model, refused.||

## Scoring

|Total|Level|Reading|
|---|---|---|
|0 to 12|1, Rented|The vendor runs the estate. Begin with Section 1: without the source, the rest cannot be fixed.|
|13 to 24|2, Configured|Institutional identity and administration exist; the structure is still the vendor's. The deciding move is a source-licensed deployment into infrastructure you control.|
|25 to 40|3, Deployed|The two problems from Chapter 1 are solved for the deployed estate. Close the gaps in Sections 2 and 5, then rehearse the exit.|
|41 to 52|4, Owned|The institution could run without the vendor. Prove it quarterly and add local models for restricted data if not yet done.|
|53 to 60|5, Sovereign|Verify the air-gapped build annually. The remaining work is operational discipline, not architecture.|

## Using the result

Score the estate, not the best pilot. Record who scored each statement and why; a 1 that one person thinks is a 2 is a conversation worth having. Re-score every quarter alongside the exit verification from Chapter 20, and keep the history: the trend is the real measure of a sovereignty programme, and it is the figure a board understands.