Assessment questionnaire for measuring maturity. Answer each question honestly based on current, implemented practices.
Canonical source-of-truth:
../practices/PC-Software-OnePager.md. The canonical v3.0 model:../HAIAMM-v3.0-Framing.md.
Practice: Policy & Compliance (PC) Domain: Software Purpose: Publish the priority policies and compliance map that make the AI/HAI Software Assurance program enforceable, so every AI/HAI artifact the organization builds is governed by a documented set of rules, gated before it reaches production, 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 software engineering policies, map them to the priority compliance requirements, and operate the go-live gate that prevents ungated AI/HAI software from reaching production.
Q1.1: Have you published and formally approved all three AI/HAI software engineering policies, AI Engineering Standards, AI Acceptable Use & Engineering Standards, and AI Software Intake / Go-Live Gate, with archetype-specific controls, data-class restrictions, agentic scope constraints, and a deployer-duty owner requirement?
Evidence Required: - [ ] AI Engineering Standards policy document approved by Legal/Privacy and Security, covering minimum required controls per archetype (LLM-integrated app, agent, RAG pipeline, fine-tune/training workload, eval harness, model-serving service, classical ML model) - [ ] AI Acceptable Use & Engineering Standards policy specifying permitted/requires-approval/prohibited actions for engineers using LLM SDKs, model registries, and tool-using agents, with data-class restrictions per archetype and deployment context - [ ] AI Software Intake / Go-Live Gate policy defining required go-live artifacts by archetype, amnesty path for previously ungated artifacts, and go-live gate authority with permanent logging of decisions - [ ] Agentic scope constraints documented: no agent may act on customer accounts, execute external writes, or call APIs outside its declared tool scope without SR-approved tool-scope boundary in the REM - [ ] Output-integrity-critical designation requirement and deployer-duty owner assignment for customer-facing and decision-affecting artifacts are explicit in the policies - [ ] All three policies are accessible to every engineer and require attestation at hire and annually; violations routed through program sponsor and Legal
Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |---|---|---|---|---|---| | % engineering headcount with acknowledged AI 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 Software Intake / Go-Live Gate policy includes per-archetype required-artifacts checklist | n/a | ___ | Yes | ☐ | |
Metric Collection Guidance: - AUP attestation rate: Query HR/LMS for current-year AI AUP acknowledgment completions divided by total engineering 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 Intake/Gate policy document contains separate artifact lists for each of the seven software archetypes, with agent-specific controls explicitly required.
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. 26/50/Annex III/Art. 9/Art. 15, GDPR Art. 22/32/33/44–49, NIST AI RMF GOVERN/MAP/MEASURE/MANAGE, ISO/IEC 42001, SOC 2 CC9.2, and applicable sector-specific obligations, to the specific AI/HAI Software 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 both AI Engineering Standards (archetype controls, output-integrity-critical flag, human-oversight assignment) and Intake Gate (go-live artifact checklist, deployer-duty owner) - [ ] GDPR Art. 22 automated decision-making row traces to AI Engineering Standards (output-integrity-critical flag triggers Art. 22 safeguards) and Intake Gate (safeguards checklist at go-live) - [ ] GDPR Art. 44–49 international transfers row traces to AUP (prohibited from piping regulated data to non-DPA-covered inference endpoint) and AI Engineering Standards (model/provider residency documented at go-live) - [ ] SOC 2 CC9.2 vendor management row traces to Intake Gate (foundation-model vendor DPA confirmed at go-live) - [ ] Sector-specific obligations (HIPAA, PCI-DSS 12.8, FINRA/SEC, FDA AI/SaMD as applicable) are mapped to archetype controls or Intake Gate checklist rows; compliance map has a documented review frequency and was reviewed within the last 12 months
Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |---|---|---|---|---|---| | Priority compliance map published and reviewed in last 12 months | n/a | ___ | Yes | ☐ | | | % AI/HAI software artifacts in production with a named deployer-duty owner | measure | ___ | 100% for customer-facing and decision-affecting artifacts | ☐ | | | Retroactive intake amnesty artifacts opened and tracked as IM findings | measure | ___ | trending down QoQ (coverage increasing) | ☐ | | | Auditor evidence turnaround for 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. - Deployer-duty owner coverage: Query SM-Software inventory for customer-facing and decision-affecting artifacts; verify each has a named deployer-duty owner field populated. - Amnesty trend: Pull intake queue records tagged "amnesty" grouped by quarter; verify QoQ count is decreasing as ungated artifacts are surfaced. - Auditor turnaround: Review any compliance or external audit requests in the last 12 months; confirm the team produced a go-live 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 Software go-live gate operational with a published intake SLA, a per-archetype artifacts checklist, and an amnesty path, and does ≥85% of AI/HAI software 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 and no customer exposure) - [ ] Per-archetype artifacts checklists are published and keyed to each of the seven software archetypes; agent-specific controls (kill-switch, tool-scope boundary, human-override path) are explicitly required on the agent checklist - [ ] Amnesty path is linked from the intake form, the AUP, and engineering all-hands communications; retroactive intake records exist for previously ungated artifacts - [ ] Gate approval creates or updates the SM-Software inventory record with artifact links; go-live gate authority (program sponsor or delegated AppSec lead) issues logged decisions - [ ] Exceptions are logged with owner, rationale, and review date; no exception open longer than 90 days without re-review - [ ] SM-Software inventory and intake queue can be queried to confirm the gate-coverage rate for the last 12 months
Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |---|---|---|---|---|---| | % AI/HAI software artifacts reaching production that passed the go-live gate | measure | ___ | ≥85% within 12 months; 100% for Critical/High archetypes | ☐ | | | Intake SLA adherence (triaged within 5 BD) | measure | ___ | ≥90% | ☐ | | | Policy exception aging, exceptions open >90 days | measure | ___ | 0 exceptions past expiry | ☐ | | | Engineering cycle-time impact (intake-to-provisional-approval time) | measure | ___ | not increasing QoQ | ☐ | |
Metric Collection Guidance: - Gate coverage rate: Divide artifacts with a gate record in the last 12 months by total new AI/HAI software artifacts in the SM-Software 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 software risk tier, automate artifact assembly from the SM-Software tier rubric, and produce audit-ready evidence trails continuously.
Q2.1: Have the three priority policies been extended with tier-specific addenda using the SM-Software L2 tier rubric, and do Critical artifacts require explicit executive (CISO or CTO) and privacy-officer sign-off, EU AI Act Annex III high-risk assessment, GDPR Art. 22 safeguards review, and foundation-model inference provider DPA and training-data posture attestation before go-live?
Evidence Required: - [ ] Tier-specific addenda exist for Critical, High, Medium, and Low tiers, referencing the SM-Software L2 rubric tier definitions - [ ] Critical tier requires: full SR pack with REM, executive (CISO or CTO) and privacy-officer sign-off, EU AI Act Annex III high-risk assessment reviewed by Legal, GDPR Art. 22 safeguards reviewed by Privacy, foundation-model inference provider DPA and training-data posture attestation on file at go-live - [ ] Critical tier requires: kill-switch/human-override path confirmed and tested; re-review within 14 days of any material change (model swap, new tool, new data class, scope expansion) - [ ] High tier requires CISO-delegated AppSec lead sign-off and EU AI Act/GDPR assessments; Medium and Low tiers are fast-tracked with documented waiver criteria - [ ] Policy-exception framework requires named owner, compensating control description, Legal/AppSec reviewer acknowledgment, and expiry date (max 12 months); Critical-tier missing go-live artifacts are blocking IM findings with no amnesty post-L2 - [ ] Gate records show executive and privacy-officer sign-off for Critical artifacts in the last 12 months
Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |---|---|---|---|---|---| | % Critical artifacts with explicit executive + privacy-officer sign-off at go-live | measure | ___ | 100% | ☐ | | | % Critical/High AI/HAI software artifacts 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 for regulator/auditor within 5 BD) | measure | ___ | Yes (last 12 months) | ☐ | |
Metric Collection Guidance: - Critical sign-off rate: Query gate records in SM-Software inventory for Critical-tier artifacts in the last 12 months; verify each has both CISO/CTO and privacy-officer sign-off timestamps. - Evidence bundle completeness: For each Critical/High artifact, check that all required bundle elements (TA snapshot, SR REM, SA confirmation, DR decision, IR attestation, ST evidence, ML logging-baseline, deployer-duty record, provider attestation) are present and within refresh windows. - Exception register completeness: Audit every entry in the exception register; 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 software artifact, covering TA snapshot, SR REM, SA pattern confirmation, DR decision, IR attestation, ST evidence, ML logging-baseline, deployer-duty record, and foundation-model provider attestation, with staleness inside tier-specific targets?
Evidence Required: - [ ] Evidence bundle structure is defined and implemented; bundle elements include TA snapshot, SR REM with gap status and owner, SA reference-pattern confirmation or DR-approved deviation, latest DR decision, latest IR attestation, ST evidence (prompt-injection regression, data-egress canary), ML logging-baseline, deployer-duty record, and foundation-model provider DPA plus training-data posture statement - [ ] Staleness rules are defined and enforced for Critical tier: TA snapshot ≤90 days, IR attestation ≤6 months, ST evidence ≤30 days, provider DPA status ≤90 days; staleness triggers a PC-Software finding routed to IM - [ ] Foundation-model provider attestation tracker is refreshed quarterly from provider trust-center pages and changelog feeds; subprocessor list with last-update date is included - [ ] The evidence bundle is the primary artifact delivered to regulators or auditors; a completed bundle can be assembled for any Critical/High artifact without specialist intervention - [ ] Sector-specific evidence bundles (HIPAA PHI-in-clinical-AI, PCI-DSS 12.8, FDA AI/SaMD, FINRA/SEC model-risk) are generated from the compliance evidence bundle for applicable artifacts; completeness is tracked - [ ] Evidence registry is queryable to report median staleness across Critical artifact bundle elements
Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |---|---|---|---|---|---| | % Critical/High AI/HAI software artifacts with complete compliance evidence bundle | measure | ___ | ≥95% | ☐ | | | Median staleness of evidence-bundle elements for Critical artifacts | measure | ___ | ≤30 days past refresh window | ☐ | | | Sector-specific evidence bundle completeness for in-scope artifacts | measure | ___ | 100% | ☐ | | | Audit findings on AI/HAI software control set, repeat findings | measure | ___ | 0 | ☐ | |
Metric Collection Guidance: - Bundle completeness: For each Critical/High artifact, check each required element is present and within its refresh window; count artifacts where all elements are current; divide by total Critical/High artifacts. - Median staleness: For each Critical artifact's evidence bundle, calculate days since each element's last refresh; compute median across all Critical artifacts. - Sector bundle completeness: For each in-scope artifact subject to HIPAA, PCI-DSS, FDA, or FINRA, 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.
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 go-live artifacts treated as blocking findings, and sector-specific evidence bundles complete for in-scope artifacts?
Evidence Required: - [ ] Exception register is integrated with the intake 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 artifacts with missing go-live artifacts are routed as blocking IM findings, no amnesty path applies post-L2 - [ ] Sector-specific evidence bundles are generated and tracked: HIPAA PHI-in-clinical-AI bundle, PCI-DSS 12.8 bundle, FDA AI/SaMD bundle, FINRA/SEC model-risk evidence set for applicable in-scope artifacts - [ ] Completeness of sector-specific bundles is reported to the program sponsor - [ ] Policy-exception volume is tracked quarterly; the trend is not increasing as tier-calibrated controls become the standard engineering 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 artifacts | 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 artifact in scope of HIPAA, PCI-DSS, FDA, or FINRA, 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 CI/CD, model-registry, and runtime telemetry; drive policy updates from monitoring signals and external regulatory motion; and contribute to AI software standards development.
Q3.1: Does a continuous attestation pipeline auto-update evidence bundles from CI/CD go-live events, model-registry promotion events, dependency-manifest changes, and runtime-egress signals, with an attestation currency SLO of ≤24 hours latency and ≤3 BD on-demand pack generation?
Evidence Required: - [ ] Evidence bundles auto-update from: CI/CD go-live events (artifact checklist attached to release record), model-registry promotion events (re-check of TA snapshot age, IR attestation currency, ST evidence currency), dependency-manifest changes (new LLM SDK import auto-opens a PC finding if artifact not yet in inventory), runtime-egress signals (new AI provider domain auto-opens intake) - [ ] Attestation-generation pipeline is implemented: any regulatory or auditor request produces a provenance-complete evidence pack, regulation-keyed (EU AI Act evidence pack, GDPR processor-obligation pack, ISO 42001 AIMS set) or artifact-keyed, within 3 business days - [ ] Attestation currency SLO is ≤24 hours latency after a triggering event; completeness SLO is ≥99% of active Critical/High artifacts continuously attested - [ ] On-call paging is configured when evidence-pipeline feed staleness thresholds are exceeded; policy-refresh cycle is on calendar with zero missed cycles in the last 12 months - [ ] Prompt/completion log volume events function as a discovery signal for previously uninventoried artifacts - [ ] SLA performance (≤3 BD on-demand pack generation) is documented and met 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 artifacts | measure | ___ | ≤24h latency post-triggering event | ☐ | | | % Critical/High artifacts continuously attested | measure | ___ | ≥99% of active Critical/High artifacts | ☐ | | | Material audit findings on AI/HAI software 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 (CI/CD go-live, model-registry promotion) and the evidence bundle update; compute % of events where latency is ≤24 hours. - Continuous attestation completeness: Divide Critical/High artifacts with a fresh evidence bundle (within SLO) by total active Critical/High artifacts. - Material audit findings: Review the last completed compliance or external audit report; count findings designated as material or high-severity.
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-Software detection trends, IM-Software 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-Software detection trends (rising AI-specific violation classes), IM-Software incident learnings (policy gaps that created incident conditions), tier-movement data (archetypes growing fastest), external regulatory updates (EU AI Act implementing acts, EDPB AI guidance, NIST AI RMF Playbook updates, US Executive Orders, state AI laws, sector guidance from FDA/FINRA/OCC/NYDFS/HHS) - [ ] Versioned changelog exists for each of the three policies; each change entry cites the specific signal or regulatory update that prompted the change - [ ] EG-Software training content is updated within 30 days of any policy change; SM-Software inventory archetypes and tier rubric are reviewed for needed updates - [ ] 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 reduce repeat-class incidents in subsequent 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. - Incident reduction: Compare incident classes identified in the prior four quarters with the current quarter; 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 software policy topics, including go-live gate schemas, compliance evidence bundle templates, archetype-keyed policy addendum patterns, or deployer-duty evidence records, 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 (Art. 26 implementing acts), GDPR EDPB AI guidance rounds, NIST AI RMF Playbook working groups, ISO/IEC 42001 community, sector regulators (FDA AI/SaMD, FINRA/OCC model risk, NYDFS Part 500, HHS), CSA AI Safety Initiative, OpenSSF AI, Shared Assessments, or OWASP AI governance - [ ] Contributions are technical artifacts implementing bodies can use, including go-live gate schemas, compliance evidence bundle templates, archetype-keyed policy addendum patterns, deployer-duty evidence records, not deadline-only comment letters - [ ] 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 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 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, or GitHub adoption metrics for published 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 attestation posture is characterized as positive.
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: Software Last Updated: 2026-05-15 Author: Verifhai
Instructions: