Assessment questionnaire for measuring maturity. Answer each question honestly based on current, implemented practices.
v3.0 canonical source:
../practices/SA-Software-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: Software Purpose: Assess organizational maturity in publishing and operationalizing reference architectures for every AI/HAI software archetype the organization ships 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-Software Score = weighted average: L1 × 0.5 + L2 × 0.3 + L3 × 0.2.
Objective: Publish reference architectures per AI/HAI software archetype and an anti-pattern catalog derived from real incidents; link each pattern to SR-Software requirements and TA-Software threats.
Q1.1: Has the organization published a reference architecture pattern for each of the seven AI/HAI software archetypes it ships, LLM-integrated app, agent, RAG pipeline, fine-tuning/training workload, eval harness, model-serving service, and classical ML model, with each pattern including a labeled data-flow diagram, data-boundary definition, identity and auth model, logging spec, and explicit row-by-row mapping to SR-Software requirements and TA-Software threats with HAI TTP tags (EA / AGH / TM / RA) and applicable MITRE ATLAS mitigation IDs, 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 data-flow diagram (scope, data boundary, identity/auth, traffic path, logging, SR mapping, threat mapping) - [ ] SR-Software requirement traceability rows present and populated for each pattern control - [ ] 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)
Outcome Metrics: | Metric | Baseline | Target | Source | Met? | Notes | |--------|----------|--------|--------|------|-------| | Reference patterns published per archetype (LLM-integrated app, agent, RAG, fine-tune/training, eval harness, model-serving service, classical ML) | 0 / 7 | 7 / 7 | Architecture registry | ☐ | | | % active AI/HAI software artifacts in the SM inventory using a named reference pattern or documented deviation | measure | ≥85% | Inventory × pattern metadata | ☐ | | | Pattern-to-SR requirement mapping coverage | measure | 100% of pattern controls tagged to SR requirement | Pattern metadata | ☐ | | | Deviation-review SLA compliance | measure | ≤5 business days from deviation request to decision | Deviation-review log | ☐ | |
Metric Collection Guidance: - Patterns published: Count published patterns with all required skeleton elements present. Source: architecture registry. Reviewed quarterly. - Inventory pattern adoption: Query SM inventory for each active artifact's pattern-adoption field. Count artifacts classified as "on pattern" or "deviation with review." Divide by total active artifacts. Source: SM inventory export. - SR mapping coverage: For each pattern, count controls that carry a SR requirement tag divided by total controls. Aggregate across all seven patterns. Source: pattern metadata. - Deviation SLA: From the deviation-review log, calculate elapsed business days from request timestamp to decision timestamp for all deviations in the review period. P90 value reported.
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 10 entries, each entry naming the pattern, explaining why it is dangerous, citing a real or representative incident, and linking to the reference pattern element that replaces it, linked from the AI Acceptable Use Policy, the SM intake gate, and EG-Software training?
Evidence Required: - [ ] Anti-pattern catalog document with at least 10 named entries covering the L1 mandatory set (prompt-injection-trusting agent, over-broad tool scope, system-prompt-leaking persona, long-session agent without memory bounds, fine-tune on user data without opt-out, silent model-family swap with no eval gate, RAG over unclassified corpus, LLM API key embedded in client code, secrets in prompts, output-integrity-critical decisions with no human gate) - [ ] Each entry includes: description, why dangerous, real/representative incident flavor, 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-Software training materials with a dated curriculum link - [ ] 100% of LLM-integrated app and agent artifacts verified (via CI secrets-scanning, not policy declaration) to route LLM provider credentials through a secrets vault
Outcome Metrics: | Metric | Baseline | Target | Source | Met? | Notes | |--------|----------|--------|--------|------|-------| | Anti-patterns catalog published and linked from intake / SM inventory | n/a | Yes | Document registry | ☐ | | | % of LLM-integrated app and agent artifacts running secrets through a secrets vault (no hardcoded API keys) | measure | 100% | IR spot-check / secrets-scanning in CI | ☐ | | | Anti-pattern catalog entries with a real-incident or representative-incident citation | measure | 100% of entries | Catalog metadata | ☐ | | | Time from new 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. - Secrets vault adoption: Run CI secrets-scanner (e.g., truffleHog, detect-secrets) across all LLM-integrated app and agent repositories. Count repositories with zero hardcoded LLM provider API key findings divided by total repositories. Source: CI pipeline report. - Incident citation coverage: Count anti-pattern entries with an incident citation field populated divided by total entries. Source: catalog metadata. - Catalog update lead time: From the incident classification timestamp in IM-Software to the catalog-entry publication timestamp. Measured per incident. Source: IM-Software 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 ownership, and are 85% or more of active AI/HAI software artifacts 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 ("on pattern" / "deviation with review" / "not classified") populated for all active artifacts - [ ] Repeat-deviation signal wired: a query, report, or automation that detects three or more deviations in the same direction for the same archetype and generates a pattern-update queue item - [ ] Pattern-update queue items traceable to deviation records with SA 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 artifacts with unreviewed/silent deviations confirmed by audit
Outcome Metrics: | Metric | Baseline | Target | Source | Met? | Notes | |--------|----------|--------|--------|------|-------| | % active AI/HAI software artifacts 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 (artifacts 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 the signal by showing at least one instance of the trigger firing and a resulting pattern-update queue item, or by showing the query/automation logic with a test-run result. Source: deviation-review log and pattern-update queue. - New-archetype lead time: For each new archetype category added to the inventory in the review period, measure elapsed days from the first intake record to the published pattern date. Source: SM inventory and architecture registry. - Silent deviations: Export SM inventory and count artifacts 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 agent-platform complexity calibrated to SM L2's tier-treatment matrix; encode patterns as IaC with conformance test suites; update the anti-pattern catalog from IM-Software incidents.
Q2.1: Are the five tier-conditional extended patterns, Critical overlay, High overlay, multi-region, multi-tenant, and agent-platform, published as forkable IaC modules with conformance test suites, and are 80% or more of Critical and High-tier AI/HAI software artifacts 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 with per-tenant isolation IaC, EU/US/sector data-residency variants, and kill-switch IaC; High overlay with monitoring and logging IaC modules; multi-region pattern; multi-tenant pattern; agent-platform pattern for multi-agent systems) - [ ] Each variant encoded as a forkable IaC module (Terraform / Pulumi / CloudFormation or equivalent) - [ ] Each IaC module ships with a conformance test suite testing: secrets in vault, egress allowlist applied, logging pipeline wired, HITL gate present for agent archetypes, per-tenant isolation enforced for multi-tenant patterns - [ ] IaC modules are version-pinned with a module update notification and drift-detection mechanism - [ ] 100% of Critical-tier artifacts 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, agent-platform) | 0 / 5 | 5 / 5 | Architecture registry | ☐ | | | % Critical and High-tier AI/HAI software artifacts using an IaC-encoded pattern | measure | ≥80% | IaC registry × SM inventory | ☐ | | | Conformance test coverage across IaC-encoded artifact deployments | measure | 100% of IaC-encoded deployments | CI/CD conformance test pipeline | ☐ | | | % Critical-tier artifacts 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 (list of artifact deployments using an IaC-encoded pattern) against the SM inventory for all Critical and High-tier artifacts. 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 artifacts whose pattern document includes an Art. 9 and Art. 15 control-mapping section divided by total Critical-tier artifacts. 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-Software 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 artifact deployments with findings tracked to resolution?
Evidence Required: - [ ] IM-Software 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-Software classifications with incident references - [ ] Anti-patterns surfaced at intake time: SM intake gate or equivalent shows new anti-patterns alongside approved vendor/archetype selection (not only in a reference document) - [ ] Conformance test failure log for the last 90 days showing findings with assigned owners and resolution timestamps - [ ] IaC module update notification mechanism operational (teams consuming a module are notified of updates requiring remediation) - [ ] Module change log maintained with dated entries
Outcome Metrics: | Metric | Baseline | Target | Source | Met? | Notes | |--------|----------|--------|--------|------|-------| | Anti-pattern catalog additions fed from IM-Software incidents in last 12 months | measure | ≥3 additions | Anti-pattern change log | ☐ | | | Conformance test coverage across IaC-encoded artifact 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 (teams notified within N days of a module update requiring remediation) | 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-Software incident reference. Source: anti-pattern catalog change log. - Conformance test coverage: Same as Q2.1. Reviewed monthly. - Finding resolution tracking: Export conformance test findings from the CI/CD pipeline. 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 artifacts carrying explicit EU AI Act Art. 9 and Art. 15 control mappings in the pattern documentation, and is the tier-treatment matrix from SM L2 reflected in the pattern variants, Critical artifacts get the Critical overlay, High artifacts get the High overlay, Medium/Low follow the base pattern?
Evidence Required: - [ ] Tier-treatment matrix from SM-Software L2 documented and linked from the SA-Software pattern selection guide - [ ] Evidence that Critical-tier artifacts are using the Critical overlay IaC module (confirmed by IaC registry query, not only policy) - [ ] Evidence that High-tier artifacts 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 artifact's pattern document - [ ] Technical-documentation artifact template auto-populated from the IaC module for Art. 11 documentation duties - [ ] Quarterly reconciliation record of Critical/High artifact list against IaC-encoded pattern adoption
Outcome Metrics: | Metric | Baseline | Target | Source | Met? | Notes | |--------|----------|--------|--------|------|-------| | % Critical-tier artifacts with EU AI Act Art. 9 and Art. 15 controls explicitly mapped in the pattern | measure | 100% | Pattern metadata | ☐ | | | % Critical-tier artifacts confirmed on the Critical overlay IaC module (not base pattern) | measure | 100% | IaC registry × SM inventory | ☐ | | | % High-tier artifacts 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: Query pattern metadata for Critical-tier artifacts. Count those with an Art. 9 and Art. 15 control-mapping section present and populated. Source: pattern metadata audit. - Critical overlay adoption: Cross-reference SM inventory (Critical-tier artifacts) against IaC registry (module ID used). Count artifacts using the Critical overlay module divided by total Critical-tier artifacts. Source: IaC registry and SM inventory. - High overlay adoption: Same method applied to High-tier artifacts. 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 reference patterns as open industry artifacts; contribute pattern-derived mitigations to MITRE ATLAS; engage regulators and standards bodies on architecture norms for AI/HAI software.
Q3.1: Have five or more reference patterns been published as open artifacts under a recognized open license via at least one industry body, OWASP SAMM AI, 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 (GitHub, OWASP, OpenSSF, 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 in published work, 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 are 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 from the published version | Pattern diff audit | ☐ | | | New internal 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 (Google Scholar, published standards documents, industry reports) and GitHub forks. Source: external telemetry report. - Internal-external alignment: Run a quarterly diff between internal pattern version and published external version for each published pattern. Count unexplained divergences. Source: pattern diff audit. - External proposal lead time: For each new internal 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-Software 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-Software pattern controls - [ ] Priority controls aligned to ATLAS primary tactics: TA0006 Persistence (model-version pinning, prompt-template versioning, lineage tracking), TA0007 Privilege Escalation (tool-scope minimization, allowlist enforcement, per-tenant isolation), TA0008 Defense Evasion (output filter, injection defense, model-card transparency, conformance testing) - [ ] ATLAS practitioner community engagement records (participation in working group, comment submissions, or practitioner meetings) covering the last 12 months - [ ] Traceability table linking each ATLAS contribution to the specific SA-Software 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-Software | 0 | ≥2 AML.M00xx entries | ATLAS contribution log | ☐ | | | ATLAS contributions traceable to SA-Software pattern controls (TA0006 / TA0007 / TA0008) | 0 | 100% of contributions have pattern traceability | ATLAS contribution log + pattern traceability table | ☐ | | | ATLAS contribution or validation cadence | measure | ≥1 per 6-month period | ATLAS contribution log | ☐ | | | ATLAS practitioner community engagement events attended or submissions made | 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-Software 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 participation events, comment submissions, or practitioner-meeting attendance 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-Software patterns in a regulatory implementing-act, sector guidance document, or published standards text, and is the regulatory engagement calendar maintained with active items, target timelines, and evidence of substantive (not declaratory) participation in EU AI Act implementing-act consultations, ISO/IEC 42001, NIST AI RMF Playbook successor, or sector-specific regulatory processes?
Evidence Required: - [ ] At least 1 documented reference to SA-Software patterns in a regulatory implementing-act, sector guidance document, or published standards text (not a blog post or conference presentation) - [ ] Regulatory engagement calendar with active items listing the body, engagement type, submission status, and target timeline - [ ] EU AI Act implementing-act consultation submissions (or records of participation) where SA-Software patterns were submitted as evidence of "state of the art" under Art. 9 - [ ] ISO/IEC 42001 AIMS community guidance contribution record, NIST AI RMF Playbook successor engagement record, or sector-specific regulatory engagement record - [ ] For sector-specific engagement (FINRA/SEC, HHS/FDA, NYDFS): evidence of sector-relevant pattern-variant submission to sector regulatory body or ISAC - [ ] Evidence that engagement is substantive: the submission text or contribution artifact includes SA-Software pattern content (not only a letter of participation)
Outcome Metrics: | Metric | Baseline | Target | Source | Met? | Notes | |--------|----------|--------|--------|------|-------| | Regulatory or standards-body references to SA-Software patterns | 0 | ≥1 documented reference | Regulatory engagement log | ☐ | | | Regulatory engagement calendar maintained with active items | measure | Yes, maintained with ≥2 active items at all times | Regulatory 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 references: Search implementing-act consultation responses, published guidance, and standards text for citations of SA-Software patterns. Count distinct documented references. Source: regulatory engagement log and external citation tracking. - Engagement calendar health: Review the regulatory engagement calendar. Count active items with a named target body, engagement type, and target timeline. Target is 2 or more active items at any point in the review period. Source: regulatory 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, regulatory engagement | ___/1.0 | ___/1.0 | ___/1.0 | ___/1.0 |
Overall SA-Software 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 software teams. - Score 0.33–0.65: L1 Partial, some reference patterns published but coverage, catalog linkage, or deviation tracking is incomplete. - Score 0.66–0.79: L1 Achieved, all seven archetypes have reference patterns; anti-pattern catalog published; deviation-review path operational; secrets vault adoption confirmed. - Score 0.80–0.89: L2 Achieved, 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; ATLAS contributions traceable; regulatory engagement substantive and documented.
Document Version: HAIAMM v3.0 Practice: Secure Architecture (SA) Domain: Software Questionnaire Version: v3.0 Publication Date: 2026-05-15 Author: Verifhai
Instructions: