> **v3.0 framing:** The canonical source-of-truth for Security Testing (ST) in the Data domain is [`../practices/ST-Data-OnePager.md`](../practices/ST-Data-OnePager.md). Outcome metrics, activities, and success criteria below are verbatim from that one-pager. Canonical subject and through-lines: [`../HAIAMM-v3.0-Framing.md`](../HAIAMM-v3.0-Framing.md).

---

# Security Testing (ST) - Data Domain
## HAIAMM Assessment Questionnaire v3.0

**Practice:** Security Testing (ST)
**Domain:** Data
**Purpose:** Assess organizational maturity in running adversarial test batteries and regression corpora against AI/HAI data flows, from foundational per-archetype batteries in CI through continuous automated adversarial testing
**Scoring Model:** Evidence + Outcome Metrics (see Scoring Methodology below)

---

## Instructions

- Answer each question honestly based on **current, implemented practices** (not plans or aspirations)
- Each question has two components: **Evidence** (what you did) and **Outcome Metrics** (how well it worked)
- **Scoring uses 4 tiers:** Fully Mature (1.0), Implemented (0.67), Partial (0.33), Not Implemented (0.0)
- **Answer progressively** - Complete all Level 1 questions before Level 2
- **Level progression** - Achieve ALL questions at lower level before advancing
- **Baseline first** - Record current metric values before setting targets

---

## Scoring Methodology

| Score | Label | Criteria |
|-------|-------|----------|
| 1.0 | Fully Mature | Evidence complete + ≥3 outcome metrics meet targets |
| 0.67 | Implemented | Evidence complete + 2 outcome metrics meet targets |
| 0.33 | Partial | Evidence partially complete + <2 outcome metrics meet targets |
| 0.0 | Not Implemented | No evidence of the activity |

**Level Score** = average of the 3 question scores for that level
**Overall ST-Data Score** = weighted average: L1 × 0.5 + L2 × 0.3 + L3 × 0.2

---

## Maturity Level 1
**Objective:** Establish a foundational per-archetype test battery and regression corpora that run in CI, and verify that every AI/HAI data flow reaches production with a passed go-live battery on record

---

### Question 1: Per-Archetype Test Battery

**Q1.1:** Is a per-archetype foundational test battery published for all seven AI/HAI data archetypes (training corpus, inference input stream, retrieval store, prompt/completion log corpus, embedding store, fine-tuning dataset, evaluation/test set), with each test class tied to a TA-Data archetype threat (HAI TTP + ATLAS tactic/technique ID) and an SR-Data requirement, defined inputs/outputs/pass-fail criteria, and an evidence artifact?

**Evidence Required:**
- [ ] Test battery document published per archetype; covers per-archetype probes including poison-detection scan (ATLAS TA0012/AML.T0019), classification-completeness scan, consent-basis sample-verify, PII-redaction-edge canary (ATLAS TA0013/AML.T0025), no-train probe, retrieval-extraction probe corpus (ATLAS TA0004/TA0013), retrieval-poisoning probe (ATLAS TA0012/AML.T0019), inversion probe corpus (ATLAS TA0013/AML.T0025), opt-out enforcement test, and eval isolation test as applicable per archetype
- [ ] Each test class records: inputs, expected safe outcome, pass/fail criteria, evidence artifact (log snippet, scan output, or CI run link)
- [ ] Each test class mapped to a TA-Data archetype threat (HAI TTP + ATLAS tactic/technique ID) and an SR-Data requirement
- [ ] Battery linked from SM-Data inventory record and DR-Data/IR-Data artifacts for each AI/HAI data flow
- [ ] Named battery owner per archetype documented; quarterly re-run scheduled in advance
- [ ] 100% of AI/HAI data flows reaching production in the last 90 days have a passed go-live battery on record

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % AI/HAI data flows reaching production with a passed go-live battery on record | ___% | ___% | ≥90% within 12 months; 100% for Critical/High-tier | ☐ | |
| % archetype threat library entries covered by at least one test or corpus entry | ___% | ___% | ≥80% by end of year 1 | ☐ | |
| % test failures routed to IM-Data within 1 business day | ___% | ___% | 100% | ☐ | |
| CI automation coverage of battery items (% running without human intervention) | ___% | ___% | ≥60% | ☐ | |

**Metric Collection Guidance:**
- **Go-live battery coverage**: Query SM-Data inventory registry for data flows promoted to production in the last 90 days; cross-reference with test-run registry. Formula: `flows_with_passed_battery / flows_reaching_production × 100`
- **Threat coverage**: For each archetype's TA-Data library entry, check whether at least one test class or corpus entry maps to it. Formula: `covered_threats / total_archetype_threats × 100`. Source: TA-Data library × test metadata mapping
- **IM routing rate**: For test failures in the last quarter, check IM-Data ticket creation timestamps. Formula: `failures_with_IM_ticket_within_1BD / total_failures × 100`. Source: CI telemetry × IM-Data system
- **CI automation**: Count battery items with a CI trigger vs. total battery items. Source: battery registry + CI configuration

**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 of per-archetype test battery)

**Evidence Location:** _______________
**Validation Date:** _______________
**Notes:** _______________

---

### Question 2: Regression Corpora in CI

**Q2.1:** Are six regression corpora (poison-detection, retrieval-extraction, retrieval-poisoning, embedding-inversion, PII-redaction-edge, DSAR-query) versioned in source control, running in CI on every PR for Critical/High-tier data flows, with a named corpus owner, a monthly refresh cadence from internal and external sources, and a CI compute budget cap?

**Evidence Required:**
- [ ] Six regression corpora published in source control: poison-detection corpus (poison-pattern fixtures targeting label-flipping, backdoor-trigger phrases, mislabeling artifacts), retrieval-extraction corpus (broad-corpus extraction query fixtures), retrieval-poisoning corpus (hostile-document fixtures with prompt-injection payloads), embedding-inversion corpus (nearest-neighbor query fixtures to recover training-record attributes), PII-redaction-edge corpus (canary PII fixtures in diverse formats, synthetic SSN, card number, email, IBAN), and DSAR-query corpus (canary subject fixtures for DSAR-surface accuracy verification)
- [ ] Each corpus entry includes: input, expected safe outcome, threat tag (HAI TTP + ATLAS tactic/technique ID), OWASP reference, source, date added
- [ ] CI wiring confirmed: corpus runs in CI for Critical/High-tier data flows; failure is a blocking check for Critical/High-tier
- [ ] Named corpus owner per corpus; corpus changes go through PR review
- [ ] Monthly refresh cadence evidenced: change-log showing updates from internal observations (IR-Data findings, IM-Data incidents), external sources (OWASP LLM Top 10, ATLAS examples, academic poison-attack datasets), and community vulnerability disclosures
- [ ] CI token/compute budget cap configured and enforced; evidence in CI configuration

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| Regression corpora published (poison-detection, retrieval-extraction, retrieval-poisoning, embedding-inversion, PII-redaction-edge, DSAR-query) | ___/6 | ___/6 | 6/6 | ☐ | |
| % PR merges for Critical/High-tier data flows that ran the regression corpus and passed | ___% | ___% | ≥95% | ☐ | |
| Corpus refresh cadence, months since last update per corpus | ___ | ___ | ≤1 month | ☐ | |
| % archetype threat library entries covered by at least one corpus entry | ___% | ___% | ≥80% by end of year 1 | ☐ | |

**Metric Collection Guidance:**
- **Corpus publication**: Count corpora present in source control with versioned entries and a named owner. Source: corpus registry in VCS
- **PR corpus run rate**: Pull CI run history for Critical/High-tier data flow PRs; cross-reference with corpus run results. Formula: `PRs_with_corpus_run_and_pass / total_Critical_High_PRs × 100`. Source: CI telemetry
- **Refresh cadence**: Inspect git log for each corpus; compute days since last commit adding new entries. Source: VCS change-log
- **Threat coverage**: TA-Data library entries mapped to corpus entries vs. total archetype library entries. Source: TA-Data library × corpus 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 regression corpora wired into CI)

**Evidence Location:** _______________
**Validation Date:** _______________
**Notes:** _______________

---

### Question 3: Go-Live Battery and IM Wire

**Q3.1:** Is the go-live battery operated with defined re-run triggers (pre-production, post-corpus-update, post-incident, quarterly), and are all test failures routed to IM-Data within 1 business day with a severity tag and named owner?

**Evidence Required:**
- [ ] Go-live battery process document defines re-run triggers: pre-production (blocks Sanctioned status in SM-Data), post-corpus-update within 14 days (Critical-tier: 7 days), post-incident before incident closure, and quarterly for all active data flows
- [ ] Go-live test records linked from SM-Data inventory and PC intake artifacts for data flows promoted in the last 90 days
- [ ] Test failure to IM-Data routing confirmed: sample of recent failures shows IM-Data tickets created within 1 business day with severity tag, named owner, and test battery reference
- [ ] Severity rubric published and applied consistently to test failure triage
- [ ] Battery re-run cadence evidenced: quarterly re-run records on file for active data flows with named battery owner
- [ ] Post-corpus-update re-run triggered and completed within SLA for any corpus/pipeline changes in the last 6 months

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % test failures routed to IM-Data within 1 business day | ___% | ___% | 100% | ☐ | |
| % post-corpus-update re-runs completed within declared SLA (7/14 days by tier) | ___% | ___% | ≥90% | ☐ | |
| % active data flows with a quarterly battery re-run completed in last 90 days | ___% | ___% | ≥90% | ☐ | |
| % AI/HAI data flows reaching production with a passed go-live battery on record | ___% | ___% | 100% for Critical/High-tier | ☐ | |

**Metric Collection Guidance:**
- **IM routing rate**: Compare test failure log timestamps to IM-Data ticket creation timestamps. Source: CI failure log × IM-Data system timestamp query
- **Post-update SLA**: For corpus/pipeline changes in last 6 months, check re-run date vs. change date by tier. Source: data pipeline changelog × test-run registry
- **Quarterly re-run rate**: Count active data flows with a battery run record dated within the last 90 days. Source: test-run registry × SM-Data inventory active flow list
- **Go-live coverage**: SM-Data inventory × test-run registry cross-reference for data flows reaching production in last 90 days

**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 go-live battery or IM-Data wiring in place)

**Evidence Location:** _______________
**Validation Date:** _______________
**Notes:** _______________

---

## Maturity Level 2
**Objective:** Calibrate test depth per risk tier using the SM-Data L2 tier-treatment matrix, run per-tier red-team exercises using TA-Data L2 deep threat models, and test cross-archetype compositions for Critical-tier data flows

---

### Question 4: Tier-Calibrated Battery and Corpus Depth

**Q4.1:** Is per-tier corpus calibration enforced in CI (Critical-tier: all 6 corpora on every PR + monthly no-train probe + quarterly DSAR-query accuracy; Low-tier: poison-detection corpus on merge), and does each Critical-tier data flow have a separately tuned corpus derived from its TA-Data L2 per-flow deep threat model?

**Evidence Required:**
- [ ] Per-tier test treatment published and aligned to SM-Data L2 tier-treatment matrix: Critical (full battery + all 6 corpora every PR + monthly no-train probe + quarterly DSAR-query), High (full battery + all 6 corpora on merge + quarterly no-train probe), Medium (subset battery + poison-detection + PII-redaction-edge on merge), Low (spot-check + poison-detection on merge)
- [ ] CI pipeline configuration confirms tier-differentiated corpus assignments, not the same corpus applied to all tiers
- [ ] Critical-tier corpus entries tuned to the data flow's specific data classes, classification scheme, and vendor LLM providers from the TA-Data L2 per-flow threat model
- [ ] Monthly no-train probe records on file for Critical-tier data flows: vendor admin API probe confirming no-train setting is active; failures route to IM-Data
- [ ] Quarterly DSAR-query accuracy verification on file for Critical-tier data flows; evidence of canary subject inclusion before deletion and exclusion after deletion
- [ ] Per-tier SLA adherence tracked and reported to program sponsor

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % Critical-tier data flows with all 6 corpora running on every PR | ___% | ___% | 100% | ☐ | |
| Per-tier SLA adherence for testing activities (go-live battery, post-update re-run, red-team cadence) | ___% | ___% | ≥90% per tier | ☐ | |
| % Critical-tier data flows with monthly no-train probe active | ___% | ___% | 100% | ☐ | |
| % Critical-tier data flows with quarterly DSAR-query accuracy verified | ___% | ___% | 100% | ☐ | |

**Metric Collection Guidance:**
- **Corpus per-PR rate**: CI telemetry for Critical-tier data flow PRs; verify all 6 corpus runs appear in each PR's check suite. Source: CI telemetry
- **SLA adherence**: Program telemetry across go-live battery turnaround, post-update re-run dates, and red-team calendar adherence. Formula: `activities_completed_within_SLA / total_activities × 100`
- **No-train probe rate**: Count Critical-tier data flows with a vendor admin API probe record dated within the last 30 days vs. total Critical-tier flows using external LLM providers. Source: probe run registry
- **DSAR accuracy**: Count Critical-tier data flows with a DSAR accuracy verification record in the last 90 days vs. total. Source: DSAR-query test run registry

**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 tier-calibrated corpus differentiation in place)

**Evidence Location:** _______________
**Validation Date:** _______________
**Notes:** _______________

---

### Question 5: Scheduled Red-Team Exercises

**Q5.1:** Are 100% of Critical-tier AI/HAI data flows red-teamed at least quarterly, and 100% of High-tier semi-annually, with scope derived from TA-Data L2 per-flow deep threat models covering poison-injection attempts, retrieval-extraction probes, cross-tenant isolation probes, embedding-inversion attacks, DSAR-surface enumeration, opt-out bypass attempts, and eval-training contamination probes?

**Evidence Required:**
- [ ] Red-team schedule on calendar covering all Critical-tier (quarterly) and High-tier (semi-annual) data flows; no Critical-tier data flow skipped in the last 12 months
- [ ] Red-team scope documented per exercise: written rules of engagement, test plan reviewed with data-flow owner, scope derived from TA-Data L2 per-flow deep threat model
- [ ] ATLAS tactic/technique IDs referenced in scope documentation: TA0004 ML Model Access, TA0012 ML Attack Staging (AML.T0019), TA0013 Exfiltration (AML.T0025), TA0001 Reconnaissance
- [ ] Red-team execution log and structured findings report on file: severity, root cause, ATLAS tactic/technique ID, SR-Data requirement traced, remediation pairing
- [ ] Findings routed to IM-Data with severity tag and named data-flow owner as assignee; remediation tracked
- [ ] Scheduled red-team exercises confirmed: quarterly for Critical, semi-annual for High

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % Critical-tier data flows red-teamed in last 90 days | ___% | ___% | 100% | ☐ | |
| % High-tier data flows red-teamed in last 180 days | ___% | ___% | 100% | ☐ | |
| % red-team findings (Critical/High severity) converted to corpus entries within 30 days | ___% | ___% | ≥90% | ☐ | |
| Per-tier SLA adherence for red-team cadence | ___% | ___% | ≥90% | ☐ | |

**Metric Collection Guidance:**
- **Critical red-team rate**: Count Critical-tier data flows with a red-team report dated within the last 90 days vs. total Critical-tier data flows. Source: ST-Data records
- **High red-team rate**: Same logic for 180 days. Source: ST-Data records
- **Finding to corpus conversion**: For Critical/High severity findings, count those with a corresponding corpus entry committed within 30 days. Formula: `findings_with_corpus_entry / total_Critical_High_findings × 100`. Source: finding → corpus pipeline telemetry
- **SLA adherence**: Compare scheduled red-team dates to actual execution dates across all tiers. Source: program calendar × ST-Data 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 scheduled red-team function in place)

**Evidence Location:** _______________
**Validation Date:** _______________
**Notes:** _______________

---

### Question 6: Cross-Archetype Composition Tests

**Q6.1:** Are cross-archetype composition tests (training corpus + eval/test set contamination, embedding store + retrieval store inversion-via-retrieval, inference input stream + prompt/completion log corpus PII-pass-through, fine-tuning dataset + training corpus lineage propagation) documented and executed for all Critical-tier data flows, with each Critical/High-severity red-team finding producing a corpus entry within 30 days?

**Evidence Required:**
- [ ] Cross-archetype composition test plan published for each Critical-tier data flow with composite archetype interactions; reviewed by named architect
- [ ] Training + eval contamination probe: verify no eval-set record IDs appear in training corpus after a corpus refresh; eval-set isolation holds after every corpus update
- [ ] Embedding + retrieval inversion probe: use retrieval queries to obtain embeddings; apply inversion techniques; assert source-text reconstruction does not exceed the declared similarity threshold
- [ ] PII input + log corpus pass-through probe: verify a PII canary entering the inference-input stream does not appear unredacted in the prompt/completion log corpus
- [ ] Fine-tuning + training lineage propagation probe: verify an opt-out deletion propagates from the training corpus to all downstream derived datasets
- [ ] Regression corpus growth rate evidenced: Critical-tier corpora show ≥1 new entry per month from red-team or incident findings
- [ ] Finding to TA-Data library-gap pipeline: Critical gaps closed within 30 days; High within 60 days

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % Critical-tier data flows with documented cross-archetype composition tests | ___% | ___% | 100% | ☐ | |
| Regression corpus growth rate, Critical-tier corpora (new entries per month) | ___ | ___ | ≥1 per month | ☐ | |
| % red-team findings (Critical/High severity) converted to corpus entries within 30 days | ___% | ___% | ≥90% | ☐ | |
| % TA-Data library gaps (Critical tier) closed within 30 days | ___% | ___% | 100% | ☐ | |

**Metric Collection Guidance:**
- **Composition test coverage**: Count Critical-tier data flows with composite interactions that have a documented test plan + execution record vs. total composite Critical-tier flows. Source: ST-Data records
- **Corpus growth**: Git log of Critical-tier corpus files; count commits adding new entries per calendar month. Source: VCS change-log per corpus file
- **Finding to corpus conversion**: Finding log × corpus commit-log cross-reference. Source: IM-Data findings × corpus change-log
- **TA-Data gap closure**: TA-Data library-gap ticket backlog filtered to Critical tier; measure open-to-close duration. Source: issue tracker

**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 cross-archetype composition tests in place)

**Evidence Location:** _______________
**Validation Date:** _______________
**Notes:** _______________

---

## Maturity Level 3
**Objective:** Operate continuous automated adversarial testing for Critical-tier data flows, contribute regression corpora and findings as open artifacts, and contribute discovered data-attack techniques to MITRE ATLAS, AVID, OWASP LLM, and NIST AI RMF Data

---

### Question 7: Continuous Automated Adversarial Testing Harness

**Q7.1:** Are ≥80% of Critical-tier AI/HAI data flows under continuous automated adversarial testing with daily probe execution, using poison-pattern generators, retrieval-extraction ladder generators, embedding-inversion probe generators, and PII-redaction-edge mutators, with novel data-attack techniques triaged into the TA-Data library within 14 days and high-severity automated findings routed to IM-Data within 24 hours?

**Evidence Required:**
- [ ] Automated adversarial testing harness deployed and producing daily probe results against Critical-tier data flows: poison-pattern generator (mutation of regression corpus, label-flip variants, backdoor-trigger mutations), retrieval-extraction ladder generator (prefix ladders, semantic near-duplicates, query-rate staircase patterns), embedding-inversion probe generator (nearest-neighbor sequences to recover source-text attributes), and PII-redaction-edge mutator (canary PII variants in novel formats and encoding patterns)
- [ ] Continuous adversarial testing telemetry: harness health dashboard showing % Critical-tier data flows with a fresh probe result within the last 24 hours; on-call paged when feed goes stale >24 hours
- [ ] Finding triage process: named ST-Data owner reviewing automated findings at least weekly; novel data-attack technique patterns forwarded to TA-Data L3 auto-proposal pipeline within 14 days
- [ ] High-severity automated findings route to IM-Data within 24 hours; evidence: IM-Data ticket timestamps vs. harness alert timestamps
- [ ] ATLAS tactic/technique coverage: harness exercises TA0012 (AML.T0019), TA0013 (AML.T0025), TA0004, TA0001 daily
- [ ] Harness scope confirmed against current Critical-tier data flow list from SM-Data inventory signals

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % Critical-tier data flows under continuous automated adversarial testing (daily probe execution) | ___% | ___% | ≥80% | ☐ | |
| New data-attack technique ingestion lead time (automated finding to TA-Data library entry) | ___ days | ___ days | ≤14 days | ☐ | |
| % high-severity automated findings routed to IM-Data within 24 hours | ___% | ___% | 100% | ☐ | |
| Continuous harness health (% Critical-tier data flows with fresh probe result in last 24 hours) | ___% | ___% | ≥95% | ☐ | |

**Metric Collection Guidance:**
- **Continuous coverage**: Harness telemetry, count Critical-tier data flows with a probe result in the last 24 hours vs. total Critical-tier. Source: ST harness telemetry
- **Technique ingestion lead time**: For novel patterns identified by the harness, measure time from harness alert to TA-Data library entry. Source: harness to TA-Data pipeline telemetry
- **IM routing within 24h**: Compare harness alert timestamp to IM-Data ticket creation timestamp for high-severity findings. Source: harness alert log × IM-Data system
- **Harness health**: Monitoring dashboard last-probe-time per Critical-tier data flow; stale feeds trigger on-call page

**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 continuous automated adversarial testing harness in place)

**Evidence Location:** _______________
**Validation Date:** _______________
**Notes:** _______________

---

### Question 8: Industry Contributions

**Q8.1:** Has the program contributed ≥4 anonymized, legally-vetted findings per year to MITRE ATLAS, AVID, OWASP LLM, or NIST AI RMF Data, with at least one accepted as a new or refined data-attack technique, and are ≥4 open regression corpora published under a permissive license and maintained upstream?

**Evidence Required:**
- [ ] Contribution log on file: ≥4 submissions per year to MITRE ATLAS (novel data-attack technique observations with AML.T technique IDs), AVID (structured disclosure submissions for novel vulnerabilities in own-operated AI data flows), OWASP LLM Top 10 (real-world telemetry evidence), or NIST AI RMF Data (policy revision cycle contributions)
- [ ] At least one submission accepted as a new or refined data-attack technique; evidence: ATLAS, AVID, or NIST acknowledgment
- [ ] Legal-vetting record for each contribution: org identity scrubbed; coordinated disclosure completed for third-party component involvement
- [ ] ≥4 open regression corpora published under a permissive license; published versions scrubbed of org-specific data classes, flow identifiers, and vendor names
- [ ] Published corpora maintained upstream with documented update cadence; internal corpora are a superset of published versions
- [ ] Industry-contribution pipeline: at least one anonymized finding in-preparation, in-legal-review, or submitted at all times

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| Industry contributions per year (MITRE ATLAS / AVID / OWASP LLM / NIST AI RMF Data) | ___ | ___ | ≥4 | ☐ | |
| Open regression corpora published and maintained upstream | ___/6 | ___/6 | ≥4 corpora published | ☐ | |
| Contributions accepted as new or refined data-attack techniques | ___ | ___ | ≥1 per year | ☐ | |
| Published corpus recency, months since last upstream update | ___ | ___ | ≤1 month | ☐ | |

**Metric Collection Guidance:**
- **Contribution count**: Contribution log filtered to the last 12 months; count submissions with submission confirmation. Source: contribution log
- **Open corpus publication**: Confirm ≥4 corpora exist in the public repository under a permissive license. Source: external repository
- **Acceptance**: Cross-reference contribution log with ATLAS/AVID/NIST/OWASP acknowledgment records. Source: contribution log × external acknowledgments
- **Corpus recency**: Last commit date to the public repository per corpus. Source: public VCS

**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 industry contributions or open corpus publication)

**Evidence Location:** _______________
**Validation Date:** _______________
**Notes:** _______________

---

### Question 9: Industry-Shared Exercises

**Q9.1:** Has the program hosted at least 1 industry-shared data-security exercise per year and participated in ≥2 additional cross-org exercises, with documented cross-org detection-benchmark improvement data from participants?

**Evidence Required:**
- [ ] Exercise log on file: ≥1 hosted data-security exercise per year (OWASP AI chapter, ATLAS practitioner table, or sector ISAC AI data working group); ≥2 additional cross-org exercises participated
- [ ] Hosted exercise documented: agenda, participant list, benchmark methodology, measurement of detection improvement before and after the exercise
- [ ] Cross-org detection-benchmark improvement data collected from participants and documented in exercise report
- [ ] Industry-exercise calendar: next hosted or co-hosted exercise scheduled at least 60 days in advance
- [ ] Participation in AISI Inspect evaluation benchmarks or sector ISAC AI data-security working groups with anonymized findings on record
- [ ] Published regression corpora cited or adopted by at least one external organization; adoption documented

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| Industry-shared exercises per year | ___ | ___ | ≥1 hosted + ≥2 participated | ☐ | |
| Cross-org detection-benchmark improvement documented | No / Yes | No / Yes | Yes | ☐ | |
| Open regression corpora published and maintained upstream | ___/6 | ___/6 | ≥4 corpora published | ☐ | |
| Next hosted exercise scheduled ≥60 days in advance | No / Yes | No / Yes | Yes | ☐ | |

**Metric Collection Guidance:**
- **Exercise count**: Exercise log filtered to the last 12 months; count hosted and participated exercises. Source: exercise log
- **Improvement documentation**: Hosted exercise report; participant pre/post detection benchmark data. Source: exercise reports
- **External adoption**: External organizations that have cited or forked the public corpora. Source: public repository analytics + community references
- **Calendar check**: Confirm a specific future exercise date ≥60 days out is on the program calendar. Source: program calendar

**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 industry-shared exercises conducted or planned)

**Evidence Location:** _______________
**Validation Date:** _______________
**Notes:** _______________

---

## Summary Scorecard

| Level | Q# | Question | Score | Weight |
|-------|-----|----------|-------|--------|
| L1 | Q1 | Per-Archetype Test Battery | ___ | |
| L1 | Q2 | Regression Corpora in CI | ___ | |
| L1 | Q3 | Go-Live Battery and IM Wire | ___ | |
| **L1 Score** | | | **___** | 0.5 |
| L2 | Q4 | Tier-Calibrated Battery and Corpus Depth | ___ | |
| L2 | Q5 | Scheduled Red-Team Exercises | ___ | |
| L2 | Q6 | Cross-Archetype Composition Tests | ___ | |
| **L2 Score** | | | **___** | 0.3 |
| L3 | Q7 | Continuous Automated Adversarial Testing Harness | ___ | |
| L3 | Q8 | Industry Contributions | ___ | |
| L3 | Q9 | Industry-Shared Exercises | ___ | |
| **L3 Score** | | | **___** | 0.2 |
| **Overall ST-Data Score** | | | **___** | |

**Maturity Level Achieved:** ☐ L1 ☐ L2 ☐ L3

**Assessment Date:** _______________
**Assessor:** _______________
**Next Review Date:** _______________

---

**Document Version:** HAIAMM v3.0
**Practice:** Security Testing (ST)
**Domain:** Data
**Questionnaire Authored:** 2026-05-15
**Author:** Verifhai