Secure-AI-Adoption Blueprint

End state, implementation process and quick scan for organisations and individuals. Netherlands edition, September 2026. Draft v0.3.

This blueprint answers three questions. What does "good" look like when an organisation builds, buys and runs AI securely and in line with Dutch and EU law? What is the shortest defensible path to get there? And how does one person harden their own AI tooling? It is built on Google's Secure AI Framework (SAIF) as the technical spine, ISO/IEC 42001 as the management system, and the OWASP GenAI lists as the threat catalogue, with the regulatory layer (AI Act, Cyberbeveiligingswet, DORA, GDPR) mapped on top. Section 9 turns it into a scan you can run with a client in an hour.

1. The compliance picture in September 2026 #

Four things changed this year, and they set the clock for everyone in the Netherlands.

Standards are catching up. ISO/IEC 42001 is certifiable and has been adopted as EN ISO/IEC 42001:2026. ISO/IEC 27090 (AI cybersecurity) reached FDIS in March 2026 with publication expected in the second half of 2026; it is guidance, not certifiable. ISO/IEC 42005:2025 covers AI impact assessment. On the agent side, NIST launched its AI Agent Standards Initiative in February 2026 and NCCoE published a concept paper on agent identity and authorisation, while the SP 800-53 agent overlays are not expected before late 2026 to 2027. Organisations deploying agents today run ahead of the controls written for them.

2. Framework choice: SAIF is the spine, not the whole skeleton #

SAIF is the right technical backbone for three reasons. It is organised by where data flows through the system rather than by abstract risk category. Its 2026 agent map breaks an agent into four components (application and perception, reasoning core, orchestration, response rendering) and names two agent specific risks: rogue actions and sensitive data disclosure. And Google donated the underlying risk data to the Coalition for Secure AI, so it is vendor neutral in substance. It also ships a Risk Self Assessment, which is a useful cross check for your own scan.

SAIF does not do governance, certification, regulatory mapping or threat modelling in depth. The blueprint therefore stacks five layers:

Use ISO 27001 as the assumed baseline. Nothing here replaces it; AI security is an extension of an existing ISMS, which is also how BaFin reads DORA for AI.

3.0 Securing the estate for AI #

Before any of the eight domains can be scored honestly, the environment underneath them has to be able to carry AI. This section answers the question "what must my estate have before I let AI in." It applies whether the AI is a SaaS copilot, a vibe coded internal tool or a fleet of agents, and it is the same list for a municipality and for a bank; the difference is how far each item has to go.

Eight foundations. Each has a readiness test with a yes or no answer.

How the estate gate works in the scan. Each foundation scores 0 (absent), 1 (partial) or 2 (in place and tested). Sixteen points total. The estate score caps the domain scores: below 8, no domain can score above level 1 (Informal or partial) whatever the answers say; between 8 and 12, domains cap at level 2 (Defined); 13 and above removes the cap. This stops the common pattern where policy and governance answers look mature while the environment cannot enforce any of it.

Order of work. If the estate scores low, build in this order: E3 egress control (fastest win, immediate visibility), E4 secrets, E1 identity, E5 logging, E7 registry, E2 classification, E6 sandboxing, E8 kill capability. E3 first because it turns shadow AI from a guess into a number in the first week.

Sector notes. Public sector and central government: E2 and E5 usually exist for information security reasons (BIO, NEN 7510) but do not yet extend to prompts and agent actions; the work is extension, not construction. Financial services under DORA: E3, E5 and E7 double as the evidence base for the Register of Information and for supervisors who now examine for proof rather than plans. Organisations newly in scope of the Cbw: E1 through E5 are also the core of the duty of care measures, so the estate work serves both purposes.

3.1 Reference architecture and tool inventory #

The eight foundations become six planes in the target architecture. Every AI use case, from a Copilot Studio agent to a vibe coded internal app to a multi agent workflow, sits inside the same six planes; only the size of each plane changes with the organisation.

flowchart TB
    subgraph GOV["Governance plane (E7, D1, D7)"]
        REG["AI inventory and registry\nmodels, agents, MCP servers, plugins"]
        POL["Policy and approvals\nintake board, tiering, allow lists"]
    end
    subgraph ID["Identity plane (E1)"]
        IDP["Identity provider\nhumans and agents"]
        CRED["Short lived, task scoped credentials\ndelegation chain recorded"]
    end
    subgraph DATA["Data plane (E2)"]
        LBL["Machine readable classification"]
        DLP["DLP and redaction at prompt time"]
        PROV["Provenance and content credentials\nlineage: data, model, prompt, approver"]
    end
    subgraph GW["Gateway plane (E3, E4)"]
        AIGW["AI gateway / agent gateway\nauth, inspect, guardrail, log, block"]
        VAULT["Secrets manager"]
    end
    subgraph RT["Runtime plane (E6)"]
        SBX["Sandboxed execution\nno standing credentials"]
        HITL["Human approval gate\nfor high impact actions"]
    end
    subgraph OBS["Observability plane (E5, E8)"]
        LOG["Tamper evident action log\nprompts, tool calls, results"]
        DET["Detection rules for agentic anomalies"]
        KILL["Kill switch\ngateway + identity + network"]
    end
    USER["Users and builders"] --> IDP
    IDP --> CRED --> AIGW
    LBL --> DLP --> AIGW
    VAULT --> AIGW
    AIGW --> MODELS["External and internal models"]
    AIGW --> TOOLS["Tools, MCP servers, enterprise systems"]
    AIGW --> SBX
    SBX --> HITL --> TOOLS
    AIGW --> LOG --> DET --> KILL
    KILL -.stops.-> AIGW
    REG --> AIGW
    POL --> REG
    TOOLS --> PROV
    MODELS --> PROV

Reading the diagram. Nothing reaches a model or a tool except through the gateway plane. Identity decides who and on whose behalf; data decides what may pass; the gateway enforces both and writes the log; the runtime isolates anything the AI executes; observability watches and can stop it; governance says what is allowed to exist at all. Provenance is written at the point where models and tools produce output, so lineage is a by product, not a reconstruction.

Tool inventory per platform #

Vendor names as of September 2026. Each cell names the component that satisfies the foundation on that platform; the last column is what to use when the estate is mixed or when the organisation is too small for the suite licence.

Which stack to recommend. A Microsoft first organisation gets the fullest coverage from Entra, Purview, Defender, Sentinel and Agent 365, because Microsoft chose to extend the existing platform rather than build separate AI security products. A Google Cloud organisation gets the tightest agent governance from the Agent Platform's Govern section, which implements SAIF directly. Most Dutch clients are Microsoft on the desktop and mixed in the cloud; for them the gateway plane is where neutrality matters most, and a vendor neutral AI gateway (Kong, Portkey, LiteLLM behind Zscaler or Netskope) in front of both clouds avoids two parallel control stacks.

Scaling from 50 to 50,000 #

The planes do not change with size; the products and the thresholds do.

The scanner: what it reads and how it scores #

The estate scan in section 3.0 is designed to be executed by a tool, not only in an interview. For each foundation the tool reads a small set of signals with read only permissions, scores 0, 1 or 2, and produces the cap.

The same tool then asks the 44 domain questions in section 9, applies the cap, and produces the readout. Outputs: an estate score out of 16, a domain profile, the cap that applied, the top five gaps ordered by the section 3.0 build order, and the recommended stack from the inventory above for the platforms detected.

3. The end state: eight domains #

Each domain describes what good looks like. The scan in section 9 measures distance from this picture.

D1. Governance and accountability #

• A named executive owns AI risk; the management body has discussed AI security at least twice in the past year. (source) D1.1
• One AI inventory (a register) lists every model, application, agent, MCP server and SaaS AI feature in use, with owner, purpose, data classes touched, AI Act classification and autonomy tier. D1.2
• An AI use policy exists, is short, and is enforced through tooling rather than trust. D1.3
• AI literacy is delivered and evidenced per role, meeting the Article 4 obligation in force since February 2025. (source) D1.4
• The AI management system is scoped to ISO/IEC 42001 (detailed under D7.5). D1.5
• The management body has set an AI risk appetite per autonomy tier, with a short list of never events that no use case may cross. D1.6

D2. Data security and provenance #

• Data is classified and the classification travels with the data into prompts, retrieval indexes, fine tuning sets and agent memory. D2.1
• An AI gateway or DLP layer inspects and, where needed, redacts what leaves the organisation toward external models; no direct calls from laptops or apps to model APIs. D2.2
• Retrieval and training corpora have integrity controls: source allow lists, content signing, change detection, poisoning checks. D2.3
• Synthetic output is marked: content credentials on generated media and machine readable disclosure on AI generated text where Article 50 requires it. (source) D2.4
• Lineage is recorded end to end: which data, which model version, which prompt template, which output, which human accepted it. D2.5

D3. Identity and access for humans and agents #

• Every agent has its own identity, distinct from the user it acts for and from generic service accounts. (source) D3.1
• Credentials are short lived and task scoped, issued just in time. (source) D3.2
• Delegation chains are explicit: user to agent, agent to tool, agent to agent, through MCP and A2A authorisation. (source) D3.3
• High impact actions (payments, deletions, external sends, access changes) require a human approval step that is designed, logged and tested. D3.4
• No agent holds more access than a human in the same role. (source) D3.5

D4. Secure AI application development (including vibe coded software) #

• AI generated code enters the same pipeline as human code: version control, review, SAST, dependency scanning, secrets scanning, and a security gate before anything touches production data. D4.1
• Every AI application has a threat model on the SAIF map before build starts and is tested against adversarial inputs before release; prompt injection, insecure output handling, excessive agency and tool misuse are addressed by design. D4.2
• Agent code execution happens in sandboxes with no standing credentials. (source) D4.3
• MCP servers, plugins, prompt templates and models are supply chain artefacts: allow listed, pinned, signed where possible, and recorded in an AI bill of materials. (source) D4.4
• Citizen built apps have a lightweight intake path so they do not become shadow IT. D4.5

D5. Model and vendor assurance #

• Every external model and AI platform has passed due diligence: data use terms, training on customer data, retention, region, subprocessors, incident notification, exit. D5.1
• For financial entities, each AI provider is in the DORA Register of Information with Article 30 clauses; concentration risk on the hyperscalers is assessed. (source) D5.2
• Models are evaluated before adoption and on version change: capability, safety, jailbreak resistance, bias where relevant. D5.3
• GPAI provider documentation (model cards, training data summaries, instructions for use) is on file for models used in regulated contexts. D5.4

D6. Runtime controls, monitoring and response #

• Guardrails sit at input and output: prompt injection detection, PII and secret filtering, output policy checks. D6.1
• Every agent action is logged in a tamper evident trail: who, on whose behalf, which tool, which parameters, which result, retained for at least the period the law requires. D6.2
• Detection rules exist for agentic anomalies: unusual tool sequences, volume spikes, access outside task scope, memory drift. D6.3
• A kill switch stops any agent or model integration within minutes, and it has been exercised. (source) D6.4
• AI incidents are in the incident playbook and mapped to Cbw and DORA reporting timelines, including suspension of use and notification of the provider. D6.5
• AI dependent processes have a continuity plan and a tested fallback for model or agent unavailability. D6.6

D7. Compliance mapping and evidence #

• Each system in the inventory has an AI Act classification and role determination (provider, deployer, both) with reasoning recorded, including cases where modification makes a deployer a provider. D7.1
• High risk candidates have a dated roadmap to the applicable deadlines: risk management, data governance, technical documentation, logging, human oversight, accuracy and robustness, quality management. (source) D7.2
• DPIAs and, where applicable, fundamental rights impact assessments and AI impact assessments are complete and linked to the inventory. D7.3
• Evidence is generated by the controls themselves (logs, pipeline gates, approvals), not assembled for the auditor afterwards. D7.4
• The AI management system is scoped and documented against ISO/IEC 42001, whether or not certification is pursued. D7.5
• Where the organisation provides high risk AI, the provider obligations are met before release: risk management, data governance, technical documentation, record keeping, instructions for use, human oversight, accuracy and robustness, quality management, conformity assessment and registration. D7.6

D8. People, culture and approved tooling #

• An approved AI tool catalogue exists and is easier to use than the alternatives. (source) D8.1
• Shadow AI is measured (network, SSO, expense data) and reduced through enablement, not bans. (source) D8.2
• Builders (including non developers) know the intake path for a new AI app and the data they may and may not use, and have a route for requesting tools that gets answered. D8.3
• Workers and affected persons are informed about AI systems used on or about them where the law requires. D8.4
• The effectiveness of AI security measures is assessed on a defined cycle and the findings feed the risk assessment. D8.5

4. Maturity levels #

The levels carry the same names as the answer scale in section 9, so a domain at level 2 and an answer of 2 mean the same thing.

Target for most Dutch organisations in scope of the Cbw by mid 2027: level 3 in D1, D2, D3, D6, level 2 elsewhere. Target for financial entities under DORA: level 3 across the board.

5. Autonomy tiering: the single most useful control decision #

Tier every AI use case once, at intake. The tier drives the required controls. The UK NCSC's central recommendation is to decide first how much autonomy an agent actually needs, and the Five Eyes guidance says to start small, on low risk tasks, with established controls from the outset.

6. The implementation process for organisations #

Five phases. The first three fit in one quarter for a mid sized organisation.

Phase 1. Discover (weeks 1 to 4)

1. Confirm regulatory scope: Cbw entity type and registration, DORA applicability, sector supervisor, AI Act roles (provider, deployer, or both).
2. Build the AI inventory from four sources: SSO and identity logs, network and proxy data, procurement and expense data, and a builder survey.
3. Classify each entry: AI Act category, data classes, autonomy tier, owner.
4. Score the estate gate (section 3.0), then run the section 9 scan (v0.3). Capture both as the baseline; the estate score decides whether Phase 3 starts with foundations or with AI specific design.

Phase 2. Decide (weeks 3 to 6)
5. Set the AI risk appetite per tier and the list of never events (for example: no agent may send external email without human release; no customer data to non contracted models).
6. Appoint the AI risk owner and the intake board (security, privacy, legal, business, architecture; one meeting per week, fifteen minutes per request).
7. Publish the AI use policy (two pages) and the approved catalogue.

Phase 3. Design (weeks 5 to 10)
8. Reference architecture: AI gateway, identity provider extended to agents, secrets management, sandbox for code execution, logging pipeline, guardrail layer, kill switch.
9. Vendor due diligence template and contract clauses (DORA Article 30 where relevant).
10. Secure pipeline for AI built apps (section 7).

Phase 4. Deliver (weeks 8 to 20)
11. Migrate existing use cases through intake; retire or contain what fails.
12. Automate the gates: pipeline checks, credential issuance, logging.
13. Train builders and reviewers; run the first tabletop with an AI incident (prompt injection leading to data exfiltration; rogue agent action).

Phase 5. Detect and improve (continuous)
14. Monitoring rules live; monthly review of agent anomalies and shadow AI metrics.
15. Red team T3 systems at least annually and on major model change.
16. Re run the scan every six months; report movement to the board.

7. Intake and gates for a new AI built application #

This is the path for anything from a Copilot workflow to a vibe coded internal tool. Six gates, each a single question with a yes or no answer.

Definition of Secure for vibe coded software (minimum, tier T1 and up):

• Code in version control, reviewed by a second person or an independent review agent with security instructions.
• No secrets in code or prompts; all credentials from the secrets manager.
• All model calls through the gateway.
• Input validation and output encoding for anything rendered or executed.
• Dependency and MCP server allow list respected; nothing installed from an unreviewed source.
• Tests for prompt injection and for the three most damaging misuse paths identified in the threat model.
• Runs under its own identity with the least access that makes the use case work.

8. The individual track #

For professionals, builders and executives who want their own AI use hardened and compliant.

Ten rules for secure personal AI use

1. Use accounts under your organisation's SSO, never personal accounts, for anything touching work data.
2. Know the data terms of every tool: does it train on your input, where is it stored, how long. Turn off training where possible.
3. Never paste secrets, credentials, customer identifiers or unreleased financials into a prompt.
4. Treat every document, web page and email an AI reads as untrusted input; indirect prompt injection via email and calendar invites is a documented attack.
5. Give agents the minimum permissions for the task and revoke afterwards; prefer read only until you have seen it behave.
6. Vet MCP servers, plugins and extensions the way you would vet a browser extension: publisher, source, permissions, recency.
7. Keep a human release step for anything that sends, pays, deletes or publishes.
8. Verify outputs that will be acted on; AI written code and figures are drafts until checked.
9. Disclose AI generated content where the law or your organisation requires it; the Article 50 transparency duties are live.
10. Follow the approved catalogue and report what is missing from it instead of routing around it.

Builder's checklist for a personal or small team AI app

• Separate development and production data; never test on live personal data.
• Use the organisation's gateway and identity, or if none exists, a dedicated API key with spending and scope limits.
• Sandbox anything the agent executes.
• Log every tool call.
• Ask who the AI Act deployer is before it goes beyond your own desk.

9. Quick scan design (v0.3) #

Structure. The estate gate from section 3.0 runs first and produces a cap. Then eight domains, 44 questions (five to seven per domain). Each question measures one construct; where the v0.1 question asked two things, the second thing moved into the scoring anchor. Questions carry an anchor strength from the traceability matrix in section 12: A for an explicit legal obligation, B for a certifiable standard control, C for authoritative framework guidance, D for practice consensus. Every question in v0.2 is A, B or C.

Scoring rule per question. Five behavioural anchors, the same for every question:

A score of 3 or 4 cannot be awarded on a verbal answer; the assessor must have seen the artefact. In self service mode, every item is capped at 2 unless evidence is uploaded. This single rule does more for inter rater reliability than any amount of question wording.

Applicability. Questions marked conditional are answered N/A with a stated reason when the condition does not apply. Domain score is the mean of applicable questions. A domain with more than half its questions N/A is reported as "insufficient coverage", not scored.

Weighting. Default is equal weight per domain. The v0.1 weighting of 1.5 on D1, D3 and D6 had no evidential basis and is withdrawn. A regulatory profile weighting is available once the traceability matrix is frozen: domain weight proportional to the number of A strength anchors that apply to the organisation's regime (Cbw entity, DORA entity, public body, unregulated). The derivation is published with the score so a client can see why their weights differ from another sector's.

Estate cap (v0.2). The v0.1 sum based cap allowed strong scores on some foundations to compensate for a missing one, which contradicts the logic that foundations are necessary conditions. The revised cap: if any of E1 (identity), E3 (egress) or E5 (logging) scores 0, every domain is capped at level 1. If any of E4, E6 or E7 scores 0, D3, D4 and D6 are capped at level 2. Below that, the sum rule applies: total under 8 caps at level 1; 8 to 12 caps at level 2.

Role divergence. Executives answer D1, D5, D7, D8; security answers all; builders answer D2, D3, D4, D6. Where roles disagree by two or more points on a question, the lower score stands and the divergence is reported as a finding. Divergence is never averaged away.

Question set v0.3 (C = conditional)

D1 Governance and accountability

1. Is there a named member of the management body accountable for AI risk, with that accountability recorded? Q1
2. Is there one inventory of AI systems, agents and MCP servers, with an owner for each entry? Q2
3. Does each inventory entry carry an autonomy tier and an AI Act classification with the reasoning recorded? Q3
4. Is AI literacy delivered and recorded for each role that uses, builds or oversees AI? Q4
5. Has the management body received and discussed an AI security report in the past twelve months? Q5
43. Is the AI use policy enforced through tooling, such as the gateway, data loss prevention or the approved catalogue, rather than relying on people reading it? Q43
44. Has the management body set an AI risk appetite per autonomy tier, including a list of never events? Q44

D2 Data security and provenance

6. Is data classification machine readable and enforced on what enters prompts, retrieval indexes and agent memory? Q6
7. Do all calls to external models pass through a gateway that authenticates, inspects and can block? Q7
8. Are retrieval and training sources allow listed and integrity checked against poisoning? Q8
9. (C: only if the organisation generates synthetic content for others) Is AI generated content marked or disclosed as Article 50 requires? Q9
10. Can one output be traced to its source data, model version, prompt and approving human? Q10

D3 Identity and access for humans and agents

11. (C: only if autonomy T2 or above is in production) Does every agent have its own identity in the identity provider, distinct from users and shared service accounts? Q11
12. (C: only if autonomy T2 or above is in production) Are agent credentials short lived and scoped to a task? Q12
13. (C: only if autonomy T2 or above is in production) Is the delegation chain (user to agent to tool) recorded so that any action can be attributed to a human principal? Q13
14. Do high impact actions require approval by a competent person with the authority to intervene, and is that approval logged? Q14
15. Has agent access been reviewed against the equivalent human role and reduced where it exceeded it? Q15

D4 Secure AI application development

16. Does AI generated code pass through the same version control, review and security scanning as human code? Q16
17. Is a threat model covering prompt injection, output handling, tool misuse and data disclosure mandatory before build? Q17
18. Does AI generated or agent driven code execute only in a sandbox without standing credentials? Q18
19. Are models, MCP servers, plugins and prompt templates allow listed, version pinned and recorded in a bill of materials? Q19
20. Is there a defined intake path for citizen built AI applications, and is it used? Q20
21. Are AI applications tested against adversarial inputs (injection, jailbreak, tool abuse) before release and after major model change? Q21

D5 Model and vendor assurance

22. Has every external AI provider passed due diligence covering training on customer data, retention, data location, subprocessors and exit? Q22
23. (C: DORA entities only) Are AI providers entered in the Register of Information with Article 30 contractual provisions? Q23
24. Is concentration risk on model and cloud providers assessed and accepted at the right level? Q24
25. Are models evaluated for capability, safety and robustness before adoption and on version change? Q25
26. (C: only if high risk candidates exist) Is provider documentation, including model cards and instructions for use, on file for regulated or high risk uses? Q26

D6 Runtime controls, monitoring and response

27. Are input and output guardrails deployed and their block events logged? Q27
28. Is every agent action logged in a tamper evident store and retained for at least the period the law requires? Q28
29. (C: only if autonomy T2 or above is in production) Do detection rules exist for agentic anomalies (unusual tool sequences, scope violations, volume spikes)? Q29
30. (C: only if autonomy T2 or above is in production) Has a kill switch that stops any agent or integration within minutes been exercised in the past quarter? Q30
31. Does the incident procedure cover AI incidents, including suspension of use, notification of the provider and the statutory reporting clocks? Q31
32. Do AI dependent processes have a continuity plan and fallback if the model or agent is unavailable? Q32

D7 Compliance and evidence

33. Is the AI Act role (provider, deployer, both) determined for each system, including cases where modification makes a deployer a provider? Q33
34. (C: only if high risk candidates exist) Is there a dated roadmap to the applicable high risk deadlines? Q34
35. Are impact assessments (DPIA, fundamental rights impact assessment where required, AI impact assessment) completed and linked to the inventory? Q35
36. Is compliance evidence generated by the controls rather than assembled for the audit? Q36
37. Is the AI management system scoped and documented against ISO/IEC 42001, whether or not certification is pursued? Q37

D8 People and transparency

38. Is there an approved AI tool catalogue, and does adoption data show people use it? Q38
39. Is shadow AI measured from network, identity or expense data at a defined cadence? Q39
40. Do builders know the intake path and the data rules, and is there a route for requesting tools that gets answered? Q40
41. (C: only if a system is used on workers or affected persons) Are workers and affected persons informed about AI systems used on or about them where the law requires? Q41
42. Is the effectiveness of AI security measures assessed on a defined cycle and fed back into the risk assessment? Q42

Bands (screening only). 0 to 1.0 Discover. 1.1 to 2.0 Decide and design. 2.1 to 3.0 Deliver. 3.1 to 4.0 Assure. Each band is named for the phase of section 6 to start in. Bands are not a certification statement and the report says so.

Individual scan. Twelve yes or no items drawn from section 8. Scored as a count; the three lowest become the personal action list. No band language.

1. Do you use AI tools for work only through your organisation's SSO account, never a personal one? (I1)
2. For every AI tool you use, do you know whether it trains on your input and where your data is stored, and have you turned training off where you can? (I2)
3. Do you keep secrets, credentials, customer identifiers and unreleased financials out of prompts, every time? (I3)
4. Do you treat documents, web pages and emails an AI reads as untrusted input, and check what it did with them before acting? (I4)
5. Do your agents get the minimum permissions for the task, read only until you have seen them behave, and revoked afterwards? (I5)
6. Do you vet MCP servers, plugins and extensions before installing them: publisher, source, permissions, recency? (I6)
7. Is there a human release step before anything an AI drafts is sent, paid, deleted or published? (I7)
8. Do you verify AI written code and figures before they are acted on? (I8)
9. Do you disclose AI generated content where the law or your organisation requires it? (I9)
10. Do you use the approved catalogue and report what is missing from it, rather than routing around it? (I10)
11. When you build with AI, does it go through your organisation's gateway and identity, or at least a dedicated key with spending and scope limits, with anything the agent executes sandboxed? (B2)
12. When you build with AI, do you keep test data separate from live personal data, log every tool call, and know who the AI Act deployer is before it leaves your desk? (B1)

10. Regulatory crosswalk #

Article references are to the AI Act as amended by the Omnibus and to the DORA regulation text; verify against the consolidated texts before client use.

11. Assumptions and open decisions #

• The blueprint assumes ISO 27001 or NEN 7510 as the existing baseline. For organisations without one, the Cbw is the forcing function and D1 through D3 come first.
• Deloitte branding, the cyberbenchmarker style peer baselines and the deck version follow once the question set is stable.
• Open decisions for you: whether the scan is self service (lead generation) or facilitated only; whether to weight domains by sector (public sector heavier on D7, financial services heavier on D5 and D6); and whether the individual track becomes a standalone Substack piece.

12. Validation of the quick scan #

12.1 What can and cannot be established on paper #

A score is trustworthy when three things hold. Content validity: each question measures a requirement that an authoritative source actually imposes. Reliability: two assessors looking at the same organisation produce the same score. Construct validity: the total behaves like the thing it claims to measure, so that organisations with higher scores have fewer AI security failures. The first can be established by tracing every question to its source and is done below. The second and third can only be established with data from real assessments, so section 12.5 sets out the protocol. Anyone who tells you a questionnaire is reliable before it has been piloted with independent raters is describing a hope.

12.2 Traceability matrix #

Anchor strength: A = explicit legal obligation for entities in scope; B = control in a certifiable standard (ISO/IEC 42001:2023 Annex A or ISO/IEC 27001:2022 Annex A); C = authoritative framework guidance (SAIF, OWASP, NIST, Five Eyes and UK NCSC). Legal references are to NIS2 Article 21(2) and Article 20 as transposed by the Cbw, the AI Act with deployer duties in Article 26, DORA and GDPR. ISO 42001 references use the nine control objectives A.2 to A.10 and their 38 controls.

Count: 40 questions anchored at A, 4 at B, 0 at C. Depth items: 16 at A, 1 at C. No question rests on practice consensus alone. Depth questions L1 to L5, T1 to T3 and provider questions R1 to R9 are listed after the main set.

12.3 Defects found in v0.1 and what changed #

Double barrelled questions. Eight v0.1 questions asked two or three things at once (owner, tier and classification in one; logged and tamper evident in one; kill switch exists and is tested in one). A respondent who has two of three cannot answer honestly on a single scale, and two assessors will split differently. Each was reduced to one construct, with the remaining elements moved into the scoring anchor where they belong: a score of 3 on question 2 requires the inventory to exist and be enforced; the owner field is the artefact.

Conditional questions scored as universal. The DORA register question, the GPAI documentation question, the high risk roadmap and the synthetic content question do not apply to every organisation. Scoring them as 0 for an organisation outside scope penalised the wrong thing. v0.2 marks them conditional with N/A handling.

A date in the question. The roadmap question named December 2027. Dates belong in the guidance, not the item; the item now refers to the applicable deadlines.

Unanchored weights. The 1.5 weighting on D1, D3 and D6 was an opinion presented as a method. It is withdrawn. The regulatory profile weighting derives from the matrix and is reproducible.

A cap that could be bought. The sum based estate cap let an organisation with no egress control but strong secrets management pass the threshold. Necessary conditions do not sum. The revised cap names the foundations that cannot be absent.

Generic scale anchors. "0 to 4 matching the maturity levels" left each assessor to decide what a 3 meant. The behavioural anchors and the evidence rule in section 9 replace that.

Coverage gaps against the source frameworks. Checking the v0.1 set against the ten NIS2 Article 21(2) measures, the twelve Article 26 deployer duties and the nine ISO 42001 control objectives found the following absent or weak, now added: business continuity for AI dependent processes (21(2)(c), DORA Art. 11 and 12), now question 32; effectiveness assessment as a loop (21(2)(f)), now question 42; adversarial testing before release (Art. 15, ISO 42001 A.6.2.4, DORA testing), now question 21; competence and authority of the overseeing person (Art. 14, Art. 26(2)), now in question 14; six month log retention (Art. 26(6)), now in question 28; suspension of use and provider notification (Art. 26(5)), now in question 31; information to workers and affected persons (Art. 26(7) and (11)), now question 41; provider versus deployer role determination including the substantial modification trap (Art. 25), now question 33.

Questions with weak anchoring, removed or rewritten. "Do security and AI teams share a backlog" and "is there a feedback route that gets answered" had no anchor above practice consensus. The first is dropped; the second is merged into question 40 under ISO 42001 A.3.3.

Still assumed rather than tested. Two NIS2 measures are treated as baseline and not scored: cryptography (21(2)(h)) and multi factor authentication (21(2)(j)). The scan assumes an ISO 27001 grade baseline exists. If a client lacks one, the estate gate will show it through E1 and E4, but the scan does not measure MFA or cryptography directly. This is a deliberate scope decision and the report states it.

12.4 Known limitations that remain #

• Five or six items per domain is enough for a screening profile, not for a precise domain score. Report domain scores to one decimal at most and never rank organisations on a single domain.
• The A strength anchors are legal obligations for entities in scope. For an organisation outside the Cbw, DORA and the AI Act's high risk tier, the same questions remain good practice but the "A" label overstates their force. The regulatory profile weighting handles this; the report must name the regime it assumed.
• The matrix cites ISO 42001 Annex A controls by number from the 2023 edition; EN ISO/IEC 42001:2026 carries the same control set but page and clause references should be re checked against the purchased text before client use.
• OWASP agentic items are cited by name, not number, because the 2026 list is recent and numbering in secondary sources varies.
• Nothing here has been tested on a real organisation.

12.5 Validation protocol before v1.0 #

1. Expert content validation. Two round Delphi with at least seven reviewers spanning legal (AI Act, Cbw, DORA), security architecture, and at least one supervisor side or auditor perspective. Each reviewer rates every question for relevance (1 to 4) and clarity. Items where fewer than 78% of reviewers rate relevance 3 or 4 are revised or dropped. Reviewers also challenge every anchor in the matrix.
2. Cognitive interviews. Five respondents per role (executive, CISO, builder) talk through each question aloud. Any question interpreted differently by two respondents is rewritten.
3. Two rater pilot. Eight to twelve organisations across the four regimes, each assessed by two independent assessors on the same evidence. Compute agreement per question (weighted kappa) and per domain (intraclass correlation). Target 0.7 or better; items below 0.6 after one revision are dropped.
4. Convergent check. Compare domain profiles with the organisation's most recent NIS2 gap assessment and, where available, the SAIF Risk Self Assessment. Large disagreements are investigated, not averaged.
5. Freeze and version. Publish v1.0 with the matrix, the weights and their derivation. Every score carries the version number. Re validate on any change to the AI Act, the Cbw or ISO 42001, and annually regardless.

Until step 3 is complete, every report states that the score is a structured screening result from a validated content framework, not a measured reliability instrument.

12.6 What changed in v0.3 #

v0.3 adds to the validated v0.2 set. None of the additions has been through the protocol in 12.5 yet, and each new item carries that note in the model.

• One ladder of names. The maturity levels in section 4 now use the names of the answer scale: Not in place, Informal or partial, Defined, Enforced, Assured. The bands are named for the phase of section 6 to start in: Discover, Decide and design, Deliver, Assure. Thresholds are unchanged.
• Two questions for gaps in D1. Q43 asks whether the AI use policy is enforced through tooling (end state D1.3, which no v0.2 question measured). Q44 asks whether the management body has set an AI risk appetite per tier with never events (section 6, step 5, now end state D1.6).
• Provider questions. R1 to R9 cover the AI Act provider obligations for high risk systems, as promised in 13.3, with a new end state bullet D7.6.
• One system, end to end. A checklist for the highest tier system in production, drawn from sections 5 and 7. It gives intake gate G6 and definition of secure items 2 to 4 a question for the first time.
• Dependencies. Q2, Q19 and Q22 now depend on E3, Q22 on E7, and Q29 on E7, so every domain depends on a critical foundation and D3, D4 and D6 each depend on E4, E6 or E7. L3 now measures D4.2 (tested against adversarial inputs) instead of D6.3.

13. The scan tool: evidence model, gating and data design #

13.1 Evidence classes #

Every uploaded artefact is classified into one of four classes at upload. The class, not the file, decides the maximum score it can support.

Rules the tool enforces:

• No evidence, maximum score 1 in self service mode; in assessor mode a verbal account supports 1 only.
• A DOC alone never supports 3, whatever the score claimed. The tool lowers the score and tells the respondent why.
• Every artefact carries a date; the tool rejects undated screenshots and asks for a re-export with the system clock visible.
• ATT artefacts older than twelve months support 3, not 4.
• The respondent claims a score; the tool computes the evidence supported maximum; the lower of the two stands. In assessor mode the assessor can raise it within the evidence supported maximum with a written reason.

13.2 Evidence specification per question #

For each question: the artefact that supports 3 (SYS), the artefact that supports 4 (ATT), and what is explicitly not accepted. Score 2 always takes the relevant DOC plus one REC instance.

13.3 Profile and gating #

The scan opens with a profile. Ten questions, each driving gates downstream.

Gating rules:

• Q9 shown only if P9 is yes. Q23 only if P4 is yes. Q26 and Q34 only if P7 is yes. Q41 only if the inventory contains a system used on workers or affected persons (asked at Q3).
• Q11, Q12, Q13, Q29 and Q30 are shown only if P8 is T2 or above. If T0 to T1 only, they are recorded as "not yet applicable" and the report includes a readiness note rather than a score; D3 and D6 are scored on the remaining items and flagged as partial.
• Size tier S (under 250): Q5 reads "the owner or management team" instead of "management body"; Q37 is replaced by a lighter item, "Is there a documented AI management approach with roles, policy and review, aligned to ISO 42001 without pursuing certification?"; evidence rule for Q2 accepts a controlled spreadsheet as the system of record for REC at score 2, and SYS at 3 still requires gateway or registry enforcement.
• Size tier L (1,000 and up) adds five depth questions, each scored on the same anchors:
  • L1 Are agent entitlements reviewed on a defined cadence per business unit? (NIS2 21(2)(i); ISO 27001 5.18)
  • L2 Is gateway policy consistent across all business units and clouds, with central policy and local enforcement? (SAIF harmonise platform controls)
  • L3 (DORA entities) Does threat led penetration testing scope include AI systems and agents? (DORA Art. 26)
  • L4 Is the AI registry integrated with procurement so that no AI purchase completes without an entry? (NIS2 21(2)(d); ISO 42001 A.10)
  • L5 Is shadow AI measured per business unit and reported to unit leadership? (NIS2 21(2)(i))
• P8 T3 adds three depth questions: whether every T3 system has a designated human overseer with authority to halt (Art. 14, Art. 26(2)); whether T3 systems were red teamed before go live (Art. 15); whether T3 systems have board level visibility (Art. 20 Cbw).
• Provider or both, with high risk candidates present, adds nine provider questions R1 to R9, one per obligation in AI Act Articles 9 to 17, 43 and 49. They are depth items, scored into their domains.
• Security and builder respondents also walk one system end to end: the AI system in production that may do the most on its own, checked against the minimum controls for its tier (section 5), the six intake gates and, for software built in house, the definition of secure (section 7). Yes, no or I don't know per item. The checklist is reported beside the score and feeds the plan; it does not change the domain scores.
• Depth questions are scored into their parent domain. The report shows the base score and the depth adjusted score separately so a large organisation is never advantaged by having more questions.

13.4 Flow #

1. Access via the portal token (existing KV token system on cyberbenchmarker). One token, one organisation, one assessment version. Tokens carry mode: self service or assessor.
2. Profile (P1 to P10). Saved on completion of each item.
3. Estate gate (E1 to E8), each with its readiness test, 0 to 2, evidence optional but the readiness test answer is recorded verbatim.
4. Domains D1 to D8 with gating applied. Each question shows: the question, the anchor with the source clause, the evidence specification for 3 and 4, the score selector, the evidence uploader, a notes field. Every change is saved immediately with a timestamp and the respondent identity from the token.
5. Depth questions where triggered.
6. Review screen: computed evidence supported maxima, claimed scores, the standing score, the cap, N/A items with reasons, and every question where the claimed score exceeds what the evidence supports.
7. Submit. The assessment is locked; a new version can be opened from it.
8. Assessor mode adds a review pass per question: accept, lower, or raise within the evidence maximum, with a mandatory reason. Role divergence is computed where more than one respondent token exists for one organisation.
9. Report: estate score, cap applied, domain profile, band, top gaps in section 3.0 build order, recommended stack from section 3.1 for the platforms in P10, the regime assumed, the version number and the wording from section 12.5.

13.5 Data model #

• organisation: id, name, profile (P1 to P10), created_at
• assessment: id, organisation_id, version, mode, status (open, submitted, reviewed), created_at, submitted_at
• respondent: id, assessment_id, token_id, role (executive, security, builder, assessor), created_at
• answer: id, assessment_id, question_id, respondent_id, claimed_score, evidence_max, standing_score, na_flag, na_reason, notes, updated_at (append only; every change creates a new row so the history is the audit trail)
• evidence: id, answer_id, class (DOC, REC, SYS, ATT), file_ref, original_name, mime, size, artefact_date, uploaded_at, sha256
• review: id, answer_id, assessor_id, decision (accept, lower, raise), score, reason, created_at
• gate_result: assessment_id, foundation_id (E1 to E8), score, readiness_answer, updated_at

Evidence files are stored separately from the database in EU jurisdiction object storage, encrypted at rest, named by hash not by original filename, with access only through signed URLs bound to the token and expiring within minutes. Retention is set per assessment and defaults to the engagement period plus twelve months; the respondent can request deletion, which removes files and leaves the hash and metadata in the audit trail. Uploads are limited to PDF, common office formats, CSV, JSON, PNG and JPEG, 25 MB per file, and are virus scanned before they are readable.

13.6 Backend target #

Front end: one self contained HTML application, deployable on Cloudflare Pages behind the existing portal, with every save going through a small API. Backend: a Cloudflare Worker with D1 for the tables above, R2 (EU jurisdiction) for evidence, and the existing KV token system for access and mode. The front end also works without the backend by keeping state in memory and exporting the full assessment as JSON, which is how it is previewed and how an assessor can run it offline in a client meeting and upload afterwards.