Security Testing (ST) - Data Assessment

Assessment questionnaire for measuring maturity. Answer each question honestly based on current, implemented practices.

v3.0 framing: The canonical source-of-truth for Security Testing (ST) in the Data domain is ../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.

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

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

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

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

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

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

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

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

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

Instructions:

Answer based on current practices, not plans
“Yes” requires documented evidence
Complete all Level 1 questions before Level 2
Partial implementation = “No”

↓ Download as Markdown