> **v3.0 framing:** The canonical source-of-truth for Security Testing (ST) in the Processes domain is [`../practices/ST-Processes-OnePager.md`](../practices/ST-Processes-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) - Processes Domain
## HAIAMM Assessment Questionnaire v3.0

**Practice:** Security Testing (ST)
**Domain:** Processes
**Purpose:** Assess organizational maturity in running adversarial test batteries and regression corpora against AI-embedded business workflows, from foundational per-archetype batteries through continuous canary-input 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-Processes Score** = weighted average: L1 × 0.5 + L2 × 0.3 + L3 × 0.2

---

## Maturity Level 1
**Objective:** Establish a foundational per-archetype test battery and versioned regression corpora that run in CI where applicable, and verify that every AI-embedded workflow 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-embedded workflow archetypes (decision pipeline, customer-facing flow, human-AI collaboration chain, back-office augmentation, approval/review workflow, content-generation workflow, knowledge-management workflow), with each test class tied to a TA-Processes archetype threat (HAI TTP + ATLAS tactic ID where applicable) and an SR-Processes requirement, defined inputs/outputs/pass-fail criteria, and an evidence artifact?

**Evidence Required:**
- [ ] Test battery document published per archetype; covers per-archetype probes including decision-bypass test, decision-laundering detection (audit-trail completeness), silent-decision-drift test, adversarial-input test (ATLAS TA0012 analog), class-shift monitor accuracy test, Art. 50 disclosure-presence test, rubber-stamp detection (sample audit of reviewer decisions vs. AI suggestion, alert if ≥98% match), RAG-poisoning probe (ATLAS TA0003), retrieval-extraction probe, copyright filter test, downstream-input-validation test (ATLAS TA0003 analog), and queue-routing-by-tier test as applicable per archetype
- [ ] Each test class records: inputs, expected output, pass/fail criteria, evidence artifact (queue-log sample, decision-log entry, screenshot, or CI run link)
- [ ] Each test class mapped to a TA-Processes threat (HAI TTP + ATLAS tactic ID where applicable) and an SR-Processes requirement
- [ ] Battery linked from SM-Processes inventory record and DR-Processes/IR-Processes artifacts for each AI-embedded workflow
- [ ] Named battery owner per archetype documented; quarterly re-run scheduled in advance
- [ ] 100% of AI-embedded workflows reaching production in the last 90 days have a passed go-live battery on record

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % AI-embedded workflows 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-Processes within 1 business day | ___% | ___% | 100% | ☐ | |
| Regression corpora published (adversarial-decision, rubber-stamp-detection, content-generation-safety, RAG-poisoning, Art. 50 disclosure-presence, class-shift detection) | ___/6 | ___/6 | 6/6 | ☐ | |

**Metric Collection Guidance:**
- **Go-live battery coverage**: Query SM-Processes inventory registry for workflows promoted to production in the last 90 days; cross-reference with test-run registry. Formula: `workflows_with_passed_battery / workflows_reaching_production × 100`
- **Threat coverage**: For each archetype's TA-Processes library entry, check whether at least one test class or corpus entry maps to it. Formula: `covered_threats / total_archetype_threats × 100`. Source: TA-Processes library × test metadata
- **IM routing rate**: For test failures in the last quarter, check IM-Processes ticket creation timestamps. Formula: `failures_with_IM_ticket_within_1BD / total_failures × 100`. Source: CI telemetry × IM-Processes system
- **Corpus publication**: Count corpora present in source control with versioned entries and a named owner. Source: corpus registry in 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 evidence of per-archetype test battery)

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

---

### Question 2: Regression Corpora in CI

**Q2.1:** Are six regression corpora (adversarial-decision, rubber-stamp-detection, content-generation-safety, RAG-poisoning, Art. 50 disclosure-presence, class-shift detection) versioned in source control with named corpus owners, a monthly refresh cadence, and budget-capped CI runs, and are Critical/High-tier workflows verified to have run and passed the applicable corpus before go-live?

**Evidence Required:**
- [ ] Six regression corpora published in source control: adversarial-decision corpus (synthetic decision inputs designed to flip decisions via boundary probing or protected-characteristic proxies), rubber-stamp-detection corpus (synthetic HITL decision batches to calibrate rubber-stamp detection thresholds), content-generation-safety corpus (generation prompts designed to produce copyright violations, brand-safety failures, or downstream-injection payloads), RAG-poisoning corpus (adversarial documents and crafted queries to redirect workflow purpose or extract cross-classification content), Art. 50 disclosure-presence corpus (UI interaction sequences for edge cases where disclosure might be suppressed), and class-shift detection corpus (synthetic input batches with controlled protected-characteristic proxy distribution shifts)
- [ ] Each corpus entry includes: input, expected safe output pattern, threat tag (HAI TTP + ATLAS tactic ID where applicable), SR-Processes requirement, source, date added
- [ ] CI wiring confirmed for workflows with programmatic interfaces: budget-capped CI runs for computational tests; Critical/High-tier workflows verified to run and pass applicable corpus before go-live
- [ ] Named corpus owner per corpus; corpus changes go through PR review
- [ ] Monthly refresh cadence evidenced: change-log showing updates from internal observations (IR-Processes findings, IM-Processes incidents), external sources (regulatory guidance, academic adversarial-ML research, ATLAS examples), and red-team exercises
- [ ] New workflow intake triggers a corpus-completeness check against the archetype's declared threat coverage

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| Regression corpora published (adversarial-decision, rubber-stamp-detection, content-generation-safety, RAG-poisoning, Art. 50 disclosure-presence, class-shift detection) | ___/6 | ___/6 | 6/6 | ☐ | |
| % Critical/High-tier workflows that ran and passed applicable corpus before go-live | ___% | ___% | 100% | ☐ | |
| 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
- **Go-live corpus pass rate**: For Critical/High-tier workflows promoted in the last 90 days, verify a corpus run and pass record exists in the test-run registry. Formula: `workflows_with_corpus_pass_at_go_live / total_Critical_High_go_lives × 100`. Source: test-run registry × SM-Processes
- **Refresh cadence**: Inspect git log for each corpus; compute days since last commit adding new entries. Source: VCS change-log
- **Threat coverage**: TA-Processes library entries mapped to corpus entries vs. total archetype library entries. Source: TA-Processes 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 in source control with CI runs)

**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-go-live, post-AI-component-update, post-incident, quarterly), and are all test failures routed to IM-Processes within 1 business day with a severity tag and named owner?

**Evidence Required:**
- [ ] Go-live battery process document defines re-run triggers: pre-go-live (blocks Sanctioned status in SM-Processes), post-AI-component-update within 14 days (Critical-tier: 7 days), post-incident before incident closure, and quarterly for all active workflows
- [ ] Go-live test records linked from SM-Processes inventory and PC intake artifacts for workflows promoted in the last 90 days
- [ ] Test failure to IM-Processes routing confirmed: sample of recent failures shows IM-Processes 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 workflows with named battery owner
- [ ] Post-AI-component-update re-run triggered and completed within SLA for any AI component changes in the last 6 months

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % test failures routed to IM-Processes within 1 business day | ___% | ___% | 100% | ☐ | |
| % post-AI-component-update re-runs completed within declared SLA (7/14 days by tier) | ___% | ___% | ≥90% | ☐ | |
| % active workflows with a quarterly battery re-run completed in last 90 days | ___% | ___% | ≥90% | ☐ | |
| % AI-embedded workflows 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-Processes ticket creation timestamps. Source: test failure log × IM-Processes system
- **Post-component-update SLA**: For AI component changes in last 6 months, check re-run date vs. change date by tier. Source: AI component changelog × test-run registry
- **Quarterly re-run rate**: Count active workflows with a battery run record dated within the last 90 days. Source: test-run registry × SM-Processes active workflow list
- **Go-live coverage**: SM-Processes inventory × test-run registry cross-reference for workflows 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-Processes wiring in place)

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

---

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

---

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

**Q4.1:** Is per-tier corpus calibration enforced (Critical-tier: all 6 corpora plus monthly rubber-stamp audit and quarterly class-shift verification; Low-tier: disclosure-presence corpus), and does each Critical-tier workflow have a separately tuned corpus from its TA-Processes L2 per-workflow deep threat model?

**Evidence Required:**
- [ ] Per-tier test treatment published and aligned to SM-Processes L2 tier-treatment matrix: Critical (full battery + all 6 corpora every CI run + monthly rubber-stamp detection audit with escalation threshold + quarterly class-shift detection verification), High (full battery + all 6 corpora on merge + quarterly rubber-stamp audit), Medium (subset battery + adversarial-decision + disclosure-presence corpus), Low (spot-check + disclosure-presence corpus)
- [ ] CI pipeline configuration confirms tier-differentiated corpus assignments, not the same corpus applied to all tiers
- [ ] Critical-tier corpus entries tuned to the workflow's specific decision thresholds, data classes, and AI component from the TA-Processes L2 per-workflow deep threat model
- [ ] Monthly rubber-stamp detection audit records on file for Critical-tier workflows: stratified sample of HITL decisions reviewed; escalation triggered when match rate ≥98%; records on file
- [ ] Quarterly class-shift detection verification records on file for Critical-tier workflows; class-shift monitor fires confirmed within declared detection window
- [ ] Per-tier SLA adherence tracked and reported to program sponsor

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % Critical-tier workflows with all 6 corpora running | ___% | ___% | 100% | ☐ | |
| Per-tier SLA adherence for testing activities (go-live battery, AI-component-update re-run, red-team cadence) | ___% | ___% | ≥90% per tier | ☐ | |
| % Critical-tier workflows with monthly rubber-stamp detection audit completed | ___% | ___% | 100% | ☐ | |
| % Critical-tier workflows with quarterly class-shift detection verified | ___% | ___% | 100% | ☐ | |

**Metric Collection Guidance:**
- **Corpus coverage**: CI telemetry for Critical-tier workflows; verify all 6 corpus runs appear in each workflow's CI check suite. Source: CI telemetry
- **SLA adherence**: Program telemetry across go-live battery turnaround, post-component-update re-run dates, and red-team calendar adherence. Formula: `activities_completed_within_SLA / total_activities × 100`
- **Rubber-stamp audit**: Count Critical-tier workflows with a rubber-stamp audit record dated within the last 30 days vs. total Critical-tier HITL workflows. Source: rubber-stamp detection audit records
- **Class-shift verification**: Count Critical-tier workflows with a class-shift monitor verification record in the last 90 days. Source: class-shift detection verification 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 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-embedded workflows red-teamed at least quarterly, and 100% of High-tier semi-annually, with scope derived from TA-Processes L2 per-workflow deep threat models covering adversarial-decision inputs, rubber-stamp induction, disclosure-bypass techniques, RAG-poisoning paths, class-shift induction, downstream injection via generated content, and HITL-saturation attacks?

**Evidence Required:**
- [ ] Red-team schedule on calendar covering all Critical-tier (quarterly) and High-tier (semi-annual) workflows; no Critical-tier workflow skipped in the last 12 months
- [ ] Red-team scope documented per exercise: written rules of engagement, test plan reviewed with workflow owner, scope derived from TA-Processes L2 per-workflow deep threat model (not archetype snapshot)
- [ ] ATLAS tactic IDs referenced in scope documentation where applicable: TA0003 Initial Access (RAG-poisoning, downstream injection), TA0012 ML Attack Staging analog (adversarial-decision inputs, class-shift induction)
- [ ] Red-team execution log and structured findings report on file: severity, root cause, SR-Processes requirement traced, HAI TTP tagged, remediation pairing
- [ ] Findings routed to IM-Processes with severity tag and named workflow 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 workflows red-teamed in last 90 days | ___% | ___% | 100% | ☐ | |
| % High-tier workflows 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 workflows with a red-team report dated within the last 90 days vs. total Critical-tier workflows. Source: ST records
- **High red-team rate**: Same logic for 180 days. Source: ST 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. Source: program calendar × ST 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 (decision pipeline + customer-facing flow, back-office content generation + downstream injection surface, knowledge-management + decision pipeline) documented and executed for all Critical-tier composite workflows, 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 composite workflow; reviewed by named architect
- [ ] Decision pipeline + customer-facing flow composition test: adversarial decision input produces a biased recommendation surfaced to the customer; tests that Art. 50 disclosure and override path both fire correctly for the composed output
- [ ] Back-office augmentation + content-generation output reaching customer-facing flow: back-office content generation produces output containing injection syntax; tests that the customer-facing flow's input-validation layer sanitizes it before customer display (ATLAS TA0003 analog)
- [ ] Knowledge-management + decision pipeline: RAG-poisoned document injects into decision pipeline context window and shifts the decision; tests that decision pipeline HITL gate catches the anomalous recommendation
- [ ] Regression corpus growth rate evidenced: Critical-tier corpora show ≥1 new entry per month from red-team or incident findings
- [ ] Finding to TA-Processes library-gap pipeline: Critical gaps closed within 30 days; High within 60 days

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| Cross-archetype composition tests documented and executed for Critical-tier composite workflows | ___% | ___% | 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% | ☐ | |
| Per-tier SLA adherence for testing activities | ___% | ___% | ≥90% | ☐ | |

**Metric Collection Guidance:**
- **Composition test coverage**: Count Critical-tier workflows with composite archetype interactions that have a documented test plan + execution record vs. total composite Critical-tier workflows. Source: ST 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-Processes findings × corpus change-log
- **SLA adherence**: Program telemetry as described in Q4 metrics

**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 on production workflows via canary inputs, publish workflow-level test patterns and regression corpora, and contribute process-level attack techniques to MITRE ATLAS, sector ISACs, and OECD AI

---

### Question 7: Continuous Canary-Input Testing

**Q7.1:** Are ≥80% of Critical-tier AI-embedded workflows under continuous canary-input testing with daily probe execution, covering adversarial-decision, rubber-stamp-induction, disclosure-bypass, and RAG-poisoning canaries, with novel process-level TTPs triaged into the TA-Processes library within 14 days and high-severity canary findings routed to IM-Processes within 24 hours?

**Evidence Required:**
- [ ] Canary-input framework deployed and injecting synthetic adversarial workflow items into production traffic at a controlled rate (≤1% of total workflow volume, clearly flagged in decision logs as synthetic canary items): adversarial-decision canaries (near-boundary decision inputs; verify class-shift monitor and HITL gate respond, ATLAS TA0012 analog), rubber-stamp-induction canaries (known "wrong" AI recommendation injected; verify ≥5% human override rate on canaries), disclosure-bypass canaries (synthetic UI interaction sessions for Art. 50 disclosure element; cover A/B variants, mobile breakpoints, escalation paths), and RAG-poisoning canaries (adversarial documents seeded into retrieval corpus; verify workflow does not follow adversarial instructions, ATLAS TA0003)
- [ ] Canary findings triaged by named ST owner at least weekly; novel process-level TTP patterns forwarded to TA-Processes L3 auto-proposal pipeline within 14 days
- [ ] High-severity canary findings route to IM-Processes within 24 hours; evidence: IM-Processes ticket timestamps vs. canary alert timestamps
- [ ] Canary items clearly attributed in decision logs; excluded from regulatory reporting; canary volume ≤1% confirmed
- [ ] Canary harness health: % Critical-tier workflows with fresh canary result within last 24 hours; on-call paged when feed goes stale >24 hours

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % Critical-tier workflows under continuous canary-input testing (daily probe execution) | ___% | ___% | ≥80% | ☐ | |
| New process-level TTP ingestion lead time (canary finding to TA-Processes library entry) | ___ days | ___ days | ≤14 days | ☐ | |
| % high-severity canary findings routed to IM-Processes within 24 hours | ___% | ___% | 100% | ☐ | |
| Canary harness health (% Critical-tier workflows with fresh canary result in last 24 hours) | ___% | ___% | ≥95% | ☐ | |

**Metric Collection Guidance:**
- **Continuous coverage**: Canary telemetry, count Critical-tier workflows with a canary result in the last 24 hours vs. total Critical-tier. Source: ST canary telemetry
- **TTP ingestion lead time**: For novel process-level patterns identified by canary testing, measure time from canary alert to TA-Processes library entry. Source: canary to TA pipeline telemetry
- **IM routing within 24h**: Compare canary alert timestamp to IM-Processes ticket creation timestamp for high-severity findings. Source: canary alert log × IM-Processes system
- **Harness health**: Monitoring dashboard last-canary-time per Critical-tier workflow; 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 canary-input testing 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 (process-level), sector ISACs, or OECD AI, with at least one accepted as a new or refined technique or advisory, and are ≥6 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 process-level attack technique observations: decision-laundering patterns, rubber-stamp induction via queue saturation, disclosure-bypass via A/B test manipulation, RAG-poisoning targeting workflow purpose, ATLAS TA0003), sector ISACs (AI-embedded workflow security advisories relevant to the org's sector), or OECD AI Policy Observatory (real-world telemetry evidence on Art. 22/Art. 50 operational compliance)
- [ ] At least one submission accepted as a new or refined technique or advisory; evidence: ATLAS, ISAC, or OECD acknowledgment
- [ ] Legal-vetting record for each contribution: org identity scrubbed; no affected-person data included in any submission
- [ ] ≥6 open regression corpora published under a permissive license; scrubbed of org-specific workflow names, data classes, and decision thresholds
- [ ] Published corpora maintained upstream; 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 process-level / sector ISACs / OECD AI) | ___ | ___ | ≥4 | ☐ | |
| Open regression corpora published and maintained upstream | ___/6 | ___/6 | ≥6 corpora published | ☐ | |
| Contributions accepted as new or refined techniques or advisories | ___ | ___ | ≥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 ≥6 corpora exist in the public repository under a permissive license. Source: external repository
- **Acceptance**: Cross-reference contribution log with ATLAS/ISAC/OECD 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 adversarial-workflow exercise per year and participated in ≥2 additional cross-org exercises, with documented cross-org adversarial-workflow detection data from participants?

**Evidence Required:**
- [ ] Exercise log on file: ≥1 hosted adversarial-workflow exercise per year (OWASP AI chapter, ATLAS practitioner table, or sector ISAC AI working group); ≥2 additional cross-org exercises participated
- [ ] Hosted exercise documented: agenda, participant list, benchmark methodology, measurement of adversarial-workflow detection improvement before and after the exercise
- [ ] Cross-org adversarial-workflow detection 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 sector ISAC AI working groups or OECD AI policy exercises 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 adversarial-workflow detection data documented | No / Yes | No / Yes | Yes | ☐ | |
| Open regression corpora published and maintained upstream | ___/6 | ___/6 | ≥6 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
- **Detection data documentation**: Hosted exercise report; participant pre/post adversarial-workflow detection 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 Canary-Input Testing | ___ | |
| L3 | Q8 | Industry Contributions | ___ | |
| L3 | Q9 | Industry-Shared Exercises | ___ | |
| **L3 Score** | | | **___** | 0.2 |
| **Overall ST-Processes Score** | | | **___** | |

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

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

---

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