Security Testing (ST) - Processes 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 Processes domain is ../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.

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

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

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

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

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

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

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

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

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

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