Policy & Compliance (PC) - Vendors Assessment

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

Policy & Compliance (PC) - Vendors Domain

HAIAMM Assessment Questionnaire v3.0

Canonical source-of-truth: ../practices/PC-Vendors-OnePager.md. The canonical v3.0 model: ../HAIAMM-v3.0-Framing.md.

Practice: Policy & Compliance (PC) Domain: Vendors Purpose: Publish the priority policies and compliance map that make a Vendor AI Assurance program enforceable, so adoption of AI/HAI tools from vendors is gated, attributable, and defensible to auditors, regulators, and customers. Shadow AI prevention is the primary L1 outcome. Scoring Model: Evidence + Outcome Metrics

Instructions

Current, implemented practices only.
Evidence + Outcome Metrics per question.
4-tier scoring: Fully Mature (1.0), Implemented (0.67), Partial (0.33), Not Implemented (0.0).
Answer progressively. Achieve all L(N) questions before L(N+1).

Scoring Methodology

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

Practice maturity level achieved = highest level where all 3 questions score ≥ 0.67.

Maturity Level 1

Objective: Publish the three priority AI vendor policies, map them to priority compliance requirements, and gate new AI vendor adoption through a lightweight intake.

Question 1: Publish the three priority AI vendor policies

Q1.1: Have you published and formally approved all three AI vendor policies, AI Acceptable Use Policy, AI Procurement & Intake Policy, and AI Vendor Data-Sharing Policy, with AI-specific clauses covering prohibited data classes, personal-account prohibition, AI-feature-inside-SaaS intake requirement, training-on-data default-off, and DPA/AI addendum requirement?

Evidence Required: - [ ] AI Acceptable Use Policy (AUP) approved by Legal/Privacy and Security, listing the approved AI vendors catalog, data classes prohibited from any AI vendor (regulated data, source code, customer PII without DPA, third-party confidential info under NDA), personal-account prohibition, output review duty, and disclosure obligation - [ ] AI Procurement & Intake Policy specifying that no AI tool may be paid for, installed, integrated, or enabled without an intake ticket, explicitly including AI-embedded features in already-approved SaaS (Notion AI, Slack AI, Zoom AI Companion, M365 Copilot, Gemini in Workspace); intake produces risk tier assignment, DPA/AI addendum confirmation, AUP-aligned data-handling decision, business owner and renewal date - [ ] AI Vendor Data-Sharing Policy establishing training-on-customer-data posture as off by default, DPA/AI addendum mandatory for any AI vendor receiving non-public data, subprocessor disclosure required, data residency and cross-border transfer requirements, retention and deletion terms explicit, and incident notification SLA from vendor (≤72 hours) - [ ] All three policies are accessible to every employee who adopts tools and require attestation at hire and annually; violations are routed through normal HR channels - [ ] Amnesty/exception path for already-in-use shadow AI is documented: disclose without penalty, retroactive intake - [ ] Intake SLA is published (triage ≤5 BD; fast-track for already-approved parent vendors)

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |---|---|---|---|---|---| | % workforce with acknowledged AI AUP (current-year attestation) | measure | ___ | ≥95% | ☐ | | | % AI vendors receiving non-public data with executed DPA / AI addendum | measure | ___ | 100% | ☐ | | | Priority compliance map published and reviewed in last 12 months | n/a | ___ | Yes | ☐ | | | Three priority policies approved by Legal/Privacy + Security | n/a | ___ | Yes (all three) | ☐ | |

Metric Collection Guidance: - AUP attestation rate: Query HR/LMS for current-year AUP acknowledgment completions divided by total workforce headcount; run monthly. - DPA/AI addendum coverage: Query the legal contract store for all AI vendors listed in the SM-Vendors inventory that receive non-public data; verify each has an executed DPA or AI addendum on file. - Compliance map publication: Verify the one-page compliance map is in the document registry with an approval date within the last 12 months and is linked from each policy. - Policy approvals: Verify Legal/Privacy and Security sign-off records exist for all three policies in the document management system.

Answer: - ☐ Fully Mature (Evidence complete + ≥3 outcome metrics meet targets) - ☐ Implemented (Evidence complete + 2 outcome metrics meet targets) - ☐ Partial (Evidence partially complete + <2 outcome metrics meet targets) - ☐ Not Implemented (No substantive evidence)

Evidence Location: ___ Metric Validation Date: ___ Notes: ___

Question 2: Map the three policies to the priority AI vendor compliance requirements

Q1.2: Is there a published one-page priority compliance map that traces each priority requirement, EU AI Act Art. 26/50, NIST AI RMF GOVERN, GDPR Art. 28/22/44–49, SOC 2 CC9.2, ISO/IEC 42001, ISO/IEC 27001 A.5.19–A.5.23, and applicable sector-specific obligations, to the specific AI vendor policy that carries it?

Evidence Required: - [ ] One-page compliance map exists in the document registry, linked from each of the three policies, covering all priority requirements - [ ] EU AI Act Art. 26 deployer duties row traces to AUP (role boundaries, output review duty) and Intake Policy (risk tier assignment, logging attestation, human oversight) - [ ] GDPR Art. 28 processor and Art. 44–49 transfers row traces to Data-Sharing Policy (DPA/AI addendum, subprocessor list, SCCs/UK IDTA for cross-border transfers) - [ ] GDPR Art. 22 automated decision-making row traces to AUP (role boundaries and output review) and Intake Policy (flag decision-affecting use cases at intake) - [ ] SOC 2 CC9.2 vendor management row traces to Intake Policy (risk tier assignment, renewal review date) - [ ] ISO/IEC 27001 A.5.19–A.5.23 supplier relationships rows trace to Data-Sharing Policy (security requirements in agreements) and Intake Policy (managing change, monitoring); sector-specific (HIPAA BAA for PHI, PCI-DSS 12.8 for CHD, FINRA/SEC model-risk, HHS/FDA where clinical) are mapped to Data-Sharing Policy or Intake risk tier rows

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |---|---|---|---|---|---| | Priority compliance map published and reviewed in last 12 months | n/a | ___ | Yes | ☐ | | | % active AI vendors with current AUP-aligned data-handling decision on file | measure | ___ | ≥90% | ☐ | | | % new AI vendor adoptions routed through the intake gate | measure | ___ | ≥80% | ☐ | | | Auditor evidence turnaround for EU AI Act Art. 26 deployer-duty inquiry | measure | ___ | satisfied within 5 BD (last 12 months) | ☐ | |

Metric Collection Guidance: - Compliance map review: Check document registry for version date and approval record within the past 12 months; verify all priority requirement rows are present including sector-specific rows. - Data-handling decision coverage: Query the SM-Vendors inventory for all active AI vendors; verify each has a data-handling decision record (permitted data classes, AUP alignment confirmation) that is current. - Gate adoption rate: Divide the count of new AI vendor adoptions that came through the intake queue by the total count of new vendors in the SM-Vendors inventory for the same period; exclude retroactive amnesty records from the denominator. - Auditor turnaround: Review any compliance or external audit requests in the last 12 months; confirm the team produced an intake record within 5 business days.

Evidence Location: ___ Metric Validation Date: ___ Notes: ___

Question 3: Operate the intake gate and track foundational compliance outcomes

Q1.3: Is the AI vendor intake gate operational with a published SLA, an amnesty path for previously undisclosed AI use, ≥95% AUP attestation, and 100% DPA/AI-addendum coverage for AI vendors handling non-public data?

Evidence Required: - [ ] Single intake form and ticket queue exist with a published SLA (triage ≤5 BD; fast-track path for already-approved parent vendors); no parallel paths - [ ] Pre-approved AI vendors expose a fast-track path to avoid redundant full reviews for subsequent business-unit requests - [ ] Gate is integrated with procurement: no PO or SaaS expense reimbursement issued without an intake ID; approval creates/updates the SM-Vendors inventory record - [ ] Amnesty path is visible and accessible: disclosed shadow AI use enters retroactive intake without penalty; retroactive intake records exist in the SM-Vendors inventory - [ ] Exceptions are logged with owner and review date; exceptions open >90 days are tracked and should trend toward zero - [ ] Sanctioned AI vendor catalog is refreshed at least quarterly

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |---|---|---|---|---|---| | % new AI vendor adoptions routed through the intake gate (vs. discovered after the fact) | measure | ___ | ≥80% | ☐ | | | % active AI vendors with current AUP-aligned data-handling decision on file | measure | ___ | ≥90% | ☐ | | | % AI vendors receiving non-public data with executed DPA / AI addendum | measure | ___ | 100% | ☐ | | | Intake triage SLA adherence (≥90% within 5 BD) | measure | ___ | ≥90% | ☐ | |

Metric Collection Guidance: - Gate adoption rate: Divide the count of new AI vendor adoptions that came through the intake queue in the last quarter by the total count of new vendors discovered (intake + shadow-discovery); confirm the proactive adoption rate is ≥80%. - Data-handling decision coverage: Query the SM-Vendors inventory for all active AI vendors; verify each has a current data-handling decision record. - DPA/AI addendum coverage: Query the legal contract store for AI vendors in the SM-Vendors inventory that receive non-public data; verify 100% have an executed DPA or AI addendum on file. - SLA adherence: From the intake ticket queue, calculate the % of tickets where triage timestamp minus submission timestamp is ≤5 BD.

Evidence Location: ___ Metric Validation Date: ___ Notes: ___

Maturity Level 2

Objective: Deepen policies and compliance evidence per AI vendor risk tier, bind intake decisions to ongoing vendor attestations, and produce audit-ready evidence trails automatically.

Question 1: Tier-aware policy depth and contractual controls

Q2.1: Have the three priority AI vendor policies been extended with tier-specific addenda, and do Critical vendors carry contractual right-to-audit, right-to-test, model-version change notification ≥30 days, subprocessor add-notice ≥30 days with opt-out, incident-notification SLA ≤24 hours, and training-data provenance attestation?

Evidence Required: - [ ] Tier-specific addenda exist for Critical, High, Medium, and Low vendor tiers, referencing the SM-Vendors L2 tier definitions - [ ] Critical tier contractual controls are in place: right-to-audit, right-to-test (red-team), model-version change notification ≥30 days, subprocessor add-notice ≥30 days with opt-out right, incident-notification SLA ≤24 hours, training-data provenance attestation; these controls appear in executed vendor contracts, not policy only - [ ] High tier requires: subprocessor add-notice, incident-notification SLA ≤72 hours, annual SOC 2/ISO 27001 evidence refresh, model-version change notification - [ ] Policy-exception framework requires named owner, compensating control description, and expiry date (max 12 months); unsanctioned AI in Critical-tier use cases is a blocking finding, no amnesty path - [ ] Contract templates have been updated to include tier-appropriate language; a documented redline framework exists for handling Critical-tier vendor pushback - [ ] Gate records show tier-appropriate contractual controls are in executed contracts for ≥90% of Critical/High AI vendors

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |---|---|---|---|---|---| | % Critical/High vendors with executed tier-appropriate contractual controls | measure | ___ | ≥90% | ☐ | | | % Critical/High AI vendors with complete compliance evidence view | measure | ___ | ≥95% | ☐ | | | Exception register: % exceptions with named owner, compensating control, expiry date | measure | ___ | 100% | ☐ | | | Regulatory inquiry turnaround (evidence view for regulator/auditor <5 BD) | measure | ___ | Yes (last 12 months) | ☐ | |

Metric Collection Guidance: - Contractual controls coverage: For each Critical/High AI vendor in the SM-Vendors inventory, check the legal contract store for executed agreement language covering each tier-required clause; compute % of vendors with all tier-appropriate clauses present. - Evidence view completeness: For each Critical/High vendor, check that all required compliance view elements (DPA/AI addendum, subprocessor list with last-update date, training-data posture, current SOC 2/ISO evidence, model-version log, incident history, deployer-duty evidence) are present and within refresh windows. - Exception register completeness: Audit every entry; each must have owner, compensating control with reviewer acknowledgment, and expiry date. - Auditor turnaround: Review any regulatory or auditor inquiries in the last 12 months; confirm each was answered within 5 business days.

Evidence Location: ___ Metric Validation Date: ___ Notes: ___

Question 2: Continuous vendor attestation and compliance evidence assembly

Q2.2: Does every Critical or High AI vendor have a live, continuously-assembled compliance evidence view, covering DPA/AI addendum, subprocessor list, training-data posture, SOC 2/ISO evidence, model-version log, incident history, and deployer-duty evidence, with staleness inside tier-specific targets?

Evidence Required: - [ ] Compliance evidence view is implemented for each Critical and High AI vendor; the view auto-assembles: current DPA/AI addendum (versioned), subprocessor list with last-update date, training-data posture statement and source, current SOC 2 Type II/ISO 27001 or equivalent, model-version and notable changes log, incident-notification history (vendor-side), deployer-duty evidence from ML-Vendors (logs, human-oversight assignments, disclosures) - [ ] Staleness rules are defined and enforced by tier (Critical quarterly, High semi-annually); any element past its refresh window raises a PC-Vendors finding routed to IM - [ ] Vendor material-change tracker is refreshed weekly from vendor changelogs, trust-center pages, and notification feeds; vendor-side changes auto-open tickets to refresh the evidence view - [ ] Sector-specific evidence bundles are generated from the compliance view: HIPAA BAA evidence set (BAA, minimum-necessary assessment), PCI SP evidence set (scope assessment, encryption evidence), clinical-AI evidence set, financial-services evidence set; completeness is tracked for applicable vendors - [ ] The evidence view is the primary artifact delivered to regulators or auditors; a completed view can be assembled for any Critical/High vendor without specialist intervention - [ ] Evidence registry is queryable to report median staleness across Critical/High vendor view elements

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |---|---|---|---|---|---| | % Critical/High AI vendors with complete compliance evidence view | measure | ___ | ≥95% | ☐ | | | Median staleness of compliance-view elements (Critical/High) | measure | ___ | ≤30 days past refresh window | ☐ | | | Sector-specific evidence bundle completeness (HIPAA/PCI/sector as applicable) | measure | ___ | 100% for in-scope vendors | ☐ | | | Audit findings on AI-vendor control set, repeat findings | measure | ___ | 0 | ☐ | |

Metric Collection Guidance: - Evidence view completeness: For each Critical/High vendor, check each required element is present and within its refresh window; count vendors where all elements are current; divide by total Critical/High vendors. - Median staleness: For each Critical/High vendor's compliance view, calculate days since each element's last refresh; compute median across all Critical/High vendors. - Sector bundle completeness: For each vendor in scope of HIPAA, PCI, or other sector regulations, verify the corresponding sector evidence bundle is assembled with all required documents present and current. - Repeat findings: Review the last completed compliance or external audit report; count findings that also appeared in the prior audit cycle.

Evidence Location: ___ Metric Validation Date: ___ Notes: ___

Question 3: Exception management and tier-aware enforcement

Q2.3: Is an exception register operated with named owners, compensating controls, and expiry dates, reviewed monthly, with unsanctioned AI in Critical-tier use cases subject to blocking enforcement, and sector-specific evidence bundles complete for in-scope vendors?

Evidence Required: - [ ] Exception register is integrated with intake; no exception is approved without tier-appropriate compensating control definition and expiry date - [ ] Monthly exception aging review is scheduled and conducted; exceptions more than 90 days past expiry auto-escalate to the program sponsor - [ ] Enforcement asymmetry is implemented: unsanctioned AI in Critical-tier use cases triggers a blocking IM finding, it cannot be routed through amnesty; all other tiers continue to use the amnesty path - [ ] Sector-specific evidence bundles are generated for applicable vendors: HIPAA BAA evidence set, PCI SP evidence set, clinical-AI evidence set, financial-services evidence set; completeness is tracked and reported - [ ] Policy-exception volume is tracked quarterly and the trend is not increasing - [ ] Audit trail of policy enforcement is documented with artifacts, not tribal knowledge

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |---|---|---|---|---|---| | Exception register: % exceptions with named owner, compensating control, expiry date | measure | ___ | 100% | ☐ | | | % exceptions past expiry escalated to program sponsor | measure | ___ | 100% | ☐ | | | Sector-specific evidence bundle completeness for in-scope vendors | measure | ___ | 100% | ☐ | | | Policy-exception volume trend | measure | ___ | trending down QoQ | ☐ | |

Metric Collection Guidance: - Exception register completeness: Audit every entry; each must have a named owner, compensating control description with reviewer acknowledgment, and a documented expiry date. - Escalation rate: Count exceptions where review-due date is past; verify each has an escalation record to the program sponsor within the required window. - Sector bundle completeness: For each vendor in scope of HIPAA, PCI, or clinical/financial sector regulations, verify the corresponding bundle is assembled and all documents are present and current. - Exception volume trend: Count new exceptions opened per quarter over the last four quarters; confirm the count is not increasing.

Evidence Location: ___ Metric Validation Date: ___ Notes: ___

Maturity Level 3

Objective: Automate compliance attestation, drive policy updates from monitoring telemetry, and contribute to AI-vendor regulatory and standards development.

Question 1: Continuous compliance attestation and on-demand evidence packs

Q3.1: Can on-demand, regulator-grade evidence packs for any active AI vendor be generated inside 3 business days, with vendor-side changes auto-refreshing the evidence view and full provenance traceable, and is ≥99% of the Critical/High vendor portfolio continuously attested?

Evidence Required: - [ ] Evidence packs are generated on demand from the live compliance view; packs are available regulation-keyed (EU AI Act Art. 26 deployer-duty pack, GDPR processor-obligation pack, sector-specific pack) or vendor-keyed - [ ] Vendor-side changes (product-update RSS feeds, trust-center deltas, subprocessor change notifications, incident disclosures) auto-open tickets that refresh the compliance evidence view - [ ] SLO: any regulator or customer evidence request turned around inside 3 business days with complete provenance; SLA is met in the last 12 months - [ ] Attestation completeness is ≥99% of active Critical/High vendors (evidence view within currency SLO) - [ ] Evidence-view change-detection pipeline health is monitored; on-call is paged when a feed staleness threshold is exceeded - [ ] Policy-refresh cycle is on calendar with zero missed cycles in the last 12 months

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |---|---|---|---|---|---| | Evidence-pack generation SLA for regulator/customer | measure | ___ | ≤3 business days | ☐ | | | % Critical/High vendors with continuously current evidence view | measure | ___ | ≥99% of active Critical/High vendors | ☐ | | | Vendor-side change auto-refresh pipeline operational | measure | ___ | Yes | ☐ | | | Material audit findings on AI-vendor controls in last 12 months | measure | ___ | 0 | ☐ | |

Metric Collection Guidance: - Pack generation SLA: From evidence-ops telemetry, measure time from regulator/customer request to evidence pack delivery; compute % of requests met within 3 BD. - Continuous attestation completeness: Divide Critical/High vendors with a fresh compliance view (within currency SLO) by total active Critical/High vendors. - Auto-refresh pipeline: Verify the vendor-side change detection pipeline is operational; count vendor-side changes in the last quarter and verify each auto-opened a ticket within the expected time window. - Material audit findings: Review the last completed compliance or external audit report; count findings designated as material or high-severity related to AI-vendor controls.

Evidence Location: ___ Metric Validation Date: ___ Notes: ___

Question 2: Telemetry-driven policy refresh

Q3.2: Does the program operate a quarterly, telemetry-driven policy-refresh cycle, drawing from ML-Vendors detection trends, IM-Vendors incident learnings, tier-movement data, and external regulatory updates, with a versioned changelog where 100% of changes are traceable to a named signal or regulatory update?

Evidence Required: - [ ] Quarterly policy-refresh cycle is on calendar and has been executed without a missed cycle in the last 12 months - [ ] Refresh inputs are documented per cycle: ML-Vendors detection trends (classes of violation rising), IM-Vendors incident learnings (policy gaps revealed by incidents), tier-movement data (which tier is growing fastest), external regulatory and standards updates (EU AI Act deployer-guidance consultations, GDPR EDPB AI guidance, NIST AI RMF working groups, ISO/IEC 42001 community, sector regulators: HHS/FDA/FINRA/NYDFS/OCC/PRA) - [ ] Versioned changelog exists for AUP, Intake Policy, and Data-Sharing Policy; each change entry cites the specific signal or regulatory update that prompted the change - [ ] EG-Vendors training content is refreshed within 30 days of any policy change; the same refresh cycle updates training - [ ] 100% of policy changes in the last 12 months are traceable to named signals or regulatory updates in the changelog - [ ] Contribution pipeline has ≥2 items in-flight at any time

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |---|---|---|---|---|---| | Policy refresh cadence met | measure | ___ | quarterly, on calendar | ☐ | | | % policy changes traceable to ML/IM telemetry or regulatory update | measure | ___ | 100% | ☐ | | | EG-Vendors training refreshed within 30 days of policy changes | measure | ___ | 100% of changes | ☐ | | | Repeat-class incident rate after targeted policy changes | measure | ___ | trending down | ☐ | |

Metric Collection Guidance: - Refresh cadence: Verify quarterly policy-review meeting minutes exist for each of the last four quarters; confirm no cycle was skipped. - Traceability: Review the policy changelog; for each change entry, verify it cites either a specific ML/IM signal (with date and source) or a named regulatory update (with citation and effective date). - Training update cadence: Compare policy-change dates to EG-Vendors training-content revision dates; verify each training update occurred within 30 days. - Incident recurrence: Compare the count of incidents matching classes targeted by recent policy changes; verify the repeat-class rate is decreasing.

Evidence Location: ___ Metric Validation Date: ___ Notes: ___

Question 3: Regulatory and standards contribution

Q3.3: Does the program contribute at least two substantive public comments or standards artifacts per year on AI-vendor topics, including AI-addendum contract templates, evidence-view schemas, or incident taxonomy contributions, with documented external recognition?

Evidence Required: - [ ] Contribution log exists tracking all public comments, standards submissions, and forum participations with dates, submitting body, and topic - [ ] At least 2 substantive contributions per year submitted to relevant forums: EU AI Act deployer-guidance consultations, GDPR EDPB AI guidance rounds, NIST AI RMF working groups, ISO/IEC 42001 community, sector regulators (HHS/FDA/FINRA/NYDFS/OCC/PRA), Shared Assessments, CSA AI Safety Initiative, or OpenSSF - [ ] Contributions are technical artifacts, AI-vendor clause templates, evidence-view schemas, incident taxonomy contributions, not deadline-only comment letters; implementing bodies can cite and adopt them - [ ] Contributed artifacts are maintained and versioned; last-updated dates confirm they are not stale - [ ] External recognition is documented: citations in published guidance, standards-body acknowledgment, working-group invitations, or adoption metrics for contributed contract language

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |---|---|---|---|---|---| | Public regulatory / standards contributions per year | 0 | ___ | ≥2 | ☐ | | | External recognition (citations, invitations) | 0 | ___ | tracked as a trend | ☐ | | | Contributed artifacts maintained and not stale | measure | ___ | Yes (≤12 months since last update) | ☐ | | | Regulator / auditor / customer feedback on evidence posture | measure | ___ | explicitly positive | ☐ | |

Metric Collection Guidance: - Contribution count: Review the contribution log; count entries for the current year where the contribution is a substantive technical artifact submitted to a named standards body or regulatory forum. - External recognition: Check the contribution log for documented acknowledgments, citations in published guidance, working-group invitations, or adoption metrics for contributed contract-clause templates or schemas. - Artifact maintenance: Review the last-updated dates for all contributed artifacts; verify none are more than 12 months stale without a planned update on record. - Regulator feedback: Review any written feedback from regulators, auditors, or customers in the last 12 months; note whether AI-vendor evidence posture is characterized positively.

Evidence Location: ___ Metric Validation Date: ___ Notes: ___

Summary Scorecard

Level	Q1	Q2	Q3	Avg	Achieved?
L1	__	__	__	__	☐
L2	__	__	__	__	☐
L3	__	__	__	__	☐

Practice maturity level achieved: ___ (highest level where all 3 questions score ≥ 0.67)

Document Version: HAIAMM v3.0 Practice: Policy & Compliance (PC) 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