# 03 — Data, Security & AI Governance Plan

| | |
|---|---|
| **Version** | v1.0 (Final) |
| **Date** | 2026-08-10 |
| **Posture** | Proportionate governance for a non-heavily-regulated SME |
| **Companion docs** | 00 Overview · 01 Target Architecture · 02 Implementation Plan · 04 Benefits Realisation |

> This plan provides a governance operating model, not legal advice. The adopting organisation remains responsible for identifying the laws, contracts, industrial instruments, professional duties and sector requirements that apply to each use case.

## 1. Purpose and principles

Governance exists to make useful adoption repeatable and safe. It should reduce ambiguity, concentrate decision-making and keep control effort proportional to consequence.

1. **Accountability is named.** Every sanctioned AI system, source and production workflow has a business owner and an operational/control owner.
2. **Proportionality governs effort.** Controls scale with data sensitivity, affected-person impact, autonomy, transaction value, reversibility, scale, criticality and legal exposure.
3. **Identity and authority are explicit.** The organisation can identify the human initiator, automated workload and authority used for a consequential act.
4. **The model does not authorise itself.** Deterministic policy and transaction controls sit between model reasoning and side effects.
5. **Data use is purpose-bound and minimised.** Access to a large corpus or broad API is not justified merely because an agent could use it.
6. **Human control must be meaningful.** Oversight requires competence, context, time, authority, independence and a practical intervention route.
7. **Testing continues in production.** Offline evaluation is necessary but insufficient; overrides, complaints, failures, drift and impacts are monitored.
8. **Telemetry is metadata-first.** Sensitive content is not copied into a new observability repository by default.
9. **Policies are implemented.** Each policy maps to a setting, register, workflow, review, control test or evidence record.
10. **Incidents improve the system.** Staff can report mistakes and near misses without blame; serious matters are contained and escalated quickly.
11. **Users and affected people receive material information.** AI use, limitations and human-review routes are disclosed where relevant or required.
12. **Governance is simplified when it stops adding control value.** The model avoids a parallel bureaucracy detached from existing risk, IT, privacy, finance and people processes.

## 2. Governance operating model

| Role | Responsibilities |
|---|---|
| Executive Sponsor | Sets risk appetite; approves policy and material exceptions; owns major customer, workforce and risk decisions |
| AI Lead | Runs the governance cadence; maintains portfolio/register integrity; coordinates first-line assessments and evidence |
| Function Product Owner | Owns function outcomes, workflow portfolio, adoption and benefit evidence |
| Workflow Owner | Owns a production workflow’s purpose, controls, quality, cost, incidents, review and retirement |
| Security/IT Owner | Identity, secrets, SaaS posture, runtime security, logging, vendor security and incident response |
| Privacy/Data Owner | Purpose, lawful handling, classification, source authority, access, retention/deletion and privacy impact |
| People/Employment Owner | Workforce consultation, role impacts, recruitment/people use cases, discrimination and employee communications |
| Finance Partner | TCO, benefit evidence, transaction authority and segregation-of-duties alignment |
| AI Council | Approves moderate/high-impact systems, T2/T3 promotion, exceptions, major vendor/model changes and remediation priorities |
| All staff/contractors | Use approved tools, protect data, verify work as trained and report incidents/near misses |

### 2.1 Decision rights

| Decision | Default approver |
|---|---|
| Low-impact T0/T1 use case using an already approved tool and data boundary | AI Lead + workflow/data owner |
| Moderate-impact use case, new C3 data source or customer-visible workflow | AI Council |
| High-impact use case, C4 processing, people-affecting system or material legal/financial action | AI Council + Executive Sponsor and specialist advice as required |
| T2 production approval | AI Council or delegated production-readiness authority within documented risk appetite |
| Any T3 action class | AI Council; sponsor where impact is high or policy requires |
| New model/provider/tool tier | Security/Privacy owners + AI Lead; council for material dependency or higher-impact use |
| Policy exception | AI Council, named owner, compensating controls and expiry date |
| Emergency pause/kill | Workflow owner, Security/IT, AI Lead or incident commander according to playbook—no council meeting required |

Low-risk decisions may be delegated, but accountability and evidence may not be delegated away.

## 3. Minimum policy and register set

### 3.1 Policies

| Policy/standard | Purpose | Owner | Default review |
|---|---|---|---|
| Acceptable Use of AI | Approved tools, prohibited data/actions, verification, disclosure and incident reporting | AI Lead | 6-monthly or material change |
| Data Classification & AI Handling | C1–C4 labels, source, prompt, retrieval, output, storage and sharing rules | Security/Privacy | Annual or law/change |
| AI Use-Case & Impact Assessment | Intake, risk rating, impact triggers, approval and evidence | AI Lead / Privacy | Annual |
| Agent & Workflow Operating Standard | Tiers, identities, tools, policy enforcement, limits, operations, promotion/demotion and retirement | AI Lead / IT | 6-monthly |
| Model, Tool & Vendor Standard | Due diligence, approved list, data terms, controls, cost, change and exit | Security/Commercial | Annual and renewal |
| Evaluation & Release Standard | Test design, evidence, change classification, production monitoring and rollback | AI Lead / Engineering | 6-monthly |
| Logging, Monitoring & Records | Metadata schema, sensitive-content policy, retention, access and business-record treatment | Security/Privacy | Annual |
| AI Incident Response | Detection, severity, containment, evidence, notification, communication, restoration and learning | Security/IT | Annual + after incident |
| Human Oversight & Transparency | Approver competence/load, disclosure, contestability, accessibility and escalation | AI Lead / People | Annual |
| Exceptions & Retirement | Exception expiry, compensating controls, decommissioning and evidence disposal | AI Lead | Annual |

### 3.2 Registers

The organisation maintains, at minimum:

1. **AI-system/tool register** — sanctioned employee AI, embedded SaaS AI, models, APIs and material features.
2. **Workflow/agent register** — every production workflow, action classes, tier, owner, identity, data, tools, model/version, controls, evals, limits, runbook and review.
3. **Source register** — grounded corpora/data sources, owner, authority, classification, allowed purposes, ACL model, freshness, retention and deletion.
4. **Vendor/subprocessor register** — contract, security, data-use, geography, model-change, support, cost and exit facts.
5. **Risk/impact assessment register** — current assessments, residual risks, decisions and reassessment triggers.
6. **Exception register** — exception, owner, rationale, compensating controls, expiry and closure.
7. **Incident/near-miss register** — class, severity, affected data/people, containment, notification decision, remediation and lessons.
8. **Benefits/TCO register** — maintained under Document 04 and linked to the workflow record.

A spreadsheet is acceptable for S1/S2 if access, versioning, ownership and review are reliable. Tool sophistication is not a governance outcome.

## 4. Data governance

### 4.1 Classification and AI handling

| Level | Examples | Default AI rule |
|---|---|---|
| **C1 — Public** | Published marketing, public product information, released policies | Any sanctioned tool; unsanctioned tools only where policy permits and no non-public context is added |
| **C2 — Internal** | General working documents, non-sensitive SOPs, internal communications | Tier A or B tools; approved grounding sources |
| **C3 — Confidential** | Customer data, non-public financials, contracts, ordinary employee data, support tickets, source code | Tier A only; purpose-bound access; registered source/workflow; ACL and retention controls |
| **C4 — Restricted** | Payroll detail, health/sensitive data, disciplinary/M&A material, highly sensitive legal data, credentials/secrets | Purpose-specific Tier A deployment only with high-impact approval; general-purpose chat prohibited; stronger minimisation/isolation/monitoring |

**Absolute rule:** credentials, API keys, access tokens, private keys, recovery codes and equivalent secrets MUST NOT be placed in model prompts, retrieval indexes, memories, eval datasets or content-bearing telemetry. They belong in a secrets system and are referenced indirectly.

Other C4 data may be processed only where the workflow is named and approved, the minimum fields are used, provider/deployment terms and location are acceptable, access is isolated, content logging is disabled or specifically controlled, and an impact/privacy assessment supports the use.

Labels SHOULD be applied through Drive labels, Purview sensitivity labels or equivalent controls. Location defaults and ownership are more reliable than expecting every user to label every item perfectly.

### 4.2 AI tool tiers

| Tier | Definition | Mandatory requirements | Maximum default data |
|---|---|---|---|
| **A — Approved enterprise** | Contracted/approved service or deployment with sufficient administrative, data and security control | Due-diligence checklist passed; approved terms/configuration; identity/admin; incident and exit route; register entry | C3; C4 only by named-workflow exception |
| **B — Approved limited** | Useful tool with known limitations that are acceptable for low-sensitivity use | Owner, limited review, explicit permitted use, SSO/admin where available, no hidden expansion to C3 | C2 |
| **C — Unapproved/personal** | Personal accounts, public consumer tools or unreviewed extensions/plugins | No company non-public data; blocked/restricted where practical | C1 only |

A product does not become Tier A solely because it states that customer data is not used for training. Retention, human review, subprocessors, location, access, logs, model changes, IP, service levels, security and exit also matter.

### 4.3 Permission hygiene

1. **Discover** — at least quarterly for material estates: external/public links, broad groups, orphaned drives/sites, stale access, risky OAuth grants and shared accounts.
2. **Prioritise** — risk-rank by classification, audience, volume, owner and whether the source is AI-grounded.
3. **Remediate** — C3/C4 and AI-grounded findings within a short defined SLA; lower-risk findings within a proportionate SLA.
4. **Prevent** — safe sharing defaults, allowlisted external collaboration where appropriate, owner at creation and controlled high-sensitivity locations.
5. **Verify** — before grounding, run adversarial access tests using representative identities; re-test after material permission or retrieval changes.
6. **Propagate** — define and test how source access revocation, deletion and retention expiry reach indexes, caches and derived stores.

A knowledge system that copies content under a broad service identity and filters only in the user interface is not permission-correct.

### 4.4 Data minimisation and purpose limitation

For each model/retrieval/tool step:

- identify the minimum fields and time range required;
- use purpose-built read models or field-level projections where practical;
- exclude unrelated free text, attachments and historical records;
- redact or tokenise direct identifiers where the task can still work;
- prevent output from being reused for a new purpose without assessment; and
- prohibit persistent “memory” for C3/C4 content unless explicitly required, owned, accessible, correctable and deletable.

### 4.5 Records, retention and telemetry

Different artefacts have different purposes and schedules.

| Artefact | Default treatment |
|---|---|
| Sent communication, filed document, approved decision or executed transaction | Business record; same schedule as human-produced equivalent |
| Proposed action and T2 approval | Retain with or link to the resulting business record for the applicable audit period |
| Consequential action event metadata | Starting default: at least 24 months, unless law/business schedule requires longer or risk supports shorter |
| Operational trace metadata | Starting default: ~90 days online, with aggregated trends retained longer as needed |
| Raw prompts, retrieved passages, tool arguments/results and model outputs in telemetry | **Off by default**; if approved for debugging/evaluation, minimise/redact, tightly restrict and retain for the shortest practical period (often 7–30 days) |
| Evaluation datasets | Versioned and retained while needed for assurance; personal/confidential data minimised and access-controlled |
| Hidden model reasoning / chain-of-thought | Do not request or retain as an audit requirement; retain final rationale, evidence and policy decisions instead |

These are model defaults, not universal legal periods. The organisation documents the purpose, authority, access and deletion method for each log class.

### 4.6 Residency, transfer and deletion

- Record provider processing/storage locations and material subprocessors.
- Match residency and transfer controls to applicable law, customer contracts and data classification.
- Test tenant/export deletion and contract termination deletion for material vendors.
- Define cache, embedding, index, backup and evaluation-copy deletion behaviour—not only source deletion.
- Maintain a data-flow record for C3/C4 production workflows.

## 5. AI-specific governance

### 5.1 Use-case intake and risk rating

Every material workflow completes the intake template in §8.1. Rate each dimension Low, Moderate or High; the overall rating is normally the highest dimension unless an approved method justifies otherwise.

| Dimension | Low | Moderate | High |
|---|---|---|---|
| Data | C1–C2 | C3 | C4 or sensitive data at scale |
| Autonomy | T0–T1 | T2 | T3 or open-ended delegation |
| Effect on people | No material individual effect | Advice/interaction may influence a person | Decision or material influence on rights, access, employment, price, service or reputation |
| Reversibility | Immediate/complete | Reversible with effort or delay | Irreversible, difficult to detect or difficult to remediate |
| External/transaction exposure | Internal, informational | Customer-visible or low-value transaction | Financial/legal commitment, public statement or high-value action |
| Scale/criticality | Small, non-critical | Repeated or operationally important | Large-scale, systemic, safety/continuity critical |
| Novelty/dependency | Mature approved pattern | New model/source/tool or material dependency | Unproven architecture, opaque third party or cascading dependencies |
| Legal/contract status | Clearly permitted | Conditions/notice required | High-risk/prohibited/uncertain use or specialist advice required |

**Approval:** Low → AI Lead/owners; Moderate → council; High → council + sponsor and specialist input as appropriate. T3 is not automatically prohibited for every high-rated system, but the burden of evidence and control increases materially; many high-impact decisions will remain human.

### 5.2 AI impact assessment

Complete an AI impact assessment, proportionate to ISO/IEC 42005-style questions, where a system:

- makes or materially informs decisions about individuals;
- may create differential outcomes across groups;
- operates at material scale or in a power-imbalanced context;
- is customer/public-facing and may mislead or materially influence behaviour;
- combines data in a novel way or infers sensitive attributes;
- creates material safety, financial, legal, environmental or societal effects; or
- is designated Moderate/High by the intake.

The assessment covers:

`purpose · affected people/groups · intended benefit · foreseeable use/misuse · data and proxy risks · error/harm pathways · accessibility · transparency · human control · contestability · monitoring · residual risk · decision`

A DPIA/privacy assessment may be required as well. One does not automatically replace the other.

### 5.3 Autonomy controls

| Control | T0 Retrieve | T1 Draft | T2 Act with approval | T3 Autonomous within policy |
|---|---|---|---|---|
| Principal | Delegated user or read-only workload | Delegated user or workload | Dedicated workload plus initiator attribution | Dedicated workload; no shared human session |
| Authority | Read/search/classify only | No consequential side effect | Exact approved typed action | Only approved action class within policy |
| Human role | Verify where task requires | Human independently sends/commits/decides | Competent person approves before execution | Human supervises portfolio, exceptions and sampled outcomes |
| Policy enforcement | Source ACL and read scope | Data/tool/output constraints | Runtime identity, value, SoD, precondition and action checks | Same as T2 plus hard caps and auto-pause |
| Evaluation | Retrieval/task fitness | Representative offline + pilot | End-to-end, security and controlled-live evidence | Sustained T2 evidence through complete business cycle and representative volume |
| Monitoring | Usage/quality spot review | Quality and user correction | 100% action event monitoring plus approval/exception trends | 100% automated monitoring plus risk-based human sample with minimum counts |
| Limits | Query/token/data limits | + output/channel limits | + transaction/action/rate/spend limits | + strict daily/period caps, anomaly and dependency circuit breakers |
| Change | Owner review | Regression on material change | Logged approval and regression before release | Council-approved material changes; canary/rollback |
| Review | At least annual | 6-monthly or change | Quarterly owner/control review | Frequent owner review; monthly council visibility initially |

#### 5.3.1 Promotion, demotion and pause

Promotion is recorded against the specific workflow version and action class. It requires evidence, residual-risk acceptance and a rollback owner.

A workflow is automatically paused or demoted on any defined trigger, including:

- evaluation or production error budget breach;
- Sev-1/2 incident or credible data-exposure concern;
- policy/permission change invalidating the approved scope;
- unexplained anomaly in action, cost, target, destination or tool use;
- monitoring or audit failure;
- material provider/model change without completed regression; or
- sampling, complaint or override evidence showing the control assumptions no longer hold.

Restoration requires containment, cause analysis, control/eval update and authorised release.

### 5.4 Workflow/agent lifecycle and change control

```text
Propose → assess value/risk/impact → design authority and controls
→ build/configure → evaluate → controlled pilot → production-readiness review
→ register/approve tier → operate/monitor → change/promote/demote → retire
```

The authoritative register record includes:

- system/workflow ID, name, business purpose and prohibited uses;
- owners and affected user/customer populations;
- environment and service dependencies;
- human initiator and workload identity model;
- data sources, classifications, retention and legal/impact assessment;
- tools/actions, scopes and policy limits;
- model/provider/version/configuration and prompt/schema versions;
- tier by action class and promotion history;
- evaluation suite, latest results, production error budget and monitoring;
- SLO, budgets, exception queue, fallback, kill/restore and runbook;
- vendor/contracts and exit dependencies;
- benefit/TCO link; and
- last/next review and retirement status.

**Material changes** include prompts/system instructions, models/configuration, retrieval method or sources, schemas, tool allowlists, scopes, policy rules, approval design, data class, affected population, transaction limits and deployment region. They trigger proportionate regression and approval.

### 5.5 Model, tool and vendor onboarding

The due-diligence checklist covers:

#### Data and privacy

- [ ] DPA/privacy terms and purpose are acceptable
- [ ] Customer data and metadata use, model training/improvement and human review are understood and configured
- [ ] Retention, deletion, backup and export behaviour is documented
- [ ] Processing locations, subprocessors and cross-border transfers are acceptable
- [ ] C3/C4 use boundaries and content-logging controls are clear

#### Security and administration

- [ ] Appropriate security assurance (e.g. SOC 2 Type II, ISO/IEC 27001 or compensating assessment)
- [ ] SSO, MFA, SCIM/lifecycle, role separation and audit export appropriate to use
- [ ] API/workload authentication and least-privilege scope supported
- [ ] Vulnerability, incident contact and breach-notification commitments
- [ ] Plugin/connector/tool governance and tenant controls

#### AI/product behaviour

- [ ] Models/features and material limitations identified
- [ ] Provider change-notification and deprecation practices understood
- [ ] Grounding, permissions, citation and admin behaviour tested—not assumed from marketing
- [ ] Evaluation, version pinning or rollback options adequate for criticality
- [ ] Safety/abuse and customer-support escalation route known

#### Commercial and legal

- [ ] Seat, usage, agent/tool and overage pricing modelled under expected and peak load
- [ ] Minimum term/commitment, renewal, suspension and price-change terms understood
- [ ] IP, confidentiality, output and indemnity terms reviewed where material
- [ ] Availability/support/SLA adequate for dependency
- [ ] Accessibility and regional availability considered
- [ ] Export, migration, termination and deletion path tested or credibly demonstrated

The vendor is assigned a tool tier and permitted data/action boundary. Approval is not permanent; renewal and material feature changes trigger review.

### 5.6 Human oversight standards

Meaningful oversight has six elements:

1. **Competence** — the person understands the domain, task, likely AI failure modes and their accountability.
2. **Context** — they see source evidence, proposed action, material differences, policy results, uncertainty/flags and consequences.
3. **Authority** — they are authorised under existing delegation and segregation-of-duties rules.
4. **Time and workload** — volume and interface permit real review; median review time, rejection and escalation are monitored.
5. **Independence** — high-consequence review is not distorted by targets that reward automatic approval.
6. **Intervention** — reject, edit, escalate, pause and correct are practical; affected people have a human route where appropriate.

A T2 approval card SHOULD show in one view:

`trigger/input · source evidence · proposed action/diff · validations/policy checks · material uncertainty/flags · consequence · approve/reject/edit/escalate`

For financial, legal, people and high-value customer actions, existing approval matrices and segregation of duties remain in force. AI cannot approve its own proposed action or satisfy a two-person control twice.

#### Fatigue controls

- set workflow-specific approval capacity based on volume and review time;
- batch only where each item remains reviewable and risk permits;
- rotate and provide backup approvers;
- monitor implausibly fast review, near-100% approvals, low evidence opening and overdue queues;
- move back to T1 or redesign if T2 creates an unsustainable approval factory; and
- never use poor approval quality as an argument to remove approval and call the workflow T3.

### 5.7 Transparency, disclosure and contestability

Provide information proportionate to context and law:

- employees know which tools are sanctioned, what is monitored and how AI affects their work;
- customers/users know when they are interacting with AI where that fact is material or required;
- AI-generated public or synthetic content is labelled where required by law, platform or policy;
- people affected by a material AI-assisted decision can obtain appropriate information and human review/complaint handling;
- disclosures explain purpose, role of AI and limits without implying certainty or hiding accountability; and
- accessibility and non-AI alternatives are maintained where necessary.

## 6. Security controls

### 6.1 Human and non-human identity

**Humans:** central IdP, universal MFA, phishing-resistant methods for privileged/high-impact roles, rapid joiner/mover/leaver controls, periodic access review and monitored risky OAuth grants.

**Interactive AI:** preserve user identity and source ACLs wherever the use is personal/delegated. Do not replace user permissions with a broad backend identity merely for convenience.

**Automated workflows:** dedicated workload identity per independently operated production trust boundary; minimal scopes; short-lived credentials or workload federation where supported; separate identities by environment; no shared human accounts or browser sessions.

**Attribution:** record both the human initiator and executing workload when a human triggers an automated action.

### 6.2 Policy enforcement and side-effect boundary

A model may produce a **typed proposed action**. Before execution, a deterministic control validates:

- authenticated principal and initiator;
- approved workflow/environment/version;
- action allowlist and tool version;
- data classification and permitted purpose;
- role/delegation and segregation of duties;
- transaction value/rate/time/recipient limits;
- current business-record preconditions;
- schema, sanitisation and destination; and
- whether human approval is required and still valid.

The policy decision and rule version are logged. Prompt instructions, model confidence or an MCP tool description are not an authorisation decision.

### 6.3 LLM and agentic threat controls

This control map should be maintained against both the current **OWASP Top 10 for LLM Applications** and **OWASP Top 10 for Agentic Applications**.

| Threat family | Primary controls |
|---|---|
| Prompt injection / agent-goal hijack | Treat retrieved, user and tool content as untrusted; separate instruction/data channels; context trust labels; least-privilege tools; deterministic policy; approval for consequential actions; adversarial tests. Pattern filters are supplementary only. |
| Tool misuse / excessive agency | Typed action schemas; explicit action allowlist; minimal scopes; transaction/rate/spend caps; sandbox; preconditions; no free-form shell/SQL/payment/HR execution |
| Identity and privilege abuse | Dedicated workload identity; delegated-user preservation; secure OAuth; no token passthrough; audience/scope validation; short-lived credentials; privileged access review |
| Insecure output handling | Parse and validate outputs; parameterised APIs/queries; HTML/content sanitisation; no direct model output into command, code, SQL or browser execution |
| Sensitive information disclosure | Purpose/field minimisation; ACL-aware retrieval; redaction; DLP/egress; content logging off; no secrets; response filtering where justified |
| Data, memory or RAG poisoning | Curated/owned sources; restricted write access; provenance; freshness/authority ranking; source-integrity monitoring; memory review/deletion; conflicting-source handling |
| Agentic supply chain / rogue tools | Approved tool/MCP registry; owner; version pinning; code review; SBOM/dependency scanning; signing/provenance where available; sandbox and egress limits |
| Insecure inter-agent communication | Avoid unnecessary multi-agent design; authenticate peers; typed messages; provenance; bounded delegation; no inherited broad authority; loop/cascade limits |
| Cascading failure / unexpected behaviour | Durable orchestration; state/step limits; recursion/loop caps; circuit breakers; exception queues; compensation; dependency isolation; auto-pause |
| Model denial-of-service / runaway cost | Input/output size limits; quotas; timeouts; concurrency controls; per-workflow budgets; anomaly alerts and hard stop |
| Overreliance and human-factor failure | Task-specific training; uncertainty/evidence; outcome evals; meaningful oversight; complaint/appeal; quality guardrails and periodic manual benchmark |
| Model/version drift | Approved version/config; regression tests; canary; provider-change monitoring; rollback/demotion and reapproval |

### 6.4 MCP and tool-adapter security

MCP is not a security boundary. Production MCP servers/clients MUST use the current specification and security guidance appropriate to their transport, including robust OAuth-based authorisation for HTTP deployments where supported.

Required controls:

- approved server registry, owner and business purpose;
- explicit client/server trust and endpoint allowlist;
- audience-bound, scoped and short-lived tokens; no credential or token passthrough;
- defence against confused-deputy, redirect and authorisation-server mix-up risks;
- per-action scopes and deterministic policy enforcement outside tool descriptions;
- schema validation and safe handling of tool outputs;
- version pinning, review, dependency/SBOM and change notification;
- tenant/data boundary validation and no implicit cross-user data sharing;
- egress, rate, action and spend limits;
- audit correlation across client, server, policy and downstream system; and
- rapid server/action disable capability.

The same principles apply to proprietary tool/function interfaces.

### 6.5 Logging and audit

Minimum consequential-action metadata:

```text
trace_id · timestamp · environment · workflow/version · workload identity
human initiator (if any) · model/provider/version/config · prompt/schema version
retrieval source references · tool/action/version · proposed-action reference/hash
policy decision/rule version · approval/approver · result/reconciliation
exception/override · latency · usage/cost · business-record/evidence references
```

Controls:

- raw content capture disabled by default;
- explicit purpose and approval for content-bearing traces;
- field redaction/tokenisation before export where practical;
- separate access roles for operators, security, evaluators and business users;
- encryption, integrity and retention controls on the log destination;
- no secrets, full credentials or hidden reasoning;
- quarterly reconstruction of representative T2/T3 actions; and
- alerting on missing logs for workflows that require complete action evidence.

Optional higher-assurance controls include append-only/WORM storage, signed events or hash chaining, but only where the threat/risk justifies the operational cost.

### 6.6 Runtime, endpoint and egress controls

- managed devices/browsers for users handling C3/C4 where proportionate;
- restrict unapproved browser extensions, plugins and OAuth apps;
- code-first runtimes use separate networks/projects/subscriptions and minimal outbound destinations;
- sandbox model-generated code and untrusted files;
- do not expose internal administrative endpoints or broad network access to an agent;
- dependency and container scanning for custom components;
- secure configuration, patching and backups aligned to existing cyber program;
- apply the Essential Eight or another recognised cyber baseline according to risk—do not assume one maturity level fits every SME; and
- test manual fallback and recovery as a cyber-resilience control.

### 6.7 Secure development and release

For custom components and workflow code:

- version control, peer review and protected production branches;
- secrets scanning, dependency/SBOM and vulnerability scanning;
- unit/integration/end-to-end and adversarial tests;
- reproducible configuration and environment separation;
- signed/provenanced builds where practical;
- release approval proportional to tier;
- canary/feature flag/rollback for material changes; and
- supported runtime, dependency and model deprecation monitoring.

## 7. Incident response

### 7.1 Incident classes

| Class | Examples | Indicative severity |
|---|---|---|
| Data/privacy exposure | Wrong-user retrieval, C3/C4 disclosure, unapproved processing, telemetry leak | Sev 1–2 |
| Unauthorised/incorrect action | Outside-scope write, wrong recipient/amount/status, bypassed approval | Sev 1–2 |
| Injection/tool compromise | Untrusted content hijacks goal or tool; malicious/rogue MCP server | Sev 1–2 |
| People/impact harm | Unfair or misleading decision/influence, inaccessible process, denied review | Sev 1–2 depending on impact |
| Quality regression | Material hallucination, extraction/routing collapse, stale source causing error | Sev 2–3 |
| Operational/cascading failure | Loop, duplicate/partial transactions, dependency outage, backlog | Sev 2–3 |
| Runaway cost/abuse | Budget breach, credential misuse, uncontrolled usage | Sev 2–3 |
| Shadow-AI exposure | Company data in unapproved tool/account | Sev 2–3 based on data and exposure |

The organisation should align severity definitions with its existing incident framework rather than create incompatible parallel terminology.

### 7.2 Response flow

```text
Detect/report → contain (pause/kill/revoke/block) → preserve evidence
→ assess data, people, transaction and dependency blast radius
→ correct/reverse/notify users as operationally required
→ determine legal, privacy, contractual, employment and customer notification
→ remediate controls/data/evals → controlled restore → post-incident learning
→ update registers, assessments, runbooks and benefit/disbenefit records
```

### 7.3 Immediate containment authority

Named incident roles may pause a workflow, revoke its identity, disable a tool/server, block a source or revert to manual operation without prior council approval. Restoration follows authorised change control.

### 7.4 Drills

- workflow-level pause/kill and manual fallback: at least quarterly for consequential T2/T3;
- data-exposure or injection tabletop: at least annually, and after material architecture change;
- restore/reconciliation test: according to workflow criticality; and
- evidence reconstruction: quarterly sample.

## 8. Templates

### 8.1 Use-case intake

```text
Workflow name / owner / function / version
Business problem, current process and baseline
Target users and people/customers affected
Outcome, unit cost and kill criteria
Data sources, fields, classifications, owner and allowed purpose
Model/provider, tools/actions, identity and scopes
Autonomy tier by action class
Reversibility, transaction/external exposure, scale and criticality
Privacy/PII and AI-impact triggers
Applicable jurisdictions, customer terms and professional duties
Human oversight, disclosure, review/appeal and accessibility
Evaluation, production monitoring and error budget
SLO, exception/fallback, kill/restore and incident owner
TCO/benefit link
Risk rating → approval path → decision/review date
```

### 8.2 AI impact assessment

```text
System/workflow and decision role
Affected individuals/groups and context/power relationship
Intended benefits and evidence
Foreseeable normal use, misuse and out-of-scope use
Data, proxies, inference and representativeness
Error types, distribution, severity and detectability
Fairness/non-discrimination and accessibility considerations
Transparency, explanation and contestability
Human authority, competence, workload and intervention
Security, privacy, safety and dependency pathways
Monitoring, complaint and remediation plan
Residual impacts, mitigations, decision and reassessment trigger
```

### 8.3 Workflow/agent register record

```text
ID / name / owner / purpose / prohibited use / environment
User/affected populations
Human initiator and workload identity
Data/source/classification/retention
Tools/actions/scopes/policy limits
Model/provider/version/config; prompt/schema versions
Tier by action class and promotion history
Eval suite/results/error budget/production monitoring
SLO/budgets/limits/exception queue/fallback/kill/restore
Impact/privacy/vendor/contract links
Runbook/support/incident owner
Benefit/TCO link
Last review / next review / status / retirement record
```

### 8.4 Exception record

```text
Exception ID / policy/control / workflow/vendor
Reason standard position cannot be met
Risk and affected data/actions/people
Compensating controls
Owner and approver
Effective date / expiry / review trigger
Remediation or exit plan
Closure evidence
```

## 9. Assurance and framework alignment

### 9.1 Reference posture as at 10 August 2026

- **Australia:** use the National AI Centre’s six Essential AI Practices as the local baseline: accountability, impact understanding, risk management, essential information, testing/monitoring and human control.
- **NIST:** map governance to the current AI RMF 1.0 functions—Govern, Map, Measure, Manage—and the NIST AI 600-1 Generative AI Profile. AI RMF 1.0 is under revision, so maintain an update trigger rather than claiming timeless conformance.
- **ISO:** keep the management system **alignment-ready** with ISO/IEC 42001. Use ISO/IEC 42005-style AI system impact assessment for material people/societal impacts. Seek certification only where customer, market or risk value justifies it.
- **Security:** maintain control mapping to the current OWASP Top 10 for LLM Applications and Agentic Applications, plus the organisation’s existing cyber framework.
- **Australia cyber baseline:** use the ASD Essential Eight or another recognised baseline proportionately. A universal maturity-level prescription for all SMEs is inappropriate.

### 9.2 Key risk indicators

Report trend, target and overdue action for:

- percentage of sanctioned AI systems/workflows correctly registered;
- production workflows with current owner, eval and review;
- unresolved permission and risky OAuth findings by classification;
- DLP/privacy events and content-logging exceptions;
- evaluation/error-budget breaches and drift;
- approval workload, median review time, rejection/override and rubber-stamp indicators;
- T3 sample failures, auto-pauses and action-limit breaches;
- incidents/near misses by class and time to contain/restore;
- unapproved AI use and remediation;
- vendor/model material changes awaiting assessment;
- overdue exceptions and impact/privacy reassessments; and
- staff/approver competency coverage.

### 9.3 Assurance cadence

| Cadence | Assurance activity |
|---|---|
| Monthly | Council KRI review, incidents, exceptions, vendor/model changes and promote/demote decisions |
| Quarterly | Workflow register recertification, access/OAuth review, action reconstruction, permission test, T2/T3 control health and benefits/TCO review |
| Six-monthly | Policy, architecture, training and threat-model refresh |
| Annual | Structured framework assessment, impact/privacy portfolio review, incident exercise, material exit/export and resilience tests |
| Triggered | Material model/tool/source/scope/change, law/contract change, incident, new affected population or transaction class |

## 10. Jurisdiction and obligation watchpoints — August 2026

### 10.1 Australia

- The Privacy Act applies to AI handling personal information where the organisation is an APP entity. Use purpose limitation, minimisation, appropriate notice, security and vendor due diligence.
- From **10 December 2026**, Australian APP entities using personal information in automated decision-making that could significantly affect rights or interests will have additional privacy-policy transparency obligations. The 24-month program must identify affected workflows and prepare policy disclosures before commencement.
- Employment, discrimination, surveillance, consumer, professional and workplace-consultation obligations may apply even where there is no AI-specific law.
- Recruitment and people workflows require particular scrutiny; the base architecture prohibits automated ranking/rejection in the starter catalogue.

### 10.2 European Union

- The EU AI Act became generally applicable on **2 August 2026**, with earlier provisions already in force and specific later dates for some high-risk obligations.
- Following the 2026 AI Omnibus changes, high-risk rules for relevant stand-alone systems are scheduled from **2 December 2027**, and certain product-embedded systems from **2 August 2028**. Applicability must be checked against the final rules, role (provider/deployer), location, affected people and use case.
- AI literacy and relevant transparency duties may already apply. Employment and other Annex III-type systems should be designed now for inventory, impact, data, logging, human oversight and documentation even where the later date applies.

### 10.3 Other jurisdictions and contracts

Maintain a simple applicability matrix covering:

`where organisation operates · where affected people are · provider/deployer role · decision domain · data location · customer/sector terms · required notice/review/records · responsible owner`

Do not infer that a vendor’s “compliant” marketing transfers legal accountability to the adopting organisation.

## 11. Proportional operating burden

The objective is effective control, not a fixed governance headcount. Indicative steady-state coordination effort may be:

- S1: embedded duties, often 0.05–0.2 FTE plus MSP/legal specialist bursts;
- S2: roughly 0.2–0.6 FTE distributed across AI Lead, IT/privacy, finance and function owners; and
- S3: roughly 0.5–1.5 FTE equivalent across the portfolio, excluding engineering and ordinary operational supervision.

These are planning ranges, not benchmarks. High-impact or regulated portfolios require more; a low-risk managed-tool portfolio may require less. If review effort grows without reducing incidents, uncertainty or decision time, simplify the control design.

## 12. Primary reference points

- [Australian Government — Guidance for AI Adoption](https://www.ai.gov.au/staying-safe-and-responsible/essential-ai-practices/guidance-ai-adoption-implementation-guidance)
- [ASD/ACSC — Careful adoption of agentic AI services](https://www.cyber.gov.au/business-government/secure-design/artificial-intelligence/careful-adoption-of-agentic-ai-services)
- [OAIC — Privacy and commercially available AI](https://www.oaic.gov.au/privacy/privacy-guidance-for-organisations-and-government-agencies/guidance-on-privacy-and-the-use-of-commercially-available-ai-products)
- [OAIC — automated decision-making transparency consultation](https://www.oaic.gov.au/engage-with-us/consultations/consultation-on-guidance-for-transparency-in-automated-decision-making)
- [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework)
- [ISO/IEC 42001 — AI management systems](https://www.iso.org/standard/42001)
- [ISO/IEC 42005 — AI system impact assessment](https://www.iso.org/standard/42005)
- [EU AI Act implementation](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai)
- [MCP specification 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28)
- [OpenTelemetry — handling sensitive data](https://opentelemetry.io/docs/security/handling-sensitive-data/)
- [OWASP Top 10 for LLM Applications 2026](https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/)
- [OWASP Top 10 for Agentic Applications 2026](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/)