Assessment questionnaire for measuring maturity. Answer each question honestly based on current, implemented practices.
Canonical source-of-truth:
../practices/PC-Infrastructure-OnePager.md. The canonical v3.0 model:../HAIAMM-v3.0-Framing.md.
Practice: Policy & Compliance (PC) Domain: Infrastructure Purpose: Publish the priority policies and compliance map that make the AI/HAI Infrastructure Assurance program enforceable, so every inference endpoint, model registry, GPU fleet, orchestrator control plane, vector store, AI-specific CI/CD pipeline, and feature store the organization hosts is governed by a documented set of rules, gated before it hosts production AI workloads, and defensible to auditors and regulators. Scoring Model: Evidence + Outcome Metrics
| 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.
Objective: Publish the three priority AI/HAI infrastructure policies, map them to the priority compliance requirements, and operate the provisioning gate that prevents ungated infrastructure from hosting production AI workloads.
Q1.1: Have you published and formally approved all three AI/HAI infrastructure policies, AI Infrastructure Standards Policy, GPU / Accelerator Acceptable Use Policy, and AI Infra Intake / Provisioning Gate Policy, with per-archetype security baselines, workload classification restrictions, and a named infrastructure-owner requirement?
Evidence Required: - [ ] AI Infrastructure Standards Policy approved by Legal/Privacy and Security, covering per-archetype security baselines for all seven archetypes (inference endpoint/model-serving cluster, model registry, GPU/accelerator fleet, orchestrator/control plane, vector-store infrastructure, AI-specific CI/CD, feature store/online serving cache) including TLS, encryption at rest, access control, and log retention requirements - [ ] GPU / Accelerator Acceptable Use Policy specifying permitted/requires-approval/prohibited workloads by data classification, including prohibition on training on customer PII without privacy-officer approval, running regulated-data workloads on multi-tenant fleets without per-workload isolation confirmation, and exporting fleet credentials to personal workstations - [ ] AI Infra Intake / Provisioning Gate Policy defining required provisioning artifacts by archetype, amnesty path for previously ungated instances, and provisioning gate authority with permanent logging of decisions - [ ] Named infrastructure owner and owning team are required provisioning artifacts for all archetypes; cross-border and regulated-data instances require residency declaration and GDPR Art. 44–49 transfer basis at gate - [ ] All three policies are accessible to every platform engineer and SRE and require attestation at hire and annually; violations routed through program sponsor and Legal - [ ] Orchestrator scope constraints documented: no orchestrator agent may call APIs outside its declared tool-call scope without SR-approved tool-scope boundary
Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |---|---|---|---|---|---| | % platform/SRE headcount with acknowledged AI Infrastructure Standards AUP (current-year attestation) | measure | ___ | ≥95% | ☐ | | | Priority compliance map published and reviewed in last 12 months | n/a | ___ | Yes | ☐ | | | Three priority policies approved by Legal/Privacy and Security | n/a | ___ | Yes (all three) | ☐ | | | AI Infra Intake / Provisioning Gate Policy includes per-archetype required-artifacts checklist | n/a | ___ | Yes | ☐ | |
Metric Collection Guidance: - AUP attestation rate: Query HR/LMS for current-year AI Infrastructure Standards AUP acknowledgment completions divided by total platform engineering and SRE headcount; run monthly. - 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. - Per-archetype checklist: Confirm the Provisioning Gate policy document contains separate artifact lists for each of the seven infrastructure archetypes, with archetype-specific controls explicitly required (e.g., no-public-endpoint for inference endpoints, GPU workload isolation for GPU fleets).
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: ___
Q1.2: Is there a published one-page priority compliance map that traces each priority requirement, EU AI Act Art. 15/12/Annex III, GDPR Art. 32/44–49/33, ISO/IEC 42001, ISO/IEC 27001 A.5/A.8, SOC 2 CC6/CC7/CC8, and applicable sector-specific obligations, to the specific AI/HAI Infrastructure 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. 15 cybersecurity row traces to AI Infrastructure Standards (archetype-level security baselines: endpoint auth, TLS, model encryption, access logging) and Provisioning Gate (Art. 15 evidence checklist required for high-risk infrastructure) - [ ] EU AI Act Art. 12 record-keeping row traces to AI Infrastructure Standards (inference access log retention, orchestrator state/tool-call log retention) and Provisioning Gate (log retention confirmed at go-live) - [ ] GDPR Art. 32 security of processing row traces to AI Infrastructure Standards (encryption at rest and in transit, access control, isolation per archetype) and GPU AUP (prohibited regulated-data workloads on unisolated fleets) - [ ] GDPR Art. 44–49 international transfers row traces to AI Infrastructure Standards (residency requirement for cross-border instances) and Provisioning Gate (transfer basis confirmed at intake) - [ ] SOC 2 CC8 change management row traces to Provisioning Gate (all provisioning changes gated; promotion gates on AI-specific CI/CD); sector-specific obligations (HIPAA security rule, PCI-DSS 12.8, FedRAMP) are mapped to AI Infrastructure Standards archetype controls or Provisioning Gate checklist rows
Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |---|---|---|---|---|---| | Priority compliance map published and reviewed in last 12 months | n/a | ___ | Yes | ☐ | | | % AI/HAI infrastructure instances in production with a named infrastructure owner | measure | ___ | 100% for customer-facing and regulated-data-processing instances | ☐ | | | Retroactive intake amnesty artifacts opened and tracked as IM findings | measure | ___ | trending down QoQ (coverage increasing) | ☐ | | | Auditor evidence turnaround for Art. 15 cybersecurity 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. - Infrastructure owner coverage: Query SM-Infrastructure inventory for customer-facing and regulated-data-processing instances; verify each has a named infrastructure owner field populated. - Amnesty trend: Pull intake queue records tagged "amnesty" grouped by quarter; verify QoQ count is decreasing. - Auditor turnaround: Review any compliance or external audit requests for Art. 15 or Art. 32 evidence in the last 12 months; confirm the team produced a provisioning gate record within 5 business days.
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: ___
Q1.3: Is the AI/HAI Infrastructure provisioning gate operational with a published intake SLA, a per-archetype artifacts checklist, and an amnesty path, and does ≥85% of AI/HAI infrastructure reaching production in the last 12 months have a gate record (100% for Critical/High-tier)?
Evidence Required: - [ ] Single intake ticket queue exists with a published SLA (triage ≤5 BD, provisional approval ≤10 BD for Low-tier archetypes with no regulated data, no customer exposure, and no cross-border flows) - [ ] Per-archetype artifacts checklists are published and keyed to each of the seven infrastructure archetypes; archetype-specific controls are explicitly required (inference endpoint: no-public-endpoint confirmation or DR approval, model encryption at rest; GPU fleet: credential vault storage, GPU workload isolation; orchestrator: tool-call scope documented and SR-approved) - [ ] Amnesty path is linked from the intake form, the AUP, and the platform engineering communication channels; retroactive intake records exist for previously ungated instances - [ ] Gate approval creates or updates the SM-Infrastructure inventory record with artifact links; provisioning gate authority (program sponsor or delegated platform security lead) issues logged decisions - [ ] Exceptions are logged with owner, rationale, and review date; no exception open longer than 90 days without re-review - [ ] SM-Infrastructure inventory and intake queue can be queried to confirm gate-coverage rate for the last 12 months
Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |---|---|---|---|---|---| | % AI/HAI infrastructure instances reaching production that passed the provisioning gate | measure | ___ | ≥85% within 12 months; 100% for Critical/High instances | ☐ | | | Intake SLA adherence (triaged within 5 BD) | measure | ___ | ≥90% | ☐ | | | Policy exception aging, exceptions open >90 days | measure | ___ | 0 exceptions past expiry | ☐ | | | Platform provisioning cycle-time impact (intake-to-provisional-approval time) | measure | ___ | not increasing QoQ | ☐ | |
Metric Collection Guidance: - Gate coverage rate: Divide instances with a gate record in the last 12 months by total new AI/HAI infrastructure instances in the SM-Infrastructure inventory for the same period; split Critical/High separately. - SLA adherence: From the intake ticket queue, calculate the % of tickets where triage timestamp minus submission timestamp is ≤5 BD. - Exception aging: Query the exception register for open entries where review-due date is in the past; target is zero. - Cycle-time trend: Track median days from intake submission to provisional approval by quarter; confirm the median is not increasing.
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: ___
Objective: Deepen policy controls and compliance evidence per AI/HAI infrastructure risk tier, assemble continuous compliance evidence bundles for Critical/High instances, and operationalize FedRAMP and regional compliance gating for applicable instances.
Q2.1: Have the three priority policies been extended with tier-specific addenda using the SM-Infrastructure L2 tier rubric, and do Critical instances require explicit CISO and VP Infrastructure sign-off, per-tenant isolation confirmation, FedRAMP or sector-equivalent compliance evidence, and GDPR Art. 32/44–49 residency and transfer basis before provisioning?
Evidence Required: - [ ] Tier-specific addenda exist for Critical, High, Medium, and Low tiers, referencing the SM-Infrastructure L2 rubric tier definitions - [ ] Critical tier requires: full SR pack with REM, CISO and VP Infrastructure sign-off required before go-live, per-tenant isolation confirmation required, FedRAMP or sector-equivalent compliance evidence required for US federal/public-sector context, EU AI Act Art. 15 cybersecurity evidence assembled, GDPR Art. 32/44–49 residency and transfer basis confirmed, GPU fleet credentials zero-standing-access confirmed - [ ] Critical tier requires re-review within 14 days of any material change (new AI workload hosted, new tenant, new region, new data class) - [ ] High tier requires CISO-delegated platform security lead sign-off and EU AI Act/GDPR assessments; isolation posture confirmed; re-review on material change within 30 days - [ ] Policy-exception framework requires named owner, compensating control description, Legal/platform-security reviewer acknowledgment, and expiry date (max 12 months); Critical-tier missing provisioning artifacts are blocking IM findings with no amnesty post-L2 - [ ] Gate records show CISO and VP Infrastructure sign-off for Critical instances in the last 12 months
Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |---|---|---|---|---|---| | % Critical instances with explicit CISO + VP Infrastructure sign-off at provisioning | measure | ___ | 100% | ☐ | | | % Critical/High AI/HAI infra instances with complete compliance evidence bundle | measure | ___ | ≥95% | ☐ | | | Exception register: % exceptions with named owner, compensating control, and expiry date | measure | ___ | 100% | ☐ | | | Regulatory inquiry turnaround (evidence bundle within 5 BD) | measure | ___ | Yes (last 12 months) | ☐ | |
Metric Collection Guidance: - Critical sign-off rate: Query gate records in SM-Infrastructure inventory for Critical-tier instances in the last 12 months; verify each has both CISO and VP Infrastructure sign-off timestamps. - Evidence bundle completeness: For each Critical/High instance, check that all required bundle elements (TA snapshot, SR REM, SA confirmation, DR decision, IR attestation, ST evidence, ML logging-baseline, infrastructure-owner record, FedRAMP/regional compliance 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.
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: ___
Q2.2: Is a compliance evidence bundle continuously maintained for every Critical and High AI/HAI infrastructure instance, covering TA snapshot, SR REM, SA pattern confirmation, DR decision, IR attestation, ST evidence, ML logging-baseline, infrastructure-owner record, and FedRAMP/sector-equivalent compliance evidence where applicable, with staleness inside tier-specific targets?
Evidence Required: - [ ] Evidence bundle structure is defined and implemented; bundle elements include: current TA snapshot, SR REM with gap status and owner, SA reference-architecture confirmation or DR-approved deviation, latest DR decision, latest IR attestation, ST evidence (full battery last run, model-extraction resistance test, vector-store inversion test, orchestrator-scope test, GPU-fleet IAM test), ML logging-baseline confirmation, infrastructure-owner record with data-residency declaration and Art. 32/Art. 15 obligations checklist, FedRAMP/sector-equivalent compliance evidence for applicable instances - [ ] Staleness rules are defined and enforced for Critical tier: TA snapshot ≤90 days, IR attestation ≤6 months, ST evidence ≤30 days; staleness triggers a PC-Infrastructure finding routed to IM - [ ] The evidence bundle is the primary artifact delivered to regulators or auditors; a completed bundle can be assembled for any Critical/High instance without specialist intervention - [ ] FedRAMP / regional compliance tracker is reviewed quarterly; no in-scope instance is missing evidence - [ ] Sector-specific evidence bundles (HIPAA security-rule bundle, PCI-DSS 12.8 bundle, FedRAMP bundle, ISO/IEC 27001 Annex A bundle) are generated from the compliance evidence bundle for applicable instances - [ ] Evidence registry is queryable to report median staleness across Critical instance bundle elements
Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |---|---|---|---|---|---| | % Critical/High AI/HAI infra instances with complete compliance evidence bundle | measure | ___ | ≥95% | ☐ | | | Median staleness of evidence-bundle elements for Critical instances | measure | ___ | ≤30 days past refresh window | ☐ | | | FedRAMP / sector-equivalent compliance evidence complete for applicable Critical instances | measure | ___ | 100% | ☐ | | | Audit findings on AI/HAI infrastructure control set, repeat findings | measure | ___ | 0 | ☐ | |
Metric Collection Guidance: - Bundle completeness: For each Critical/High instance, check each required element is present and within its refresh window; count instances where all elements are current; divide by total Critical/High instances. - Median staleness: For each Critical instance's evidence bundle, calculate days since each element's last refresh; compute median across all Critical instances. - FedRAMP completeness: For each instance in US federal/public-sector context, verify the FedRAMP bundle is assembled with all required documents present and current; confirm no in-scope instance is missing evidence. - Repeat findings: Review the last completed compliance or external audit report; count findings that also appeared in the prior audit cycle.
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: ___
Q2.3: Is an exception register operated with named owners, compensating controls, and expiry dates, reviewed monthly, with Critical-tier missing provisioning artifacts treated as blocking findings, and sector-specific evidence bundles (HIPAA / PCI-DSS / FedRAMP as applicable) complete for in-scope instances?
Evidence Required: - [ ] Exception register is integrated with the provisioning gate; no exception is approved without tier-appropriate compensating control definition and expiry date (max 12 months) - [ ] Monthly exception aging review is scheduled and conducted; exceptions more than 90 days past expiry auto-escalate to the program sponsor - [ ] Critical-tier instances with missing provisioning artifacts are routed as blocking IM findings, no amnesty path applies post-L2 - [ ] Sector-specific evidence bundles are generated and tracked: HIPAA security-rule bundle (PHI-processing infra), PCI-DSS 12.8 bundle (cardholder-data-adjacent inference infra), FedRAMP bundle (US federal/public-sector infra), ISO/IEC 27001 Annex A bundle where applicable - [ ] Completeness of sector-specific bundles is reported to the program sponsor; tracked per instance - [ ] Policy-exception volume is tracked quarterly; the trend is not increasing as tier-calibrated controls become the standard provisioning path
Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |---|---|---|---|---|---| | Exception register: % exceptions with named owner, compensating control, and expiry date | measure | ___ | 100% | ☐ | | | % exceptions past expiry escalated to program sponsor | measure | ___ | 100% | ☐ | | | Sector-specific evidence bundle completeness for in-scope instances | 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 instance in scope of HIPAA, PCI-DSS, or FedRAMP, 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.
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: ___
Objective: Automate compliance attestation from IaC, cloud-provider, and runtime telemetry; drive policy updates from monitoring signals and regulatory motion; and contribute to AI infrastructure standards development through CNCF, OpenSSF AI, and sector regulators.
Q3.1: Does a continuous attestation pipeline auto-update evidence bundles from IaC state events, cloud-provider provisioning events, Kubernetes admission webhook records, and runtime configuration signals, with an attestation currency SLO of ≤24 hours latency and ≤3 BD on-demand pack generation?
Evidence Required: - [ ] Evidence bundles auto-update from: IaC state events (Terraform plan/apply records carry artifact checklist status), cloud-provider provisioning events (new endpoint created auto-opens intake check), Kubernetes admission webhook records (policy-as-code assertions on GPU workloads and serving deployments verified at admission), runtime configuration events (drift from declared baseline opens PC finding), ML logging-baseline validation events, model-registry promotion events (CI/CD pipeline integrity evidence refreshed) - [ ] Attestation-generation pipeline is implemented: any regulatory or auditor request produces a provenance-complete evidence pack, regulation-keyed (EU AI Act Art. 15 evidence pack, GDPR Art. 32 processing-security pack, SOC 2 CC6/CC7/CC8 evidence set, FedRAMP evidence set) or instance-keyed, within 3 business days - [ ] Attestation currency SLO is ≤24 hours latency after a triggering event; completeness SLO is ≥99% of active Critical/High instances continuously attested - [ ] On-call paging is configured when evidence-pipeline feed staleness thresholds are exceeded - [ ] SLA performance (≤3 BD on-demand pack generation) is documented and met in the last 12 months - [ ] Policy-refresh cycle is on calendar with zero missed cycles in the last 12 months
Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |---|---|---|---|---|---| | Attestation-pack generation SLA for regulator / auditor | measure | ___ | ≤3 business days | ☐ | | | Attestation currency SLO for Critical/High instances | measure | ___ | ≤24h latency post-triggering event | ☐ | | | % Critical/High instances continuously attested | measure | ___ | ≥99% of active Critical/High instances | ☐ | | | Material audit findings on AI/HAI infrastructure controls in last 12 months | measure | ___ | 0 | ☐ | |
Metric Collection Guidance: - Pack generation SLA: From evidence-ops telemetry, measure time from regulator/auditor request to evidence pack delivery; compute % of requests met within 3 BD. - Attestation currency SLO: From evidence pipeline telemetry, measure time between a triggering event (IaC state change, cloud-provider provisioning event) and the evidence bundle update; compute % of events where latency is ≤24 hours. - Continuous attestation completeness: Divide Critical/High instances with a fresh evidence bundle (within SLO) by total active Critical/High instances. - Material audit findings: Review the last completed compliance or external audit report; count findings designated as material or high-severity related to AI/HAI infrastructure controls.
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: ___
Q3.2: Does the program operate a quarterly, telemetry-driven policy-refresh cycle, drawing from ML-Infrastructure detection trends, IM-Infrastructure incident learnings, tier-movement data, and a regulatory-motion tracker, 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-Infrastructure detection trends (rising infrastructure misconfigurations), IM-Infrastructure incident learnings (policy gaps that created incident conditions), tier-movement data (archetype classes growing fastest), external regulatory updates (EU AI Act implementing acts, GDPR EDPB AI guidance, NIST AI RMF Playbook updates, FedRAMP revision cycles, sector-specific guidance from HHS/PCI SSC/FedRAMP PMO/sector cloud regulators) - [ ] Versioned changelog exists for each of the three policies; each change entry cites the specific signal or regulatory update that prompted the change - [ ] EG-Infrastructure training content is updated within 30 days of any policy change - [ ] Regulatory-motion tracker is maintained: a log of open regulatory instruments with expected effective dates, mapped to the policy they will affect, reviewed quarterly by the working group - [ ] 100% of policy changes in the last 12 months are traceable to named signals or regulatory updates in the changelog
Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |---|---|---|---|---|---| | Policy refresh cadence met | measure | ___ | quarterly, on calendar | ☐ | | | % policy changes traceable to ML/IM telemetry or named regulatory update | measure | ___ | 100% | ☐ | | | Regulatory-motion tracker reviewed quarterly, open instruments missed | measure | ___ | 0 | ☐ | | | Policy changes measurably close infrastructure misconfig classes identified in prior quarters | 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). - Regulatory tracker: Review the regulatory-motion tracker document; verify it was reviewed in each of the last four quarters and no open regulatory instruments are missing. - Misconfig reduction: Compare the count of infrastructure misconfig incidents per quarter over the last four quarters; verify that classes targeted by policy changes are not recurring.
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: ___
Q3.3: Does the program contribute at least two substantive public comments or standards artifacts per year on AI/HAI infrastructure policy topics, including provisioning gate schemas, compliance evidence bundle templates, archetype-keyed policy-as-code assertions, or IaC module templates, 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: CNCF AI/ML Working Group, CNCF TAG Security, OpenSSF AI supply-chain security, FinOps Foundation AI Infrastructure SIG, EU AI Act Art. 15 implementing-acts consultations, NIST AI RMF Playbook infrastructure chapter working groups, FedRAMP Emerging Technology Advisory Group, sector regulators (HHS AI infrastructure guidance, PCI SSC AI guidance), CSA AI Safety Initiative, or Shared Assessments - [ ] Contributions are technical artifacts implementing bodies can use, including provisioning gate schemas, compliance evidence bundle templates, archetype-keyed policy-as-code assertions, IaC module templates with embedded compliance guardrails, not deadline-only comment letters - [ ] Contributed artifacts are maintained and versioned; last-updated dates confirm they are not stale and reflect current cloud-provider APIs - [ ] External recognition is documented: citations in published guidance, standards-body acknowledgment, working-group invitations, or community adoption metrics
Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |---|---|---|---|---|---| | Public regulatory / standards contributions per year | 0 | ___ | ≥2 | ☐ | | | External recognition (citations, adoptions, invitations) | 0 | ___ | tracked, trending up | ☐ | | | Contributed artifacts maintained and not stale | measure | ___ | Yes (≤12 months since last update) | ☐ | | | Regulator / auditor / customer feedback on infrastructure attestation 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, email confirmations from standards bodies, citations in published guidance, working-group invitations, GitHub fork/star counts for published IaC 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; confirm they reflect current cloud-provider API changes. - Regulator feedback: Review any written feedback from regulators, auditors, or customers in the last 12 months; note whether infrastructure attestation posture is characterized positively.
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: ___
| 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: Infrastructure Last Updated: 2026-05-15 Author: Verifhai
Instructions: