Assessment questionnaire for measuring maturity. Answer each question honestly based on current, implemented practices.
v3.0 canonical source:
../practices/SA-Data-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: Data Purpose: Assess organizational maturity in publishing and operationalizing reference architectures for every AI/HAI data archetype the organization ingests, stores, routes, or retires 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-Data Score = weighted average: L1 × 0.5 + L2 × 0.3 + L3 × 0.2.
Objective: Publish reference architectures per AI/HAI data archetype and an anti-pattern catalog derived from real incidents; link each pattern to SR-Data requirements and TA-Data threats.
Q1.1: Has the organization published a reference architecture pattern for each of the seven AI/HAI data archetypes it operates, training corpus, inference input stream, retrieval store, prompt/completion log corpus, embedding store, fine-tuning dataset, and evaluation/test set, with each pattern including a labeled data-flow diagram, classification flow, consent/lawful-basis check point, lineage and provenance hooks, access control model, logging specification, and explicit row-by-row mapping to SR-Data requirements and TA-Data threats with HAI TTP tags and applicable MITRE ATLAS technique 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 covering scope, data boundary and classification flow, consent/lawful-basis check point, lineage/provenance hooks, access control model, logging spec, SR mapping, and threat mapping - [ ] MITRE ATLAS technique IDs (AML.T0019, T0020, T0024, T0025, T0010 where applicable) and HAI TTP tags (EA / AGH / TM / RA) 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 training-corpus and fine-tuning-dataset assets verified (via data-catalog audit) to have a classification-gating check on file before entering any AI training pipeline
Outcome Metrics: | Metric | Baseline | Target | Source | Met? | Notes | |--------|----------|--------|--------|------|-------| | Reference patterns published per archetype (training corpus, inference input stream, retrieval store, prompt/completion log corpus, embedding store, fine-tuning dataset, evaluation/test set) | 0 / 7 | 7 / 7 | Architecture registry | ☐ | | | % active AI/HAI data assets in the SM inventory using a named reference pattern or documented deviation | measure | ≥85% | Inventory × pattern metadata | ☐ | | | % training-corpus and fine-tuning-dataset assets with a completed classification-gating check on file | measure | 100% | IR spot-check / data-catalog audit | ☐ | | | Pattern-to-SR 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. Source: architecture registry. Reviewed quarterly. - Inventory pattern adoption: Query SM inventory for each active data asset's pattern-adoption field. Count assets classified as "on pattern" or "deviation with review" divided by total active data assets. Source: SM inventory export. - Classification-gating check: Query the data catalog for training-corpus and fine-tuning-dataset assets. Count those with a completed classification-gating check record on file divided by total such assets. Source: data-catalog 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 10 entries, each 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 Data Policy, the SM intake gate, and EG-Data training, and are 100% of training-corpus and fine-tuning-dataset assets verified via data-catalog audit to have passed through a classification-gating check with a documented consent/lawful-basis record on file?
Evidence Required: - [ ] Anti-pattern catalog document with at least 10 named entries covering the L1 mandatory set (regulated PII in training without DPIA, PII in logs unredacted, embedding stores world-readable, eval set leaked to training, no-train assertion trusted from contract text, fine-tuning dataset built from inference logs without re-use assessment, retrieval store over unclassified corpus, cross-border data flow without transfer mechanism, DSAR deletion ignored for training data, lineage absent from pipeline transforms) - [ ] Each entry includes: description, why dangerous, real/representative incident flavor, and the reference pattern element that replaces it - [ ] Catalog linked from the AI Data Policy (with a dated link) - [ ] Catalog linked from the SM intake gate (verified by IR spot-check) - [ ] Catalog referenced in EG-Data training materials with a dated curriculum link - [ ] Data-catalog audit records confirming classification-gating check and consent/lawful-basis record for all training-corpus and fine-tuning-dataset assets
Outcome Metrics: | Metric | Baseline | Target | Source | Met? | Notes | |--------|----------|--------|--------|------|-------| | Anti-pattern catalog published and linked from intake / SM inventory | n/a | Yes | Document registry | ☐ | | | % training-corpus and fine-tuning-dataset assets with classification-gating check and consent/lawful-basis record on file | measure | 100% | Data-catalog audit | ☐ | | | Anti-pattern catalog entries with a real-incident or representative-incident citation | measure | 100% of entries | Catalog metadata | ☐ | | | Time from new IM-Data 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. - Classification-gating adoption: Query data catalog for all training-corpus and fine-tuning-dataset assets. Count those with both a classification-gating check record and a consent/lawful-basis record on file divided by total such assets. Source: data-catalog audit. - 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 IM-Data incident classification timestamp to catalog-entry publication timestamp. Source: IM-Data 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 data 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 data assets - [ ] Repeat-deviation signal wired: a query, report, or automation that detects three or more deviations in the same direction for the same data 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 data archetype category to pattern publication) - [ ] Pattern quarterly review schedule with change-log entries maintained - [ ] Zero data assets with unreviewed/silent deviations confirmed by audit
Outcome Metrics: | Metric | Baseline | Target | Source | Met? | Notes | |--------|----------|--------|--------|------|-------| | % active AI/HAI data 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 (data 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 data 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 data 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 / cross-border, multi-tenant, and tier-conditional variants calibrated to SM L2's tier-treatment matrix; encode patterns as IaC; update the anti-pattern catalog from IM-Data incidents.
Q2.1: Are the four tier-conditional extended patterns, Critical overlay, High overlay, multi-region/cross-border, and multi-tenant, published as forkable IaC modules with conformance test suites, and are 80% or more of Critical and High-tier AI/HAI data assets running on IaC-encoded patterns as confirmed by the IaC and SM inventory registries?
Evidence Required: - [ ] Four tier-conditional pattern variants documented and published (Critical overlay with per-tenant isolation IaC, data-residency enforcement, and automated SCC/transfer-mechanism verification; High overlay with monitoring and logging IaC modules; multi-region/cross-border pattern; multi-tenant pattern for shared data infrastructure) - [ ] Each variant encoded as a forkable IaC module (Terraform / Pulumi / CloudFormation or equivalent) - [ ] Each IaC module ships with a conformance test suite testing: classification gate active, PII redaction enabled at logging, per-tenant isolation enforced, transfer mechanism verified, retention policy enforced, RBAC applied, audit log active - [ ] IaC modules version-pinned with module update notification and drift-detection mechanism - [ ] 100% of Critical-tier data assets with automated transfer-mechanism verification in the IaC module
Outcome Metrics: | Metric | Baseline | Target | Source | Met? | Notes | |--------|----------|--------|--------|------|-------| | Tier-conditional pattern variants published (Critical overlay, High overlay, multi-region/cross-border, multi-tenant) | 0 / 4 | 4 / 4 | Architecture registry | ☐ | | | % Critical and High-tier AI/HAI data assets using an IaC-encoded pattern | measure | ≥80% | IaC registry × SM inventory | ☐ | | | Conformance test coverage across IaC-encoded data-pipeline deployments | measure | 100% of IaC-encoded deployments | CI/CD conformance test pipeline | ☐ | | | % Critical-tier data assets with automated transfer-mechanism verification in the IaC module | measure | 100% | IaC module 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 data 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. - Transfer-mechanism verification: Count Critical-tier data assets whose IaC module includes the automated transfer-mechanism verification step divided by total Critical-tier data assets. Source: IaC module 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: ___
Q2.2: Has the anti-pattern catalog been updated from three or more real IM-Data 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 data-pipeline deployments with findings tracked to resolution?
Evidence Required: - [ ] IM-Data 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-Data classifications with incident references - [ ] Anti-patterns surfaced at intake time: SM intake gate shows new anti-patterns alongside approved 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-Data incidents in last 12 months | measure | ≥3 additions | Anti-pattern change log | ☐ | | | Conformance test coverage across IaC-encoded data-pipeline 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-Data 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 data assets using the Critical-tier overlay IaC module with automated transfer-mechanism verification, and does the tier-treatment matrix from SM-Data L2 drive the pattern variant selection: Critical assets on the Critical overlay, High assets on the High overlay, Medium/Low on the base pattern?
Evidence Required: - [ ] Tier-treatment matrix from SM-Data L2 documented and linked from the SA-Data pattern selection guide - [ ] Evidence that Critical-tier data assets are using the Critical overlay IaC module (confirmed by IaC registry query, not only policy) - [ ] Evidence that High-tier data assets are using the High overlay IaC module (confirmed by IaC registry query) - [ ] GDPR Art. 35 DPIA evidence template auto-populated from the IaC module for Critical-tier data assets, confirmed by at least one sample artifact - [ ] EU AI Act Art. 10 training-data quality controls explicitly mapped in Critical-tier training-corpus and fine-tuning-dataset pattern documentation - [ ] Quarterly reconciliation record of Critical/High data-asset list against IaC-encoded pattern adoption
Outcome Metrics: | Metric | Baseline | Target | Source | Met? | Notes | |--------|----------|--------|--------|------|-------| | % Critical-tier data assets confirmed on the Critical overlay IaC module | measure | 100% | IaC registry × SM inventory | ☐ | | | % Critical-tier data assets with automated transfer-mechanism verification in the IaC module | measure | 100% | IaC module metadata | ☐ | | | % High-tier data 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: - Critical overlay adoption: Cross-reference SM inventory (Critical-tier data assets) against IaC registry (module ID used). Count assets using the Critical overlay module divided by total Critical-tier data assets. Source: IaC registry and SM inventory. - Transfer-mechanism verification coverage: Same as Q2.1 outcome metric 4. Source: IaC module metadata. - High overlay adoption: Same method applied to High-tier data 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 reference patterns as open industry artifacts; contribute pattern-derived mitigations to MITRE ATLAS; engage standards bodies on data architecture norms for AI/HAI data pipelines.
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 LLM/Agentic, OpenSSF AI, DAMA / EDM Council, 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 - [ ] 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 data 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 data 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 data 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-Data pattern controls aligned to the primary data-attack ATLAS techniques, AML.T0019 Publish Poisoned Datasets, AML.T0020 Poison Training Data, AML.T0024 Exfiltration via ML Inference API, AML.T0025 Exfiltration via Cyber Means, AML.T0010 ML Supply Chain Compromise, and is there an active ATLAS practitioner engagement cadence?
Evidence Required: - [ ] ATLAS contribution log with at least 2 entries showing proposed or validated AML.M00xx mitigations traceable to SA-Data pattern controls - [ ] Priority controls aligned to primary data-attack techniques: AML.T0019 (classification-gating staging, provenance verification), AML.T0020 (anomaly detection at ingest, lineage tracking), AML.T0024 (retrieval-only access, embedding inversion defense, per-tenant isolation), AML.T0025 (access-controlled log export interface), AML.T0010 (source-lineage verification, supply-chain gating) - [ ] ATLAS practitioner community engagement records covering the last 12 months - [ ] Traceability table linking each ATLAS contribution to the specific SA-Data 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-Data | 0 | ≥2 AML.M00xx entries | ATLAS contribution log | ☐ | | | ATLAS contributions traceable to primary data-attack techniques (AML.T0019 / T0020 / T0024 / T0025 / T0010) | 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-Data 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-Data 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 Art. 10 consultations, GDPR supervisory authority guidance, NIST AI RMF Playbook successor, DAMA/EDM Council, or sector-specific regulatory processes?
Evidence Required: - [ ] At least 1 documented reference to SA-Data patterns in a regulatory implementing-act, sector guidance document, or published standards text - [ ] Regulatory engagement calendar with active items listing the body, engagement type, submission status, and target timeline - [ ] EU AI Act Art. 10 training-data consultation submissions or participation records where SA-Data patterns were submitted as evidence of "state of the art" - [ ] GDPR supervisory authority guidance contribution record (consent-tracking at scale, DPIA requirements for large-scale personal-data training, or Art. 17 deletion-propagation obligations) - [ ] NIST AI RMF Playbook successor engagement record or DAMA International / EDM Council AI Data Governance working-group contribution record - [ ] Evidence that engagement is substantive: submission text or contribution artifact includes SA-Data pattern content (not only a letter of participation)
Outcome Metrics: | Metric | Baseline | Target | Source | Met? | Notes | |--------|----------|--------|--------|------|-------| | Regulatory or standards-body references to SA-Data 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-Data 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. 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-Data 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 data pipeline teams. - Score 0.33–0.65: L1 Partial, some reference patterns published but classification-gating, catalog linkage, or deviation tracking is incomplete. - Score 0.66–0.79: L1 Achieved, all seven data archetypes have reference patterns; anti-pattern catalog published; classification-gating checks confirmed; deviation-review path operational. - Score 0.80–0.89: L2 Achieved, tier-conditional IaC patterns operational; automated transfer-mechanism verification at target; incident-informed catalog updates in place. - Score 0.90–1.0: L3 Achieved, patterns published as open industry artifacts; ATLAS contributions traceable to primary data-attack techniques; regulatory engagement substantive and documented.
Document Version: HAIAMM v3.0 Practice: Secure Architecture (SA) Domain: Data Questionnaire Version: v3.0 Publication Date: 2026-05-15 Author: Verifhai
Instructions: