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

HAIAMM Assessment Questionnaire v3.0

Practice: Security Testing (ST) Domain: Infrastructure Purpose: Assess organizational maturity in running adversarial test batteries and regression corpora against AI/HAI infrastructure components, from foundational per-archetype batteries 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-Infrastructure 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 on a defined cadence, and verify that every AI/HAI infrastructure component 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 infrastructure archetypes (inference endpoint/model-serving cluster, model registry, GPU/accelerator fleet, orchestrator/control plane, vector-store infrastructure, AI-specific CI/CD, feature store/online serving cache), with each test class tied to a TA-Infrastructure archetype threat (HAI TTP + ATLAS tactic ID) and an SR-Infrastructure requirement, defined inputs/outputs/pass-fail criteria, and an evidence artifact?

Evidence Required: - [ ] Test battery document published per archetype; covers per-archetype probes including model-extraction probe (ATLAS TA0004/TA0013), cross-tenant isolation test (ATLAS TA0013), DoS/prompt-flood resilience test, model-swap detection test, unauthorized-upload probe (ATLAS TA0004), signed-artifact enforcement test, GPU residual-state-clearing test (ATLAS TA0012), workflow-signing test (ATLAS TA0012), cross-tenant retrieval probe (ATLAS TA0013), pipeline-signing test (ATLAS TA0012), and feature-poisoning detection test as applicable per archetype - [ ] Each test class records: inputs, expected safe outcome, pass/fail criteria, evidence artifact (probe result, log snippet, or CI run link) - [ ] Each test class mapped to a TA-Infrastructure threat (HAI TTP + ATLAS tactic ID) and an SR-Infrastructure requirement - [ ] Battery linked from SM-Infrastructure inventory record and DR/IR artifacts for each AI/HAI infrastructure component - [ ] Named battery owner per archetype documented; quarterly re-run scheduled in advance - [ ] 100% of AI/HAI infrastructure components reaching production in the last 90 days have a passed go-live battery on record

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % of AI/HAI infrastructure components 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 within 1 business day | % | % | 100% | ☐ | | | Quarterly battery re-runs completed for all active components | % | % | ≥90% per quarter | ☐ | |

Metric Collection Guidance: - Go-live battery coverage: Query SM-Infrastructure inventory registry for components promoted to production in the last 90 days; cross-reference with test-run registry. Formula: components_with_passed_battery / components_reaching_production × 100 - Threat coverage: For each archetype's TA-Infrastructure library entry, check whether at least one test class or corpus entry maps to it. Formula: covered_threats / total_archetype_threats × 100. Source: TA-Infrastructure library × test metadata - IM routing rate: For test failures in the last quarter, check IM ticket creation timestamps. Formula: failures_with_IM_ticket_within_1BD / total_failures × 100. Source: test failure log × IM system - Quarterly re-run rate: Count active components with a battery run record dated within the last 90 days. Source: battery run registry × SM-Infrastructure active component list

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 on Defined Cadence

Q2.1: Are six regression corpora (model-extraction, cross-tenant-isolation, GPU-residual-state, workflow-injection, retrieval-extraction, pipeline-signing) versioned in source control, running on a monthly-or-better cadence for Critical/High-tier components, with a named corpus owner and a monthly refresh cadence from internal and external sources?

Evidence Required: - [ ] Six regression corpora published in source control: model-extraction corpus (20–60 prefix-completion and nearest-neighbor query patterns), cross-tenant-isolation probe corpus (20–60 cross-tenant query patterns across inference endpoint, vector-store, and GPU fleet archetypes), GPU-residual-state corpus (15–40 job-pair test configurations), workflow-injection corpus (20–50 crafted workflow step payloads and unsigned workflow definitions), retrieval-extraction corpus (20–60 query sequences probing cross-tenant retrieval and embedding extraction at scale), and pipeline-signing corpus (15–40 pipeline trigger attempts with unsigned definitions) - [ ] Each corpus entry includes: input, expected safe outcome, threat tag (HAI TTP + ATLAS tactic ID), source, date added - [ ] Corpus runs wired on a defined cadence: monthly minimum for Critical/High-tier; failure blocks production promotion for Critical-tier components - [ ] Named corpus owner per corpus; corpus changes go through review with named owner - [ ] Monthly refresh cadence evidenced: change-log showing updates from internal observations (IR findings, IM incidents, red-team results), external sources (ATLAS examples, OWASP LLM/Agentic Top 10 infrastructure examples), and MLOps security research - [ ] New AI/HAI infrastructure component provisioning triggers a corpus completeness check against the component's archetype battery

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Regression corpora published (model-extraction, cross-tenant-isolation, GPU-residual-state, workflow-injection, retrieval-extraction, pipeline-signing) | /6 | /6 | 6/6 | ☐ | | | % Critical/High-tier component changes that triggered the relevant corpus run | % | % | ≥90% | ☐ | | | 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 - Corpus run trigger rate: For Critical/High-tier component changes in the last quarter, verify a corpus run was triggered within the declared cadence. Formula: changes_with_corpus_run / total_Critical_High_changes × 100. Source: change management system × corpus run registry - Refresh cadence: Inspect git log for each corpus; compute days since last commit adding new entries. Source: VCS change-log - Threat coverage: TA-Infrastructure library entries mapped to corpus entries vs. total archetype library entries. Source: TA-Infrastructure 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-configuration-update, post-incident, quarterly), and are all test failures routed to IM-Infrastructure 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-Infrastructure), post-configuration-update within 7 days for Critical-tier and 14 days for High-tier, post-incident before incident closure, and quarterly for all active components - [ ] Go-live test records linked from SM-Infrastructure inventory and PC intake artifacts for components promoted in the last 90 days - [ ] Test failure to IM routing confirmed: sample of recent failures shows IM 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 components with named battery owner - [ ] Post-configuration-update re-run triggered and completed within SLA for any GPU scheduling policy, signing policy, rate-limit policy, or isolation policy changes in the last 6 months

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

Evidence Location: __ Validation Date: __ Notes: ___

Maturity Level 2

Objective: Calibrate test depth per risk tier using the SM-Infrastructure L2 tier-treatment matrix, run scheduled per-tier red-team exercises using TA-Infrastructure L2 deep threat models, and test cross-archetype compositions for Critical-tier components

Question 4: Tier-Calibrated Battery and Corpus Depth

Q4.1: Is per-tier corpus calibration enforced (Critical-tier: all 6 corpora on monthly cadence with separately tuned per-component corpus; Low-tier: model-extraction corpus on quarterly cadence), and does each Critical-tier component have a component-specific tuned corpus derived from its TA-Infrastructure L2 deep threat model?

Evidence Required: - [ ] Per-tier test treatment published and aligned to SM-Infrastructure L2 tier-treatment matrix: Critical (full battery + all 6 corpora monthly + separately tuned component corpus + logging-completeness quarterly), High (full battery + all 6 corpora monthly), Medium (subset battery + model-extraction + cross-tenant-isolation quarterly), Low (spot-check + model-extraction corpus quarterly) - [ ] Corpus run schedule confirmed for each tier, not the same cadence applied to all tiers - [ ] Critical-tier corpus entries tuned to the component's specific tenant population, model versions, query patterns, and GPU fleet configuration from the TA-Infrastructure L2 per-component deep threat model - [ ] Logging-completeness verified quarterly for Critical-tier; semi-annually for High-tier; annually for Medium; at go-live for Low; evidence on file - [ ] Per-tier SLA adherence tracked and reported to program sponsor - [ ] Post-configuration-update re-run differentiated: Critical-tier full battery within 7 days; High within 14 days; Medium subset within 30 days

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % Critical-tier components with all 6 corpora running on monthly cadence | % | % | 100% | ☐ | | | Per-tier SLA adherence for testing activities (go-live battery, post-config-update re-run, red-team cadence) | % | % | ≥90% per tier | ☐ | | | % Critical-tier components with a separately tuned corpus from TA-Infrastructure L2 threat model | % | % | 100% | ☐ | | | % Critical-tier components with logging-completeness verified in last 90 days | % | % | 100% | ☐ | |

Metric Collection Guidance: - Corpus cadence adherence: Corpus run registry for Critical-tier components; verify a run occurred within the last 30 days for each corpus per component. Source: corpus run registry - SLA adherence: Program telemetry across go-live battery turnaround, post-config-update re-run dates, and red-team calendar adherence. Formula: activities_completed_within_SLA / total_activities × 100 - Tuned corpus coverage: Count Critical-tier components with a corpus file containing component-specific entries vs. total Critical-tier components. Source: corpus registry - Logging-completeness: Count Critical-tier components with a logging-completeness verification record in the last 90 days. Source: logging-completeness verification records

Evidence Location: __ Validation Date: __ Notes: ___

Question 5: Scheduled Red-Team Exercises

Q5.1: Are 100% of Critical-tier AI/HAI infrastructure components red-teamed at least quarterly, and 100% of High-tier semi-annually, with scope derived from TA-Infrastructure L2 per-component deep threat models covering model-extraction campaigns, cross-tenant retrieval extraction, GPU residual-state composition, pipeline-tampering, workflow-injection chains, and feature-poisoning chains?

Evidence Required: - [ ] Red-team schedule on calendar covering all Critical-tier (quarterly) and High-tier (semi-annual) components; no Critical-tier component skipped in the last 12 months - [ ] Red-team scope documented per exercise: written rules of engagement, test plan reviewed with component owner, scope derived from TA-Infrastructure L2 per-component deep threat model - [ ] ATLAS tactic IDs referenced in scope documentation: TA0001 Reconnaissance, TA0004 ML Model Access, TA0012 ML Attack Staging, TA0013 Exfiltration - [ ] Red-team execution log and structured findings report on file: severity, root cause, ATLAS tactic ID, SR-Infrastructure requirement traced, remediation pairing - [ ] Findings routed to IM-Infrastructure with severity tag and named component 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 components red-teamed in last 90 days | % | % | 100% | ☐ | | | % High-tier components 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 components with a red-team report dated within the last 90 days vs. total Critical-tier components. 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 (inference endpoint + GPU fleet residual-state, orchestrator + vector-store retrieval-injection chain, AI-CI/CD + model registry tampering) documented and executed for all Critical-tier composite components, 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 component with composition dependencies; reviewed by named architect - [ ] Inference endpoint + GPU fleet residual-state composition test: job A from tenant A on a GPU node, then inference from tenant B on the same GPU node; probe for evidence of tenant A's residual state in tenant B's completions (ATLAS TA0004/TA0012) documented - [ ] Orchestrator + vector-store retrieval-injection chain test: crafted retrieval response containing workflow-injection instructions; verify orchestrator does not execute injected instructions (AGH; ATLAS TA0001/TA0012) documented - [ ] AI-CI/CD + model registry tampering test: pipeline run attempting to replace a signed model artifact with an unsigned or modified artifact; verify signing enforcement prevents substitution (ATLAS TA0012) documented - [ ] Regression corpus growth rate evidenced: Critical-tier corpora show ≥1 new entry per month from red-team or incident findings - [ ] Finding to TA-Infrastructure library-gap pipeline: Critical gaps closed within 30 days; High within 60 days

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % Critical-tier composite components 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-Infrastructure library gaps (Critical tier) closed within 30 days | % | % | 100% | ☐ | |

Metric Collection Guidance: - Composition test coverage: Count Critical-tier components with composition dependencies that have a documented test plan + execution record vs. total composite Critical-tier components. 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 findings × corpus change-log - TA gap closure: TA-Infrastructure 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 infrastructure components, publish regression corpora and findings as open artifacts, and contribute discovered techniques to MITRE ATLAS, AVID, CNCF AI infrastructure advisories, and OWASP LLM/Agentic Top 10 infrastructure patterns

Question 7: Continuous Automated Adversarial Testing Harness

Q7.1: Are ≥80% of Critical-tier AI/HAI infrastructure components under continuous automated adversarial testing with daily probe execution, using model-extraction generators, cross-tenant isolation probers, GPU residual-state probers, pipeline-tampering generators, and retrieval-extraction seeders, with novel techniques triaged into the TA-Infrastructure library within 14 days and high-severity automated findings routed to IM within 24 hours?

Evidence Required: - [ ] Automated adversarial testing harness deployed and producing daily probe results against Critical-tier components: model-extraction generator (mutation of regression corpus, query-pattern variation, rate-limit boundary probing, ATLAS TA0004/TA0013), cross-tenant isolation prober (cross-tenant access patterns targeting namespace boundaries, IAM scope limits, ATLAS TA0013), GPU residual-state prober (job-pair compositions for residual-state leakage, ATLAS TA0012), pipeline-tampering generator (unsigned pipeline triggers, missing-provenance promotion attempts, ATLAS TA0012), and retrieval-extraction seeder (query sequences to reconstruct tenant embedding spaces, ATLAS TA0013) - [ ] Continuous adversarial testing telemetry: harness health dashboard showing % Critical-tier components with a fresh probe result within the last 24 hours; on-call paged when feed goes stale >24 hours - [ ] Finding triage process: named ST owner reviewing automated findings at least weekly; novel technique patterns forwarded to TA-Infrastructure L3 auto-proposal pipeline within 14 days - [ ] High-severity automated findings route to IM-Infrastructure within 24 hours; evidence: IM ticket timestamps vs. harness alert timestamps - [ ] ATLAS tactic walk records: harness exercises TA0001, TA0004, TA0012, TA0013 technique coverage daily

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

Metric Collection Guidance: - Continuous coverage: Harness telemetry, count Critical-tier components 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-Infrastructure library entry. Source: harness to TA pipeline telemetry - IM routing within 24h: Compare harness alert timestamp to IM ticket creation timestamp for high-severity findings. Source: harness alert log × IM system - Harness health: Monitoring dashboard last-probe-time per Critical-tier component; 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, CNCF AI Working Group, or OWASP LLM/Agentic Top 10 infrastructure patterns, with at least one accepted as a new or refined technique, and are all 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 model-extraction patterns, GPU residual-state leakage mechanics, pipeline-tampering paths, ATLAS TA0004/TA0012/TA0013), AVID (structured vulnerability disclosures), CNCF AI Working Group/CNCF TAG Security (AI infrastructure security advisories), or OWASP LLM/Agentic Top 10 (real-world telemetry evidence) - [ ] At least one submission accepted as a new or refined technique; evidence: ATLAS, AVID, CNCF, or OWASP acknowledgment - [ ] Legal-vetting record for each contribution: org identity scrubbed; coordinated disclosure completed for any third-party component involvement - [ ] All 6 open regression corpora published under a permissive license; published versions scrubbed of org-specific component names, tenant identifiers, and model versions - [ ] 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 / AVID / CNCF AI / OWASP) | ___ | ___ | ≥4 | ☐ | | | Open regression corpora published and maintained upstream | /6 | /6 | ≥6 corpora published | ☐ | | | Contributions accepted as new or refined 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 ≥6 corpora exist in the public repository under a permissive license. Source: external repository - Acceptance: Cross-reference contribution log with ATLAS/AVID/CNCF/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 red-team 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 exercise per year (CNCF AI security working group, 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 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 CNCF TAG Security AI exercises, ATLAS practitioner tables, or sector ISAC AI infrastructure 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 detection-benchmark improvement 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 - 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 on Defined Cadence	___
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-Infrastructure Score			___

Maturity Level Achieved: ☐ L1 ☐ L2 ☐ L3

Assessment Date: __ Assessor: __ Next Review Date: ___

Document Version: HAIAMM v3.0 Practice: Security Testing (ST) Domain: Infrastructure 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