Environment Hardening (EH) - Vendors Assessment

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

v3.0 questionnaire. Source of truth: ../practices/EH-Vendors-OnePager.md. Canonical subject and through-lines: ../HAIAMM-v3.0-Framing.md §8.

Environment Hardening (EH) - Vendors Domain

HAIAMM Assessment Questionnaire v3.0

Practice: Environment Hardening (EH) Domain: Vendors Purpose: Assess organizational maturity in hardening the organization's perimeter against AI-vendor data leakage and shadow AI by tuning SSO/IdP, DLP, browser, endpoint, and SaaS-admin controls for AI-vendor-specific behavior

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

Scoring Methodology

Each question is scored on a 4-tier scale:

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

Level Score = Average of question scores within the level Overall Score = Weighted average across levels (L1: 50%, L2: 30%, L3: 20%)

Maturity Level 1

Objective: Tune SSO/IdP, DLP, browser, endpoint, and SaaS-admin controls to enforce AI-vendor policies and raise the cost of shadow AI so sanctioned use is frictionless and unsanctioned use is observable and often prevented.

Question 1: Identity and SSO Tuning for AI Vendors

Q1.1: Are 100% of sanctioned AI SaaS vendors behind SSO/SAML/OIDC with org-tenant binding enforced, prohibited consumer AI services blocked at egress with explicit rules, and AI-aware DLP rules tuned for prompt-like bulk pastes and file uploads deployed and actively monitored?

Evidence Required: - [ ] IdP configuration records showing SSO/SAML/OIDC enforcement for each sanctioned AI SaaS vendor from the SM-Vendors inventory, local auth disabled on admin tenants where possible - [ ] Org-tenant binding configuration preventing personal-account sign-ins with org domains to consumer GenAI enterprise plans via the IdP - [ ] Service principal / machine identity records for AI API use, scoped, owner-attributed, with rotation schedule; shared static keys tracked and scheduled for replacement - [ ] Egress/DNS/proxy configuration with: (a) known-AI-vendor domain allow-list for sanctioned catalog, (b) explicit block rules for prohibited consumer AI services (personal ChatGPT, personal Claude, personal Gemini); alerting on traffic to unclassified AI-vendor domains - [ ] DLP rule configuration recognizing prompt-like bulk text pastes and file uploads into browser tabs on AI vendor domains, block or warn based on data class - [ ] Conditional access rules for AI vendor SaaS matching risk tier: MFA always enforced; device-trust applied where applicable

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % sanctioned AI SaaS vendors behind SSO | % | % | 100% | ☐ | | | % prohibited consumer AI services blocked at egress (explicit block rules) | % | % | 100% | ☐ | | | DLP rules tuned for AI-vendor paths (prompt-like pastes, file uploads to AI vendor domains) deployed and active | 0 / set | target set | target set defined + deployed | ☐ | | | Blocked-unsanctioned-AI events per quarter (trend measured) | ___ | ___ | tracked; trending up then stabilizing | ☐ | |

Metric Collection Guidance: - SSO coverage: Audit IdP configuration against SM-Vendors sanctioned AI SaaS list; count vendors with SSO as the only auth path. Source: IdP config - Egress block coverage: Audit egress/proxy/DNS configuration against prohibited AI vendor list; count prohibited domains with explicit block rules. Source: egress / proxy config - DLP rule deployment: Confirm AI-vendor-path DLP rules are active in DLP management console; verify rules cover prompt-paste and file-upload scenarios. Source: DLP management - Unsanctioned AI events: Count DLP or egress block events attributed to prohibited AI vendor domains per quarter. Source: DLP/egress alert telemetry

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 SSO tuning or AI-vendor DLP)

Evidence Location: __ Validation Date: __ Notes: ___

Question 2: Browser, Endpoint, and SaaS-Admin Governance for AI Vendors

Q2.1: Does endpoint AI-app and extension inventory cover ≥95% of managed endpoints via MDM/EDR, with developer-endpoint coding-assistant policy (IDE version, regulated-repo exclusion) actively enforced, and is an AI-feature registry published for every approved parent SaaS vendor with a default-off posture?

Evidence Required: - [ ] MDM/EDR AI-app and browser-extension inventory configuration covering managed endpoints; allowlist managed for sanctioned AI desktop apps and browser extensions; alerts on unsanctioned install - [ ] Managed-browser policy (Chrome Enterprise, Edge Enterprise, or equivalent) limiting AI extension installation to approved allowlist; separate-profile model for work/personal; tab-level data-loss alerts on AI vendor domains - [ ] Developer-endpoint AI coding assistant policy records: approved IDE, approved version range, regulated-repo exclusion list; exclusion list confirmed pushed to IDE plugin configuration - [ ] AI-feature registry per approved parent SaaS vendor, which AI features exist, which are enabled, who has access; registry version-controlled - [ ] Default posture configuration, AI features off org-wide until PC intake has covered them; turn-on action is change-managed - [ ] Admin-audit feed configuration from parent SaaS vendors to detect silent new AI features shipped by the vendor; quarterly review by named admin-governance owner with documented evidence

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Endpoint AI-app inventory coverage | % | % | ≥95% of managed endpoints | ☐ | | | % approved parent-SaaS vendors with documented AI-feature registry | % | % | 100% | ☐ | | | Quarterly parent-vendor AI-feature panel review cadence, reviews completed with evidence | /year | /year | 4/year | ☐ | | | Shadow AI ratio, % reduction attributable to hardening controls (trend measured) | % | % | trending down | ☐ | |

Metric Collection Guidance: - Endpoint AI-app coverage: Query MDM/EDR inventory for managed endpoint count vs. endpoints with AI-app policy applied. Source: MDM/EDR compliance dashboard - AI-feature registry coverage: Audit AI-feature registry against approved parent-SaaS vendor list; count vendors with a registry entry. Source: registry - Quarterly review cadence: Count completed quarterly reviews with evidence per year. Source: governance review records - Shadow AI ratio trend: Cross-reference SM-Vendors inventory shadow-AI discovery trend against the quarter hardening controls were activated. Source: SM-Vendors inventory trend × IM-Vendors events

Evidence Location: __ Validation Date: __ Notes: ___

Question 3: Classification-Gated Egress per Vendor

Q3.1: Is a per-vendor classification-gated egress policy active, preventing regulated PII/PHI/PCI from flowing to AI vendor domains without an explicit approval gate, and are sanctioned AI vendor domains distinguished from general SaaS in egress and DLP configurations with monthly domain-list refresh cadence?

Evidence Required: - [ ] Per-vendor classification-gated egress policy configuration: regulated data classes (PII, PHI, PCI) blocked from flowing to AI vendor domains without an explicit approval gate documented in the SM-Vendors record - [ ] Sanctioned vs. prohibited AI vendor domain segmentation in egress/DNS/proxy, AI vendor domains treated as a distinct category from general SaaS for DLP rule targeting - [ ] Monthly domain-list refresh cadence records, sanctioned and prohibited AI vendor lists reviewed monthly; new consumer GenAI services added to prohibition list within cycle - [ ] DLP rule quarterly tuning records, AI-specific rules reviewed for false-positive/false-negative rate; tuning changes logged - [ ] Evidence that the egress blocklist covers the prohibition list comprehensively, not only major consumer services but mid-tier GenAI services discovered via shadow-AI telemetry - [ ] Process evidence that when a new unsanctioned AI vendor domain is discovered via egress telemetry, it is assessed and added to the prohibition list within 5 business days

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % AI vendor domain categories with explicit egress classification (sanctioned vs. prohibited vs. unclassified) | % | % | 100% | ☐ | | | Frictionless sanctioned adoption, time-to-productive for users of sanctioned AI vendors (SSO-backed) | days | days | no regression as hardening tightens | ☐ | | | Monthly domain-list refresh completed with evidence | /year | /year | 12/year | ☐ | | | Newly discovered unsanctioned AI vendor domains assessed and added to prohibition list within 5 business days | % | % | 100% | ☐ | |

Metric Collection Guidance: - Domain classification coverage: Audit egress/proxy config; count AI vendor domains with explicit classification vs. unclassified. Source: egress / proxy config - Time-to-productive: Survey or ticket-time analysis for new sanctioned AI vendor onboarding. Source: IT service desk / onboarding tickets - Domain-list refresh cadence: Count monthly domain-list review records completed with evidence per year. Source: governance review records - New domain response SLA: Count newly discovered unsanctioned domains added within 5 business days / total new domains discovered. Source: shadow-AI telemetry × egress config change log

Evidence Location: __ Validation Date: __ Notes: ___

Maturity Level 2

Objective: Extend hardening with CASB/SSPM tuned for AI vendors, SASE-level egress governance with per-user/per-device granularity, and per-tenant isolation in multi-tenant AI vendor deployments.

Question 4: CASB/SSPM Enforcement Tuned for AI Vendors

Q2.1: Are AI-vendor-tuned CASB/SSPM policies deployed with a named owner, detecting bulk-paste, file-upload, and tool-invocation patterns specific to AI vendors, with false-positive rates on AI-specific signals actively monitored and trending down?

Evidence Required: - [ ] CASB (Netskope, Defender for Cloud Apps, Zscaler, Cisco Umbrella, or equivalent) policy configuration tuned for AI vendor behaviors: bulk-paste detection on AI vendor domains, file upload controls, tool-invocation detection where API visibility permits - [ ] SSPM (Obsidian, Adaptive Shield, AppOmni, or equivalent) configuration focused on parent-SaaS AI-feature config drift and admin-console changes, alert routing to named owner - [ ] Named owner record for AI-vendor-tuned CASB/SSPM policies, responsible for monthly policy review - [ ] Monthly CASB/SSPM policy review cadence records, AI-specific rule performance (false-positive, false-negative rates) reviewed and changes logged - [ ] SSPM alert routing configuration, config-drift alerts from AI-feature panels route to triage queue with defined SLA, not a shared inbox with no owner - [ ] Evidence that CASB/SSPM signals produce AI-vendor-specific findings distinct from generic SaaS noise

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | AI-vendor-tuned CASB policies deployed with named owner | ☐ yes / ☐ no |, | yes | ☐ | | | False-positive rate on AI-specific DLP/CASB signals (trend) | % | % | actively tuned; trending down | ☐ | | | Monthly CASB/SSPM review cadence completed with evidence | /year | /year | 12/year | ☐ | | | SSPM AI-feature config drift alerts triaged within defined SLA | % | % | 100% within SLA | ☐ | |

Metric Collection Guidance: - CASB policy deployment: Verify AI-vendor-specific CASB policies are active and assigned to a named owner in the CASB management console. Source: CASB config - False-positive rate trend: Count CASB/DLP alerts tagged as false-positive per month for AI-vendor paths; compute rate and track trend. Source: alerting telemetry - Monthly review cadence: Count monthly CASB/SSPM review records with documented outcomes per year. Source: governance review records - SSPM alert triage SLA: Count SSPM config-drift alerts triaged within defined SLA / total SSPM alerts. Source: SSPM alert telemetry × triage records

Evidence Location: __ Validation Date: __ Notes: ___

Question 5: SASE Per-User/Per-Device Egress Governance for Critical-Tier AI SaaS

Q2.2: Are 100% of Critical-tier AI SaaS vendors under SASE per-user/per-device egress policy requiring device-trust for session establishment, with SASE policy drift audited quarterly, and content inspection active on outbound AI-provider API calls where permissible?

Evidence Required: - [ ] SASE (Zscaler, Netskope, Palo Alto Prisma, or equivalent) per-user/per-app/per-device policy records for Critical-tier AI SaaS vendors from the SM-Vendors tier-treatment matrix - [ ] Device-trust enforcement configuration, policy-based access to Critical-tier AI SaaS requires device-trust posture (MDM-enrolled, compliant) and current session; unmanaged-device access blocked - [ ] API content inspection configuration (where DPA and provider terms permit) for Critical-tier AI SaaS vendor API calls, alert on bulk-export patterns (large prompt/completion payloads, embedding batch exports) - [ ] Quarterly SASE policy drift audit records, deviations from declared per-user rules identified and resolved as IM-Vendors findings within 5 business days - [ ] Per-user/per-device rule configuration evidence showing rules are per-user (not coarse allow/deny) for Critical-tier AI SaaS domains - [ ] Reduced unsanctioned AI-vendor egress volume trend attributable to SASE per-user tuning

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % Critical-tier AI SaaS under SASE per-user/per-device policy with device-trust required | % | % | 100% | ☐ | | | Quarterly SASE policy drift audit completed with evidence | /year | /year | 4/year | ☐ | | | SASE policy drift deviations resolved as IM-Vendors findings within 5 business days | % | % | 100% | ☐ | | | Unsanctioned AI-vendor egress volume reduction attributable to SASE tuning (trend) | % | % | trending down | ☐ | |

Metric Collection Guidance: - SASE per-user coverage: Audit SASE policy registry for Critical-tier AI SaaS vendors; verify per-user/per-device rules with device-trust enforcement. Source: SASE telemetry - SASE drift audit cadence: Count quarterly SASE policy drift audits completed with evidence per year. Source: governance audit records - Drift deviation resolution SLA: Count SASE policy drift deviations routed as IM-Vendors findings within 5 business days / total deviations. Source: policy audit × IM-Vendors backlog - Egress volume trend: Measure unsanctioned AI-vendor egress volume (bytes or sessions) per quarter; compare before and after SASE per-user rule activation. Source: SASE telemetry

Evidence Location: __ Validation Date: __ Notes: ___

Question 6: Per-Tenant Key/Data Scope for Multi-Tenant AI Vendor Deployments

Q2.3: Are ≥90% of multi-tenant AI vendor deployments enforcing per-tenant key and data scope in the secret manager and IdP, with admin governance distinguishing tenant-scoped vs. org-wide settings, and is per-tenant scope audited quarterly?

Evidence Required: - [ ] Per-tenant key scope configuration in the secrets vault / secret manager for AI API integrations used at vendor boundaries, each tenant uses a separate scoped key, not a shared org-level API key - [ ] Per-tenant data scope configuration in shared AI-vendor environments, data partitioning or access-control boundary enforced at the vendor platform layer - [ ] Admin-governance model documentation distinguishing tenant-scoped settings (per-tenant API keys, per-tenant data boundaries) vs. org-wide settings (DLP policies, SSO enforcement) - [ ] Quarterly per-tenant scope audit records, confirming per-tenant key and data scope are enforced and have not drifted to shared org-level configuration - [ ] IR-Vendors review records confirming fewer cross-tenant findings after per-tenant scope enforcement - [ ] Evidence that all integrations sharing an org-level API key have been identified and are on a migration timeline to per-tenant scope

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % multi-tenant AI-vendor deployments with per-tenant key/data scope enforced | % | % | ≥90% | ☐ | | | Quarterly per-tenant scope audits completed with evidence | /year | /year | 4/year | ☐ | | | Cross-tenant findings in IR-Vendors reviews for multi-tenant AI vendor deployments (trend) | ___ | ___ | trending down | ☐ | | | Integrations sharing org-level API key (not per-tenant scope) remaining on migration backlog | ___ | ___ | tracked; declining | ☐ | |

Metric Collection Guidance: - Per-tenant scope coverage: Audit secret manager for AI API integrations; count integrations using per-tenant scoped keys vs. shared org-level keys. Source: IdP + secret manager - Audit cadence: Count quarterly per-tenant scope audit records completed with evidence per year. Source: governance audit records - Cross-tenant findings trend: Count cross-tenant findings in IR-Vendors reviews for multi-tenant AI vendor deployments per quarter; track trend. Source: IR-Vendors findings log - Migration backlog: Count integrations on migration backlog to per-tenant scope at each quarter. Source: IM-Vendors backlog

Evidence Location: __ Validation Date: __ Notes: ___

Maturity Level 3

Objective: Adaptive policy tightening from ML-Vendors detections and IM-Vendors incidents; all EH controls expressed as IaC; contribute AI-vendor hardening baselines to CIS, CSA AI Safety Initiative, and sector ISACs.

Question 7: Hardening-as-Code, IaC for All EH-Vendors Controls

Q3.1: Are ≥90% of EH-Vendors controls expressed as IaC (Terraform, OPA, Rego, Kyverno, or equivalent), covering CASB policies, DLP rules, SASE rules, SSO policies, and MDM/EDR AI-tooling configuration, with drift detected continuously and ≥70% of low-risk drift auto-remediated?

Evidence Required: - [ ] IaC registry records showing CASB policy configuration, DLP rule sets (AI-specific patterns), and SASE per-user/per-device rules expressed as configuration-as-code, deployed as authoritative source, not stubs - [ ] SSO/IdP policy configuration (sanctioned AI SaaS, org-tenant binding, conditional access for AI vendor sessions) expressed as IaC - [ ] MDM/EDR AI-tool allowlist and browser policy configuration (AI extension allowlist, tab-level alert rules) expressed as configuration profiles deployable via MDM API - [ ] Drift-detection pipeline running on a scheduled cadence against deployed CASB, DLP, SASE, and MDM configurations; low-risk drift auto-remediated; high-risk drift (DLP rule removed, SASE per-user rule disabled, prohibited vendor unblocked) triggers human-review alert within 2 business days - [ ] Machine-readable change log for auto-remediation events visible to downstream network and identity teams - [ ] IaC module updates notify consuming teams with a required-remediation flag

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % EH-Vendors controls expressed as IaC (authoritative deployed source, not stubs) | % | % | ≥90% | ☐ | | | IaC drift auto-remediation rate for low-risk findings | % | % | ≥70% | ☐ | | | High-risk drift findings human-reviewed within 2 business days | % | % | 100% | ☐ | | | Reviewer-hours per EH-Vendors policy change (trend) | ___ | ___ | trending down quarter-over-quarter | ☐ | |

Metric Collection Guidance: - IaC coverage: Count EH-Vendors controls with authoritative IaC / total EH-Vendors controls. Source: IaC registry - Auto-remediation rate: Count low-risk drift findings auto-remediated / total low-risk drift findings per quarter. Source: remediation telemetry - High-risk drift review SLA: Count high-risk findings with human review within 2 business days / total high-risk findings. Source: policy change log × IM-Vendors backlog - Reviewer-hours per change: Track security engineer hours spent per EH-Vendors policy change event quarter-over-quarter. Source: time-tracking / change management

Evidence Location: __ Validation Date: __ Notes: ___

Question 8: Adaptive Policy Tightening from ML-Vendors and IM-Vendors Signals

Q3.2: Is an adaptive-policy pipeline operational, with ML-Vendors detections and IM-Vendors incidents generating human-approved policy-tightening proposals on a tracked cadence, every change traceable to a source signal, and the change log machine-readable?

Evidence Required: - [ ] Adaptive-tightening pipeline configuration wiring ML-Vendors detection signals (shadow AI discovery, unsanctioned AI egress spike, CASB bulk-paste detection) to tightening proposal generation (e.g., DLP rule sensitivity increase, SASE per-user rule tightening, new prohibited domain addition) - [ ] Adaptive-tightening pipeline configuration wiring IM-Vendors post-incident review records to hardening-baseline update proposals - [ ] Human-approval gate for all proposals before deploy - [ ] Machine-readable change log records showing source signal (ML-Vendors detection ID or IM-Vendors incident ID), approval record, and downstream notification per tightening change - [ ] Evidence that downstream network and identity teams are notified within 24 hours of a tightening change affecting their configuration scope - [ ] Adaptive-policy pipeline freshness monitoring, ML-Vendors and IM-Vendors signal feeds checked weekly; stale feeds (>14 days without a processed event) flagged

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Adaptive-policy changes per quarter traceable to ML-Vendors or IM-Vendors source signal | 0 | ___ | tracked; growing | ☐ | | | % adaptive-policy proposals human-approved before deploy | % | % | 100% | ☐ | | | Downstream teams notified within 24h of tightening change | % | % | 100% | ☐ | | | Stale signal feeds (>14 days without processed ML-Vendors or IM-Vendors event) | ___ | ___ | 0 stale feeds | ☐ | |

Metric Collection Guidance: - Traceable changes: Count policy changes in change log with valid source signal reference per quarter. Source: policy change log - Human-approval rate: Count proposals deployed with approval record / total proposals deployed. Source: policy change log - Notification SLA: Count tightening changes with downstream team notification within 24h / total. Source: notification log - Signal feed freshness: Check last-processed timestamp for each ML-Vendors and IM-Vendors feed; flag feeds with >14 days since last event. Source: pipeline monitoring

Evidence Location: __ Validation Date: __ Notes: ___

Question 9: Industry AI-Vendor Hardening Baseline Contributions

Q3.3: Does the program contribute ≥2 AI-vendor hardening baselines per year to industry bodies, CIS AI workloads, CSA AI Safety Initiative, or sector ISACs, with documented adoption and baselines maintained upstream aligned with current internal practice?

Evidence Required: - [ ] Contribution records showing ≥2 substantive submissions per year to CIS AI workloads, CSA AI Safety Initiative, or sector ISACs (FS-ISAC, H-ISAC, IT-ISAC AI working groups), e.g., DLP AI-path pattern library, CASB AI-vendor policy template, SASE AI-vendor egress ruleset - [ ] Evidence of adoption or citation of contributed baselines by the recipient body - [ ] Maintenance records confirming internal practice stays aligned with the published external version, not a one-time contribution left to diverge - [ ] Quarterly adaptive-policy change log traceable to ML-Vendors detections and IM-Vendors incident patterns - [ ] Evidence that shadow-AI incidents decreased attributable to adaptive DLP/SASE tightening driven by ML detections, measured as fewer IM-Vendors blocker/critical events per quarter - [ ] IaC coverage growth rate tracked month-over-month with target ≥90% before the quarter closes

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Industry AI-vendor hardening baseline contributions per year | 0 | ___ | ≥2 | ☐ | | | Contributed baselines maintained upstream (internal practice aligned with published version) | ☐ yes / ☐ no |, | yes | ☐ | | | Shadow-AI incidents attributable to adaptive DLP/SASE tightening (IM-Vendors blocker/critical events per quarter) | ___ | ___ | trending down | ☐ | | | Adaptive-policy change log machine-readable with source signal reference field confirmed | ☐ yes / ☐ no |, | yes | ☐ | |

Metric Collection Guidance: - Contribution count: Count published contributions with named recipient body and contribution artifact per calendar year. Source: contribution log - Maintenance alignment: Review most recent version of each contributed baseline; confirm it reflects current internal practice. Source: contribution log × practice review - Shadow-AI incident trend: Count IM-Vendors blocker/critical events per quarter attributed to shadow AI; compare before and after adaptive-tightening activation. Source: IM-Vendors event log - Change log format: Confirm policy change log is machine-readable (JSON/YAML) with source signal reference field populated on each entry. Source: policy change log audit

Evidence Location: __ Validation Date: __ Notes: ___

Summary Scorecard

Level	Question	Score (0.0 / 0.33 / 0.67 / 1.0)
L1	Q1: Identity and SSO Tuning for AI Vendors	___
L1	Q2: Browser, Endpoint, and SaaS-Admin Governance	___
L1	Q3: Classification-Gated Egress per Vendor	___
L2	Q4: CASB/SSPM Enforcement Tuned for AI Vendors	___
L2	Q5: SASE Per-User/Per-Device Egress Governance	___
L2	Q6: Per-Tenant Key/Data Scope for Multi-Tenant AI Vendors	___
L3	Q7: Hardening-as-Code IaC for EH-Vendors Controls	___
L3	Q8: Adaptive Policy Tightening	___
L3	Q9: Industry AI-Vendor Hardening Baseline Contributions	___

L1 Score (avg Q1–Q3): ___ L2 Score (avg Q4–Q6): ___ L3 Score (avg Q7–Q9): ___ Overall Score (L1×0.5 + L2×0.3 + L3×0.2): ___

Document Version: HAIAMM v3.0 Practice: Environment Hardening (EH) Domain: Vendors Questionnaire Date: 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