Secure Architecture (SA)

Data Domain - HAIAMM v3.0

Practice Overview

Objective: Publish the reference architectures for safely ingesting, storing, routing, and retiring each AI/HAI data archetype the organization uses, so data engineering and MLOps teams have a vetted "green path" that already implements SR-Data requirements and contains the threats identified by TA-Data.

Description: SA-Data ships a catalog of reference patterns, one per AI/HAI data archetype, showing how to classify, gate, isolate, log, and expire the data that flows into and out of AI systems. Each pattern covers scope, data boundary and classification flow, access control model, lineage and provenance tracking, logging specification, controls mapped to SR-Data requirements, and threats mitigated (tagged to HAI TTPs and MITRE ATLAS). The catalog is accompanied by an anti-pattern list derived from real incidents and first-party post-incident reviews. Teams use the reference pattern as the starting point; deviations require design review. At L2, patterns are extended with multi-region / cross-border data-residency variants and tier-conditional controls encoded as IaC. At L3, patterns are published as open artifacts adopted by the industry.

Context: Without reference patterns, every data engineering team building a training pipeline, a retrieval store, or a logging subsystem makes the same architectural missteps: regulated PII flowing into training without consent verification, retrieval stores indexed without per-source classification, prompt/completion logs retained indefinitely without PII redaction, embedding stores world-readable without access control. The downstream cost is threat models that discover problems too late, design reviews that repeat the same finding set, and GDPR enforcement actions that replay avoidable anti-patterns. SA-Data makes the secure path the default path for every AI data archetype, not by blocking data engineering, but by publishing a pre-vetted architecture that teams reach for first.

Maturity Level 1

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

At this level, architecture becomes prescriptive rather than advisory for AI data assets. Reference patterns are named, versioned, and the first thing a team reaches for when designing an ingestion pipeline, a retrieval store, an embedding index, a logging subsystem, a fine-tuning curation workflow, or an evaluation framework.

Dependencies

• SR-Data L1 (required): patterns implement the base + archetype requirement packs; without the pack, pattern controls are stylistic choices rather than requirement-backed decisions.
• TA-Data L1 (required): threat library drives which controls appear in each pattern and which threats each pattern claims to mitigate.
• PC-Data L1 (required): patterns operationalize AI Data Policy constraints including consent-basis requirements, cross-border flow mechanisms, and retention obligations.
• SM-Data L1 (required): inventory shows which data archetypes the org actually uses; patterns are authored for that archetype list.
• Supports / unblocks: DR-Data L1 (design reviews use the pattern as the baseline), IR-Data L1 (implementation reviews check pattern adherence), EH-Data L1 (hardening targets the pattern's surface areas), ST-Data L1 (security tests target the pattern's controls).

Desired Outcomes

• Every team building or modifying an AI/HAI data pipeline finds a documented reference pattern within one click of the SM inventory record.
• Each pattern is concrete enough to implement: classification flow diagram, access control model, lineage and provenance hooks, logging points, controls with SR traceability, and named threats mitigated.
• Known anti-patterns, the architectural mistakes that have produced real incidents, are named, explained, and linked to the reference pattern that replaces them.
• Deviations from reference patterns are visible and reviewed, not accidental or silent.
• Architecture decisions carry explicit traceability to SR requirements and TA threats.

Activities

A) Publish reference architectures per AI/HAI data archetype

Publish one pattern per archetype the org actually uses. Each pattern is concise (≤3 pages), includes a labeled data-flow diagram, and covers the same structural elements.

Pattern skeleton (every archetype): - Scope, what the pattern covers and what it explicitly does not. - Data boundary and classification flow, where data enters the AI pipeline; classification label applied or verified; label propagation through transforms; where regulated data is gated or blocked. - Consent and lawful basis check point, where consent verification or lawful-basis record is confirmed before the data proceeds; who owns the check and what blocks progress if the check fails. - Lineage and provenance hooks, where lineage metadata is attached; which pipeline steps record their transformations; where the lineage record is stored and how it is queried. - Access control model, RBAC roles for read, write, export, and delete; service-principal model for pipeline service accounts; audit log coverage. - Logging specification, what events are logged (ingest, transform, access, export, delete, retention enforcement); retention period; export mechanism for DSAR and regulator requests. - Controls mapped to SR requirements, explicit row-by-row mapping; gaps acknowledged. - Threats mitigated, which TA-Data archetype threats the pattern addresses, which remain residual; HAI TTP tags (EA / AGH / TM / RA); MITRE ATLAS technique IDs (AML.T0019, T0020, T0024, T0025, T0010 where applicable) and mitigation IDs where available.

Archetype reference patterns:

Training corpus pattern. Centralized ingestion through a classification-gating staging area: raw source data lands in a staging zone; a classification check runs before promotion to the curated training lake (data with regulated PII, PHI, or confidential content that lacks a documented lawful basis is blocked at the staging gate); consent-basis record confirmed at ingest (each data source has a documented Art. 6 lawful basis or consent; sources without a documented basis are quarantined); lineage tagging applied at ingest (source URL or internal registry ID, ingest timestamp, data class, consent basis, lineage version); access through a curated training-data lake (pipeline service accounts access the curated lake, not the raw staging zone); poisoned-data detection scan at ingest (automated deduplication plus anomaly detection on label distributions for labeled corpora; manual review sampling for new sources); retention/expiry enforcement (automated retention policy; assets past retention date flagged for purge or anonymization). Threats mitigated: AML.T0020 training-data poisoning (gating + scan), AML.T0010 supply-chain compromise (source-lineage verification), unconsented data inclusion (consent check at staging gate), regulated-data leakage at training time (classification gating). HAI-TTP: RA. ATLAS: TA0005 Persistence mitigated by lineage tagging; TA0002 Resource Development (AML.T0019) mitigated by scan at ingest.

Inference input stream pattern. PII redaction at input-edge: incoming inference inputs are screened for PII and regulated data classes before reaching the inference service; PII found in inputs destined for vendor LLM APIs is redacted or pseudonymized unless the DPA explicitly covers the data class. Classification-gated routing: inputs classified as containing Art. 9 special-category personal data (health, biometric, ethnic-origin) are routed only to inference endpoints with confirmed no-train status; no Art. 9 data reaches an endpoint whose no-train assertion has not been verified at the admin-console level. Per-tenant context isolation: prompt context from one tenant does not cross to another tenant's inference context; tenant identifier is propagated through the inference path. Rate-limit and abuse-detection layer at the input edge. Prompt events logged with tenant identifier, classification tag, and timestamp, not full prompt content unless a lawful basis for detailed logging is in place. Threats mitigated: direct prompt injection (AML.T0051) defense-in-depth through input validation; regulated-data leakage to vendor LLMs (classification-gated routing + no-train verification); sensitive-information disclosure (per-tenant isolation). HAI-TTP: AGH. ATLAS: TA0003 Initial Access mitigated by input validation; TA0011 Exfiltration (AML.T0024) mitigated by classification-gated routing.

Retrieval store pattern. Classification-labeled documents: every document indexed into the retrieval store is labeled with a classification at index time; unlabeled documents are quarantined. Per-tenant retrieval isolation: retrieval namespaces are partitioned by tenant; a query from tenant A cannot return chunks from tenant B's namespace. Injection-defense over retrieved content: retrieved chunks are treated as untrusted; the prompt structure separates system instructions from retrieved material; retrieved content is not executed or passed to downstream tools without validation. Provenance metadata on every retrieved chunk: source identifier, last-verified date, classification label, and lineage version stored alongside the embedding and retrievable with the chunk. Embedding-store access control: the vector index is not world-readable; RBAC applied to the embedding query interface. Retrieval logging: every retrieval event logged (tenant, query-hash, top-k source identifiers, classification of returned chunks, timestamp). Threats mitigated: retrieval poisoning (AML.T0020, source classification + provenance); corpus exfiltration (AML.T0024, retrieval-only access + rate limit); indirect prompt injection (AGH, untrusted-content treatment + structural separation); classification-label bypass (per-tenant isolation + label enforcement). ATLAS: TA0006 Persistence mitigated by source provenance; TA0010 Collection mitigated by retrieval-only access and rate limit.

Prompt/completion log corpus pattern. PII redaction at logging: prompt and completion text is screened and PII is redacted or pseudonymized at log-write time before persistence; raw prompt content containing regulated data is not written in plaintext. Retention by archetype: prompt/completion logs carry a retention tag at write time aligned to the GDPR Art. 5(1)(e) storage-limitation principle; automated retention enforcement purges or anonymizes records past the retention period. Export through a controlled DSAR-capable interface: no bulk export without access-control enforcement; a DSAR export interface locates and packages records for a named data subject within the statutory timeline. Per-tenant partitioning: log records are partitioned by tenant; cross-tenant log access is blocked at the query layer. Lineage linkage: log records carry a reference to the SM inventory record of the AI artifact that produced them. Threats mitigated: retention-policy violation (automated enforcement); regulated-data persistence in logs (PII redaction at write); unauthorized log export (access-controlled export interface); log-mining for training without consent (no-train-reuse check before any log corpus is used as fine-tuning data). ATLAS: TA0011 Exfiltration (AML.T0025) mitigated by export access control.

Embedding store pattern. Access control on raw embeddings: vector embeddings are accessible only through a classification-aware RBAC query interface; no direct vector download without explicit authorization. Inversion-defense controls: embeddings of sensitive content (Art. 9 data, confidential documents) have noise or clipping applied before indexing to reduce susceptibility to embedding inversion (AML.T0024 mitigated); for highest-sensitivity content, retrieval-only access (no raw vector returned, only the associated content with access control) is enforced. Per-tenant partitioning: embedding namespaces separated by tenant; cross-tenant nearest-neighbor queries blocked. Nearest-neighbor rate limiting: systematic enumeration attacks mitigated by per-user query rate limits with anomaly detection on query patterns. Access audit log: every embedding query logged (tenant, query timestamp, result count, classification tier of returned content). Threats mitigated: embedding inversion (AML.T0024, noise + retrieval-only access); nearest-neighbor extraction (AML.T0024, rate limit + anomaly detection); retrieval poisoning at embedding layer (HAA.PI, untrusted-content treatment). HAI-TTP: TM. ATLAS: TA0010 Collection mitigated by rate limit and retrieval-only access.

Fine-tuning dataset pattern. DPIA-gated curation: a DPIA is completed and signed before a fine-tuning dataset containing personal data is approved for use; the DPIA reference is required in the dataset's SM inventory record and in the SR-Data REM. Consent-tracked subject inclusion: each data subject contributing records to the dataset has a documented consent basis or lawful basis; the basis record is linked to the dataset version. Opt-out enforcement: subjects who have withdrawn consent or exercised Art. 17 deletion are excluded from the dataset before fine-tuning commences; an automated deduplication step confirms exclusion before training-job approval. Lineage to training-job event: the dataset version used in each fine-tuning run is recorded in the training-job event log, enabling post-hoc DSAR and audit queries. Dataset isolation: the fine-tuning dataset does not have network access from the training environment; no production system credentials in the training environment. Threats mitigated: unconsented data inclusion (consent-tracking + DPIA gate); training-data poisoning (AML.T0020, lineage + provenance); label-flip attacks (anomaly detection on label distribution at curation). HAI-TTP: RA. ATLAS: TA0005 Persistence mitigated by lineage tracking; TA0002 Resource Development (AML.T0019) mitigated by provenance verification.

Evaluation / test set pattern. Isolation from training: eval set data does not flow to training pipelines; pipeline access controls enforce the isolation; a bidirectional deduplication check confirms no overlap between the eval set and the training or fine-tuning corpora before any evaluation run. Contamination-prevention gate: deduplication and membership-inference scan runs as a pre-condition for evaluation; results are recorded in the model's eval attestation. Reproducibility metadata: eval set version, model version, inference configuration, and evaluation timestamp recorded and retained alongside evaluation results; eval results are signed and stored in the model registry as a prerequisite for model promotion. Access control: eval set access restricted to named evaluation personnel; read-only access for evaluation runs; write access only for dataset curators. Threats mitigated: eval contamination (isolation + contamination-prevention gate); eval gaming (AML.T0048, signed attestation + reproducibility); eval suppression (mandatory attestation before model promotion). ATLAS: TA0008 Defense Evasion mitigated by signed attestation; TA0040 ML Attack Staging (AML.T0048) mitigated by contamination gate.

B) Publish the anti-pattern catalog

Name, describe, and prohibit the AI/HAI data architectural patterns that reliably produce incidents. Each anti-pattern entry includes: description, why it is dangerous, real-incident flavor (industry or first-party), and the reference pattern element that replaces it.

L1 anti-pattern set:

• Regulated PII in training without DPIA or lawful basis, a training corpus is assembled by bulk export of production data; no GDPR Art. 35 DPIA is completed; no Art. 6 lawful basis is documented; the model is trained, memorizes PII, and regurgitates it in completions. Replaced by: training corpus pattern classification-gating staging area and consent-basis check point.
• PII in prompt/completion logs unredacted, inference logs retain full prompt and completion text including names, email addresses, and account numbers submitted by users; logs are retained indefinitely and are exported to a data warehouse without access control. Replaced by: prompt/completion log corpus pattern PII redaction at logging and controlled export interface.
• Embedding stores world-readable, the vector index backing a RAG pipeline is accessible without authentication; any engineer or service in the network can download all embeddings and reconstruct source content via inversion. Replaced by: embedding store pattern classification-aware RBAC and retrieval-only access.
• Eval set leaked to training, evaluation examples are added to training data to improve benchmark scores without corresponding improvement in real-world performance; safety benchmarks are invalidated. Replaced by: evaluation/test set pattern contamination-prevention gate and signed attestation.
• No-train assertion trusted from contract text, the org's DPA states the vendor will not train on customer data, but the admin-console setting enabling training-on-customer-data is never disabled; the contractual assertion and the technical state diverge; regulated personal data trains the vendor's model. Replaced by: inference input stream pattern admin-console-level no-train verification with recurrent re-verification.
• Fine-tuning dataset built from inference logs without re-use assessment, prompt/completion logs are repurposed as fine-tuning data; the original consent basis for inference does not cover training use; GDPR Art. 6 secondary-purpose condition is not assessed; a DPIA is not triggered. Replaced by: fine-tuning dataset pattern DPIA-gated curation and lineage to training-job event.
• Retrieval store over unclassified corpus, the full internal document library is indexed into the retrieval store without per-source classification or per-tenant isolation; a sales-team user query surfaces a confidential M&A document indexed for the executive namespace. Replaced by: retrieval store pattern classification-labeled documents and per-tenant isolation.
• Cross-border data flow without transfer mechanism, training data or prompt/completion logs containing EU personal data flow to a US cloud region without an SCC or adequacy decision in place; the transfer is discovered during a supervisory authority inquiry. Replaced by: base pack cross-border flows requirement and the L2 multi-region pattern.
• DSAR deletion ignored for training data, a data subject exercises Art. 17 right to erasure; the response team removes the subject from the user database but does not propagate the deletion to training corpora or fine-tuning datasets; the model continues to regurgitate the subject's data. Replaced by: training corpus and fine-tuning dataset patterns opt-out enforcement and lineage to training-job event for deletion propagation.
• Lineage absent from pipeline transforms, a training corpus undergoes multiple filtering, deduplication, and augmentation steps; no transform step records its operation; an audit of the corpus's provenance cannot reconstruct which source data contributed to the final training set. Replaced by: training corpus pattern lineage tagging and lineage hooks at every transform step.

C) Integrate patterns into the intake/inventory flow and establish the deviation-review path

Reference patterns are only useful if teams encounter them at the right moment, when they are proposing or modifying an AI/HAI data pipeline.

• SM inventory records link to the applicable reference pattern(s) at intake.
• Teams choosing an archetype see the reference pattern and declare: "using pattern" or "deviating from pattern."
• Deviations require a lightweight design review (DR-Data L1) with a named architect reviewer and a documented rationale stored with the asset's inventory record.
• Patterns are reviewed and change-logged quarterly; repeat deviations in the same direction are a signal to update the pattern.
• New archetypes that do not fit an existing pattern trigger a pattern-authoring sprint within 30 days of the first intake.

Outcome Metrics (L1)

Process Metrics (leading)

• Pattern review cadence, quarterly refresh with change-log maintained.
• New-archetype lead time, new pattern published within 30 days of the first intake in a new archetype category.
• Deviation-review SLA, ≤5 business days from deviation request to decision.
• Anti-pattern catalog linked from the AI Data Policy and the SM intake gate.

Effectiveness Metrics (business value)

• Build lead time, time-to-production for a team building a new AI/HAI data pipeline via the reference pattern (should decrease after patterns land).
• Avoided-incident stories, documented cases where the pattern (e.g., classification gate, PII redaction, consent-basis check) blocked or contained a real risk before it reached production.
• Pattern reuse rate, % of new assets using the pattern unchanged vs. deviating; rising reuse indicates the pattern is fit for purpose.

Success Criteria

• Seven reference patterns published, each with: labeled data-flow diagram, scope declaration, data-boundary and classification flow, consent/lawful-basis check point, lineage and provenance hooks, access control model, logging specification, and row-by-row mapping to SR-Data requirements and TA-Data threats with HAI TTP tags (EA / AGH / TM / RA) and applicable MITRE ATLAS technique IDs.
• Anti-pattern catalog published (minimum 10 entries), linked from the AI Data Policy, the SM intake gate, and EG-Data training.
• Deviation-review path operational with a named architect-reviewer population and ≤5 BD SLA.
• ≥85% of active AI/HAI data assets in the SM inventory classified as "on pattern" or "deviation with review"; no silent deviations.
• 100% of training-corpus and fine-tuning-dataset assets with a classification-gating check on file before entering any AI training pipeline.

Maturity Level 2

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

At this level, architecture moves from "single-path reference" to "production-scale reference set." Tier-conditional patterns apply: Critical-tier data assets receive full per-tenant isolation, data-residency enforcement, and automated transfer-mechanism verification; patterns are encoded as IaC so teams fork rather than handcraft; multi-region and cross-border complexity are explicitly addressed. The anti-pattern catalog evolves from real IM-Data findings.

Dependencies

• SA-Data L1 (required): base reference patterns and anti-pattern catalog are the substrate L2 extends.
• SR-Data L2 (required): quantitative and tier-calibrated requirements drive the L2 pattern controls.
• TA-Data L2 (required): per-asset and per-tier deep threat models surface the controls each L2 pattern must cover.
• SM-Data L2 (required): risk-tier rubric determines which tier-conditional pattern variant applies to each data asset.
• IM-Data L1+ (required): incidents feed anti-pattern additions and drive pattern evolution.

Desired Outcomes

• Teams building Critical or High-tier AI/HAI data pipelines have a production-grade pattern to fork rather than a napkin sketch to interpret.
• Tier-conditional pattern variants are explicit: Critical gets per-tenant isolation IaC, data-residency enforcement, and automated SCC/transfer-mechanism verification; High gets monitoring and logging IaC modules; Medium and Low follow the base pattern.
• Anti-pattern catalog reflects real incidents from IM-Data, not only theoretical harms.
• Pattern drift is detectable: IaC-encoded patterns enable conformance testing; assets using old or hand-modified patterns are flagged.
• Architecture evidence for Critical-tier data assets is sufficient to support GDPR Art. 35 DPIA, Art. 44–49 transfer-mechanism documentation, and EU AI Act Art. 10 training-data quality obligations.

Activities

A) Tier-conditional pattern extensions

Publish extended pattern variants calibrated to SM L2's tier-treatment matrix for data assets:

• Critical-tier overlay (applies to any archetype at Critical tier): per-tenant isolation enforced at data boundary, at the retrieval store, and at the embedding namespace; data-residency-aware routing (classification-aware routing enforces that EU personal data stays within the EU region or a region with an adequacy decision in place; cross-region failover preserves residency); automated transfer-mechanism verification (IaC module queries the DPA registry at deploy time and blocks deployment if a documented transfer mechanism is not on file for a cross-border flow); EU AI Act Art. 10 training-data quality controls explicitly mapped in the pattern; GDPR Art. 35 DPIA evidence template auto-populated from the IaC module.
• High-tier overlay: monitoring and logging IaC modules included in the fork (pre-wired access-audit log pipeline, retention-enforcement trigger, no-train re-verification scheduler, alert routing to the SIEM); standard detections from ML-Data L2 pre-wired.
• Multi-region / cross-border pattern: residency enforcement for global data pipelines (region pinning at the ingestion layer, cross-region failover with residency preservation, GDPR international-transfer mechanism selection step included as a required decision gate in the IaC module); SCC currency verification automated.
• Multi-tenant pattern for shared data infrastructure: per-tenant namespace isolation at every pipeline stage (ingest, transform, store, retrieve, log); per-tenant classification policy enforcement; per-tenant DSAR response isolation (a DSAR for tenant A's subjects does not surface tenant B's data); tenant-isolation conformance test wired into CI.

B) Patterns-as-IaC with conformance test suites

• All Critical and High-tier pattern variants encoded as forkable IaC modules (Terraform / Pulumi / CloudFormation or equivalent); teams fork rather than handcraft; deviations surface at plan or apply time.
• Each IaC module ships with a conformance test suite: automated checks that the deployed pipeline matches the pattern's controls (classification gate active, PII redaction enabled at logging, per-tenant isolation enforced, transfer mechanism verified, retention policy enforced, access control RBAC applied, audit log active).
• IaC modules version-pinned; module updates trigger a drift-detection pass against all deployed instances.
• Module change log maintained; teams consuming a module are notified of updates requiring remediation.

C) Incident-informed anti-pattern catalog refresh

• Every IM-Data incident classified to an anti-pattern (existing or new); classification recorded in the IM finding.
• Catalog refreshed monthly from IM-Data findings; new anti-patterns surfaced to teams at intake time.
• Quarterly review: if three or more assets have deviated from a pattern in the same direction, the pattern is queued for update.
• Anti-patterns originating from Critical-tier incidents are escalated to the SM working group for a pattern-update sprint within 30 days.

Outcome Metrics (L2)

Process Metrics (leading)

• Pattern refresh cadence, at least one substantive pattern change per quarter, change-logged.
• Anti-pattern review cadence, monthly from IM-Data findings.
• IaC pipeline health monitored, module-update notification and drift-detection pass tracked.
• Tier-treatment matrix adherence check, quarterly reconciliation of Critical/High data-asset list against IaC-encoded pattern adoption.

Effectiveness Metrics (business value)

• Pipeline time-to-production drops for teams building Critical/High-tier data assets that fork IaC modules rather than handcrafting architecture.
• Incident rate on IaC-encoded pipelines lower than on hand-crafted pipelines, tracked as a rolling 12-month comparison.
• Conformance test failures caught in CI before production, not in DR or IR.

Success Criteria

• Four tier-conditional extended patterns published (Critical overlay, High overlay, multi-region/cross-border, multi-tenant), each encoded as a forkable IaC module with a conformance test suite.
• ≥80% of Critical and High-tier AI/HAI data assets running on IaC-encoded patterns with plan-time deviation flagging.
• Anti-pattern catalog updated from ≥3 real IM-Data incidents in the last 12 months; new entries surfaced at intake time.
• Conformance test coverage at 100% of IaC-encoded data-pipeline deployments.
• 100% of Critical-tier data assets with automated transfer-mechanism verification in the IaC module.

Maturity Level 3

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

At this level, the reference patterns are open artifacts that the industry adopts, forks, and builds on. The org contributes pattern-derived mitigations to MITRE ATLAS (AML.M00xx), to OWASP LLM Top 10 / Agentic Top 10, to OpenSSF AI, and to DAMA / EDM Council AI Data Governance working groups. Pattern adoption telemetry is operational. Engagement on GDPR supervisory authority guidance and EU AI Act implementing acts that address training-data and data-pipeline architecture is active.

Dependencies

• SA-Data L2 (required): IaC-encoded patterns and conformance test suites are the substrate L3 publishes and maintains externally.
• SM-Data L3 (alignment): automation substrate supports the telemetry and benchmarking activities at L3.
• IM-Data L2+ (required): incident-to-pattern feedback loop must be operational before incident data drives external contributions.

Desired Outcomes

• At least two SA-Data reference patterns are cited or forked by recognized industry bodies (OWASP, OpenSSF AI, DAMA / EDM Council, MITRE ATLAS, sector equivalents).
• MITRE ATLAS mitigation library carries at least two AML.M00xx entries attributable to SA-Data patterns (classification-gating at training ingest, embedding inversion defense, corpus isolation, contamination-prevention gate, or equivalent).
• Internal practice is aligned to the published external version.
• Regulatory bodies and sector organizations reference SA-Data patterns in data-pipeline architecture guidance or implementing-act consultations.

Activities

A) Publish reference patterns as open artifacts

• Patterns published under Apache 2.0 or equivalent open license via OWASP LLM / Agentic, OpenSSF AI, DAMA / EDM Council, or equivalent; sector-specific variants via relevant sector bodies (FS-ISAC, H-ISAC, sector AI working groups).
• Maintained upstream in the public repository; internal use aligns with the external version; internal deviations are documented with rationale and fed back as upstream proposed changes rather than silent forks.
• Pattern adoption telemetry tracked: GitHub forks, citations in published work, documented adopters.
• New archetypes or overlays developed internally are proposed for inclusion in the external catalog within 90 days of internal publication.

B) Contribute to MITRE ATLAS mitigation library

• For each control in the reference patterns that corresponds to a threat technique in the ATLAS taxonomy, propose or validate a mitigation entry in the ATLAS mitigation library (AML.M00xx).
• Priority contributions aligned to SA-Data's primary data-attack techniques: AML.T0019 Publish Poisoned Datasets (mitigated by classification-gating staging and provenance verification), AML.T0020 Poison Training Data (mitigated by anomaly detection at ingest and lineage tracking), AML.T0024 Exfiltration via ML Inference API (mitigated by retrieval-only access, embedding inversion defense, and per-tenant isolation), AML.T0025 Exfiltration via Cyber Means (mitigated by access-controlled log export interface), AML.T0010 ML Supply Chain Compromise (mitigated by source-lineage verification and supply-chain gating at staging).
• Target: at least two AML.M00xx entries proposed or validated per year.
• Participate in the ATLAS practitioner community to align SA-Data control vocabulary with ATLAS technique taxonomy.

C) Engage regulators and standards bodies on data-pipeline architecture norms

• Active participation in EU AI Act implementing-act consultations where training-data quality and data-pipeline architecture standards (Art. 10) are under discussion; submit SA-Data patterns as evidence of "state of the art" data-pipeline practice.
• Contribute to GDPR supervisory authority guidance on AI training data, specifically DPA guidance on consent-tracking at scale, DPIA requirements for large-scale personal-data training, and Art. 17 deletion-propagation obligations.
• Engage NIST AI RMF Playbook successor editions with SA-Data pattern mappings to GOVERN / MAP / MEASURE / MANAGE.
• Contribute to DAMA International and EDM Council AI Data Governance working groups: data-archetype pattern schema, classification-gating framework, lineage-and-provenance standard as referenceable open artifacts.

Outcome Metrics (L3)

Process Metrics (leading)

• External contribution pipeline, ≥2 pattern items in-flight (draft, in-review, or in-publication) at all times.
• Internal-external alignment audit, quarterly diff between internal pattern versions and published external versions; unexplained divergence queued for resolution.
• ATLAS contribution cadence, at least one contribution or validation per 6 months.
• Regulatory engagement calendar maintained with active items and target timelines.

Effectiveness Metrics (business value)

• Industry recognition, invitations to working groups, citations in published standards, peer adoption of SA-Data patterns.
• Regulatory benefit, SA-Data patterns referenced in implementing-act or guidance documents reduce compliance uncertainty for the org and the industry.
• Talent, external publication and standards participation attracts experienced privacy-engineering and data-security talent with AI-specific expertise.
• Faster sanctioned data pipeline build, industry adoption of patterns means external data partners the org integrates with arrive already familiar with the architecture norms; integration friction decreases.

Success Criteria

• ≥5 reference patterns published as open artifacts under a recognized open license via at least one industry body (OWASP, OpenSSF AI, DAMA, or equivalent).
• ≥2 patterns externally cited or forked by recognized industry or sector bodies.
• ≥2 MITRE ATLAS AML.M00xx mitigation entries proposed or validated, traceable to SA-Data pattern controls, aligned to the primary data-attack techniques (AML.T0019, T0020, T0024, T0025, T0010).
• Internal practice 100% aligned to the published external version, no unexplained internal deviations; all deviations proposed as upstream contributions.
• At least one documented regulatory or standards-body reference to SA-Data patterns in implementing-act, guidance, or standards text.

Key Success Indicators

Level 1: - Seven reference patterns published, one per archetype (training corpus, inference input stream, retrieval store, prompt/completion log corpus, embedding store, fine-tuning dataset, evaluation/test set), each with a labeled data-flow diagram, scope, classification flow, consent/lawful-basis check point, lineage/provenance hooks, access control model, logging spec, and row-by-row mapping to SR-Data requirements and TA-Data threats; HAI TTP tags (EA / AGH / TM / RA) and applicable MITRE ATLAS technique IDs (AML.T0019, T0020, T0024, T0025, T0010 where applicable) present. - Anti-pattern catalog published (minimum 10 entries), each linked to a reference pattern element that replaces it; linked from the AI Data Policy, the SM intake gate, and EG-Data training. - ≥85% of active AI/HAI data assets in the SM inventory classified as "on pattern" or "deviation with review"; no silent deviations. - 100% of training-corpus and fine-tuning-dataset assets with a classification-gating check on file before entering any AI training pipeline; confirmed by data-catalog audit. - Deviation-review path operational with a named architect-reviewer population, ≤5 BD SLA, and a repeat-deviation signal that queues pattern updates.

Level 2: - Four tier-conditional extended patterns published (Critical overlay, High overlay, multi-region/cross-border, multi-tenant), each encoded as a forkable IaC module with a conformance test suite; ≥80% of Critical and High-tier data assets running on IaC-encoded patterns. - Anti-pattern catalog updated from ≥3 real IM-Data incidents in the last 12 months; new entries surfaced at intake time. - Conformance test coverage at 100% of IaC-encoded data-pipeline deployments; plan-time deviation flagging operational. - 100% of Critical-tier data assets with automated transfer-mechanism verification in the IaC module.

Level 3: - ≥5 reference patterns published as open artifacts under a recognized open license; ≥2 cited or forked by recognized industry or sector bodies. - ≥2 MITRE ATLAS AML.M00xx mitigation entries proposed or validated, traceable to SA-Data pattern controls aligned to primary data-attack techniques. - Internal practice 100% aligned to published external versions; all deviations proposed as upstream contributions, none silently forked. - At least one documented reference to SA-Data patterns in a regulatory implementing-act, sector guidance document, or standards text.

Common Pitfalls

Level 1: - ❌ Patterns are written but not linked from the SM inventory record or the intake gate, teams skip them because they are hard to find, not because they disagree with them. - ❌ The training corpus pattern omits the classification-gating staging area, regulated PII flows directly to the curated training lake without a blocking gate; the gate exists in the document but not in the deployed pipeline. - ❌ Anti-patterns remain theoretical; they are not tied to real incidents or to the specific pattern element that replaces them, so data engineers do not recognize the hazard when they encounter it. - ❌ Deviations are approved individually but the repeat-deviation signal is never wired, patterns never update because nobody aggregates the pattern-update trigger. - ❌ The prompt/completion log corpus pattern specifies PII redaction at logging but no redaction service is deployed, plaintext prompt content containing PII is written to log storage from day one, and the pattern is aspirational. - ❌ The retrieval store pattern covers per-tenant isolation but omits per-source classification at index time, queries bleed across classification boundaries because the corpus was never labeled. - ❌ Pattern controls are mapped to SR requirements in the document but the mapping is never validated against an actual deployed pipeline, the traceability is aspirational.

Level 2: - ❌ IaC patterns are forked once and then hand-edited at each deployment, drift is immediate and the IaC substrate provides no baseline enforcement; conformance tests are skipped. - ❌ The multi-region / cross-border pattern covers data-residency in the diagram but does not include the GDPR international-transfer mechanism selection step, teams deploy cross-border data flows without a documented legal basis. - ❌ Critical-tier overlay exists on paper but the IaC module does not enforce per-tenant isolation, data from tenant A and tenant B co-mingles in the retrieval store and the embedding namespace. - ❌ Anti-pattern catalog grows from incidents but is only accessible as a reference document; teams encounter the anti-pattern again before they encounter the catalog entry. - ❌ Pattern-drift detection fires on low-signal configuration noise; the team ignores it within a month; meaningful drift goes undetected. - ❌ Transfer-mechanism verification is in the IaC module spec but fails silently when the DPA registry is unavailable, the pipeline deploys without a mechanism on file.

Level 3: - ❌ Externally contributed patterns diverge from internal practice, what is published reflects what the org once did; external adopters discover the discrepancy during implementation; trust erodes. - ❌ ATLAS contribution targets are treated as a compliance checkbox, entries are proposed but never followed through to publication because internal legal or security review creates indefinite delay. - ❌ Regulatory engagement is declaratory ("we participated in the Art. 10 consultation") rather than substantive ("our pattern text was incorporated into the guidance"), the program cannot demonstrate that engagement produced outcomes. - ❌ Industry contributions are conference presentations and blog posts; no technical artifacts actually land in MITRE / OWASP / NIST / OpenSSF / DAMA, external recognition is aspirational. - ❌ Pattern adoption telemetry is not tracked, the org claims patterns are "widely adopted" but has no evidence; external benchmarking is not possible.

Practice Maturity Questions

Level 1: 1. Are seven reference patterns published, one per archetype (training corpus, inference input stream, retrieval store, prompt/completion log corpus, embedding store, fine-tuning dataset, evaluation/test set), each with a labeled data-flow diagram, classification flow, consent/lawful-basis check point, lineage/provenance hooks, access control model, logging spec, and explicit row-by-row mapping to SR-Data requirements and TA-Data threats with HAI TTP tags and applicable MITRE ATLAS technique IDs (AML.T0019, T0020, T0024, T0025, T0010 where applicable), accessible within one click of the SM inventory record? 2. Are 100% of training-corpus and fine-tuning-dataset assets verified (via data-catalog audit, not only policy declaration) to have passed through a classification-gating check and have a documented consent/lawful-basis record on file before entering any AI training pipeline, and is the anti-pattern catalog linked from the AI Data Policy, the SM intake gate, and EG-Data training, with each entry tied to the real or representative incident that generated it? 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% of active AI/HAI data assets in the SM inventory classified as "on pattern" or "deviation with review" with no silent deviations?

Level 2: 1. Are the four tier-conditional extended patterns (Critical overlay, High overlay, multi-region/cross-border, multi-tenant) published as forkable IaC modules with conformance test suites, and are ≥80% of Critical and High-tier AI/HAI data assets running on IaC-encoded patterns as confirmed by the IaC and SM inventory registries? 2. Has the anti-pattern catalog been updated from ≥3 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? 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 L2 drive the pattern variant selection: Critical assets on the Critical overlay, High assets on the High overlay, Medium/Low on the base pattern?

Level 3: 1. Have ≥5 reference patterns been published as open artifacts under a recognized open license via at least one industry body, and have ≥2 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? 2. Have ≥2 MITRE ATLAS AML.M00xx mitigation entries been proposed or validated, traceable to specific SA-Data pattern controls aligned to 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? 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?

Document Version: HAIAMM v3.0 Practice: Secure Architecture (SA) Domain: Data Last Updated: 2026-05-13 Author: Verifhai