Strategy & Metrics (SM) - Infrastructure Domain

HAIAMM Assessment Questionnaire v3.5

Generated from cells/SM-Infrastructure-L*.cell.json. Do not edit by hand. Canonical model: HAIAMM-v3.5-Framing.md · Handbook: HAIAMM-v3.5-Handbook.md.

---

Practice: Strategy & Metrics (SM) Domain: Infrastructure Business Function: Governance Purpose: Stand up AI infrastructure assurance, inventory every place models are served, stored and trained, and baseline the metrics that prove shadow AI infrastructure is shrinking. Scoring Model: Evidence + Outcome Metrics (see Scoring Methodology below)

---

Instructions

• Answer from current, implemented practice, not plans or aspirations.
• Each question has two components: Evidence (what you did) and Outcome Metrics (how well it worked).
• Levels are derived, never self-assigned. Record evidence and metric values; the level falls out of the scoring below.
• Silence is not a pass. A metric you cannot produce is left blank and counts as not met. Do not estimate.
• Answer progressively. Complete all Level 1 questions before Level 2.

Evidence grade

Record how each answer is known, not only what is claimed (v3.5 framing §6). A level claim is graded at its weakest field.

Grade	Meaning
E0	Asserted by a practitioner, unevidenced
E1	Asserted, with a link to a named artifact
E2	Emitted by a system as telemetry
E3	Machine-attested and independently checkable

---

Scoring Methodology

Tier	Score	Criteria
Fully Mature	1.0	Evidence complete + ≥3 outcome metrics meet targets
Implemented	0.67	Evidence complete + 2 outcome metrics meet targets
Partial	0.33	Evidence partially complete + <2 outcome metrics meet targets
Not Implemented	0.0	No substantive evidence of practice

Practice maturity level achieved = the highest level where all 3 questions score ≥ 0.67.

---

Maturity Level 1, Foundational

Objective: Stand up AI infrastructure assurance, inventory every place models are served, stored and trained, and baseline the metrics that prove shadow AI infrastructure is shrinking.

Question L1.1: Charter AI infrastructure assurance with FinOps at the table

Q1.1: Is there a published AI infrastructure assurance charter jointly sponsored by the CISO and the infrastructure leader, with FinOps as a standing working-group member and explicit decision rights over provisioning accelerator capacity, registering models and exposing inference endpoints?

Evidence Required:

• [ ] Publish a charter within the first 30 days, sponsored by the CISO jointly with the VP Infrastructure or Head of Platform Engineering
• [ ] Name the seven in-scope archetypes, being inference endpoint, model registry, GPU or accelerator fleet, orchestrator and control plane, vector-store infrastructure, AI-specific CI/CD, and feature store
• [ ] Seat FinOps on the working group as a standing member alongside Platform and SRE, Cloud Architecture, ML Platform, AI/ML engineering and Privacy counsel, because in this domain cost allocation is not a reporting convenience but the primary discovery instrument
• [ ] An untagged accelerator reservation is both a FinOps problem and a security finding, and separating those conversations means neither side sees the whole signal
• [ ] Define decision rights over who may provision accelerator capacity, who may register and promote a model, who may expose an inference endpoint beyond the cluster boundary, and who can revoke any of the three
• [ ] Commit to a numeric year-one target per outcome metric

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

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)

Evidence Location: _________________________________

Notes: ___________________________________________

Question L1.2: Inventory the estate and read the cost signal for shadow infrastructure

Q1.2: Does one inventory cover all seven infrastructure archetypes, reconciled monthly against cloud cost-allocation data, scheduler telemetry, network egress and registry records, reaching 90% coverage or better of discovered assets within 12 months?

Evidence Required:

• [ ] Build one AI infrastructure inventory recording per asset the archetype, owning team, environment, region and residency, accelerator class and quantity, the models served or stored, network exposure, identity and access model, and links to the SA reference pattern and EH hardening baseline it claims to follow
• [ ] Seed from cloud asset inventories, Kubernetes and orchestrator APIs, model registries and infrastructure-as-code state
• [ ] Then run the domain's shadow-AI mechanism monthly across four signals: cloud cost-allocation data filtered to accelerator instance types, managed inference services and AI platform products, where unexplained spend or an untagged cost centre is a shadow-infrastructure candidate
• [ ] Scheduler and cluster telemetry showing accelerator workloads whose namespace maps to no chartered team
• [ ] Network egress revealing self-hosted inference endpoints reachable from outside their intended boundary
• [ ] And registry reconciliation revealing models served from artifacts that were never registered
• [ ] Cost is the highest-yield of the four and the cheapest to read, because it requires no new agent anywhere

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

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)

Evidence Location: _________________________________

Notes: ___________________________________________

Question L1.3: Baseline the infrastructure scoreboard and open the capacity ledger

Q1.3: Do all production AI infrastructure assets carry an owning team and cost-allocation tag, does model provenance trace to a registry entry for at least 95% of serving endpoints, and is a capacity ledger open reporting utilisation alongside denominated cost?

Evidence Required:

• [ ] Instrument and report quarterly to the sponsor: inventory coverage against discovery reconciliation, the shadow-infrastructure ratio, the share of serving endpoints whose model provenance traces to a registry entry, the share of assets carrying an owning team and a cost-allocation tag, and provider and region concentration
• [ ] Open the capacity ledger recording accelerator-hours and inference cost attributed to owning team and workload, with the denominator declared per archetype, being cost per thousand inference requests for serving and cost per served model-hour for fleet capacity
• [ ] Report utilisation alongside cost, because an idle reserved fleet and a saturated one cost similarly and mean opposite things
• [ ] Where accelerator spend is not allocated to an owning team, record the ledger as blocked on allocation and raise the tagging standard with FinOps rather than estimating, since in this domain an unallocated bill is precisely the shadow-infrastructure signal being lost

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

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)

Evidence Location: _________________________________

Notes: ___________________________________________

Level 1 Outcome Metrics

Metric	Baseline	Current	Target	Met?	Notes
AI infrastructure inventory coverage against discovery reconciliation	___	___	≥90% within 12 months	☐
Shadow-infrastructure ratio (unsanctioned AI assets ÷ total AI assets)	___	___	≤10% and falling for two consecutive quarters	☐
Serving endpoints whose model provenance traces to a registry entry	___	___	≥95%	☐
AI infrastructure assets carrying an owning team and a cost-allocation tag	___	___	100% of production assets	☐
Provider and accelerator-class concentration for production inference	___	___	documented with a named single-point-of-failure list and a stated risk acceptance	☐

Where each number is read from:

• AI infrastructure inventory coverage against discovery reconciliation — Inventory reconciled against cloud asset APIs, orchestrator APIs and registries
• Shadow-infrastructure ratio (unsanctioned AI assets ÷ total AI assets) — Inventory status field reconciled with cost and scheduler telemetry
• Serving endpoints whose model provenance traces to a registry entry — Model registry reconciled against serving configuration; where no registry exists, the deployment manifest of each serving host, recorded at E1
• AI infrastructure assets carrying an owning team and a cost-allocation tag — Cloud tagging compliance report joined to inventory
• Provider and accelerator-class concentration for production inference — Inventory provider and accelerator-class fields

Level 1 Consumption Metrics

Absolute spend is a ledger input, never a metric. Every row is divided by a unit of business work. If AI spend is not allocated to an owning team, record this level as blocked on allocation rather than scoring it down (v3.5 framing §12).

Metric	Denominator	Current	Economic failure it detects	Met?
Inference cost per thousand requests, by serving endpoint	per 1k inference requests	___	denial-of-wallet at the serving layer, where request volume drains budget without degrading availability, and inefficient serving configurations that only show up when normalised by request count	☐
Accelerator cost per served model-hour, with utilisation reported alongside	per served model-hour	___	idle reserved capacity and shadow GPU workloads, which are indistinguishable from legitimate demand on an absolute spend line but obvious once divided by delivered model-hours	☐
Unallocated AI infrastructure spend as a share of the ledger	per dollar of AI infrastructure consumption	___	shadow infrastructure hiding in untagged cost centres, which is simultaneously an allocation gap and the domain's single most reliable discovery signal	☐

Level 1 30-second check (E0)

• ☐ Yes ☐ No — Do you know every place a model is being served in your environment?
• ☐ Yes ☐ No — Would an unexplained GPU spend spike reach a security person?
• ☐ Yes ☐ No — Can every production inference endpoint be traced to a registered model?

---

Maturity Level 2, Comprehensive

Objective: Tier the AI infrastructure estate by exposure and criticality, calibrate hardening and monitoring intensity per tier, and bound accelerator and inference consumption.

Prerequisite cells: SM-Infrastructure-L1, PC-Infrastructure-L1, TA-Infrastructure-L1

Question L2.1: Publish the infrastructure risk-tier rubric

Q2.1: Is every production AI infrastructure asset assigned a tier from a published rubric covering network exposure, data sensitivity in flight, served-workload criticality, concentration and blast radius, re-derived automatically when exposure changes?

Evidence Required:

• [ ] Derive four tiers from five auditable dimensions
• [ ] Network exposure is the strongest: an inference endpoint reachable from the public internet is Critical or High regardless of what it serves, because reachability is what converts every other weakness into an incident
• [ ] Data sensitivity in flight elevates where regulated or customer-confidential content passes through the asset at inference or training
• [ ] Criticality of the served workload elevates where the asset is on a revenue path, a customer-onboarding flow or an authentication decision
• [ ] Concentration elevates where the asset is the single point of failure for a production AI capability, or where a provider, region or accelerator class carries a disproportionate share of production inference
• [ ] Blast radius elevates where a compromise reaches beyond the asset, which applies particularly to orchestrators and control planes whose credentials command the fleet
• [ ] Publish the rubric with its derivation rule and re-derive automatically when exposure or served-workload fields change, since infrastructure exposure changes faster than infrastructure inventory does

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

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)

Evidence Location: _________________________________

Notes: ___________________________________________

Question L2.2: Calibrate hardening intensity and consumption limits per tier

Q2.2: Is there a published tier-treatment matrix covering tenancy and isolation, identity model, egress control, secrets, hardening baseline, monitoring and testing, with at least 95% of Critical-tier assets conforming to their hardening baseline and drift remediated inside the tier window?

Evidence Required:

• [ ] Publish a tier-treatment matrix covering, per tier: tenancy and isolation model from shared to dedicated
• [ ] Identity model, moving toward no standing human access on Critical-tier fleets with time-bound elevation
• [ ] Egress control from monitored to explicit allowlist
• [ ] Secrets management and rotation cadence
• [ ] Hardening baseline and its drift-detection cadence
• [ ] Monitoring detections and log completeness
• [ ] And re-review triggers on material change
• [ ] Add the consumption row that this domain needs more than any other: Critical- and High-tier inference endpoints carry per-tenant request rate limits and spend limits with a declared behaviour at the limit, being shed, queue or refuse, and never silently continue
• [ ] Denial-of-wallet at the serving layer is invisible to availability monitoring by construction, so the limit is the control and its at-cap behaviour must be tested like any other boundary
• [ ] Treat a capacity change, a model swap, a region change or a retention reduction on a Critical-tier asset as a material change triggering re-review, including when the motivation was cost

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

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)

Evidence Location: _________________________________

Notes: ___________________________________________

Question L2.3: Report per tier and manage concentration explicitly

Q2.3: Do all Critical-tier inference endpoints carry per-tenant request and spend limits with tested at-cap behaviour, and is there a sponsor-signed concentration statement recording an explicit accept, mitigate or migrate decision for each single point of failure?

Evidence Required:

• [ ] Report the scoreboard per tier and archetype quarterly
• [ ] Cover inventory and tier state, shadow-infrastructure ratio per tier, tagging and provenance conformance, hardening-baseline drift, per-tier service-level adherence, and the Assured Spend Ratio for accelerator and inference consumption per tier with full attribution targeted at Critical
• [ ] Produce a standing concentration statement naming, for production inference, the share carried by each provider, each region and each accelerator class, together with the single points of failure that follow and an explicit decision to accept, mitigate or migrate each one, signed by the sponsor
• [ ] Concentration in this domain is usually the result of accumulated convenience rather than a decision anyone made, and writing it down is what converts it into a governed position
• [ ] Maintain a tier-movement log recording the triggering dimension for each change, and review it quarterly

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

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)

Evidence Location: _________________________________

Notes: ___________________________________________

Level 2 Outcome Metrics

Metric	Baseline	Current	Target	Met?	Notes
AI infrastructure assets carrying a current tier assignment	___	___	100% of production assets, with tier age under 6 months	☐
Critical-tier assets conforming to the tier hardening baseline	___	___	≥95%, with drift remediated inside the tier window	☐
Critical- and High-tier inference endpoints with request and spend limits and tested at-cap behaviour	___	___	100% of Critical, ≥90% of High	☐
Standing human access to Critical-tier accelerator fleets and control planes	___	___	0 standing human identities, with time-bound elevation only	☐
Per-tier service-level adherence across hardening, monitoring, testing and issue management	___	___	≥90% per tier	☐
Assured Spend Ratio for accelerator and inference consumption at Critical tier	___	___	100% of Critical-tier consumption attributed	☐

Where each number is read from:

• AI infrastructure assets carrying a current tier assignment — Inventory tier field
• Critical-tier assets conforming to the tier hardening baseline — Configuration drift detection against the hardening baseline
• Critical- and High-tier inference endpoints with request and spend limits and tested at-cap behaviour — Gateway limit configuration reconciled against inventory tier; where no AI gateway is deployed, provider-side usage and limit configuration read per provider account, recorded at E1
• Standing human access to Critical-tier accelerator fleets and control planes — Cloud IAM and cluster RBAC review
• Per-tier service-level adherence across hardening, monitoring, testing and issue management — Program telemetry from each practice's log
• Assured Spend Ratio for accelerator and inference consumption at Critical tier — Capacity ledger joined to inventory tier

Level 2 Consumption Metrics

Absolute spend is a ledger input, never a metric. Every row is divided by a unit of business work. If AI spend is not allocated to an owning team, record this level as blocked on allocation rather than scoring it down (v3.5 framing §12).

Metric	Denominator	Current	Economic failure it detects	Met?
Inference cost per thousand requests at Critical tier against the endpoint's rolling median	per 1k inference requests	___	denial-of-wallet at the serving layer, which drains budget while uptime, latency and error rate all stay green and therefore trips no conventional alarm	☐
Spend-limit breach rate and at-cap behaviour conformance per tier	per endpoint-quarter	___	limits that are configured but silently continue past the cap, which is functionally equivalent to having no limit at all	☐
Accelerator cost per served model-hour by tier, with utilisation	per served model-hour	___	capacity concentration and idle reservation at high tiers, where the cost of resilience is paid without the resilience being verified	☐

Level 2 30-second check (E0)

• ☐ Yes ☐ No — Does every AI infrastructure asset carry a risk tier?
• ☐ Yes ☐ No — Is there a spend limit on your most exposed inference endpoint?
• ☐ Yes ☐ No — Does anyone hold standing admin access to your GPU fleet?

---

Maturity Level 3, Industry-Leading

Objective: Drive infrastructure inventory and tiering from live cloud and orchestrator signals, benchmark serving unit economics externally, and contribute infrastructure assurance patterns back.

Prerequisite cells: SM-Infrastructure-L2, ML-Infrastructure-L2, EG-Infrastructure-L2

Question L3.1: Automate inventory, tier and provenance from live signals

Q3.1: Do inventory, tier and provenance auto-update from cloud asset, orchestrator admission, registry, infrastructure-as-code and billing events against a published objective of tier correctness within 24 hours of an exposure change, with at least 85% of curation automated?

Evidence Required:

• [ ] Derive the estate picture from the control planes that already emit it: cloud asset and configuration events for creation, modification and deletion of AI infrastructure
• [ ] Orchestrator admission telemetry for workloads requesting accelerators
• [ ] Model-registry events for registration, promotion and deprecation
• [ ] Infrastructure-as-code state changes
• [ ] Network exposure changes from security-group and ingress events
• [ ] And provider billing feeds for cost attribution and new-tag appearance
• [ ] Implement tier derivation as a versioned, replayable rule set over the L2 dimensions, and wire tier changes to open downstream obligations automatically so that an endpoint newly exposed to the internet triggers its hardening, monitoring and testing obligations without waiting on a human to notice the security-group change
• [ ] Publish a data-quality service-level objective covering tier correctness within 24 hours of an exposure change, which is tighter than the other domains warrant because infrastructure exposure changes in seconds and its consequences are immediate
• [ ] Reserve human curation for novel archetypes, ambiguous ownership and conflicting dimensional inputs

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

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)

Evidence Location: _________________________________

Notes: ___________________________________________

Question L3.2: Benchmark serving unit economics and hardening posture externally

Q3.2: Does the semi-annual benchmarking brief compare at least five peer-comparable metrics including inference cost per thousand requests and accelerator cost per served model-hour, reporting control coverage alongside cost so efficiency cannot be confused with removed controls?

Evidence Required:

• [ ] Publish a semi-annual brief comparing the program against named peers on at least five metrics: inventory coverage and freshness, shadow-infrastructure ratio, hardening-baseline conformance, inference cost per thousand requests by serving archetype, and accelerator cost per served model-hour with utilisation
• [ ] Unit economics carry particular weight in this domain because serving configurations are optimised continuously and rarely re-reviewed
• [ ] A cost per thousand requests well below the peer median may indicate efficient batching, or it may indicate that per-request authorization, logging and content filtering were removed to hit a savings target
• [ ] Report cost and control coverage together so that the comparison cannot be read as a pure efficiency ranking
• [ ] Draw from CNCF AI and ML working groups, OpenSSF AI supply-chain work, the FinOps Foundation AI scope, sector information-sharing bodies and ML-platform community forums
• [ ] Name the peer cohort and record where the program trails

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

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)

Evidence Location: _________________________________

Notes: ___________________________________________

Question L3.3: Publish hardened patterns and compute the domain return

Q3.3: Does the program contribute at least four externally accepted infrastructure assurance artifacts per year weighted toward executable modules, and is the domain return computed from capacity-ledger arithmetic covering contained denial-of-wallet, reclaimed idle reservation and avoided overage?

Evidence Required:

• [ ] Contribute at least four substantive artifacts per year, weighted toward executable rather than descriptive ones: hardened infrastructure-as-code modules for inference serving, registry and vector-store deployment published through OpenSSF AI or CNCF
• [ ] Accelerator-fleet identity and isolation patterns
• [ ] Provenance-verification tooling for registry-to-serving reconciliation
• [ ] Observed infrastructure-layer techniques submitted to MITRE ATLAS
• [ ] And FinOps Foundation AI-scope contributions on capacity governance and concentration risk
• [ ] Count only what external bodies accept
• [ ] Compute the domain return from the capacity ledger: contained denial-of-wallet events valued at burn rate multiplied by time to detect
• [ ] Reclaimed idle reservation, which is usually the largest single component and the easiest to verify
• [ ] Avoided commitment overage under governed capacity planning
• [ ] And capacity reclaimed by retiring endpoints serving no traffic
• [ ] Reconcile with Finance annually and publish alongside the Assurance Cost Ratio for the domain

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

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)

Evidence Location: _________________________________

Notes: ___________________________________________

Level 3 Outcome Metrics

Metric	Baseline	Current	Target	Met?	Notes
Inventory and tier auto-update latency after an exposure change	___	___	≤24 hours at the 99th percentile	☐
Inventory entries auto-curated rather than human-curated	___	___	≥85% auto-curated	☐
Model provenance verified automatically from registry to running serving configuration	___	___	≥99% of production endpoints, verified continuously	☐
Peer-comparable metrics in the semi-annual brief, reported with control coverage alongside cost	___	___	≥5 metrics with a named and defended peer cohort	☐
Externally accepted infrastructure assurance contributions per year	___	___	≥4 accepted, weighted toward executable artifacts	☐

Where each number is read from:

• Inventory and tier auto-update latency after an exposure change — Cloud and orchestrator event pipeline telemetry
• Inventory entries auto-curated rather than human-curated — Curation telemetry from the inventory pipeline
• Model provenance verified automatically from registry to running serving configuration — Continuous registry-to-serving reconciliation job
• Peer-comparable metrics in the semi-annual brief, reported with control coverage alongside cost — Published benchmarking brief
• Externally accepted infrastructure assurance contributions per year — Contribution log with external acceptance references

Level 3 Consumption Metrics

Absolute spend is a ledger input, never a metric. Every row is divided by a unit of business work. If AI spend is not allocated to an owning team, record this level as blocked on allocation rather than scoring it down (v3.5 framing §12).

Metric	Denominator	Current	Economic failure it detects	Met?
Inference cost per thousand requests benchmarked against the peer cohort, reported with control coverage	per 1k inference requests	___	a cost advantage that reflects removed authorization, logging or filtering rather than efficient serving, which a cost-only comparison actively rewards	☐
Reclaimed idle accelerator reservation	per served model-hour	___	reserved capacity paid for and never delivered against, which is the largest and most verifiable component of this domain's return and is invisible on an absolute spend line	☐
Contained denial-of-wallet value: burn rate multiplied by time to detect	per contained event	___	serving-layer budget drain running long because no availability signal degrades, making detection time the whole of the loss	☐

Level 3 30-second check (E0)

• ☐ Yes ☐ No — Does your AI infrastructure inventory update itself from cloud events?
• ☐ Yes ☐ No — Do you know how your inference cost per thousand requests compares with peers?
• ☐ Yes ☐ No — Have you published a hardened AI infrastructure pattern externally this year?

---

Summary Scorecard

Level	Q1	Q2	Q3	Level score	Weakest evidence grade	Achieved?
L1	___	___	___	___	___	☐
L2	___	___	___	___	___	☐
L3	___	___	___	___	___	☐

Strategy & Metrics (SM) maturity in the Infrastructure domain: ____________

---

Document Version: HAIAMM v3.5 (generated)