Threat Assessment (TA) - Vendors Assessment

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

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

Threat Assessment (TA) - Vendors Domain

HAIAMM Assessment Questionnaire v3.0

Practice: Threat Assessment (TA) Domain: Vendors Purpose: Assess organizational maturity in building the AI-vendor threat library, one threat model per AI-vendor archetype, so every intake produces a fast, consistent threat snapshot in under 30 minutes, and shadow AI has its own explicit threat surface 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, TA-Vendors catalogs threats FROM AI vendors to the organization. Internal LLM tooling the org builds for vendor-risk work belongs in the Software domain's TA practice

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-vendor threat library, produce a threat snapshot at every intake, and explicitly model the shadow AI threat surface.

Question 1: Build the AI-vendor threat library (category-level)

Q1.1: Does the organization have a published, versioned threat library containing one threat model per AI-vendor archetype, covering all five archetypes (consumer GenAI, AI-embedded SaaS feature, AI coding assistant, AI API/foundation-model vendor, AI agent/automation platform), with each archetype's threats tagged to HAI TTPs (EA/AGH/TM/RA), core threat categories (data egress/training-on-your-data, prompt injection, output misuse, tool/function abuse, subprocessor exposure, model-family changes, vendor lock-in), per-archetype shadow AI variant threats, reference incidents, and the PC-Vendors 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 five archetype models published: consumer GenAI, AI-embedded SaaS feature, AI coding assistant, AI API/foundation-model vendor, AI agent/automation platform, each explicitly scoped to threats from AI vendors to the org - [ ] Consumer GenAI archetype covers: training-on-your-data by default setting, prompt injection via shared content, hallucination treated as authoritative, no-DPA exposure when personal accounts used, subprocessor chain opacity (TA/AGH tags) - [ ] AI-embedded SaaS archetype covers: silent AI-feature enablement inheriting full SaaS data scope (EA/TA0006), regulated data flowing to vendor model without DPA (GDPR Art. 28), no-train assertion absent or unverified, vendor model-family swap without notification - [ ] AI coding assistant archetype covers: source-code egress to vendor API (EA/TA0011), confidential code memorization risk, prompt injection via code-file content (AGH/AML.T0051), no-train posture defaults - [ ] AI API/model archetype covers: training-data posture defaults (train-on-your-data enabled), subprocessor exposure (who runs inference), GDPR Arts. 28/44–49 transfer mechanism gaps, model-family silent swap, inference logging retention risks - [ ] AI agent platform archetype covers: permission-model breadth exceeding any individual user (EA/TA0006), AGH via tool-function abuse (TM/AGH), subprocessor scope for tool endpoints, kill-switch absence - [ ] HAI TTP tags at the per-threat level for all five archetypes; compliance linkage per threat to EU AI Act Art. 26, GDPR Arts. 22/28, ISO/IEC 42001 supplier controls, SOC 2 CC9.2

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % of AI vendor intakes with a threat snapshot attached before approval | measure | % | 100% | ☐ | | | Archetype coverage (AI vendor archetypes with a published threat model) | 0 / 5 | ___ / 5 | 5 / 5 | ☐ | | | Median snapshot time per intake | measure | ___ min | ≤30 minutes | ☐ | | | % of active AI vendors in inventory with a current-year snapshot | measure | % | ≥90% | ☐ | |

Metric Collection Guidance: - Snapshot coverage: Count AI vendor intake tickets in the last 90 days with a threat snapshot attached before approval issued. Divide by total intake approvals in that period - Archetype coverage: Count distinct published archetype models for the five AI-vendor archetypes. Target is 5/5 before the intake gate goes live - Snapshot turnaround: Median elapsed time from intake ticket open to threat snapshot delivered, measured over last 30 intakes. Source: intake workflow telemetry - Active vendor snapshot currency: Count active AI vendors in SM inventory with a TA snapshot dated within the current calendar year divided by total active AI vendors

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 AI-vendor threat library)

Evidence Location: _____ Validation Date: ____ Notes: ______

Question 2: Produce a per-intake threat snapshot inside the intake gate

Q2.1: Is a threat snapshot produced inside the PC-Vendors intake gate for every AI vendor intake, delivered in under 30 minutes, documenting the applicable archetype(s), data classes at stake, elevated/reduced/n-a archetype threats for this vendor with justification, top-3 threats with HAI TTP tags and compliance linkage, controls covered by the vendor (from DPA/security questionnaire/SOC 2) vs. gaps for SR/SA follow-up, and reviewer/date/expiry, with 100% of new AI vendor approvals in the last 90 days having a snapshot attached?

Evidence Required: - [ ] Snapshot gate is bound to the PC-Vendors intake: no approval issued without a snapshot attached - [ ] Snapshot template includes: archetype(s), data classes at stake, threat elevation/reduction/n-a assessment with short justification per threat, top-3 threats with HAI TTP tags and compliance linkage, controls covered by vendor (DPA, security questionnaire, SOC 2) vs. gaps, reviewer, date, expiry - [ ] Snapshot expiry rules documented: re-snapshot on contract renewal or material AI-feature change - [ ] 100% of new AI vendor approvals in the last 90 days have a snapshot attached (audit evidence on file) - [ ] Vendor may be tagged to more than one archetype (e.g., Cursor is both AI coding assistant and AI agent platform); composite tagging is reflected in the snapshot

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % of AI vendor intakes with a threat snapshot attached before approval | measure | % | 100% | ☐ | | | Median snapshot time per intake | measure | ___ min | ≤30 minutes | ☐ | | | % of active AI vendors in inventory with a current-year snapshot | measure | % | ≥90% | ☐ | | | Snapshot-to-SR linkage rate (snapshots whose top-3 threats referenced by ≥1 SR-Vendors requirement) | measure | ___% | ≥80% | ☐ | |

Metric Collection Guidance: - Snapshot coverage: Same measurement as Q1, intake tickets with snapshots divided by intake approvals in last 90 days - Snapshot turnaround: Median time from intake ticket open to snapshot delivered. Measure over last 30 intakes - Active vendor snapshot currency: Same as Q1 - SR linkage: After SR-Vendors L1 is operational, cross-reference snapshot top-3 threat IDs against SR-Vendors requirements. Track % of snapshots with ≥1 SR-Vendors cross-reference

Evidence Location: _____ Validation Date: ____ Notes: ______

Question 3: Model the shadow AI threat surface explicitly

Q3.1: Is there a published shadow AI threats document, reviewed by the program sponsor within the last 12 months, that documents entry vectors for unsanctioned AI vendor use, threats specific to shadow AI (no DPA, training-on-your-data by default, no logging, no human-oversight assignment, no subprocessor visibility, no breach-notification SLA, regulated data leaving compliance scope), threat amplifiers (AI features auto-enabled via vendor product updates, agent platforms with permission models broader than any single user), the L1 detections available (egress/DNS signals, expense-data patterns, SaaS-admin audit logs, SSO app catalog drift, employee self-disclosure), and a triage rubric for shadow findings?

Evidence Required: - [ ] "Shadow AI Threats" one-pager exists, is dated, and names the reviewer (program sponsor or delegate) - [ ] Document covers entry vectors: free tier + personal email; AI assistant toggled on inside existing SaaS; browser-extension AI tools; credit-card SaaS under expense thresholds; developer-downloaded OSS models; agent platforms wired to vendor APIs without security review - [ ] Threats specific to shadow AI documented: no DPA, data used for training by default, no logging, no human-oversight assignment, no subprocessor visibility, no breach-notification SLA, regulated data leaving compliance scope - [ ] Threat amplifiers documented: AI features auto-enabled via vendor product updates; AI features in approved SaaS without new contract; agent platforms with permission models broader than any individual user - [ ] L1 detections documented: egress/DNS signals, expense-data patterns, SaaS-admin audit logs, SSO app catalog drift, endpoint inventory, employee self-disclosure via amnesty program - [ ] Triage rubric documented: when a shadow finding becomes an incident (regulated data, customer-facing output, agentic access to internal systems) vs. retroactive intake - [ ] Document feeds ML-Vendors detection backlog and IM-Vendors triage playbook (links on file) - [ ] Shadow AI threat doc published and reviewed in last 12 months

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Shadow AI threat doc published and reviewed in last 12 months | n/a | Yes/No | Yes | ☐ | | | % of AI vendor intakes with a threat snapshot attached before approval | measure | % | 100% | ☐ | | | Archetype coverage (AI vendor archetypes with a published threat model) | 0 / 5 | ___ / 5 | 5 / 5 | ☐ | | | Downstream reuse rate (SR, SA, ST artifacts citing snapshot threats vs. re-deriving) | measure | % | ≥80% | ☐ | |

Metric Collection Guidance: - Shadow threat doc currency: Confirm document exists with review date within last 12 months and program-sponsor approval record - Snapshot coverage: Same measurement as Q1 - Archetype coverage: Same 5/5 metric as Q1 - Downstream reuse: Sample 10 recent SR-Vendors, SA-Vendors, or ST-Vendors artifacts and check whether threats trace back to snapshot top-3 entries rather than being newly derived

Evidence Location: _____ Validation Date: ____ Notes: ______

Maturity Level 2

Objective: Layer per-vendor deep threat models on top of archetype snapshots for Critical/High tiers, integrate external AI-vendor threat intelligence, and red-team the threat library itself quarterly.

Question 4: Per-vendor deep threat modeling for Critical and High-tier vendors

Q4.1: Does every Critical-tier AI vendor have a current-year per-vendor deep threat model, not a recycled archetype snapshot, covering vendor-specific attack trees (custom features, specific subprocessors, model-family choice, API surface, org-specific data flow), a named-adversary abuse-case catalog, EU AI Act Art. 26 deployer-duty mapping, and ATLAS full tactic walk with technique-level specificity, with ≥90% of High-tier vendors receiving the same treatment, and refresh cadence at Critical semi-annual plus change-driven and High annual plus change-driven?

Evidence Required: - [ ] Per-vendor deep threat models exist for 100% of Critical-tier AI vendors; model age does not exceed 180 days for any Critical-tier vendor - [ ] Per-vendor models contain: vendor-specific exposure (custom features, specific subprocessors identified by name, model-family choice, full API surface); org-specific data flow with data class and volume specifics - [ ] Abuse-case catalog names adversary archetypes (external attacker, malicious insider with access to the vendor's admin console, compromised subprocessor, vendor model-family compromise) with concrete attack narratives for this specific vendor - [ ] EU AI Act Art. 26 deployer-duty mapping covers the threat-control chain specific to this vendor (Art. 26 AI-model deployer obligations including training-data posture, human-oversight assignment, incident-reporting chain) - [ ] ATLAS full tactic walk for the vendor integration: all 14 tactics enumerated; technique IDs assigned; exclusions with rationale; training-data posture (TA0002 Resource Development / AML.T0019 if vendor trains on org data) explicitly addressed - [ ] High-tier vendors carry archetype snapshot + vendor-specific deltas + ATLAS tactic walk (no High-tier vendor 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 AI vendors with current-year per-vendor deep threat model | measure | % | 100% | ☐ | | | % High AI vendors with current-year per-vendor deep threat model | 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 AI vendors with a per-vendor deep model dated within 180 days divided by all Critical-tier vendors - High-tier coverage: Count High-tier vendors with archetype snapshot + vendor-specific deltas + ATLAS walk divided by all High-tier vendors - 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 intel item 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-vendor threat intelligence integration

Q5.1: Is external AI-vendor threat intelligence, covering MITRE ATLAS updates, AI Vulnerability Database (AVID) new entries, OWASP LLM/Agentic Top 10 revisions, sector ISAC AI-vendor intelligence, academic security venues tracking AI vendors, and vendor-advisory feeds from Critical-tier vendor trust centers and changelogs, 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 source categories: MITRE ATLAS, AVID, OWASP LLM/Agentic Top 10, sector ISAC AI-vendor intelligence, academic security venues; plus vendor-advisory feeds for all Critical-tier vendors - [ ] Quarterly triage cadence documented: triage session records showing date, intel items reviewed, 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 and closed per quarter | measure | tracked | trending down | ☐ | | | % Critical AI vendors with current-year per-vendor 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 ATLAS/AVID/vendor-advisory items 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 vendor 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-Vendors probes an in-scope AI vendor integration 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 gap closure as a governance activity and the gap rate trending down quarter over quarter?

Evidence Required: - [ ] Quarterly red-team-the-library exercise on file: exercise records show date, vendor integration 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 - [ ] External purple-team participation where possible: industry tabletop or ISAC exercise records on file when available - [ ] Gaps reviewed for SR-Vendors and ST-Vendors update implications

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Library gaps discovered and closed per quarter | measure | tracked | trending down | ☐ | | | % Critical AI vendors with current-year per-vendor deep threat model | measure | % | 100% | ☐ | | | % High AI vendors with current-year per-vendor deep threat model | 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: Verify no Critical gap exceeded 30 days from creation to closure in the last four quarters - 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 publish anonymized AI-vendor threat patterns back to the industry.

Question 7: Telemetry-driven library updates

Q7.1: Does the threat library auto-update from an integrated signal pipeline, consuming ML-Vendors detection patterns, IM-Vendors incident records, MITRE ATLAS updates, AVID new entries, OWASP LLM/Agentic revision drafts, and sector ISAC AI-vendor advisories, 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-Vendors detections and IM-Vendors incident records generate structured candidate threat entries surfaced to the curation queue - [ ] External feed ingestion active: ATLAS, AVID, OWASP LLM/Agentic, sector-ISAC AI-vendor advisories, vendor-advisory feeds for Critical-tier vendors 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 - [ ] Change-log is machine-readable; downstream SR-Vendors and ST-Vendors 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. ATLAS updates, AVID new entries, and Critical-tier vendor advisory notifications are the primary signal types. 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 AI-vendor TTP patterns (training-data posture defaults, subprocessor exposure chains, agent permission-scope inheritance) 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 emerging AI-vendor 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 AI-vendor TTPs discovered through own operations (training-data posture defaults that cause data exfiltration, subprocessor chain exposure mechanics, agent permission-scope inheritance exploitation, shadow AI threat patterns), 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, 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 vendor-domain attack classes: training-data posture defaults, subprocessor exposure, agent permission inheritance, shadow AI threat patterns, model-family swap without notification impacts

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: technical artifact with evidence = counts; comment without evidence = does not count - Recognized TTPs: Check ATLAS commit history, AVID entry list, OWASP revision changelogs for citations - 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 AI-vendor 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, sector ISAC AI working group, or vendor-risk community event) tied to the library?

Evidence Required: - [ ] Anonymized AI-vendor archetype threat models published: public or consortium-accessible URL on file; license is permissive; vendor names and org-specific data flows scrubbed - [ ] Anonymization review record on file confirming vendor 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 AI-vendor 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 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-Vendors practice is at Level ___ . The AI-vendor threat library covers ___ / 5 archetypes (consumer GenAI, AI-embedded SaaS, AI coding assistant, AI API/model, AI agent platform) mapped to HAI TTPs (EA/AGH/TM/RA). Threat snapshots are produced for ___% of AI vendor intakes in under 30 minutes. Shadow AI has its own documented threat surface: [Yes / No / Partial]. [Add narrative on gaps, next steps, and L2/L3 readiness.]

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