Threat Assessment (TA) - Data Assessment

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

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

Threat Assessment (TA) - Data Domain

HAIAMM Assessment Questionnaire v3.0

Practice: Threat Assessment (TA) Domain: Data Purpose: Assess organizational maturity in building and maintaining a reusable threat library for the data flowing into and out of AI/HAI systems, covering all seven data archetypes mapped to HAI TTPs, ATLAS tactics (TA0001–TA0014) and data-specific technique IDs (AML.T0019, AML.T0020, AML.T0024, AML.T0025, AML.T0010), and OWASP LLM Top 10 (2025) 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 data asset is the subject being assessed; the threat library describes what threatens the asset, not what the asset 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 data archetype threat library, integrate a threat snapshot into every data-asset intake, and ensure every data asset's threat surface is documented before it enters an AI pipeline.

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

Q1.1: Does the organization have a published, versioned threat library containing one threat model per AI/HAI data archetype, covering all seven archetypes (training corpus, inference input stream, retrieval store, prompt/completion log corpus, embedding store, fine-tuning dataset, evaluation/test set), with each archetype's threats tagged to HAI TTPs (EA/AGH/TM/RA), ATLAS tactic IDs and data-specific technique IDs (AML.T0019, AML.T0020, AML.T0024, AML.T0025, AML.T0010 where applicable), OWASP LLM Top 10 (2025) references, and the PC-Data 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: training corpus, inference input stream, retrieval store, prompt/completion log corpus, embedding store, fine-tuning dataset, evaluation/test set, each scoped to data assets flowing into or out of AI systems - [ ] Training corpus and fine-tuning dataset archetypes cover: AML.T0020 Poison Training Data, AML.T0019 Publish Poisoned Datasets, AML.T0010 ML Supply Chain Compromise, unconsented data inclusion (GDPR Arts. 6/9/17), regulated-data leakage at training time (TA0011/LLM06), label-flip attacks (RA/TA0040), backdoor-trigger insertion (TA0005/AML.T0020) - [ ] Retrieval store archetype covers: retrieval poisoning (AGH/AML.T0020/TA0006), retrieval extraction (TM/AML.T0024/TA0010), classification-label bypass (GDPR Art. 32), indirect prompt injection via retrieved content (AGH/AML.T0051/LLM01) - [ ] Embedding store archetype covers: embedding inversion (AML.T0024/TA0010), nearest-neighbor extraction (TM/AML.T0024), retrieval poisoning at the embedding layer (AGH/AML.T0020) - [ ] Evaluation/test set archetype covers: eval contamination (TA0040/AML.T0048), eval gaming (RA/TA0008), eval suppression (TA0008) - [ ] Prompt/completion log corpus archetype covers: retention-policy violation (GDPR Art. 5(1)(e)), regulated-data persistence (GDPR Arts. 32/35), unauthorized log export (AML.T0025/TA0011), log-mining for training without consent (GDPR Art. 6/EU AI Act Art. 10) - [ ] Full ATLAS tactic walk documented per archetype (TA0001–TA0014) with data-specific technique IDs assigned; compliance linkage per threat to GDPR Arts. 6, 9, 17, 22, 28, 32, 35, 44–49; EU AI Act Arts. 10, 26; ISO/IEC 42001

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % of AI/HAI data assets in SM inventory with a current-year threat snapshot | measure | % | 100% for approved assets; ≥90% for all | ☐ | | | Archetype coverage (data 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 or technique ID | measure | % | 100% | ☐ | |

Metric Collection Guidance: - Snapshot coverage: Count data assets in SM inventory with a TA snapshot dated within the current calendar year divided by total active data assets. Source: SM inventory × TA snapshot registry - Archetype coverage: Count distinct published archetype models for the seven data archetypes. Target is 7/7 before intake gates go live - Snapshot turnaround: Median elapsed time from SM data-asset intake registration to threat snapshot delivery. Source: intake workflow telemetry - TTP/tactic tagging rate: For each snapshot, confirm top-5 threats each carry both a HAI TTP tag and an ATLAS tactic ID or AML.T technique ID. 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 data archetype threat library)

Evidence Location: _____ Validation Date: ____ Notes: ______

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

Q2.1: Is a threat snapshot produced for every AI/HAI data asset registering in the SM inventory, delivered within one business day of intake for approved assets, documenting the applicable archetype(s), asset-specific deltas (classification tier, lineage/provenance status, volume/criticality, cross-border flows and transfer mechanisms, decision-affecting use, subject-access-rights exposure), top-5 threats with HAI TTP tags, ATLAS tactic/technique IDs, OWASP references, and compliance linkage, with 100% of newly approved assets in the last 90 days carrying a snapshot before pipeline approval is issued?

Evidence Required: - [ ] Snapshot gate is bound to the SM data-asset intake flow: pipeline approval cannot be issued without a snapshot attached - [ ] Snapshot template includes: archetype(s), asset-specific deltas (classification, lineage, cross-border flows, transfer mechanism, decision-affecting use, subject-access-rights exposure), top-5 threats with HAI TTP tags, ATLAS tactic/technique IDs, OWASP references, compliance linkage, controls evident, gaps - [ ] Asset-specific deltas populated per snapshot, reviewers adapt archetype content to the specific asset's actual data classes, regulatory exposure, and pipeline position - [ ] Snapshot expiry rules documented: re-snapshot triggers include new data source, classification change, pipeline scope change, material volume change - [ ] 100% of newly approved AI/HAI data assets in the last 90 days have a snapshot attached (sample audit evidence on file) - [ ] ≥90% of all active data assets in the SM inventory carry a current-year snapshot

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % of AI/HAI data assets in SM inventory with a current-year threat snapshot | measure | % | 100% for approved assets; ≥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 or technique ID | measure | % | 100% | ☐ | | | Snapshot-to-SR linkage rate (snapshots whose top-5 threats referenced by ≥1 SR-Data requirement) | measure | ___% | ≥80% | ☐ | |

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

Evidence Location: _____ Validation Date: ____ Notes: ______

Question 3: Author the shadow-data-for-AI threat view

Q3.1: Is there a published shadow-data-for-AI threat view, reviewed by the program sponsor within the last 12 months, that documents entry vectors for unsanctioned data-sharing with AI services, elevated threats for shadow data assets (no snapshot, no transfer mechanism, no GDPR Art. 28 DPA, Arts. 44–49 transfer obligations unmet), specific failure modes (regulated PII to vendor with training enabled, health data without Art. 9 condition, cross-border flow without adequacy decision or SCC), and the L1 detections available (DLP signals on outbound calls to AI provider domains, egress telemetry, canary-document detection in AI completions)?

Evidence Required: - [ ] "Shadow Data for AI, Threat View" document exists, is dated, and names the reviewer (program sponsor or delegate) - [ ] Document covers entry vectors: developers submitting production PII to consumer GenAI; automated pipelines calling LLM APIs without no-train verification; canary-tagged datasets flowing to unapproved retrieval stores; prompt/completion logs exported without consent review - [ ] Elevated threats documented: no TA snapshot, no SR requirements, no transfer mechanism, no GDPR Art. 28 DPA in place; Arts. 44–49 transfer obligations unmet - [ ] Specific failure modes named: regulated PII to vendor LLM with training enabled; health data without Art. 9 special-category condition documented; customer data cross-border without adequacy decision or SCC - [ ] L1 detections documented: DLP signals on outbound calls to AI provider domains; egress telemetry for LLM API calls from data pipeline infrastructure; canary-document detection in external AI completions - [ ] Document feeds ML-Data detection backlog and IM-Data triage playbook (links on file) - [ ] Shadow-data-for-AI threat view published and reviewed in last 12 months

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Shadow-data-for-AI 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 or technique ID | measure | % | 100% | ☐ | | | Archetype coverage (data 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 approval record - Tagging rate: Same measurement source as Q1/Q2 - Archetype coverage: Same 7/7 metric as Q1 - Downstream reuse: Sample 10 recent SR-Data, SA-Data, or ST-Data artifacts and check whether threats trace back to snapshot top-5 entries rather than being newly derived without snapshot citation

Evidence Location: _____ Validation Date: ____ Notes: ______

Maturity Level 2

Objective: Layer per-asset deep threat models for Critical-tier data assets, integrate external AI-data-attack threat intelligence, and red-team the threat library quarterly against novel real-world attack patterns.

Question 4: Per-asset deep threat modeling for Critical-tier data assets

Q4.1: Does every Critical-tier AI/HAI data asset in the SM inventory have a current-year per-asset deep threat model, not a recycled archetype snapshot, covering asset-specific attack trees (lineage/provenance chain compromise, regulatory data-class exposure analysis, cross-border flow gap enumeration, downstream AI system blast-radius assessment), a named-adversary abuse-case catalog, GDPR Art. 32/35/EU AI Act Art. 10 compliance-duty mapping, and a full ATLAS tactic walk with technique-level specificity, with a semi-annual refresh cadence and change-driven updates on new data sources, classification changes, or pipeline scope changes?

Evidence Required: - [ ] Per-asset deep threat models exist for 100% of Critical-tier data assets; model age does not exceed 180 days for any Critical-tier asset - [ ] Per-asset models contain: asset-specific lineage/provenance chain with each link's compromise surface; specific regulatory data classes with exposure consequence analysis; specific cross-border flows with transfer-mechanism gaps identified; downstream AI systems with blast-radius assessment per threat - [ ] Abuse-case catalog names adversary archetypes (external attacker, malicious insider, compromised data vendor, compromised annotation/labeling platform, upstream supply-chain compromise) with concrete attack narratives for the specific asset - [ ] Compliance-duty mapping covers GDPR Art. 32 security requirements, Art. 35 DPIA triggers, EU AI Act Art. 10 training-data requirements, and sector obligations mapped to the specific asset's threat-control chain - [ ] Full ATLAS tactic walk: all 14 tactics enumerated; data-specific technique IDs (AML.T0019/T0020/T0024/T0025/T0010) assigned where applicable; exclusions with rationale on record - [ ] High-tier assets carry archetype snapshot + asset-specific deltas + ATLAS tactic walk (no High-tier asset 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 data assets with current-year per-asset deep threat model | measure | % | 100% | ☐ | | | % High-tier data assets with archetype snapshot + asset-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 data assets with a per-asset deep model dated within 180 days divided by all Critical-tier data assets - High-tier coverage: Count High-tier assets with archetype snapshot + deltas + ATLAS walk divided by all High-tier assets - Intel triage cadence: Count completed quarterly intel triage sessions in last 12 months. Each session must produce a triage log artifact - Change lead time: For each Critical-impact item (especially new AML.T techniques) in the last four quarters, calculate days from receipt to library update. Compute median and P90

Evidence Location: _____ Validation Date: ____ Notes: ______

Question 5: External AI-data-attack threat intelligence integration

Q5.1: Is external AI-data-attack threat intelligence, covering MITRE ATLAS updates including AML.T0019/T0020/T0024/T0025/T0010 and new data-specific entries, AVID entries for data-attack techniques, OWASP LLM Top 10/Agentic Top 10 revisions, academic adversarial-ML venues covering embedding inversion, membership inference, and corpus poisoning, 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 (data-technique focus), AVID, OWASP LLM/Agentic Top 10, academic adversarial-ML venues, sector ISAC AI working groups - [ ] Quarterly triage cadence documented: triage session records showing date, intel items reviewed (including new AML.T entries), triage decisions with library impact assessment - [ ] 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 data assets with current-year per-asset 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 referencing AML.T technique IDs reviewed - Change lead time: For each Critical-impact item in the last four quarters, calculate days from receipt to library update. Compute median and P90 - Library gaps: From red-team exercise output, count data-pipeline threats identified not present in the library for that archetype. Track per quarter - 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-Data probes an in-scope AI/HAI data pipeline 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, data pipeline 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 expiry date - [ ] Critical-tier gap closure SLA enforced: no Critical gap open past 30 days (audit evidence on file) - [ ] High-tier gap closure SLA: no High gap open past 60 days - [ ] Gap rate tracked per quarter and documented as trending down - [ ] Gaps reviewed for SR-Data and ST-Data update implications: missing library threats are 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 data assets with current-year per-asset deep threat model | measure | % | 100% | ☐ | | | % High-tier data assets with archetype snapshot + asset-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 then sustained decline - Gap closure SLA: For each gap in the last four quarters, verify no Critical gap exceeded 30 days from creation to closure - Critical-tier and High-tier coverage: Same metrics as Q4 - 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 data-attack TTPs back to MITRE ATLAS, AVID, and OWASP.

Question 7: Telemetry-driven library updates

Q7.1: Does the threat library auto-update from an integrated signal pipeline, consuming ML-Data detection alert patterns, IM-Data post-incident ATLAS tactic walks, ATLAS technique additions (especially new AML.T data-attack entries), AVID new entries, OWASP LLM/Agentic revision drafts, and weekly academic adversarial-ML and privacy-attack paper digests, via human-curator approval 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-Data detections and IM-Data incident ATLAS walks generate structured candidate threat entries surfaced to the curation queue - [ ] External feed ingestion active: ATLAS, AVID, OWASP LLM/Agentic, academic publication digest (embedding inversion, membership inference, corpus poisoning focus), sector-ISAC AI advisories - [ ] 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 - [ ] Change-log is machine-readable; downstream SR-Data and ST-Data practices subscribe and receive update-required notifications - [ ] Lead time from signal to library update ≤14 days: change-log timestamps support this claim

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 to library commit. Focus on AML.T technique updates as the highest-cadence signal type. Compute median and P90 - Auto-proposal rate: Count changes with origin "auto-proposed" divided by all changes in last 12 months - Industry contributions: Count substantive technical artifacts submitted to ATLAS/AVID/OWASP. Novel corpus poisoning mechanics, new embedding inversion approaches, supply-chain compromise specific to dataset curation tools qualify - Recognized TTPs: Check ATLAS commit history, AVID entry list, OWASP revision changelogs for citations of the program

Evidence Location: _____ Validation Date: ____ Notes: ______

Question 8: Industry contribution of discovered AI/HAI data-attack TTPs

Q8.1: Does the program contribute at least four substantive, evidence-backed technical artifacts per year to MITRE ATLAS, AVID, and OWASP LLM/Agentic Top 10, covering novel data-attack TTPs discovered in own-operated AI data pipelines (corpus poisoning mechanics, new embedding inversion approaches, supply-chain compromise specific to dataset curation tools, prompt/completion log mining patterns) following ATLAS evidence-and-provenance requirements, with at least two contributions externally recognized in published advisories or standard revisions?

Evidence Required: - [ ] Contribution log maintained: each entry records target body (ATLAS/AVID/OWASP), submission date, artifact type, evidence package, anonymization review sign-off, and status - [ ] ≥4 substantive technical contributions submitted in the last 12 months, each is a technical artifact with evidence (AML.T technique submission with provenance, AVID structured disclosure, OWASP revision comment with telemetry data), 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; review record on file for each submission - [ ] Contributions focus on data-domain attack classes: corpus poisoning, embedding inversion, membership inference, supply-chain compromise to dataset curation tools, prompt/completion log mining

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 contribution log. Quality-grade: AML.T technique submission with provenance = counts; comment without evidence = does not count - Recognized TTPs: Check ATLAS commit history, AVID entry list, OWASP revision changelogs for citations of the program's artifacts - 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 data archetype threat models 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 data archetype threat models published: public or consortium-accessible URL on file; license is permissive; org-specific data source names and classification details scrubbed - [ ] Anonymization review record on file confirming org-specific identifiers removed - [ ] 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 data threat library, and participant count - [ ] Published models maintained in sync with internal library: last internal update vs. last published update 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 - 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-Data practice is at Level ___ . The archetype threat library covers ___ / 7 data archetypes mapped to HAI TTPs (EA/AGH/TM/RA), ATLAS tactic IDs with data-specific technique IDs (AML.T0019/T0020/T0024/T0025/T0010), and OWASP LLM Top 10 (2025) references. Threat snapshots are produced at SM intake for ___% of approved data assets. [Add narrative on gaps, next steps, and L2/L3 readiness.]

Document Version: HAIAMM v3.0 Practice: Threat Assessment (TA) Domain: Data 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