Threat Assessment (TA) - Processes Domain

HAIAMM Assessment Questionnaire v3.5

Generated from cells/TA-Processes-L*.cell.json. Do not edit by hand. Canonical model: HAIAMM-v3.5-Framing.md · Handbook: HAIAMM-v3.5-Handbook.md.

---

Practice: Threat Assessment (TA) Domain: Processes Business Function: Building Purpose: Publish an archetype-level threat library for the Processes domain, tagged to the HAI TTPs and MITRE ATLAS, so threat modelling starts from a reusable baseline rather than a blank page. Scoring Model: Evidence + Outcome Metrics (see Scoring Methodology below)

---

Instructions

• Answer from current, implemented practice, not plans or aspirations.
• Each question has two components: Evidence (what you did) and Outcome Metrics (how well it worked).
• Levels are derived, never self-assigned. Record evidence and metric values; the level falls out of the scoring below.
• Silence is not a pass. A metric you cannot produce is left blank and counts as not met. Do not estimate.
• Answer progressively. Complete all Level 1 questions before Level 2.

Evidence grade

Record how each answer is known, not only what is claimed (v3.5 framing §6). A level claim is graded at its weakest field.

Grade	Meaning
E0	Asserted by a practitioner, unevidenced
E1	Asserted, with a link to a named artifact
E2	Emitted by a system as telemetry
E3	Machine-attested and independently checkable

---

Scoring Methodology

Tier	Score	Criteria
Fully Mature	1.0	Evidence complete + ≥3 outcome metrics meet targets
Implemented	0.67	Evidence complete + 2 outcome metrics meet targets
Partial	0.33	Evidence partially complete + <2 outcome metrics meet targets
Not Implemented	0.0	No substantive evidence of practice

Practice maturity level achieved = the highest level where all 3 questions score ≥ 0.67.

---

Maturity Level 1, Foundational

Objective: Publish an archetype-level threat library for the Processes domain, tagged to the HAI TTPs and MITRE ATLAS, so threat modelling starts from a reusable baseline rather than a blank page.

Prerequisite cells: SM-Processes-L1, PC-Processes-L1

Question L1.1: Build the archetype threat library

Q1.1: Does a published threat snapshot exist for at least 90% of inventoried processes archetypes, each establishing entities and trust boundaries before enumerating threats, validated with a practitioner who works on that archetype?

Evidence Required:

• [ ] Author one threat snapshot per archetype covering decision pipeline, customer-facing flow, human-in-the-loop chain, back-office augmentation, approval and review workflow, content-generation workflow and knowledge-management workflow
• [ ] For each archetype, identify the entities and trust boundaries first, being the inputs to the decision, the AI contribution, the human review step, the decision record and the route by which an affected person can contest it, because a threat list without a boundary model is a list of worries rather than an analysis
• [ ] Then enumerate the threats that follow from those boundaries, which in this domain centre on automation bias leading reviewers to accept what they should refuse, decisions with legal effect reaching people without a safeguard, oversight degrading silently as volume grows, and process drift where AI's role expands beyond what was assessed
• [ ] Keep each snapshot to a length a team will actually read, targeting two pages, and write each threat as a concrete failure with a named precondition rather than as a risk category
• [ ] Derive the snapshots from workflow definitions, the process inventory and decision records and validate each with one practitioner who works on that archetype daily, because a threat library authored entirely by security will describe the system security imagines rather than the one that exists

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

Answer:

• ☐ Fully Mature (Evidence complete + ≥3 metrics meet targets)
• ☐ Implemented (Evidence complete + 2 metrics meet targets)
• ☐ Partial (Evidence partially complete + <2 metrics meet targets)
• ☐ Not Implemented (No evidence)

Evidence Location: _________________________________

Notes: ___________________________________________

Question L1.2: Tag every threat to the shared vocabulary

Q1.2: Does every threat entry carry a HAI TTP tag, a genuine MITRE ATLAS technique where one applies with gaps recorded rather than forced, an OWASP LLM reference and the relevant compliance obligation? For Processes, the assessor should be shown the threat snapshot for a decision pipeline, including automation bias.

Evidence Required:

• [ ] Tag each threat entry with the HAI TTP it expresses, being excessive agency, agent goal hijack, tool misuse or rogue agents
• [ ] The MITRE ATLAS technique where a real one applies
• [ ] The OWASP LLM 2025 reference
• [ ] And the compliance obligation it bears on where relevant
• [ ] Use only technique identifiers that genuinely exist, because a plausible but invented identifier is worse than none, it survives review and misleads everyone downstream
• [ ] Where no ATLAS technique fits, record that explicitly rather than forcing the nearest match, and treat the gap as a candidate contribution at L3
• [ ] The tagging is what makes the library composable with everything else: it lets monitoring ask which threats have detections, testing ask which have tests, and requirements ask which have controls, without any of them re-reading the prose

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

Answer:

• ☐ Fully Mature (Evidence complete + ≥3 metrics meet targets)
• ☐ Implemented (Evidence complete + 2 metrics meet targets)
• ☐ Partial (Evidence partially complete + <2 metrics meet targets)
• ☐ Not Implemented (No evidence)

Evidence Location: _________________________________

Notes: ___________________________________________

Question L1.3: Trace every threat to a treating practice and publish the gaps

Q1.3: Are at least 85% of threats traced to a named treating practice and specific control, with untreated threats published as gaps and those at high-risk archetypes carrying an owner and remediation date? In Processes, ask to see the threat snapshot for a decision pipeline, including automation bias.

Evidence Required:

• [ ] For every threat in the library, name the practice expected to address it and the specific control, requirement, pattern, test or detection that does so
• [ ] Then publish the gaps, which is the activity teams most often skip and the one that gives the library its value: a threat with no named treatment is an accepted risk whether or not anyone decided to accept it, and making that visible is the point of the exercise
• [ ] Report the treatment-coverage rate to the sponsor quarterly and treat an untreated threat at a high-risk archetype as an open finding with an owner rather than as a line in a register
• [ ] Establish a 30-day service level for producing a threat snapshot when a new archetype enters the inventory, and review the whole library at least quarterly against external threat intelligence

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

Answer:

• ☐ Fully Mature (Evidence complete + ≥3 metrics meet targets)
• ☐ Implemented (Evidence complete + 2 metrics meet targets)
• ☐ Partial (Evidence partially complete + <2 metrics meet targets)
• ☐ Not Implemented (No evidence)

Evidence Location: _________________________________

Notes: ___________________________________________

Level 1 Outcome Metrics

Metric	Baseline	Current	Target	Met?	Notes
Processes archetypes with a current published threat snapshot	___	___	≥90% of inventoried archetypes within 6 months	☐
Threat entries carrying a HAI TTP tag and, where applicable, a real ATLAS technique	___	___	100%, with no invented technique identifiers	☐
Threats traced to a named treating practice and a specific control	___	___	≥85%, with the untreated remainder published as gaps	☐
Untreated threats at high-risk archetypes carrying an owner and a remediation date	___	___	100%	☐
New archetypes receiving a threat snapshot within 30 days of entering the inventory	___	___	≥90%	☐

Where each number is read from:

• Processes archetypes with a current published threat snapshot — Threat library register joined to the asset inventory
• Threat entries carrying a HAI TTP tag and, where applicable, a real ATLAS technique — Threat library tag audit against the published ATLAS catalogue
• Threats traced to a named treating practice and a specific control — Threat-to-treatment traceability matrix
• Untreated threats at high-risk archetypes carrying an owner and a remediation date — Issue tracker joined to the threat library
• New archetypes receiving a threat snapshot within 30 days of entering the inventory — Threat library creation dates joined to inventory first-seen dates

Level 1 30-second check (E0)

• ☐ Yes ☐ No — Is there a written threat model for each kind of AI processes asset you run?
• ☐ Yes ☐ No — Can you name one threat you have accepted without a control?
• ☐ Yes ☐ No — Would a new AI asset get a threat model before it ships?

---

Maturity Level 2, Comprehensive

Objective: Model threats per asset at a depth calibrated to its risk tier, refresh models on material change, and keep the Processes threat picture current against real adversary behaviour.

Prerequisite cells: TA-Processes-L1, SM-Processes-L2

Question L2.1: Calibrate threat-model depth to asset tier

Q2.1: Is threat-model depth calibrated by asset tier with published turnaround service levels, such that Critical-tier assets receive a per-asset model with an adversarial ATLAS overlay and a named architect reviewer while Low-tier assets inherit the archetype snapshot? Evidence this in the Processes domain against the threat snapshot for a decision pipeline, including automation bias.

Evidence Required:

• [ ] Publish what each tier receives
• [ ] Critical: a per-asset threat model, an adversarial overlay walking the relevant ATLAS tactics end to end, an explicit abuse-case set, and a named architect reviewer
• [ ] High: the archetype model plus documented per-asset deltas and an ATLAS tactic walk
• [ ] Medium: the archetype model with deltas recorded
• [ ] Low: the archetype model unchanged
• [ ] Publishing this is what stops the two failure modes of uniform depth, namely modelling everything shallowly so the Critical assets are under-analysed, or modelling everything deeply so the practice becomes a bottleneck and teams route around it
• [ ] Set turnaround service levels per tier and report adherence, because a threat-modelling practice that cannot say how long it takes will be worked around by teams under delivery pressure whatever its analytical quality
• [ ] Per-asset modelling in this domain means walking the decision path with the people who work it: what the reviewer actually sees, how long they actually have, what they are actually empowered to refuse, and what happens to a person on the receiving end of a wrong decision, which no archetype model reaches

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

Answer:

• ☐ Fully Mature (Evidence complete + ≥3 metrics meet targets)
• ☐ Implemented (Evidence complete + 2 metrics meet targets)
• ☐ Partial (Evidence partially complete + <2 metrics meet targets)
• ☐ Not Implemented (No evidence)

Evidence Location: _________________________________

Notes: ___________________________________________

Question L2.2: Refresh on material change rather than on the calendar

Q2.2: Does material change, including a new capability, a data-class change, a model or provider change, an exposure change or a tier increase, trigger a re-model within 14 days at Critical and 30 at High, with refresh records stating what actually changed rather than only a date? For Processes, the assessor should be shown the threat snapshot for a decision pipeline, including automation bias.

Evidence Required:

• [ ] Define material change per domain and wire the trigger to the signals that already exist
• [ ] In this domain a material change includes a new capability or interface on the asset, a change to the data classes it handles, a model or provider change, a change in exposure or the population reached, and a tier increase from the SM rubric
• [ ] Each triggers a re-model inside the tier's window, being 14 days at Critical and 30 at High
• [ ] Annual review remains as a floor, not as the mechanism
• [ ] The calendar is the least informative trigger available and relying on it means an asset that changed materially in month two carries a stale model for ten months
• [ ] Record every refresh with what changed and what it changed in the model, so that a reviewer can see whether the re-model was substantive or a date stamp
• [ ] In this domain the material change that most often invalidates a model is a volume increase, because oversight degrades continuously with load and nothing in the workflow signals when it crosses from meaningful to nominal

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

Answer:

• ☐ Fully Mature (Evidence complete + ≥3 metrics meet targets)
• ☐ Implemented (Evidence complete + 2 metrics meet targets)
• ☐ Partial (Evidence partially complete + <2 metrics meet targets)
• ☐ Not Implemented (No evidence)

Evidence Location: _________________________________

Notes: ___________________________________________

Question L2.3: Feed external intelligence in and push threat output downstream

Q2.3: Is external threat intelligence assessed for applicability within 30 days with negative assessments recorded, and do at least 90% of Critical- and High-tier threats generate a tracked requirement, test case and detection candidate? In Processes, ask to see the threat snapshot for a decision pipeline, including automation bias.

Evidence Required:

• [ ] Consume external threat intelligence on a defined cadence, drawing from MITRE ATLAS updates, OWASP LLM and Agentic project output, vendor and provider advisories, sector information-sharing bodies and published incident analyses
• [ ] Assess each item for applicability to the archetypes in the library within 30 days, and record the assessment even when the answer is not applicable, because the record is what demonstrates the cadence is real
• [ ] Push threat-model output downstream mechanically rather than by expectation: each Critical- and High-tier threat generates a requirement in the SR pack, a test case in the ST battery and a detection candidate in the ML set, tracked to closure
• [ ] A threat model whose output is not visible in what gets tested and detected has produced a document, and the practice is then measured on documents
• [ ] Process threat output lands most usefully in the oversight specification and the seeded-error test, which together turn an abstract concern about automation bias into a measured catch rate

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

Answer:

• ☐ Fully Mature (Evidence complete + ≥3 metrics meet targets)
• ☐ Implemented (Evidence complete + 2 metrics meet targets)
• ☐ Partial (Evidence partially complete + <2 metrics meet targets)
• ☐ Not Implemented (No evidence)

Evidence Location: _________________________________

Notes: ___________________________________________

Level 2 Outcome Metrics

Metric	Baseline	Current	Target	Met?	Notes
Critical-tier assets with a current per-asset threat model and adversarial overlay	___	___	100% of Critical, ≥90% of High	☐
Material changes triggering a re-model inside the tier window	___	___	≥95% within 14 days at Critical, 30 days at High	☐
External intelligence items assessed for applicability within 30 days	___	___	100%, including items assessed as not applicable	☐
Critical- and High-tier threats generating a tracked requirement, test case and detection candidate	___	___	≥90% traced to all three	☐
Per-tier threat-modelling turnaround against the published service level	___	___	≥90% per tier	☐

Where each number is read from:

• Critical-tier assets with a current per-asset threat model and adversarial overlay — Threat model register joined to the asset inventory tier
• Material changes triggering a re-model inside the tier window — Change events joined to threat model revision dates
• External intelligence items assessed for applicability within 30 days — Threat intelligence assessment log
• Critical- and High-tier threats generating a tracked requirement, test case and detection candidate — Traceability matrix across SR, ST and ML registers
• Per-tier threat-modelling turnaround against the published service level — Threat modelling request log with timestamps

Level 2 30-second check (E0)

• ☐ Yes ☐ No — Does your highest-risk AI asset have its own threat model?
• ☐ Yes ☐ No — Would adding a capability to an AI asset trigger a threat model refresh?
• ☐ Yes ☐ No — Does anything from your threat models end up as a test?

---

Maturity Level 3, Industry-Leading

Objective: Drive Processes threat modelling from live signal and adversary emulation, validate models against what actually happens, and contribute observed techniques back to ATLAS and the community.

Prerequisite cells: TA-Processes-L2, ST-Processes-L2, ML-Processes-L2, IM-Processes-L2

Question L3.1: Validate models through adversary emulation

Q3.1: Is every Critical-tier asset exercised by adversary emulation at least annually by a team that did not author the model, with both error directions measured, including behaviours the model failed to anticipate? Evidence this in the Processes domain against the threat snapshot for a decision pipeline, including automation bias.

Evidence Required:

• [ ] Run adversary emulation against Critical-tier assets at least semi-annually, scoped from the threat model and executed by a team that did not author it
• [ ] Measure the two directions of error explicitly: threats the model predicted that emulation could not demonstrate, and behaviours emulation found that the model did not anticipate
• [ ] The second is the more valuable and the more uncomfortable, and a practice that only reports confirmations is not learning
• [ ] Record for every threat in the library whether it has been demonstrated in this environment, demonstrated elsewhere, or remains theoretical, and report the distribution, since a library where most entries are theoretical is a library built from reading rather than from testing
• [ ] Feed every unanticipated finding into the archetype library, not only into the asset's model, so that one exercise improves every asset sharing that archetype
• [ ] Per-asset modelling in this domain means walking the decision path with the people who work it: what the reviewer actually sees, how long they actually have, what they are actually empowered to refuse, and what happens to a person on the receiving end of a wrong decision, which no archetype model reaches

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

Answer:

• ☐ Fully Mature (Evidence complete + ≥3 metrics meet targets)
• ☐ Implemented (Evidence complete + 2 metrics meet targets)
• ☐ Partial (Evidence partially complete + <2 metrics meet targets)
• ☐ Not Implemented (No evidence)

Evidence Location: _________________________________

Notes: ___________________________________________

Question L3.2: Update models from live signal continuously

Q3.2: Is every library threat classified as demonstrated here, demonstrated elsewhere or theoretical, and is the share of incidents whose root cause was an already-documented untreated threat reported openly and falling? For Processes, the assessor should be shown the threat snapshot for a decision pipeline, including automation bias.

Evidence Required:

• [ ] Close the loop from operations back to the models
• [ ] Feed detection telemetry, incident root causes, security test failures and near-misses into the library continuously rather than at review time, and treat any observed technique not represented in the library as a defect in the library with an owner and a date
• [ ] Publish a service level covering the interval from an observed technique to an updated model, targeting 30 days
• [ ] Track the share of incidents whose root cause was already present in the library as an untreated threat, which is the single most informative metric this practice produces: it separates a failure to foresee, which is hard, from a failure to act on what was already written down, which is not, and the second is far more common than most programmes admit
• [ ] In this domain the material change that most often invalidates a model is a volume increase, because oversight degrades continuously with load and nothing in the workflow signals when it crosses from meaningful to nominal

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

Answer:

• ☐ Fully Mature (Evidence complete + ≥3 metrics meet targets)
• ☐ Implemented (Evidence complete + 2 metrics meet targets)
• ☐ Partial (Evidence partially complete + <2 metrics meet targets)
• ☐ Not Implemented (No evidence)

Evidence Location: _________________________________

Notes: ___________________________________________

Question L3.3: Contribute observed techniques back

Q3.3: Does the organisation contribute at least four accepted techniques per year to ATLAS and the community, anonymised, legally reviewed and disclosure-coordinated, drawing first on the threats for which no existing technique fitted? In Processes, ask to see the threat snapshot for a decision pipeline, including automation bias.

Evidence Required:

• [ ] Submit techniques observed in this environment to MITRE ATLAS, and contribute to OWASP LLM and Agentic project revisions, sector information-sharing bodies and published incident analyses
• [ ] This matters more in AI security than in most fields because the public technique catalogue is young, and the gap between what practitioners observe and what is publicly documented is wide, which means a single well-documented submission can be genuinely novel rather than incremental
• [ ] Target at least four substantive submissions per year, count only those accepted, anonymise and legally review every one, and coordinate disclosure with affected model providers or vendors where a technique touches their systems
• [ ] Where the L1 activity recorded threats for which no ATLAS technique fit, revisit that list first: it is the highest-yield source of contribution candidates the programme has
• [ ] Process threat output lands most usefully in the oversight specification and the seeded-error test, which together turn an abstract concern about automation bias into a measured catch rate

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

Answer:

• ☐ Fully Mature (Evidence complete + ≥3 metrics meet targets)
• ☐ Implemented (Evidence complete + 2 metrics meet targets)
• ☐ Partial (Evidence partially complete + <2 metrics meet targets)
• ☐ Not Implemented (No evidence)

Evidence Location: _________________________________

Notes: ___________________________________________

Level 3 Outcome Metrics

Metric	Baseline	Current	Target	Met?	Notes
Critical-tier assets exercised by adversary emulation in the last 12 months	___	___	100%	☐
Threats in the library classified as demonstrated here, demonstrated elsewhere or theoretical	___	___	100% classified, with the theoretical share reported and falling	☐
Emulation findings not anticipated by the model, fed back into the archetype library	___	___	100% fed back within 30 days	☐
Observed techniques reaching an updated model within the service level	___	___	≥90% within 30 days	☐
Incidents whose root cause was an untreated threat already in the library	___	___	falling year over year, reported openly	☐
Accepted external technique contributions per year	___	___	≥4 accepted, anonymised and legally reviewed	☐

Where each number is read from:

• Critical-tier assets exercised by adversary emulation in the last 12 months — Emulation exercise register joined to the asset inventory
• Threats in the library classified as demonstrated here, demonstrated elsewhere or theoretical — Threat library validation status field
• Emulation findings not anticipated by the model, fed back into the archetype library — Emulation findings joined to library change log
• Observed techniques reaching an updated model within the service level — Library change log joined to detection and incident records
• Incidents whose root cause was an untreated threat already in the library — Incident root-cause analysis joined to the threat library
• Accepted external technique contributions per year — Contribution log with acceptance references

Level 3 30-second check (E0)

• ☐ Yes ☐ No — Has anyone tried to break your highest-risk AI asset this year?
• ☐ Yes ☐ No — Do you know which of your documented threats have ever actually been demonstrated?
• ☐ Yes ☐ No — Have you submitted a technique you observed to ATLAS?

---

Summary Scorecard

Level	Q1	Q2	Q3	Level score	Weakest evidence grade	Achieved?
L1	___	___	___	___	___	☐
L2	___	___	___	___	___	☐
L3	___	___	___	___	___	☐

Threat Assessment (TA) maturity in the Processes domain: ____________

---

Document Version: HAIAMM v3.5 (generated)