Threat Assessment (TA) - Software Assessment

Assessment questionnaire for measuring maturity. Answer each question honestly based on current, implemented practices.

Source of truth: ../practices/TA-Software-OnePager.md | ../HAIAMM-v3.0-Framing.md §8 (HAI TTPs), §10.1 (ATLAS), §14.5 (ATLAS tactic taxonomy)

Threat Assessment (TA) - Software Domain

HAIAMM Assessment Questionnaire v3.0

Practice: Threat Assessment (TA) Domain: Software Purpose: Assess organizational maturity in building and maintaining a reusable threat library for AI/HAI software the organization builds, covering all seven software archetypes mapped to HAI TTPs, ATLAS tactics (TA0001–TA0014), and OWASP LLM/Agentic Top 10 Scoring Model: Evidence + Outcome Metrics (see Scoring Methodology below)

Instructions

Answer each question honestly based on current, implemented practices (not plans or aspirations)
Each question has two components: Evidence (what you did) and Outcome Metrics (how well it worked)
Scoring uses 4 tiers: Fully Mature (1.0), Implemented (0.67), Partial (0.33), Not Implemented (0.0)
Answer progressively, complete all Level 1 questions before Level 2
Level progression, achieve ALL questions at lower level before advancing
Baseline first, record current metric values before setting targets
Subject framing, the AI/HAI software artifact is the subject being assessed; the organization's threat library describes what threatens that artifact, not what the artifact does for security

Scoring Methodology

Score	Label	Criteria
1.0	Fully Mature	All evidence items present AND ≥3 outcome metrics meet targets
0.67	Implemented	All evidence items present AND 2 outcome metrics meet targets
0.33	Partial	Evidence partially complete OR fewer than 2 metrics meet targets
0.0	Not Implemented	No substantive evidence of the activity

Level Score = average of the three question scores at that level Practice Score = weighted average: L1 × 0.5 + L2 × 0.3 + L3 × 0.2 (L2/L3 only scored if L1 = Fully Mature)

Maturity Level 1

Objective: Build the AI/HAI software archetype threat library, integrate a threat snapshot into every SM intake, and ensure every artifact's threat surface is documented before production landing.

Question 1: Build the AI/HAI software archetype threat library

Q1.1: Does the organization have a published, versioned threat library containing one threat model per AI/HAI software archetype, covering all seven archetypes (LLM-integrated app, autonomous agent, RAG pipeline, fine-tune/training workload, evaluation harness, model-serving service, classical ML model), with each archetype's threats tagged to HAI TTPs (EA/AGH/TM/RA), ATLAS tactic IDs (TA0001–TA0014), OWASP LLM/Agentic Top 10 references, and the PC-Software priority compliance map, owned by a named library steward with a documented quarterly refresh cadence?

Evidence Required: - [ ] Threat library document exists, is versioned, and names a single library steward responsible for quarterly refresh - [ ] All seven archetype models published: LLM-integrated app, autonomous agent, RAG pipeline, fine-tune/training workload, evaluation harness, model-serving service, classical ML, each scoped to first-party artifacts the org builds - [ ] Each archetype model tags threats to HAI TTPs (EA, Excessive Agency; AGH, Agent Goal Hijack; TM, Tool Misuse; RA, Rogue Agents) at the per-threat level, not only in a header - [ ] Each archetype model includes a full ATLAS tactic walk (TA0001 Reconnaissance through TA0014 Impact plus TA0040 ML Attack Staging) with explicit exclusions and rationale; technique IDs assigned where applicable - [ ] OWASP LLM/Agentic Top 10 (2025) cross-references tagged per archetype: agent threats → LLM01/LLM06/LLM07/Agentic Top 10; RAG threats → LLM01/LLM02/LLM08; fine-tune threats → LLM03/LLM08 - [ ] Compliance linkages recorded per threat (EU AI Act Art. 26, Art. 15, GDPR Art. 22, EU AI Act Annex III) - [ ] Quarterly refresh cadence recorded; no quarter with zero archetype updates

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % of AI/HAI software artifacts in SM inventory with a current-year threat snapshot | measure | % | 100% for Sanctioned; ≥90% for all | ☐ | | | Archetype coverage (software archetypes with a published threat model) | 0 / 7 | ___ / 7 | 7 / 7 | ☐ | | | Median snapshot turnaround from SM intake to threat snapshot delivery | measure | ___ | ≤1 business day | ☐ | | | % of snapshot top-5 threats tagged to a HAI TTP and an ATLAS tactic ID | measure | % | 100% | ☐ | |

Metric Collection Guidance: - Snapshot coverage: Count artifacts in SM inventory with a TA snapshot dated within the current calendar year divided by total active artifacts. Source: SM inventory × TA snapshot registry - Archetype coverage: Count distinct published archetype models in the threat library. Target is 7/7 before any intake gates go live - Snapshot turnaround: Median elapsed time from SM intake registration timestamp to threat snapshot delivery timestamp. Source: intake workflow telemetry - TTP/tactic tagging rate: For each snapshot, count top-5 threats with both a HAI TTP tag and an ATLAS tactic ID present. Source: snapshot metadata fields

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 of archetype threat library)

Evidence Location: _____ Validation Date: ____ Notes: ______

Question 2: Produce a per-intake threat snapshot for every SM inventory registration

Q2.1: Is a threat snapshot produced for every AI/HAI software artifact registering in the SM inventory, delivered within one business day of intake for Sanctioned artifacts, documenting the applicable archetype(s), artifact-specific deltas (tool list, retrieval sources, data classes, output-integrity-critical paths), top-5 threats with HAI TTP tags and ATLAS tactic IDs, controls evident, and gaps for SR/SA follow-up, with 100% of newly Sanctioned artifacts in the last 90 days carrying a snapshot before Sanctioned status is issued?

Evidence Required: - [ ] Snapshot gate is bound to the SM intake flow: Sanctioned status cannot be issued without a snapshot attached - [ ] Snapshot template includes: archetype(s), artifact-specific deltas (tool list, retrieval sources, data classes, output-integrity-critical paths), top-5 threats, HAI TTP tags, ATLAS tactic IDs, OWASP references, compliance linkage, controls evident, gaps - [ ] Artifact-specific deltas are populated for each snapshot, reviewers are adapting archetype content to the specific artifact, not copying the archetype verbatim - [ ] Snapshot expiry rules documented and enforced: re-snapshot triggers include model-family swap, new tool addition, new retrieval source, scope change, material code change - [ ] 100% of newly Sanctioned AI/HAI software artifacts in the last 90 days have a snapshot attached (sample audit evidence on file) - [ ] ≥90% of all active artifacts in the SM inventory carry a current-year snapshot

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % of AI/HAI software artifacts in SM inventory with a current-year threat snapshot | measure | % | 100% for Sanctioned; ≥90% for all | ☐ | | | Median snapshot turnaround from SM intake to threat snapshot delivery | measure | ___ | ≤1 business day | ☐ | | | % of snapshot top-5 threats tagged to a HAI TTP and an ATLAS tactic ID | measure | % | 100% | ☐ | | | Snapshot-to-SR linkage rate (snapshots whose top-5 threats are referenced by ≥1 SR requirement) | measure | ___% | ≥80% | ☐ | |

Metric Collection Guidance: - Snapshot coverage: As in Q1, count current-year snapshots divided by active artifacts in SM inventory - Turnaround: Median time from SM intake open to snapshot delivered timestamp; measure weekly - Tagging rate: Per-snapshot check: each of the top-5 threats must have both TTP and ATLAS tactic ID fields populated - SR linkage: After SR-Software L1 is operational, cross-reference snapshot threat IDs against SR requirements. Track as % of snapshots with ≥1 SR cross-reference

Evidence Location: _____ Validation Date: ____ Notes: ______

Question 3: Author the shadow-AI-in-engineering threat view

Q3.1: Is there a published shadow-AI-in-engineering threat view, reviewed by the program sponsor within the last 12 months, that documents entry vectors for unsanctioned AI/HAI software artifacts (unannounced LLM API calls, researcher-run fine-tunes, agents wired behind feature flags), elevated threats for shadow artifacts (no TA snapshot, no SR requirements pack, unmet EU AI Act Art. 26 deployer duties), specific failure modes, and the detections available at L1 (source-code signals, CI/CD telemetry, runtime egress, cloud-spend signals) to surface them?

Evidence Required: - [ ] "Shadow AI in Engineering, Threat View" document exists, is dated, and names the reviewer (program sponsor or delegate) - [ ] Document covers all four entry-vector categories: unannounced LLM API calls in feature branches; direct SDK imports without security review; researcher-run fine-tuning from notebooks; agents wired to production APIs behind feature flags - [ ] Elevated threats for shadow artifacts documented: no TA snapshot, no SR requirements, no design review, EU AI Act Art. 26 unmet, GDPR Art. 28 unmet for cross-boundary data flows - [ ] Specific failure modes named: training on regulated production data outside lawful basis; agent with production tool access without kill-switch; RAG over confidential corpus without retrieval-source provenance - [ ] L1 detections documented: source-code signals (LLM SDK imports in branches), CI/CD telemetry, runtime egress to AI provider domains, cloud-spend signals (untagged AI API usage) - [ ] Document feeds the ML-Software detection backlog and the IM-Software triage playbook (links on file) - [ ] Shadow-AI-in-engineering threat view published and reviewed in last 12 months

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Shadow-AI-in-engineering threat view published and reviewed in last 12 months | n/a | Yes/No | Yes | ☐ | | | % of snapshot top-5 threats tagged to a HAI TTP and an ATLAS tactic ID | measure | % | 100% | ☐ | | | Archetype coverage (software archetypes with a published threat model) | 0 / 7 | ___ / 7 | 7 / 7 | ☐ | | | Downstream reuse rate (SR, SA, ST artifacts citing snapshot threats vs. re-deriving) | measure | % | ≥80% | ☐ | |

Metric Collection Guidance: - Shadow threat view currency: Confirm document exists with review date within last 12 months and program-sponsor signature/approval record - Tagging rate: Same metric as Q1/Q2, share a single measurement source - Archetype coverage: Same 7/7 metric as Q1 - Downstream reuse: Sample 10 recent SR, SA, or ST artifacts and check whether threats listed trace back to snapshot top-5 entries vs. newly derived without snapshot citation

Evidence Location: _____ Validation Date: ____ Notes: ______

Maturity Level 2

Objective: Layer per-artifact deep threat models on top of archetype snapshots for Critical-tier artifacts, integrate external AI security threat intelligence, and red-team the threat library quarterly against novel real-world attack patterns.

Question 4: Per-artifact deep threat modeling for Critical-tier artifacts

Q4.1: Does every Critical-tier AI/HAI software artifact in the SM inventory have a current-year per-artifact deep threat model, not a recycled archetype snapshot, covering artifact-specific attack trees (per-tool abuse paths, per-retrieval-source provenance and injection surface, per-data-class memorization risk), a named-adversary abuse-case catalog, EU AI Act Art. 26 deployer-duty mapping, and a full ATLAS tactic walk with technique-level specificity (all 14 tactics enumerated, exclusions explicit), with a semi-annual refresh cadence and change-driven updates on model-family swap, new tool, new retrieval source, or scope change?

Evidence Required: - [ ] Per-artifact deep threat models exist for 100% of Critical-tier artifacts in the SM inventory; model age does not exceed 180 days for any Critical-tier artifact - [ ] Per-artifact models contain: artifact-specific tool list with per-tool abuse paths; retrieval-source provenance chain with injection surface analysis; data classes with memorization-risk quantification; output-integrity-critical paths with downstream consequence analysis - [ ] Abuse-case catalog names adversary archetypes (external attacker, malicious insider, compromised subprocessor, compromised vendor model family) with concrete attack narratives for the specific artifact - [ ] EU AI Act Art. 26 deployer-duty mapping covers Art. 15 (accuracy, robustness, cybersecurity), Art. 14 (human oversight), Art. 13 (documentation) for the specific artifact's threat-control chain - [ ] Full ATLAS tactic walk for the artifact: all 14 tactics enumerated; technique IDs from the AI-Attack-Taxonomy assigned; exclusions with rationale on record - [ ] High-tier artifacts carry archetype snapshot + artifact-specific deltas + ATLAS tactic walk (no High-tier artifact on archetype snapshot alone) - [ ] Refresh cadence: Critical semi-annual + change-driven; High annual + change-driven; cadence compliance tracked

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % Critical-tier artifacts with current-year per-artifact deep threat model | measure | % | 100% | ☐ | | | % High-tier artifacts with archetype snapshot + artifact-specific deltas + ATLAS tactic walk | measure | % | ≥90% | ☐ | | | External intel triage cadence met (quarterly) | measure | ___ / year | 4 / year | ☐ | | | Threat-library change lead time from intel signal to library update | measure | ___ days | ≤30 days for Critical-impact items | ☐ | |

Metric Collection Guidance: - Critical-tier coverage: Count Critical-tier artifacts with a per-artifact deep model dated within 180 days divided by all Critical-tier artifacts. Source: SM inventory tier field × TA library index - High-tier coverage: Count High-tier artifacts with archetype snapshot + deltas + ATLAS walk divided by all High-tier artifacts - Intel triage cadence: Count completed quarterly intel triage sessions per calendar year. Target is 4; record session date, items reviewed, and items resulting in library changes - Change lead time: Measure days from intel item first received (ATLAS update email timestamp, AVID entry date) to library change commit date for Critical-impact items

Evidence Location: _____ Validation Date: ____ Notes: ______

Question 5: External AI-security threat intelligence integration

Q5.1: Is external AI-security threat intelligence, covering MITRE ATLAS technique updates, AVID submissions, OWASP LLM/Agentic Top 10 revisions, academic adversarial-ML venues (IEEE S&P, USENIX Security, NeurIPS ML Safety), and sector ISAC AI working groups, subscribed to and operationalized with a quarterly triage cadence producing a documented change-log, with intel-to-library update ≤30 days on Critical-impact items?

Evidence Required: - [ ] Subscriptions active for all five intelligence sources: MITRE ATLAS, AVID, OWASP LLM/Agentic Top 10, academic adversarial-ML venues, sector ISAC AI working groups - [ ] Quarterly triage cadence documented: triage session records on file showing date, intel items reviewed, triage decisions (change library / change per-artifact model / change SR or ST / defer / reject) - [ ] Documented change-log with entries keyed to intel source, item date, impact assessment, library update record, and steward sign-off - [ ] Change-log reviewed by the library steward and the IM backlog owner each quarter - [ ] Intel-to-library update lead time ≤30 days for Critical-impact items: evidence from change-log timestamps - [ ] No quarter in the last 12 months with zero library changes

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | External intel triage cadence met (quarterly) | measure | ___ / year | 4 / year | ☐ | | | Threat-library change lead time from intel signal to library update | measure | ___ days | ≤30 days for Critical-impact items | ☐ | | | Library gaps discovered per quarter (red-team exercises) | measure | tracked | trending down | ☐ | | | % Critical-tier artifacts with current-year per-artifact deep threat model | measure | ___% | 100% | ☐ | |

Metric Collection Guidance: - Triage cadence: Count triage session records in the last 12 months. Each session must produce a triage log artifact - Change lead time: For each Critical-impact item in the last four quarters, calculate days from receipt to library update commit. Compute median and P90 - Library gaps: From red-team exercise output, count threats identified by red team not present in the library for that archetype. Track count per quarter and direction of trend - Critical-tier coverage: Same metric as Q4

Evidence Location: _____ Validation Date: ____ Notes: ______

Question 6: Red-team the threat library itself

Q6.1: Does the organization run a quarterly red-team-the-library exercise, where ST-Software probes an in-scope AI/HAI software artifact using only threat scenarios documented in the library for that archetype, surfaces all unmatched findings as library gaps rather than passing results, and closes every gap with a named owner and expiry date (Critical gaps within 30 days, High within 60 days), with the gap rate trending down quarter over quarter?

Evidence Required: - [ ] Quarterly red-team-the-library exercise on file: exercise records show date, artifact probed, archetype used, library version, probe scenarios drawn exclusively from library, and unmatched findings enumerated - [ ] Gap log maintained: every unmatched finding becomes a ticket with a named owner and an expiry date - [ ] Critical-tier gap closure SLA enforced: no Critical gap open past 30 days (audit evidence on file) - [ ] High-tier gap closure SLA enforced: no High gap open past 60 days - [ ] Gap rate tracked per quarter and documented as trending down as the library matures - [ ] Gaps reviewed for SR and ST update implications: if a threat is missing from the library, it is also checked against SR requirements and ST test batteries

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Library gaps discovered per quarter (red-team exercises) | measure | tracked | trending down | ☐ | | | % Critical-tier artifacts with current-year per-artifact deep threat model | measure | % | 100% | ☐ | | | % High-tier artifacts with archetype snapshot + artifact-specific deltas + ATLAS tactic walk | measure | % | ≥90% | ☐ | | | External intel triage cadence met (quarterly) | measure | ___ / year | 4 / year | ☐ | |

Metric Collection Guidance: - Library gap rate: Count library gaps logged per quarter from red-team exercises. Plot trend. Expect initial rise as exercises mature, then sustained decline as gaps are closed - Gap closure SLA: For each gap in the last four quarters, calculate days from gap creation to closure. Verify no Critical gap exceeded 30 days - Critical-tier coverage: Same metric as Q4 and Q5 - Intel triage cadence: Same metric as Q5

Evidence Location: _____ Validation Date: ____ Notes: ______

Maturity Level 3

Objective: Automate threat-library maintenance from telemetry and external feeds, and contribute discovered AI/HAI software TTPs back to MITRE ATLAS, OWASP, and AVID.

Question 7: Telemetry-driven library updates

Q7.1: Does the threat library auto-update from an integrated signal pipeline, consuming ML-Software detection alert patterns, IM-Software post-incident ATLAS tactic walks, ATLAS technique additions, AVID new entries, OWASP LLM/Agentic Top 10 revision drafts, and weekly academic adversarial-ML paper digests, via human-curator approval/reject/defer workflow, with ≥60% of changes auto-proposed, ≤14-day lead time from signal to update, and a machine-readable change-log subscribed to by downstream SR and ST practices?

Evidence Required: - [ ] Auto-proposal pipeline operational: ML-Software detections and IM-Software incident records generate structured candidate threat entries surfaced to the curation queue - [ ] External feed ingestion active: ATLAS, AVID, OWASP LLM/Agentic, academic publication digest, sector-ISAC AI advisories all feeding the pipeline - [ ] Human-curator workflow implemented: curators approve, reject, or defer each auto-proposal with decision rationale on record - [ ] ≥60% of library changes in the last 12 months were auto-proposed (not manually authored from scratch) - [ ] Change-log is machine-readable; downstream SR and ST practices subscribe and receive update-required notifications when a threat they reference changes - [ ] Lead time from signal to library update ≤14 days: change-log timestamps support this claim for the last 12 months

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Library change lead time from telemetry / external signal to update | measure | ___ days | ≤14 days | ☐ | | | % of library changes auto-proposed vs. manually authored | measure | ___% | ≥60% auto-proposed | ☐ | | | Industry contributions per year (MITRE ATLAS / AVID / OWASP) | 0 | ___ | ≥4 | ☐ | | | External-recognized TTPs originating from the program | 0 | ___ | ≥2 / year | ☐ | |

Metric Collection Guidance: - Change lead time: Measure days from signal timestamp (ML alert, ATLAS update email, AVID entry publish date) to library commit date. Compute median and P90 over last 12 months - Auto-proposal rate: Count changes where the origin field is "auto-proposed" divided by all changes in last 12 months - Industry contributions: Count substantive technical artifacts (new technique submissions, revised entries, real-world evidence notes) submitted to ATLAS/AVID/OWASP in last 12 months. Cosmetic comments and +1s do not count - Recognized TTPs: Count contributions that resulted in a published ATLAS technique update, AVID entry, or OWASP revision citing the program

Evidence Location: _____ Validation Date: ____ Notes: ______

Question 8: Industry contribution of discovered AI/HAI software TTPs

Q8.1: Does the program contribute at least four substantive, evidence-backed technical artifacts per year to MITRE ATLAS, OWASP LLM/Agentic Top 10, and AVID, covering novel TTPs discovered in own-built AI/HAI software (prompt-injection variants, agent-loop attack patterns, retrieval-poisoning mechanics) following ATLAS evidence-and-provenance requirements and OWASP revision-cycle protocols, with at least two contributions externally recognized in published advisories or standard revisions?

Evidence Required: - [ ] Contribution log maintained: each entry records the target body (ATLAS/AVID/OWASP), submission date, artifact type, evidence package, legal/anonymization review sign-off, and status (submitted / accepted / published) - [ ] ≥4 substantive technical contributions submitted in the last 12 months; each contribution is a technical artifact (technique submission, real-world evidence note, OWASP revision comment with telemetry) not a cosmetic observer comment - [ ] ≥2 contributions externally recognized in the last 12 months (ATLAS technique merge, AVID entry published, OWASP revision incorporating the submission) - [ ] Submissions anonymized and legally vetted before submission: anonymization review record on file for each submission - [ ] NIST AI RMF Playbook successor input submitted or in-flight for at least one cycle

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Industry contributions per year (MITRE ATLAS / AVID / OWASP) | 0 | ___ | ≥4 | ☐ | | | External-recognized TTPs originating from the program | 0 | ___ | ≥2 / year | ☐ | | | Library change lead time from telemetry / external signal to update | measure | ___ days | ≤14 days | ☐ | | | % of library changes auto-proposed vs. manually authored | measure | ___% | ≥60% auto-proposed | ☐ | |

Metric Collection Guidance: - Contributions: Source is the contribution log. Quality-grade each entry: technical artifact with evidence = counts; comment or observer participation = does not count - Recognized TTPs: Check ATLAS commit history, AVID entry list, and OWASP revision changelogs for citations of the program or the specific artifact submitted - Change lead time and auto-proposal rate: Same as Q7

Evidence Location: _____ Validation Date: ____ Notes: ______

Question 9: Shared threat-model artifacts and industry tabletops

Q9.1: Are anonymized archetype threat models (scrubbed of org-specific tool names and data classes) published under a permissive license with tracked peer-org adoption, and does the program host or co-host at least one industry tabletop per year (ATLAS practitioner table, OWASP AI chapter, or sector ISAC AI working group) tied to the library?

Evidence Required: - [ ] Anonymized archetype threat models published: public or consortium-accessible URL on file; license is permissive (CC-BY, Apache 2.0, or equivalent); at least one version published in the last 12 months - [ ] Anonymization review record on file confirming org-specific tool names and data classes are scrubbed - [ ] Peer-org adoption tracked: download counts, fork counts, direct adoption notifications, or consortium usage reports - [ ] Industry tabletop hosted or co-hosted in last 12 months: event record with date, hosting org(s), topic tied to the library, and participant count - [ ] Published models maintained in sync with the internal library: last internal update date vs. last published update date gap ≤90 days

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Peer-org adoption of published archetype threat models | 0 | tracked | tracked | ☐ | | | External-recognized TTPs originating from the program | 0 | ___ | ≥2 / year | ☐ | | | Industry contributions per year (MITRE ATLAS / AVID / OWASP) | 0 | ___ | ≥4 | ☐ | | | % of library changes auto-proposed vs. manually authored | measure | ___% | ≥60% auto-proposed | ☐ | |

Metric Collection Guidance: - Peer-org adoption: Collect download/fork/adoption metrics from the publishing platform quarterly. Trend is the measure; absolute counts vary by distribution channel - Recognized TTPs: Same metric as Q8 - Contributions and auto-proposal rate: Same metrics as Q7/Q8

Evidence Location: _____ Validation Date: ____ Notes: ______

Summary Scorecard

Level	Q1	Q2	Q3	Level Score	Gate Met?
L1	___	___	___	___	☐

Level	Q4	Q5	Q6	Level Score	Gate Met?
L2	___	___	___	___	☐

Level	Q7	Q8	Q9	Level Score	Gate Met?
L3	___	___	___	___	☐

Practice Maturity Score: ___ Assessed Maturity Level: ☐ L1 ☐ L2 ☐ L3

Practice Maturity Statement: The organization's TA-Software practice is at Level ___ . The archetype threat library covers ___ / 7 software archetypes mapped to HAI TTPs (EA/AGH/TM/RA), ATLAS tactic IDs (TA0001–TA0014), and OWASP LLM/Agentic Top 10 references. Threat snapshots are produced at SM intake for ___% of Sanctioned artifacts within the target turnaround. [Add narrative on gaps, next steps, and L2/L3 readiness.]

Document Version: HAIAMM v3.0 Practice: Threat Assessment (TA) Domain: Software Last Updated: 2026-05-15 Author: Verifhai

Instructions:

Answer based on current practices, not plans
“Yes” requires documented evidence
Complete all Level 1 questions before Level 2
Partial implementation = “No”

↓ Download as Markdown