Assessment questionnaire for measuring maturity. Answer each question honestly based on current, implemented practices.
v3.0 canonical source:
../practices/SA-Infrastructure-OnePager.md. Outcome metrics, activities, and success criteria are verbatim from that document. Subject rule (§12.1): the AI is what is being secured, not a tool performing security tasks.
Practice: Secure Architecture (SA) Domain: Infrastructure Purpose: Assess organizational maturity in publishing and operationalizing reference architectures for every AI/HAI infrastructure archetype the organization operates Scoring Model: Evidence + Outcome Metrics (see Scoring Methodology below)
| Tier | Score | Criteria |
|---|---|---|
| Fully Mature | 1.0 | Evidence complete + 3 or more outcome metrics meet targets |
| Implemented | 0.67 | Evidence complete + 2 outcome metrics meet targets |
| Partial | 0.33 | Evidence partially complete + fewer than 2 metrics meet targets |
| Not Implemented | 0.0 | No evidence of the practice |
Level Score = average of the three question scores for that level. Overall SA-Infrastructure Score = weighted average: L1 × 0.5 + L2 × 0.3 + L3 × 0.2.
Objective: Publish reference architectures per AI/HAI infrastructure archetype and an anti-pattern catalog derived from real incidents; link each pattern to SR-Infrastructure requirements and TA-Infrastructure threats.
Q1.1: Has the organization published a reference architecture pattern for each of the seven AI/HAI infrastructure archetypes it operates, inference endpoint, model registry, GPU/accelerator fleet, orchestrator/control plane, vector-store, AI CI/CD pipeline, and feature store, with each pattern including a labeled architecture diagram, identity and auth model, isolation spec, traffic path, logging specification, and explicit row-by-row mapping to SR-Infrastructure requirements and TA-Infrastructure threats with HAI TTP tags (EA / AGH / TM / RA), applicable MITRE ATLAS mitigation IDs, and HCT threat roots addressed, accessible within one click of the SM inventory record?
Evidence Required: - [ ] Architecture registry listing all seven archetype reference patterns with version and publication date - [ ] Each pattern document includes a labeled architecture diagram covering scope, identity and auth model, isolation model, traffic path, logging spec, SR mapping, threat mapping, HCT threat roots (BadCode / BadAction / BadPrincipal / BadPermissions) - [ ] HAI TTP tags (EA / AGH / TM / RA) and applicable MITRE ATLAS mitigation IDs present in each pattern - [ ] SM inventory records link to the applicable reference pattern within one click of the asset record - [ ] Deviation-review path documented with a named architect-reviewer population and a stated SLA (target: ≤5 business days) - [ ] 100% of inference endpoints and model registries verified (via IAM audit) to use workload-identity-only access with no long-lived API keys in service principals
Outcome Metrics: | Metric | Baseline | Target | Source | Met? | Notes | |--------|----------|--------|--------|------|-------| | Reference patterns published per archetype (inference endpoint, model registry, GPU fleet, orchestrator, vector store, AI CI/CD, feature store) | 0 / 7 | 7 / 7 | Architecture registry | ☐ | | | % active AI/HAI infrastructure assets in the SM inventory using a named reference pattern or documented deviation | measure | ≥85% | Inventory × pattern metadata | ☐ | | | % of inference endpoints and model registries with workload-identity-only access (no long-lived keys) | measure | 100% | IAM audit / IR spot-check | ☐ | | | Pattern-to-SR-Infrastructure requirement mapping coverage | measure | 100% of pattern controls tagged to SR requirement | Pattern metadata | ☐ | |
Metric Collection Guidance: - Patterns published: Count published patterns with all required skeleton elements present including HCT threat roots. Source: architecture registry. Reviewed quarterly. - Inventory pattern adoption: Query SM inventory for each active infrastructure asset's pattern-adoption field. Count assets classified as "on pattern" or "deviation with review" divided by total active infrastructure assets. Source: SM inventory export. - Workload-identity adoption: Run IAM audit across inference endpoint and model registry service principals. Count principals using workload identity (IRSA / GCP Workload Identity / Azure Managed Identity) with zero long-lived API keys divided by total such principals. Source: IAM audit. - SR mapping coverage: For each pattern, count controls with a SR requirement tag divided by total controls. Aggregate across all seven patterns. Source: pattern metadata.
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 evidence)
Evidence Location: __ Validation Date: __ Notes: ___
Q1.2: Has the organization published an anti-pattern catalog with a minimum of 8 entries, each naming the pattern, explaining why it is dangerous, citing a real or authoritative case study, and linking to the reference pattern element that replaces it, linked from the AI Acceptable Use Policy, the SM intake gate, and EG-Infrastructure training, and are 100% of inference endpoints and model registries verified via IAM audit to use workload-identity-only access with no long-lived API keys in service principals?
Evidence Required: - [ ] Anti-pattern catalog document with at least 8 named entries covering the L1 mandatory set (shared GPUs for regulated workloads, world-readable model registry, unsigned model artifacts in production, control-plane API without auth, vector store without per-tenant partitioning, CI/CD with hardcoded credentials, inference endpoint without rate limits, long-lived admin credentials for registry and orchestrator) - [ ] Each entry includes: description, why dangerous, real/authoritative case study, and the reference pattern element that replaces it - [ ] Catalog linked from the AI Acceptable Use Policy (with a dated link) - [ ] Catalog linked from the SM intake gate (verified by IR spot-check) - [ ] Catalog referenced in EG-Infrastructure training materials with a dated curriculum link - [ ] IAM audit records confirming workload-identity-only access for all inference endpoints and model registries
Outcome Metrics: | Metric | Baseline | Target | Source | Met? | Notes | |--------|----------|--------|--------|------|-------| | Anti-patterns catalog published and linked from intake / SM inventory | n/a | Yes | Document registry | ☐ | | | % of inference endpoints and model registries with workload-identity-only access confirmed by IAM audit | measure | 100% | IAM audit | ☐ | | | Anti-pattern catalog entries with a real-incident or authoritative-case-study citation | measure | 100% of entries | Catalog metadata | ☐ | | | Time from new IM-Infrastructure incident classification to anti-pattern catalog entry | measure | ≤30 days | Catalog change log | ☐ | |
Metric Collection Guidance: - Catalog published: Binary check, catalog exists, is versioned, and links are present from the three required touchpoints. Source: document registry audit. - Workload-identity adoption: IAM audit, same metric as Q1.1 outcome metric 3. Source: IAM audit. - Incident citation coverage: Count anti-pattern entries with a citation field populated divided by total entries. Source: catalog metadata. - Catalog update lead time: From IM-Infrastructure incident classification timestamp to catalog-entry publication timestamp. Source: IM-Infrastructure log and catalog 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 evidence)
Evidence Location: __ Validation Date: __ Notes: ___
Q1.3: Is a repeat-deviation signal operational, such that three deviations in the same direction for the same archetype automatically queue a pattern-update review with SA-Infrastructure ownership, and are 85% or more of active AI/HAI infrastructure assets in the SM inventory classified as "on pattern" or "deviation with review" with no silent deviations?
Evidence Required: - [ ] SM inventory fields for pattern-adoption status populated for all active infrastructure assets - [ ] Repeat-deviation signal wired: a query, report, or automation that detects three or more deviations in the same direction for the same infrastructure archetype and generates a pattern-update queue item - [ ] Pattern-update queue items traceable to deviation records with SA-Infrastructure ownership assigned - [ ] New-archetype lead-time SLA documented (target: 30 days from first intake in a new archetype category to pattern publication) - [ ] Pattern quarterly review schedule with change-log entries maintained - [ ] Zero infrastructure assets with unreviewed/silent deviations confirmed by audit
Outcome Metrics: | Metric | Baseline | Target | Source | Met? | Notes | |--------|----------|--------|--------|------|-------| | % active AI/HAI infrastructure assets in the SM inventory using a named reference pattern or documented deviation | measure | ≥85% | Inventory × pattern metadata | ☐ | | | Repeat-deviation signal operational (three deviations in same direction queue pattern-update review) | measure | Yes, operational and tested | Deviation-review log | ☐ | | | New-archetype lead time (days from first intake to pattern publication) | measure | ≤30 days | Architecture registry change log | ☐ | | | Silent-deviation count (assets with no pattern classification) | measure | 0 | SM inventory audit | ☐ | |
Metric Collection Guidance: - Inventory adoption: Same query as Q1.1 outcome metric 2. Reported monthly. - Repeat-deviation signal: Demonstrate by showing at least one instance of the trigger firing and a resulting pattern-update queue item, or the query/automation logic with a test-run result. Source: deviation-review log and pattern-update queue. - New-archetype lead time: For each new infrastructure archetype category added to the inventory in the review period, measure elapsed days from first intake record to published pattern date. Source: SM inventory and architecture registry. - Silent deviations: Export SM inventory and count infrastructure assets where pattern-adoption field is null, empty, or unclassified. Target is zero. Source: SM inventory export.
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 evidence)
Evidence Location: __ Validation Date: __ Notes: ___
Objective: Extend reference patterns to multi-region, multi-tenant, and per-tier complexity calibrated to SM-Infrastructure L2's tier-treatment matrix; encode patterns as IaC modules with conformance test suites; update the anti-pattern catalog from IM-Infrastructure incidents.
Q2.1: Are the five tier-conditional extended patterns, Critical overlay, High overlay, multi-region, multi-tenant, and per-tier IaC modules, published as forkable IaC modules with conformance test suites, and are 80% or more of Critical and High-tier AI/HAI infrastructure assets running on IaC-encoded patterns as confirmed by the IaC and SM inventory registries?
Evidence Required: - [ ] Five tier-conditional pattern variants documented and published: Critical overlay (dedicated-node isolation IaC, kill-switch IaC, data-residency enforcement variant), High overlay (monitoring and logging IaC modules), multi-region pattern, multi-tenant pattern, and per-tier IaC modules for inference endpoint / model registry / GPU fleet / orchestrator - [ ] Each variant encoded as a forkable IaC module (Terraform / Pulumi / Helm or equivalent) - [ ] Each IaC module ships with a conformance test suite testing: workload-identity-only access confirmed, signed-artifact admission hook present, GPU residual-state clearing configured, SIEM forwarding active, per-tenant partitioning enforced for multi-tenant assets, rate-limit layer active for inference endpoints - [ ] IaC modules version-pinned with module update notification and drift-detection mechanism - [ ] 100% of Critical-tier assets with EU AI Act Art. 9 and Art. 15 controls explicitly mapped in the pattern documentation
Outcome Metrics: | Metric | Baseline | Target | Source | Met? | Notes | |--------|----------|--------|--------|------|-------| | Tier-conditional pattern variants published (Critical overlay, High overlay, multi-region, multi-tenant, per-tier IaC modules) | 0 / 5 | 5 / 5 | Architecture registry | ☐ | | | % Critical and High-tier AI/HAI infrastructure assets using an IaC-encoded pattern | measure | ≥80% | IaC registry × SM inventory | ☐ | | | Conformance test coverage across IaC-encoded asset deployments | measure | 100% of IaC-encoded deployments | CI/CD conformance test pipeline | ☐ | | | % Critical-tier assets with EU AI Act Art. 9 and Art. 15 controls explicitly mapped in the pattern | measure | 100% | Pattern metadata | ☐ | |
Metric Collection Guidance: - Tier-conditional variants: Count published variants with IaC module and conformance test suite present. Source: architecture registry. Reviewed quarterly. - IaC adoption rate: Cross-reference IaC registry against SM inventory for all Critical and High-tier infrastructure assets. Divide IaC-encoded count by total Critical/High count. Source: IaC registry and SM inventory export. - Conformance test coverage: Count IaC-encoded deployments with a passing conformance test run in the last 30 days divided by total IaC-encoded deployments. Source: CI/CD pipeline report. - EU AI Act mapping: Count Critical-tier assets whose pattern document includes Art. 9 and Art. 15 control-mapping section divided by total Critical-tier assets. Source: pattern metadata and SM inventory.
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 evidence)
Evidence Location: __ Validation Date: __ Notes: ___
Q2.2: Has the anti-pattern catalog been updated from three or more real IM-Infrastructure incidents in the last 12 months, with new entries surfaced at intake time rather than stored only in a reference document, and is conformance testing covering 100% of IaC-encoded infrastructure asset deployments with findings tracked to resolution?
Evidence Required: - [ ] IM-Infrastructure incident log showing at least 3 incidents in the last 12 months classified to an anti-pattern (existing or new) - [ ] Anti-pattern catalog change log showing entries added from IM-Infrastructure classifications with incident references - [ ] Anti-patterns surfaced at intake time: SM intake gate shows new anti-patterns alongside approved archetype selection - [ ] Conformance test failure log for the last 90 days showing findings with assigned owners and resolution timestamps - [ ] IaC module update notification mechanism operational - [ ] Module change log maintained with dated entries
Outcome Metrics: | Metric | Baseline | Target | Source | Met? | Notes | |--------|----------|--------|--------|------|-------| | Anti-pattern catalog additions fed from IM-Infrastructure incidents in last 12 months | measure | ≥3 additions | Anti-pattern change log | ☐ | | | Conformance test coverage across IaC-encoded asset deployments | measure | 100% of IaC-encoded deployments | CI/CD conformance test pipeline | ☐ | | | Conformance test findings tracked to resolution (no open findings >30 days without an owner) | measure | 100% of findings have an owner and resolution timeline | Conformance finding tracker | ☐ | | | IaC module update notification SLA | measure | ≤10 business days | Module change log + notification records | ☐ | |
Metric Collection Guidance: - Anti-pattern additions from incidents: Count catalog entries added in the last 12 months that carry an IM-Infrastructure incident reference. Source: anti-pattern catalog change log. - Conformance test coverage: Same as Q2.1. Reviewed monthly. - Finding resolution tracking: Export conformance test findings. Count findings with no assigned owner or with age >30 days and no resolution timestamp. Target is zero. Source: conformance finding tracker. - Module notification SLA: For each IaC module update in the review period, calculate elapsed days from module version-bump to last team-notification confirmation. Source: module change log and notification 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 evidence)
Evidence Location: __ Validation Date: __ Notes: ___
Q2.3: Are 100% of Critical-tier assets carrying explicit EU AI Act Art. 9 and Art. 15 control mappings in the pattern documentation, and is the tier-treatment matrix from SM-Infrastructure L2 reflected in the pattern variants (Critical assets get the Critical overlay, High assets get the High overlay, Medium/Low follow the base pattern)?
Evidence Required: - [ ] Tier-treatment matrix from SM-Infrastructure L2 documented and linked from the SA-Infrastructure pattern selection guide - [ ] Evidence that Critical-tier infrastructure assets are using the Critical overlay IaC module including dedicated-node isolation IaC and kill-switch IaC (confirmed by IaC registry query) - [ ] Evidence that High-tier assets are using the High overlay IaC module (confirmed by IaC registry query) - [ ] EU AI Act Art. 9 and Art. 15 control-mapping section present in each Critical-tier asset's pattern document - [ ] Technical-documentation artifact template auto-populated from the IaC module for Art. 11 documentation duties, confirmed by at least one sample artifact - [ ] Quarterly reconciliation record of Critical/High infrastructure asset list against IaC-encoded pattern adoption
Outcome Metrics: | Metric | Baseline | Target | Source | Met? | Notes | |--------|----------|--------|--------|------|-------| | % Critical-tier assets with EU AI Act Art. 9 and Art. 15 controls explicitly mapped in the pattern | measure | 100% | Pattern metadata | ☐ | | | % Critical-tier assets confirmed on the Critical overlay IaC module (including kill-switch IaC) | measure | 100% | IaC registry × SM inventory | ☐ | | | % High-tier assets confirmed on the High overlay IaC module | measure | ≥80% | IaC registry × SM inventory | ☐ | | | Quarterly tier-treatment matrix reconciliation completed on schedule | measure | 4 of 4 quarters completed | Reconciliation log | ☐ | |
Metric Collection Guidance: - Art. 9/15 mapping coverage: Count Critical-tier assets whose pattern document includes Art. 9 and Art. 15 control-mapping section divided by total Critical-tier assets. Source: pattern metadata audit. - Critical overlay adoption: Cross-reference SM inventory (Critical-tier assets) against IaC registry. Count assets using the Critical overlay module divided by total Critical-tier assets. Source: IaC registry and SM inventory. - High overlay adoption: Same method applied to High-tier assets. Source: IaC registry and SM inventory. - Reconciliation cadence: Count reconciliation records completed in the last 12 months. Target is 4. Source: reconciliation 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 evidence)
Evidence Location: __ Validation Date: __ Notes: ___
Objective: Publish infrastructure reference patterns as open industry artifacts; contribute pattern-derived mitigations to MITRE ATLAS; engage CNCF AI working groups and OpenSSF AI on architecture norms for AI/HAI infrastructure.
Q3.1: Have five or more reference patterns been published as open artifacts under a recognized open license via at least one industry body, CNCF AI working groups, OpenSSF AI, CSA AI Safety Initiative, or equivalent, and have two or more of those patterns been cited or forked by recognized industry or sector bodies, with documented adoption evidence and internal practice aligned to the published version?
Evidence Required: - [ ] At least 5 patterns published under Apache 2.0 or equivalent open license in a public repository (CNCF, OpenSSF, CSA, or equivalent) - [ ] Publication link, license declaration, and publication date on file for each published pattern - [ ] At least 2 patterns with documented external citations or forks (GitHub fork count, citation in published work, documented adopter organization) - [ ] Pattern adoption telemetry report (GitHub forks, citations, documented adopters) covering the last 12 months - [ ] Internal-external alignment audit showing zero unexplained divergences between internal pattern versions and published external versions - [ ] New archetypes or overlays developed internally proposed for external inclusion within 90 days of internal publication (process documented)
Outcome Metrics: | Metric | Baseline | Target | Source | Met? | Notes | |--------|----------|--------|--------|------|-------| | Reference patterns externally published (open license) | 0 | ≥5 patterns published | External repository | ☐ | | | Patterns cited or forked by recognized industry bodies | 0 | ≥2 cited or forked | External telemetry / citation tracking | ☐ | | | Internal practice aligned to published external version | n/a | 100%, zero unexplained internal deviations | Pattern diff audit | ☐ | | | New internal infrastructure archetypes proposed for external inclusion within 90 days | measure | 100% of new internal archetypes | Architecture registry change log | ☐ | |
Metric Collection Guidance: - Patterns published: Count patterns with a public repository URL, open-license declaration, and publication date. Source: external repository and architecture registry. - External citations/forks: Count external citations and GitHub forks. Source: external telemetry report. - Internal-external alignment: Run a quarterly diff between internal pattern version and published external version. Count unexplained divergences. Source: pattern diff audit. - External proposal lead time: For each new internal infrastructure archetype, measure elapsed days from internal publication to external proposal submission. Source: architecture registry and external contribution 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 evidence)
Evidence Location: __ Validation Date: __ Notes: ___
Q3.2: Have two or more MITRE ATLAS AML.M00xx mitigation entries been proposed or validated, traceable to specific SA-Infrastructure pattern controls aligned to ATLAS primary tactics TA0006 Persistence, TA0007 Privilege Escalation, and TA0008 Defense Evasion, and is there an active ATLAS practitioner engagement cadence with at least one contribution or validation per six months?
Evidence Required: - [ ] ATLAS contribution log with at least 2 entries showing proposed or validated AML.M00xx mitigations traceable to SA-Infrastructure pattern controls - [ ] Priority controls aligned to ATLAS primary tactics: TA0006 Persistence (signed artifacts, version pinning, residual-state clearing, immutable promotion log), TA0007 Privilege Escalation (workload-identity-only access, per-step principal, per-tenant partitioning), TA0008 Defense Evasion (eval-gate enforcement, signed pipeline definitions, conformance testing) - [ ] ATLAS practitioner community engagement records covering the last 12 months - [ ] Traceability table linking each ATLAS contribution to the specific SA-Infrastructure pattern control it corresponds to - [ ] At least 1 ATLAS contribution or validation completed in each 6-month period over the last 12 months
Outcome Metrics: | Metric | Baseline | Target | Source | Met? | Notes | |--------|----------|--------|--------|------|-------| | MITRE ATLAS mitigation entries proposed or validated by SA-Infrastructure | 0 | ≥2 AML.M00xx entries | ATLAS contribution log | ☐ | | | ATLAS contributions traceable to SA-Infrastructure pattern controls (TA0006 / TA0007 / TA0008) | 0 | 100% of contributions have pattern traceability | ATLAS contribution log + traceability table | ☐ | | | ATLAS contribution or validation cadence | measure | ≥1 per 6-month period | ATLAS contribution log | ☐ | | | ATLAS practitioner community engagement events or submissions | measure | ≥2 per year | Engagement records | ☐ | |
Metric Collection Guidance: - ATLAS contributions: Count AML.M00xx entries in the ATLAS contribution log with a status of "proposed" or "validated." Source: ATLAS contribution log. - Pattern traceability: For each ATLAS contribution, verify that a traceability row linking to a specific SA-Infrastructure pattern control is present. Source: traceability table. - Contribution cadence: Divide the last 12 months into two 6-month periods. Count contributions or validations in each period. Source: ATLAS contribution log timestamps. - Community engagement: Count ATLAS practitioner working-group events, comment submissions, or practitioner-meeting records. Source: engagement 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 evidence)
Evidence Location: __ Validation Date: __ Notes: ___
Q3.3: Is there at least one documented reference to SA-Infrastructure patterns in a regulatory implementing-act, sector guidance document, CNCF AI community document, OpenSSF AI guidance, or published standards text, and is the regulatory and community engagement calendar maintained with active items, target timelines, and evidence of substantive (not declaratory) participation?
Evidence Required: - [ ] At least 1 documented reference to SA-Infrastructure patterns in a regulatory implementing-act, sector guidance document, CNCF AI community document, OpenSSF AI guidance, or published standards text - [ ] Regulatory and community engagement calendar with active items listing the body, engagement type, submission status, and target timeline - [ ] CNCF AI working-group contribution record: GPU isolation pattern, orchestrator signing pattern, or vector-store partitioning pattern submitted for community adoption - [ ] OpenSSF AI submission record: AI CI/CD pattern (signed pipeline definitions, SLSA provenance, eval-gate enforcement) submitted as a practitioner contribution - [ ] EU AI Act implementing-act consultation submissions where SA-Infrastructure patterns were submitted as evidence of "state of the art" under Art. 9 and Art. 15 - [ ] Evidence that engagement is substantive: submission text or contribution artifact includes SA-Infrastructure pattern content (not only a letter of participation)
Outcome Metrics: | Metric | Baseline | Target | Source | Met? | Notes | |--------|----------|--------|--------|------|-------| | Regulatory or standards-body references to SA-Infrastructure patterns | 0 | ≥1 documented reference | Regulatory engagement log | ☐ | | | Community engagement calendar maintained with active items | measure | Yes, maintained with ≥2 active items at all times | Regulatory and community engagement calendar | ☐ | | | External contribution pipeline (pattern items in-flight: draft, in-review, or in-publication) | measure | ≥2 items in-flight at all times | External contribution pipeline log | ☐ | | | Internal-external alignment audit completed quarterly | measure | 4 of 4 quarters completed | Pattern diff audit log | ☐ | |
Metric Collection Guidance: - Regulatory/community references: Search implementing-act consultation responses, CNCF/OpenSSF published guidance, and standards text for citations of SA-Infrastructure patterns. Count distinct documented references. Source: regulatory engagement log and external citation tracking. - Engagement calendar health: Review the calendar. Count active items with a named target body, engagement type, and target timeline. Source: regulatory and community engagement calendar. - Contribution pipeline: Count items in the external contribution pipeline with a status of draft, in-review, or in-publication. Source: external contribution pipeline log. Reviewed monthly. - Alignment audit cadence: Count quarterly diff audits completed in the last 12 months. Target is 4. Source: pattern diff audit 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 evidence)
Evidence Location: __ Validation Date: __ Notes: ___
| Level | Q1 Score | Q2 Score | Q3 Score | Level Score |
|---|---|---|---|---|
| L1, Publish reference architectures and anti-pattern catalog | ___/1.0 | ___/1.0 | ___/1.0 | ___/1.0 |
| L2, IaC-encoded patterns with conformance test suites | ___/1.0 | ___/1.0 | ___/1.0 | ___/1.0 |
| L3, Open artifacts, ATLAS contributions, CNCF/OpenSSF engagement | ___/1.0 | ___/1.0 | ___/1.0 | ___/1.0 |
Overall SA-Infrastructure Score (L1×0.5 + L2×0.3 + L3×0.2): ___/1.0
Maturity Statement: - Score 0.0–0.32: Pre-L1, reference patterns and anti-pattern catalog are not yet published; no vetted green path exists for AI/HAI infrastructure platform teams. - Score 0.33–0.65: L1 Partial, some reference patterns published but workload-identity adoption, catalog linkage, or deviation tracking is incomplete. - Score 0.66–0.79: L1 Achieved, all seven infrastructure archetypes have reference patterns; anti-pattern catalog published; workload-identity-only access confirmed by IAM audit; deviation-review path operational. - Score 0.80–0.89: L2 Achieved, five tier-conditional IaC patterns operational; conformance test coverage at target; incident-informed catalog updates in place. - Score 0.90–1.0: L3 Achieved, patterns published as open industry artifacts via CNCF/OpenSSF; ATLAS contributions traceable; regulatory and community engagement substantive.
Document Version: HAIAMM v3.0 Practice: Secure Architecture (SA) Domain: Infrastructure Questionnaire Version: v3.0 Publication Date: 2026-05-15 Author: Verifhai
Instructions: