> **v3.0 questionnaire.** Source of truth: [`../practices/EH-Vendors-OnePager.md`](../practices/EH-Vendors-OnePager.md). Canonical subject and through-lines: [`../HAIAMM-v3.0-Framing.md`](../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

**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 endpoint/browser/SaaS-admin governance for AI vendors)

**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

**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 classification-gated egress or domain-list governance)

**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

**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 AI-vendor-tuned CASB/SSPM)

**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

**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 SASE per-user/per-device governance for Critical-tier AI SaaS)

**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

**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 per-tenant key/data scope for multi-tenant AI vendor deployments)

**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

**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 IaC for EH-Vendors controls)

**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

**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 adaptive-policy pipeline for EH-Vendors)

**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

**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 industry contributions or adaptive-tightening evidence)

**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