Skip to content

Risk classification

Every meaningful AI-governance decision sooner or later reduces to: "what is at stake if this goes wrong?" The risk classification matrix is how this framework answers that question consistently, across teams and across years, so that the same system gets the same answer regardless of who is asking.

The matrix is used to:

The five factors

Each factor is scored 1–4. Definitions:

Factor 1 2 3 4
Data sensitivity Public Internal Confidential Restricted / regulated
System impact Non-prod / dev Staging Prod, non-critical Prod, critical (revenue / safety)
User exposure Internal only, small Internal, broad External, limited (partners) External, customer-facing
Regulatory requirement None Internal standard Contract / SLA Legal / regulatory
Security requirement Standard Hardened Hardened + audit Highest + attestation

Scoring notes

  • Score for the highest class the system can see, not the average class. A "marketing site" that can also render authenticated customer pages scores against the authenticated experience.
  • Score for current state, not roadmap intentions. If the system will be customer-facing next quarter, re-classify when it actually is.
  • "Don't know" defaults to 4. Unknown risk is not-Low.
  • Multi-tenant systems score for the highest-impact tenant, not the average.

Tiering

Sum the five factors for a total between 5 and 20. Place the system in a tier:

Tier Score Implication summary
Low 5 Standard governance; AI assistants broadly permitted.
Medium 6–10 Standard governance + AI-specific reviews; V.E.R.I.F.Y. Level 1.
High 11–15 Enhanced review; Level 2; AppSec pre-merge; prompts logged.
Critical 16–20 Highest rigour; Level 3; no autonomous agent write access; AppSec approval per merge.

Why four bands

Three bands (low/medium/high) collapse the meaningful difference between "AppSec pre-merge" and "no autonomous agent write access". Both are high-rigour but are different controls. Four bands preserve that distinction.

Tier implications in detail

Low (score 5)

  • AI assistants: approved tools permitted under AUP.
  • Prompts / outputs: retained per default policy.
  • Verification: standard review.
  • Agents: permitted under standard guardrails.
  • Audit: standard evidence.

Medium (score 6–10)

  • Same as Low, plus:
  • Verification: V.E.R.I.F.Y. Level 1 (explicit AI-aware checks in review).
  • Prompts / outputs: logged with session identifier against PR.
  • Agents: permitted with tool-use logging; no write to Critical data classes.

High (score 11–15)

  • Same as Medium, plus:
  • Verification: Level 2 (AppSec pre-merge for security-sensitive paths; second reviewer outside immediate team).
  • Data: only data-category-approved tools may process source code; no third-party public tier tools.
  • Agents: no cross-system write action without runbook + approved exception.

Critical (score 16–20)

  • Same as High, plus:
  • Verification: Level 3 (named AppSec + Architect review for merges to Critical paths; dual-sign-off for security-critical primitives).
  • Data: data classes in the system are defaults-deny for AI tools unless explicitly permitted by addendum.
  • Agents: no autonomous write access to production. Agents are read-only or produce change proposals that humans apply.
  • Audit: prompts / outputs retained per regulatory retention; attested per audit cycle.

Worked examples

Example 1: Marketing CMS

  • Data sensitivity: 2 (public content + internal drafts).
  • System impact: 2 (prod, non-critical).
  • User exposure: 3 (external, limited; visitors).
  • Regulatory: 2 (GDPR for forms, standards).
  • Security: 2 (hardened).
  • Total: 11, High.

Example 2: Payments service

  • Data sensitivity: 4 (PCI).
  • System impact: 4 (prod, critical).
  • User exposure: 4 (external, customer-facing).
  • Regulatory: 4 (PCI DSS).
  • Security: 4 (highest + attestation).
  • Total: 20, Critical.

Example 3: Internal Slack bot for HR FAQs

  • Data sensitivity: 2 (internal policies).
  • System impact: 1 (internal productivity).
  • User exposure: 2 (broad internal).
  • Regulatory: 1 (none specific).
  • Security: 1 (standard).
  • Total: 7, Medium.

Additional worked examples are in the Risk classification workshop.

Process

Initial classification

Run the Risk classification workshop as part of Phase 0. Seed with the 10–20 systems that most clearly touch the factors above. A partial classification is fine; record what is unclassified as a follow-up.

Re-classification

  • Every 6 months as a scheduled refresh.
  • Whenever a system materially changes, e.g., becomes customer-facing, starts holding a new data class, moves region.
  • After an incident that revealed the classification was wrong.

Appeals

Teams may appeal a classification. The appeal:

  • Goes to the CoE Lead (or equivalent).
  • Is documented in a Decision Record.
  • Is reviewed alongside AppSec and the data owner.
  • Does not automatically grant a lower tier; the default is to keep the higher tier until the evidence for a lower one is on file.

Integration with AUP

The AUP references the classification, not the other way around. Example clause:

§3.2 Data Classes. Systems classified High or Critical may process source code only within approved enterprise-tenant tools listed in Appendix A. Customer PII must not be processed by any AI tool regardless of tier.

Integration with other frameworks

Framework How the tier is used
S.C.A.F.F. Higher tiers have stricter "Guardrails" clauses.
V.E.R.I.F.Y. Tier determines verification level (0–3).
S.H.I.E.L.D. Tier influences attack-surface focus in review.
C.L.E.A.R. Tier determines reviewer composition.
R.E.F.A.C.T. Tier drives caution during legacy modernization.

Anti-patterns

Don't

  • Don't classify by team. Teams change; systems persist.
  • Don't let "most of our systems are High" become normal. If the matrix is not discriminating, either the system inventory is biased or the matrix is being applied too pessimistically.
  • Don't collapse the bands. Specifically, don't merge High and Critical.
  • Don't freeze a classification for more than 6 months. The world moves. So do the classifications.
  • Don't treat "Low" as "ignore." Standard controls still apply; they are just the floor rather than the ceiling.

Further reading

  • NIST AI RMF, Govern function, especially G1.2 (risk tolerance) and G3.2 (risk prioritisation)1.
  • ISO/IEC 42001:2023, clauses 6 and 8: planning and operational risk treatment2.
  • EU AI Act, Title III: risk categorisation of AI systems for providers3 (note: the Act classifies AI systems; this matrix classifies the company's systems that use AI).

Next

  1. NIST, NIST AI 100-1: Artificial Intelligence Risk Management Framework, Jan 2023. ↩

  2. ISO, ISO/IEC 42001:2023. ↩

  3. European Union, Regulation (EU) 2024/1689 (AI Act), Jul 2024. ↩