Security Requirements (SR) - 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 Requirements (SR) in the Infrastructure domain is ../practices/SR-Infrastructure-OnePager.md. Outcome metrics in this questionnaire are reproduced verbatim from that one-pager. Canonical subject and through-lines: ../HAIAMM-v3.0-Framing.md §8.

Security Requirements (SR) - Infrastructure Domain

HAIAMM Assessment Questionnaire v3.0

Practice: Security Requirements (SR) Domain: Infrastructure Purpose: Assess organizational maturity in authoring and maintaining the AI/HAI Infrastructure Requirements Pack, a base set plus per-archetype deltas, and producing a Requirements-Evidence Map (REM) for every infrastructure asset hosting or serving AI workloads. 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 a lower level before advancing
Baseline first, Record current metric values before setting targets

Scoring Methodology

Score	Label	Criteria
1.0	Fully Mature	Evidence complete AND ≥3 outcome metrics meet targets
0.67	Implemented	Evidence complete AND 2 outcome metrics meet targets
0.33	Partial	Evidence partially complete AND <2 metrics meet targets
0.0	Not Implemented	No evidence present

Maturity Level 1

Objective: Publish the AI/HAI Infrastructure Requirements Pack (base plus per-archetype deltas), wire it into the SM intake gate, and produce a Requirements-Evidence Map for every infrastructure asset hosting AI workloads.

Question 1: Author the base AI/HAI Infrastructure Requirements Pack

Q1.1: Does a published, versioned AI/HAI Infrastructure Requirements Pack exist containing a base set (target ≤20 requirements) covering identity and workload-identity/isolation/encryption/region and residency/observability/patch and image/quotas and abuse/backup and RTO-RPO/failure-mode/disclosure, with every requirement tagged to at least one TA-Infrastructure archetype threat and one PC-Infrastructure priority-compliance item?

Evidence Required: - [ ] Base requirements pack document published in the requirements registry with a version number and a named owner - [ ] Pack covers minimum base categories: identity and workload-identity, isolation, encryption (at rest and in transit), region and data-residency enforcement, observability, patch and image hygiene, quotas/rate limits/abuse detection, backup and recovery (RTO/RPO), failure-mode design, and disclosure (EU AI Act Art. 26/50 logging capability) - [ ] Each requirement row carries: ID, statement, rationale (threat tag + compliance tag), evidence source, test method, and acceptance criterion - [ ] REM (Requirements-Evidence Map) template exists and is linked from the SM intake checklist; template includes Met / Met-with-compensating-control / Gap-accepted / Not-applicable columns with evidence citation, gap owner, gap expiry, and compensating-control description - [ ] Accepted-gaps register exists with named owner and expiry date per row - [ ] Pack-version control record shows version, change date, and change summary for each revision - [ ] Cross-domain REM linkage process documented: Software-domain artifact REMs reference the Infrastructure REM of the hosting cluster for base infrastructure categories (identity, isolation, encryption, observability, patch hygiene)

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Base + archetype requirements packs published | 0 / 8 documents | /8 | 8 / 8 (base + 7 archetype deltas) | ☐ | Requirements registry | | % new AI/HAI infrastructure assets with a completed REM | measure | % | 100% | ☐ | SM intake ticket + REM artifact | | % active AI/HAI infrastructure assets in inventory with a current-year REM | measure | % | ≥90% | ☐ | Inventory × REM artifacts | | % of pack requirements tagged to a TA-Infrastructure archetype threat and a PC-Infrastructure compliance item | measure | % | 100% | ☐ | Pack metadata | | % of Software-domain REMs referencing an Infrastructure REM for base infra categories | measure | ___% | ≥80% | ☐ | Cross-domain REM linkage telemetry | | Accepted-gap aging (median age of open accepted-gap rows) | measure | ___ days | ≤90 days | ☐ | REM backlog |

Metric Collection Guidance: - Packs published: Count published documents in the requirements registry: 1 base + 7 archetype deltas (inference endpoint, model registry, GPU/accelerator fleet, orchestrator/control plane, vector-store infra, AI-specific CI/CD, feature store). Source: requirements registry index. - % new assets with REM: Query SM intake tickets closed in the last 90 days; count those with a linked REM artifact. Formula: REMs on file / total new infrastructure asset approvals × 100. - % active assets with current-year REM: Cross-reference SM inventory against REM artifact store. Formula: assets with current-year REM / total active assets × 100. - % requirements tagged: Count requirements with both a TA threat tag and a PC compliance tag. Formula: tagged requirements / total requirements × 100. - % Software REMs cross-referencing Infrastructure REM: Query SR-Software REM store; count Software artifact REMs that include a reference link to an Infrastructure REM for base categories. Formula: Software REMs with Infra cross-reference / total Software REMs × 100. - Accepted-gap aging: Compute median calendar days from gap-open date to today for all currently open rows.

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 a published infrastructure requirements pack)

Evidence Location: __ Validation Date: __ Notes: ___

Question 2: Author per-archetype requirement deltas

Q2.1: Have per-archetype requirement deltas been authored and published for all seven infrastructure archetypes (inference endpoint, model registry, GPU/accelerator fleet, orchestrator/control plane, vector-store infrastructure, AI-specific CI/CD, feature store), and are the correct deltas automatically applied at intake?

Evidence Required: - [ ] Seven archetype-delta documents (or pack sections) published with version numbers and tagged to TA-Infrastructure archetype threats - [ ] Each delta includes minimum-viable scope items specific to its archetype (e.g., GPU residual-state clearing for GPU fleet, workload-identity-only writes for model registry, signed workflow definitions for orchestrator, SLSA provenance for AI-specific CI/CD) - [ ] Intake process routes each infrastructure asset to base pack + applicable archetype delta(s); routing logic is documented and tested with at least one intake example per archetype - [ ] REM template enforces that archetype-specific delta rows are present and populated for the declared archetype - [ ] Pack-version control record reflects delta amendments and cross-references the TA-Infrastructure archetype threat that drove each change - [ ] Traceability matrix links delta requirements back to TA-Infrastructure archetype threat models and the PC-Infrastructure priority compliance map - [ ] Compensating-controls list documents approved compensating controls for common gap patterns per archetype

Metric Collection Guidance: - Packs published: Verify all seven archetype-delta documents are present in the registry with current version numbers. - % new assets with REM: Verify REM rows for the asset's archetype delta are populated, not only base pack rows. - % active assets with current-year REM: Confirm archetype delta rows are present in each REM. - % requirements tagged: Confirm all delta requirements carry both a TA threat tag and a PC compliance tag. - % Software REMs cross-referencing: Same as Q1. - Accepted-gap aging: Include archetype-delta gap rows in the aging calculation.

Evidence Location: __ Validation Date: __ Notes: ___

Question 3: Wire the pack into the SM intake gate and establish cross-domain REM linkage

Q3.1: Is the requirements pack wired into the SM intake gate so that every AI/HAI infrastructure asset carries a completed REM, with Met rows citing specific evidence (IaC configuration reference, conformance test result, IAM audit output, SIEM completeness metric), and do Software-domain artifact REMs reference the Infrastructure REM for base infrastructure categories?

Evidence Required: - [ ] SM intake checklist includes a gate step requiring a completed REM before Sanctioned status is issued for the infrastructure asset - [ ] At least three production REMs on file from the last 90 days, each showing Met / Gap-accepted / Not-applicable rows with specific evidence citations (IaC config reference, admission-controller policy, secrets-scanner CI result, GPU isolation conformance test result, SIEM log forwarding confirmation, backup test record, kill-switch test result, or signed-image attestation) - [ ] Each Met row in the sample REMs cites a specific artifact, not a narrative assertion - [ ] Each Gap-accepted row carries: compensating control, named owner, re-review date (≤90 days from open date at L1), and residual-risk rationale - [ ] Cross-domain REM linkage is operational: at least three Software-domain artifact REMs on file that include a reference link to the Infrastructure REM of their hosting cluster for base categories - [ ] Material-change trigger list is documented (new tenant onboarded, network topology change, platform major version upgrade, workload-tier reclassification) and included in the intake checklist - [ ] Pack-version control confirms quarterly refresh cadence with at least one refresh on record

Metric Collection Guidance: - Packs published: Confirm 8/8 documents in the registry with current version numbers. - % new assets with REM: Pull SM intake ticket list for last 90 days; confirm each Sanctioned status was preceded by a linked REM artifact. - Cross-domain linkage: Query SR-Software REM store; compute the percentage of Software artifact REMs that include a reference link to an Infrastructure REM for base categories. - Evidence quality check: Spot-check 10 REM rows across 3 infrastructure assets; confirm each Met row cites a specific evidence artifact. - Accepted-gap aging: Confirm median open-gap age is within ≤90 days; flag any gap without a named owner or expiry.

Evidence Location: __ Validation Date: __ Notes: ___

Maturity Level 2

Objective: Replace qualitative requirements with quantitative, SLA-bound, and binary-evidence conditions; calibrate the requirements pack per risk tier; validate REM evidence continuously for Critical and High-tier infrastructure assets; and maintain IR feedback loops.

Question 4: Quantitative and binary requirement pack

Q4.1: Do 100% of pack requirements carry a quantitative or binary evidence condition, with every SLA (vulnerability remediation days, GPU clearing conformance test cadence, SIEM completeness percentage, kill-switch response time, RTO/RPO) and binary state (workload-identity-only access confirmed, signed artifacts enforced, dedicated nodes for Critical tier confirmed, rate limits verified) specified, and has all qualitative language been removed?

Evidence Required: - [ ] Requirements pack shows no qualitative language; all language is measurable or binary - [ ] GPU residual-state clearing requirement is binary: documented clearing mechanism verified between every job on shared GPU hardware; last conformance test date and result on file; clearing mechanism tested quarterly - [ ] Workload-identity-only access requirement is binary: zero long-lived access keys confirmed by last IAM audit scan with date and zero-finding result - [ ] Signed model artifacts requirement is binary: inference endpoint's admission hook rejects unsigned artifacts; last verification test date; zero unsigned artifacts served in production in last 90 days - [ ] SIEM log forwarding completeness requirement is measurable: ≥99% of AI infrastructure audit events reach the SIEM within 5 minutes; daily completeness metric collected; SLA breach generates a P1 alert - [ ] Kill-switch test requirement is binary: emergency-halt mechanism tested quarterly; ≤5-minute halt-to-full-stop SLA; last test date, invoker, and result on file - [ ] REM template updated to reflect quantitative conditions; each row's evidence field maps to the specific SLA or binary predicate - [ ] Pack-version control log shows the quantitative update was a tracked amendment with a version bump

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % requirements with quantitative or binary evidence condition | measure | % | 100% | ☐ | Requirements pack | | % Critical-tier REMs re-validated against observed reality in last 90 days | measure | % | ≥95% | ☐ | REM validation log | | Accepted-gap aging, median age of Critical-tier open gaps | measure | ___ days | ≤60 days | ☐ | Gap register | | % Critical-tier assets with EU AI Act Art. 26 full deployer-duty checklist in the REM | measure | % | 100% | ☐ | Compliance view | | % IR-Infrastructure findings that trigger a REM row re-review within 5 BD | measure | % | ≥90% | ☐ | IR-to-REM linkage telemetry |

Metric Collection Guidance: - % requirements quantitative/binary: Count requirements with a measurable SLA or explicit binary predicate vs. total requirements. Source: requirements pack document. - % Critical-tier REMs re-validated: Count Critical-tier assets whose REM validation log shows a re-validation run (not self-attestation alone) in the last 90 days. Formula: re-validated Critical-tier assets / total Critical-tier assets × 100. - Accepted-gap aging (Critical): Filter gap register to Critical-tier rows; compute median calendar days open. - % Critical-tier with Art. 26 checklist: Count Critical-tier asset REMs that include the EU AI Act Art. 26 full deployer-duty checklist appendix with verifiable evidence. - % IR findings triggering REM re-review: Count IR-Infrastructure findings in the last 90 days; confirm the percentage that generated a REM row re-review flag within 5 business days. Formula: IR findings with REM re-review flag within 5 BD / total IR findings × 100.

Evidence Location: __ Validation Date: __ Notes: ___

Question 5: Per-tier requirement depth

Q5.1: Has a per-tier pack overlay been published and enforced at SM intake, with Critical-tier assets requiring dedicated-node isolation, executive sign-off, a 60-day accepted-gap SLA, and quarterly REM re-validation, and Low-tier assets receiving base pack only?

Evidence Required: - [ ] Per-tier pack overlay document published showing Critical / High / Medium / Low tier treatment matrices - [ ] Critical-tier overlay includes: full base pack + all applicable archetype deltas; dedicated-node isolation required (binary, enforced by scheduler policy); executive sign-off requirement; EU AI Act Art. 26 full deployer-duty checklist as a discrete REM appendix; 60-day accepted-gap aging SLA; quarterly re-validation; IR-Infrastructure auto-revalidation: every IR finding for a Critical-tier asset triggers a full REM re-validation run within 5 business days - [ ] SM intake routing logic enforces tier-appropriate depth; intake ticket records tier assignment and pack overlay version applied - [ ] Accepted-gaps register is tiered: Critical-tier gaps are flagged before the 60-day escalation threshold - [ ] Scheduler policy configuration confirms dedicated-node enforcement for Critical-tier workloads (zero Critical-tier training or inference workloads on nodes shared with lower-tier workloads) - [ ] Pack-version control shows the per-tier overlay was versioned and announced to the reviewer community - [ ] Traceability matrix confirms Critical-tier REM rows link EU AI Act Art. 26 deployer duties to specific evidence artifacts (IaC config, conformance test, IAM audit output)

Metric Collection Guidance: - % requirements quantitative/binary: Confirm no regressions from Q4 after tier overlay was applied. - % Critical-tier REMs re-validated: Verify the re-validation cadence is operating using observable-reality checks (IAM audit, GPU isolation conformance test, signed-image admission-controller query, SIEM completeness metric, kill-switch test). - Accepted-gap aging (Critical): Confirm no Critical-tier gap has exceeded 60 days without a documented escalation record. - % Critical-tier with Art. 26 checklist: Verify the Art. 26 appendix is complete and contains verifiable evidence (not assertions) in every Critical-tier REM. - % IR findings triggering REM re-review: Confirm the IR-to-REM feedback loop is operational; IR findings are not closed until the REM row reflects the current state.

Evidence Location: __ Validation Date: __ Notes: ___

Question 6: REM auto-revalidation cadence and IR feedback loop

Q6.1: Are Critical-tier REMs re-validated against observed reality at least quarterly and High-tier at least semi-annually, with validation deltas routed to IM-Infrastructure as findings and the IR-Infrastructure feedback loop ensuring that IR findings update REM rows within 5 business days?

Evidence Required: - [ ] REM validation log exists and shows at least one completed validation run for every Critical-tier asset in the last 90 days using observable reality checks (IAM audit, GPU isolation conformance test, signed-image admission-controller query, SIEM completeness metric, kill-switch test) - [ ] Validation method documented: stratified sample of at least one row per base category (identity/workload-identity, isolation, encryption, region/residency, observability, patch/image, quotas/abuse, backup/RTO-RPO, failure-mode, disclosure) per asset - [ ] Validation deltas are routed to IM-Infrastructure as findings with severity tags and remediation SLAs matching the asset's tier - [ ] Accepted-gaps register shows no Critical-tier gap past 60 days without a documented escalation record naming the program sponsor - [ ] IR-Infrastructure feedback loop is operating: every IR finding for a requirement covered by the pack generates a REM row re-review flag; the finding is not closed until the REM row reflects the current state - [ ] REM-population status per asset reflects the last validation date and outcome for each Critical/High-tier asset - [ ] Pack-version control records any requirement amendments triggered by validation findings

Metric Collection Guidance: - % Critical-tier REMs re-validated: Pull REM validation log; confirm re-validation runs use observable-reality checks (not self-report). Formula: validated Critical-tier assets / total Critical-tier assets × 100. - Accepted-gap aging (Critical): Spot-check any gap older than 60 days for an escalation record; zero exceptions without documented escalation. - Validation delta routing: Confirm IM-Infrastructure backlog contains findings from REM validation deltas in the last 90 days; findings reference the specific REM row and asset. - IR feedback loop: Confirm the % of IR findings with a linked REM row re-review flag within 5 business days; findings not closed until REM row reflects current state. - Art. 26 checklist: Confirm checklist evidence is current and not a legacy document predating the current infrastructure configuration.

Evidence Location: __ Validation Date: __ Notes: ___

Maturity Level 3

Objective: Express the AI/HAI Infrastructure Requirements Pack as a machine-readable artifact, automate REM-evidence validation from IaC attestation and runtime signals, and contribute to industry-standard AI infrastructure security requirements bodies.

Question 7: Machine-readable pack and IaC attestation at deploy

Q7.1: Is the AI/HAI Infrastructure Requirements Pack expressed in a machine-readable schema (JSON or YAML), and do Critical-tier infrastructure IaC deploys fail the pipeline gate when a REM requirement check fails, with Infrastructure REM attestations consumable by Software-domain CI/CD gates?

Evidence Required: - [ ] Machine-readable requirements pack published (JSON or YAML schema); each requirement has: ID, machine-readable evidence type (iac-config-check / log-query / test-result-reference / runtime-signal / manual-attestation), acceptance predicate, and tier applicability field - [ ] IaC deploy pipeline for Critical-tier assets includes automated REM checks: workload-identity-only access confirmed via IAM audit; signed-image policy confirmed via admission-controller configuration; SIEM forwarding confirmed via log-completeness signal; GPU isolation confirmed via scheduler-policy configuration; kill-switch mechanism confirmed via test result within defined age - [ ] Failed REM check blocks the IaC deploy for Critical-tier assets; evidence of at least one blocked deploy or a test of the block is on file - [ ] Infrastructure REM attestations are published as machine-readable artifacts that Software-domain CI/CD pipelines can reference; a Software artifact's CI/CD gate can verify that its hosting cluster's Infrastructure REM is currently passing before the software deploy proceeds - [ ] Passed REM checks write a signed attestation to the REM record; attestation log is queryable - [ ] Pack published under a permissive license with external adoption tracking (forks, citations, downloads logged) - [ ] Pack-version control aligns the public version with the internal version; no version lag exceeding one quarter

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % Critical-tier REM requirements with automated IaC attestation at deploy time | measure | % | ≥80% | ☐ | IaC pipeline attestation log | | % REM evidence rows auto-validated (vs. manual-only) | measure | % | ≥70% | ☐ | Validation telemetry | | IaC deploy blocks triggered by failed Critical-tier REM check | measure | ___ | tracked; zero silent failures | ☐ | Pipeline telemetry | | % Software-domain CI/CD gates referencing Infrastructure REM attestation | measure | ___% | ≥70% of Critical/High Software artifacts | ☐ | Cross-domain pipeline telemetry | | Industry-standard contributions per year | 0 | ___ | ≥2 | ☐ | Contribution log |

Metric Collection Guidance: - % Critical-tier requirements with IaC attestation: Count Critical-tier REM requirement rows with an automated IaC check vs. total Critical-tier requirement rows. Formula: automated Critical-tier rows / total Critical-tier rows × 100. - % REM rows auto-validated: Count all REM rows where the last validation was performed by an automated check vs. total rows. Formula: auto-validated rows / total rows × 100. - IaC deploy blocks: Count blocked IaC deploys in the last 90 days where the block was triggered by a failed Critical-tier REM check; confirm zero silent failures. - % Software CI/CD gates referencing Infrastructure REM attestation: Query CI/CD pipeline definitions for Critical/High Software artifacts; count those that include a step verifying the hosting cluster's Infrastructure REM attestation. Formula: Software CI/CD gates with Infra REM check / total Critical/High Software pipelines × 100. - Industry-standard contributions: Count substantive contributions to CNCF AI / OpenSSF AI / NIST AI RMF Playbook / ISO AI security standards work in the last 12 months.

Evidence Location: __ Validation Date: __ Notes: ___

Question 8: Automated REM-evidence validation from runtime signals

Q8.1: Are ≥70% of REM evidence rows auto-validated via IaC, runtime monitoring (ML-Infrastructure), and SIEM signal ingestion, with ≥70% of Critical/High Software-domain CI/CD gates referencing the Infrastructure REM attestation, and automation error-rate monitored?

Evidence Required: - [ ] REM validation pipeline is subscribed to ML-Infrastructure monitoring outputs (log-completeness signal, GPU isolation conformance signal, rate-limit enforcement signal) and routes failures to the correct REM rows - [ ] IM-Infrastructure incident records feed the REM validation pipeline: post-incident reviews touching a pack requirement auto-flag the relevant REM rows for re-validation - [ ] SM inventory change events (tier upgrade) auto-trigger a full REM re-validation run under the new tier's requirements depth - [ ] Software-domain CI/CD gates for Critical/High Software artifacts include a step that references the Infrastructure REM attestation and verifies it is currently passing (not a static historical link) - [ ] Automation error-rate (false-positive and false-negative gate failures) is monitored; a defined threshold triggers human review of the affected check - [ ] Human review queue is bounded: only novel clauses, edge-case N/A justifications, and accepted-gap escalations remain for manual handling - [ ] REM-population status per asset reflects auto-validated rows separately from manual-attestation rows

Metric Collection Guidance: - % auto-validated rows: Pull validation telemetry; count rows with an auto-validation result in the last 90 days vs. total active REM rows. Confirm the 70% target is met. - % Software CI/CD gates referencing Infrastructure REM attestation: Confirm the gates are checking the current attestation state, not a historical snapshot. - Automation error-rate: Query the pipeline's false-positive and false-negative logs; threshold for human review should be documented. - IaC gate: Confirm the pipeline is still enforcing the gate from Q7; zero silent failures. - ML-Infrastructure signal subscription: Verify the REM pipeline received and processed at least one log-completeness or GPU isolation conformance signal in the 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 automated REM-evidence validation from runtime signals)

Evidence Location: __ Validation Date: __ Notes: ___

Question 9: Standards contribution

Q9.1: Has the program contributed at least two substantive artifacts per year to recognized standards bodies, with contributions publicly documented and traceable to adoption in CNCF AI, OpenSSF AI, NIST AI RMF Playbook, or ISO AI security standards successor work?

Evidence Required: - [ ] Contribution log lists at least 2 substantive contributions in the last 12 months with: body name, contribution type, submission date, and a link or reference to the external artifact - [ ] Contributions are legally vetted (internal legal review record on file) and anonymized or attributed per the org's disclosure policy - [ ] At least one contribution is a machine-readable artifact (IaC attestation framework, Kubernetes AI workload isolation requirements, machine-readable requirement schema, or equivalent) - [ ] External adoption is tracked: at least one contribution has a confirmed path to adoption - [ ] Pack and REM schema published under a permissive license with version aligned to the internal version; no version lag exceeding one quarter - [ ] CNCF AI and/or OpenSSF AI working group engagement is documented with meeting participation or contribution submission records - [ ] Contribution pipeline has ≥2 contributions in-flight at any given time

Metric Collection Guidance: - Industry-standard contributions: Count contributions in the last 12 months in the contribution log; confirm each has a body name, submission date, and external reference link. Minimum 2 to meet target. - Pack adoption: Confirm external telemetry shows an upward trend in forks, citations, or downloads. - Contribution pipeline health: Confirm ≥2 contributions are actively in-flight. - Version alignment: Check that the public pack version tag matches the current internal version tag. - L3 automation goals: Confirm the IaC attestation and auto-validation goals from Q7 and Q8 remain met.

Evidence Location: __ Validation Date: __ Notes: ___

Summary Scorecard

Question	Activity	Score
Q1	L1-A: Base infrastructure requirements pack	☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0
Q2	L1-B: Per-archetype deltas	☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0
Q3	L1-C: SM intake gate + REM per asset + cross-domain linkage	☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0
Q4	L2-A: Quantitative and binary pack	☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0
Q5	L2-B: Per-tier requirement depth	☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0
Q6	L2-C: REM auto-revalidation + IR feedback loop	☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0
Q7	L3-A: Machine-readable pack + IaC attestation	☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0
Q8	L3-B: Automated REM-evidence from runtime signals	☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0
Q9	L3-C: Standards contribution	☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0
Total		___ / 9.0

Achieved Maturity Level: ☐ Not Started / ☐ Level 1 / ☐ Level 2 / ☐ Level 3

Document Version: HAIAMM v3.0 Practice: Security Requirements (SR) 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