Environment Hardening (EH) - Software Assessment

Assessment questionnaire for measuring maturity. Answer each question honestly based on current, implemented practices.

v3.0 questionnaire. Source of truth: ../practices/EH-Software-OnePager.md. Canonical subject and through-lines: ../HAIAMM-v3.0-Framing.md §8.

Environment Hardening (EH) - Software Domain

HAIAMM Assessment Questionnaire v3.0

Practice: Environment Hardening (EH) Domain: Software Purpose: Assess organizational maturity in hardening the compute/runtime, build-time, model-supply-chain, engineering-endpoint, and data-flow envelopes for AI/HAI software the organization builds

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

Each question is scored on a 4-tier scale:

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 control

Level Score = Average of question scores within the level Overall Score = Weighted average across levels (L1: 50%, L2: 30%, L3: 20%)

Maturity Level 1

Objective: Harden the compute/runtime, build-time, model-supply-chain, engineering-endpoint, and data-flow envelopes for all AI/HAI software the organization builds, so each artifact runs in a least-privilege, observable perimeter and AI-specific exfiltration paths are controlled.

Question 1: Compute/Runtime Envelope Hardening

Q1.1: Does every AI/HAI software artifact in production run under a named, dedicated, least-privilege service account, with LLM provider API keys in a secrets vault and an explicit egress allowlist scoped to declared provider and model registry domains?

Evidence Required: - [ ] Per-artifact service account (IAM role, Kubernetes service account, Workload Identity, or equivalent) confirmed for every artifact in the SM inventory, no shared credentials - [ ] Secrets vault configuration records showing all LLM provider API keys (OpenAI, Anthropic, Bedrock, Vertex, HuggingFace tokens) stored in vault with zero hardcoded instances confirmed by CI secrets-scan - [ ] Egress allowlist policies for each artifact's service account or network namespace, explicit allow to declared LLM provider and model registry domains only - [ ] CI secrets-scanning configuration showing the check runs as a blocking gate on every PR and main-branch commit - [ ] Per-tenant isolation enforcement records for multi-tenant artifacts, namespace or vector-store partitioning per tenant - [ ] Runtime resource limit configuration (GPU/CPU/memory quotas) per workload namespace

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % AI/HAI software artifacts in production with a named, dedicated service account (not shared) | % | % | 100% | ☐ | | | % LLM provider API keys managed via secrets vault (CI secrets-scan with zero findings) | % | % | 100% | ☐ | | | Egress allowlist coverage, % AI/HAI service accounts with explicit egress allowlist for LLM provider and model registry domains | % | % | ≥90% | ☐ | | | Unsanctioned AI egress alerts generated and routed to SM inventory per quarter | ___ | ___ | tracked; ≥1 signal per incident | ☐ | |

Metric Collection Guidance: - Service account coverage: Reconcile SM-Software inventory against IAM audit; count artifacts with a named, dedicated service account. Formula: dedicated_accounts / total_artifacts × 100 - Secrets vault coverage: Run CI secrets-scan report across all repos; count LLM provider API key patterns found. Zero findings = 100%. Source: CI scan telemetry - Egress allowlist coverage: Audit network policies or SASE rules against SM inventory; count service accounts with an explicit allowlist. Source: network/IAM policy audit - Unsanctioned egress alerts: Count alert events where an unregistered service initiates outbound calls to AI provider domains. Source: egress alert telemetry

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 runtime envelope hardening)

Evidence Location: __ Validation Date: __ Notes: ___

Question 2: Build-Time and Model-Supply-Chain Envelope Hardening

Q1.2: Are build artifacts signed at build time, do model artifacts carry SLSA-style provenance attestations at registry promotion, and are AI SDK dependencies version-pinned with SCA scanning running in CI?

Evidence Required: - [ ] Signed-build configuration records (Sigstore/cosign, Notary v2, or equivalent) and deployment gate policy that rejects unsigned artifacts - [ ] SLSA-style provenance attestation records for model artifacts in the registry, training data source, job identity, eval result reference, build system identity - [ ] Model registry policy configuration blocking promotion of any artifact without a signed provenance attestation for Critical/High-tier - [ ] AI SDK dependency pinning evidence, version-pinned entries for openai, anthropic, langchain, transformers, vllm, etc. in all manifest files - [ ] SCA tool CI configuration (Dependabot, Snyk, OWASP Dependency-Check, or equivalent) running on every build with blocking on critical findings for Critical/High-tier - [ ] CI secrets-scanning configuration for AI SDK supply-chain patterns (HuggingFace tokens, model-registry credentials) as blocking PR checks

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % model registry promotions with a signed provenance attestation (Critical/High-tier) | % | % | 100% for Critical/High-tier | ☐ | | | % AI SDK dependencies version-pinned across all manifest files | % | % | 100% | ☐ | | | Open critical SCA findings for Critical/High-tier artifacts resolved within 7 days | % | % | 100% resolved within SLA | ☐ | | | Unsigned artifact deployment-gate rejections per month (policy enforcement confirmed) | ___ | ___ | tracked; blocking enforced | ☐ | |

Metric Collection Guidance: - Provenance attestation coverage: Query model registry API for promotion events; count those with a valid signed attestation. Source: model registry telemetry - Dependency pinning coverage: Scan manifest files for version-pinned vs. unpinned entries for AI SDK packages. Source: repo audit tooling - SCA resolution SLA: Count critical SCA findings per artifact; measure time from detection to resolved. Source: SCA tool / ticketing system - Gate rejections: Count deployment admission controller rejections attributed to unsigned artifacts. Source: admission controller logs

Evidence Location: __ Validation Date: __ Notes: ___

Question 3: Engineering-Endpoint and Data-Flow Envelope Hardening

Q1.3: Are SSO + MFA enforced on model registry and LLM provider consoles, DLP rules tuned for AI-specific exfiltration patterns deployed on engineering endpoints, and a PII redaction layer active on prompt/completion logging pipelines for artifacts processing regulated data?

Evidence Required: - [ ] IdP configuration records showing SSO/SAML/OIDC enforcement on model registry, OpenAI/Anthropic/Bedrock/Vertex AI consoles, CI/CD, and code repositories, local-account access disabled for org-domain identities - [ ] MFA enforcement policy records for all AI/HAI-specific consoles - [ ] DLP rule configuration covering AI-specific exfiltration patterns: bulk embedding exports, prompt/completion bulk exports (CSV/JSON), model-weight exfiltration (.bin, .safetensors, .gguf, .pt, .ckpt), training-dataset exports - [ ] Browser policy configuration restricting engineers from sending work data to unsanctioned consumer LLM services during managed work sessions - [ ] PII redaction layer configuration for prompt/completion logging pipelines, redaction rules, tokenization, or separate regulated-data log tier with stricter access controls - [ ] Privacy/Legal sign-off documentation for any artifact logging regulated data in clear-text

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % AI/HAI-specific consoles (model registry, LLM provider admin, CI/CD) requiring SSO + MFA | % | % | 100% | ☐ | | | DLP rules tuned for AI-specific exfiltration patterns deployed and active on managed engineering endpoints | 0 / set | target set | target set defined + deployed | ☐ | | | % prompt/completion logging pipelines for regulated-data artifacts with PII redaction layer active | % | % | 100% for artifacts processing regulated data | ☐ | | | DLP rule false-positive rate on AI-specific patterns (trend) | % | % | actively tuned; trend documented | ☐ | |

Metric Collection Guidance: - SSO + MFA coverage: Audit IdP configuration for each AI console entry; verify SSO is the only auth path and MFA is enforced. Source: IdP configuration audit - DLP rule deployment: Confirm AI-specific rules are active in DLP management console; count endpoints covered. Source: DLP management console - PII redaction coverage: Audit logging pipeline configurations for each artifact processing regulated data; verify redaction layer is active. Source: pipeline configuration review - DLP false-positive rate: Count false-positive alerts per week from AI-specific DLP rules; track trend over rolling 90 days. Source: alerting telemetry

Evidence Location: __ Validation Date: __ Notes: ___

Maturity Level 2

Objective: Calibrate hardening depth per risk tier using the SM L2 tier-treatment matrix; apply SASE/zero-trust controls for AI access on Critical-tier artifacts; and enforce per-tenant isolation and enhanced DLP at the tier level.

Question 4: Tier-Conditional Hardening Calibration

Q2.1: Is a hardening tier-treatment matrix published and enforced, with Critical-tier artifacts under per-artifact SASE egress rules at the workload-identity level and just-in-time access (≤4-hour time-limited, approval-gated) for model registry write permissions and LLM provider admin consoles?

Evidence Required: - [ ] Published tier-treatment matrix document covering service account depth, egress policy granularity, model registry access, secrets management, VPC/network isolation, DLP depth, prompt/completion logging, and per-tenant isolation per tier (Critical/High/Medium/Low) - [ ] SASE per-artifact egress rule configuration for Critical-tier service accounts, each artifact has its own outbound-traffic policy at the workload-identity level, not a shared per-service allowlist - [ ] JIT access tooling configuration for model registry write/promote permissions, time-limited (≤4h), approval-gated, scoped to specific model artifacts - [ ] JIT access tooling configuration for LLM provider admin consoles (OpenAI org admin, Anthropic console, Bedrock, Vertex AI), no standing billing or API-key management permissions - [ ] SM-Software inventory records showing hardening status per tier for each artifact - [ ] IaC-or-equivalent enforcement at provisioning time gating new artifacts on their tier's required controls

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % Critical-tier artifacts with per-artifact SASE egress rules (not per-service) | % | % | 100% | ☐ | | | % Critical-tier model registry operations using JIT access (no standing write permissions) | % | % | 100% | ☐ | | | % SM-Software inventory artifact records showing hardening status per tier | % | % | 100% | ☐ | | | Tier-hardening gaps identified and tracked as open IM-Software findings | ___ | ___ | 100% gaps tracked as IM findings | ☐ | |

Metric Collection Guidance: - Per-artifact SASE coverage: Compare SASE policy registry against SM inventory for Critical-tier artifacts; count those with individual workload-identity policies. Source: SASE policy registry × SM inventory - JIT access coverage: Query IAM audit log for model registry promote operations; verify all use JIT grants, not standing tokens. Source: IAM audit telemetry - Inventory hardening status coverage: Review SM-Software inventory records; count artifact entries with a populated hardening-status field. Source: SM inventory - Hardening gap tracking: Count tier-hardening gaps opened as IM-Software findings vs. total gaps identified in last audit. Source: IM backlog

Evidence Location: __ Validation Date: __ Notes: ___

Question 5: Zero-Trust AI Access and Enhanced DLP for Critical-Tier

Q2.2: Are Critical-tier artifacts running in a dedicated VPC or private link for inference, with enhanced DLP policies active for content inspection on outbound AI-provider calls from engineering endpoints, including bulk-embedding and model-weight transfer alerts?

Evidence Required: - [ ] Dedicated VPC or private link / VPC endpoint configuration for Critical-tier inference clusters and model registry backends, no public internet egress paths for Critical-tier - [ ] Enhanced DLP policy configuration for Critical-tier artifact development: content inspection on outbound AI-provider calls from engineering endpoints, alert on bulk-embedding export files (.npy, .parquet, float-array formats), model-weight transfer alert on uploads of .bin, .safetensors, .gguf, .pt, .ckpt to external destinations - [ ] SASE content-inspection configuration (where provider terms permit) for bulk-export patterns from Critical-tier artifact service accounts - [ ] Training and fine-tuning pipeline submission enforcement records: submitter identity logged, training-data classification pre-flight check passed, Privacy sign-off reference for regulated data - [ ] False-positive rate monitoring records for AI-specific DLP/egress signals, monthly review cadence with tuning changes logged - [ ] Zero-trust session validation configuration for LLM provider admin access at Critical tier

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % Critical-tier multi-tenant artifacts with infrastructure-layer per-tenant isolation (confirmed by IR review + ST test) | % | % | ≥90% | ☐ | | | Enhanced DLP policies for Critical-tier artifact development deployed and active | 0 / set | target set | target set complete | ☐ | | | False-positive rate on AI-specific DLP/egress-inspection signals | % | % | actively tuned; trending down | ☐ | | | % Critical-tier artifacts with dedicated VPC/private-link for inference (no public egress) | % | % | 100% | ☐ | |

Metric Collection Guidance: - Infrastructure-layer per-tenant isolation: Query IR-Software review findings for Critical-tier multi-tenant artifacts; confirm ST isolation tests pass. Source: IR findings × SA pattern conformance - Enhanced DLP deployment: Verify content-inspection and bulk-transfer alert rules are active in DLP console for Critical-tier engineering endpoints. Source: DLP management console - False-positive rate trend: Count DLP alerts per week tagged as false-positive; compute rate; compare month-over-month. Source: alert telemetry × DLP console - VPC/private-link coverage: Audit cloud network configuration for Critical-tier inference and registry backends; count those with dedicated private endpoints. Source: cloud network policy audit

Evidence Location: __ Validation Date: __ Notes: ___

Question 6: Classification-Label Enforcement in Pipelines

Q2.3: Are classification labels propagated through all ETL, fine-tuning, and inference pipeline stages, with pipeline stages that drop or downgrade classification labels without explicit policy authorization tracked as blocking findings, and is the tier-hardening matrix enforced at provisioning?

Evidence Required: - [ ] Classification-label propagation configuration in data pipelines, labels attached at ingest and carried through ETL, fine-tuning job, and inference pipeline stages - [ ] Pipeline governance policy defining blocking-finding criteria for classification label drops or unauthorized downgrades - [ ] Provisioning-gate configuration that enforces tier hardening controls at artifact registration time, not post-hoc after DR/IR finding - [ ] Per-tenant encryption key configuration for Critical-tier multi-tenant artifacts at the infrastructure layer (dedicated namespace or VPC endpoint or separate encryption key per tenant) - [ ] ST-Software isolation test results for Critical-tier multi-tenant artifacts confirming infrastructure-layer tenant boundary - [ ] Quarterly SASE/IAM policy drift audit records with deviation findings tracked as IM-Software findings within 5 business days

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % data pipelines with classification-label propagation enforced through all stages | % | % | 100% for Critical/High-tier | ☐ | | | Classification-label-drop blocking findings opened and resolved within SLA | /quarter | /quarter | 100% within tier SLA | ☐ | | | % Critical-tier artifacts provisioned with tier-appropriate hardening controls at registration (not retroactively) | % | % | 100% | ☐ | | | SASE/IAM policy drift deviations resolved as IM-Software findings within 5 business days | % | % | 100% | ☐ | |

Metric Collection Guidance: - Label propagation coverage: Audit pipeline DAGs for each Critical/High-tier artifact; verify classification labels are present at each stage output. Source: pipeline configuration review - Label-drop finding SLA: Count blocking findings for classification label drops; measure time from detection to resolution. Source: IM-Software backlog - Provisioning-gate coverage: Compare SM registration events against IaC provisioning telemetry; verify tier controls applied at registration. Source: inventory × provisioning telemetry - SASE/IAM drift resolution: Count SASE/IAM policy drift findings per quarter; measure % resolved within 5 business days. Source: policy change log × IM backlog

Evidence Location: __ Validation Date: __ Notes: ___

Maturity Level 3

Objective: Express all EH controls as IaC modules; implement adaptive policy tightening driven by ML-Software detections and IM-Software incidents; and contribute AI/HAI software hardening baselines to industry bodies.

Question 7: Hardening-as-Code, IaC Modules for All EH Controls

Q3.1: Are all EH-Software controls expressed as version-controlled, authoritative Terraform or Pulumi IaC modules, covering runtime envelope, build-time envelope, model-supply-chain, engineering-endpoint, and data-flow, with drift detection running continuously and ≥70% of low-risk drift auto-remediated?

Evidence Required: - [ ] IaC registry records showing runtime envelope module (service account, least-privilege IAM, egress allowlist, secrets vault path, resource limits) version-controlled and deployed as the authoritative source for each archetype and tier - [ ] Build-time envelope IaC: reusable pipeline components (GitHub Actions composite actions, GitLab CI templates) for secrets scanning, SCA, signed-build configuration, and SLSA provenance, version-controlled - [ ] Model-supply-chain module: model registry access policy, JIT access configuration for Critical/High-tier, provenance-attestation requirement, IaC-encoded - [ ] Engineering-endpoint module: DLP policy configuration, browser-policy enforcement, MDM AI-tool allowlist, expressed as configuration-as-code for MDM/EDR and CASB/DLP platforms - [ ] Drift-detection pipeline configuration running hourly; classification of findings as low-risk (auto-remediate) vs. high-risk (human-review alert within 2 business days + IM-Software finding) - [ ] Machine-readable change log for auto-remediation events visible to downstream network and identity teams

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % EH controls expressed as IaC (version-controlled, authoritative deployed source, not stubs) | % | % | ≥90% | ☐ | | | IaC drift auto-remediation rate for low-risk findings | % | % | ≥70% | ☐ | | | High-risk drift findings human-reviewed within 2 business days | % | % | 100% | ☐ | | | New AI/HAI software artifacts auto-provisioned with tier-appropriate hardening within 24h of SM registration | % | % | 100% | ☐ | |

Metric Collection Guidance: - IaC coverage: Count EH controls with authoritative IaC (deployed state = IaC spec, not stub); divide by total EH controls. Source: IaC registry - Auto-remediation rate: Count low-risk drift findings auto-remediated / total low-risk drift findings per quarter. Source: remediation telemetry - High-risk drift review SLA: Count high-risk drift findings with human review within 2 business days / total high-risk findings. Source: policy change log × IM backlog - Auto-provisioning rate: Compare SM registration events against IaC provisioning telemetry within 24h window. Source: inventory × IaC provisioning telemetry

Evidence Location: __ Validation Date: __ Notes: ___

Question 8: Adaptive Policy Tightening from ML and IM Signals

Q3.2: Is an adaptive-policy pipeline operational, with ML-Software detections (abuse-pattern signals, shadow-AI egress) and IM-Software incident patterns generating human-approved policy-tightening proposals on a tracked cadence, with every change traceable to a source signal?

Evidence Required: - [ ] Adaptive-tightening pipeline configuration wiring ML-Software detection signals (token-spend abuse, shadow-AI egress) to tightening proposal generation - [ ] Adaptive-tightening pipeline configuration wiring IM-Software post-incident review records (hardening gap findings) to tightening proposal generation - [ ] Human-approval gate configuration for each proposal, security platform engineer approval required before deploy - [ ] Machine-readable change log records showing source signal (ML detection trend ID or IM incident ID), approval record, and downstream notification per tightening change - [ ] Evidence that downstream artifact teams are notified within 24 hours of a tightening change affecting their artifact's hardening profile - [ ] Feedback loop configuration to TA-Software and SR-Software: hardening changes that reflect new threat patterns are routed as new threat entries and requirement-pack items

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Adaptive-policy changes per quarter traceable to ML-Software or IM-Software source signal | 0 | ___ | tracked; growing | ☐ | | | % adaptive-policy proposals human-approved before deploy (no unapproved auto-deploy) | % | % | 100% | ☐ | | | Downstream teams notified within 24h of tightening change | % | % | 100% | ☐ | | | Stale signal feeds (>7 days without a processed ML or IM event) | ___ | ___ | 0 stale feeds | ☐ | |

Metric Collection Guidance: - Traceable changes: Count policy changes in the change log with a valid source signal reference per quarter. Source: policy change log - Human-approval rate: Count proposals deployed with an approval record / total proposals deployed. Source: policy change log - Notification SLA: Count tightening changes with downstream team notification within 24h / total tightening changes. Source: notification log - Signal feed freshness: Check last-processed timestamp for each ML-Software and IM-Software feed; flag any feed with >7 days since last processed event. Source: pipeline monitoring

Evidence Location: __ Validation Date: __ Notes: ___

Question 9: Industry Hardening Baseline Contributions

Q3.3: Does the program contribute ≥2 AI/HAI software hardening baselines per year to industry bodies, CIS AI workloads, CSA AI Safety Initiative, or sector ISACs, with documented adoption, and are new artifacts auto-provisioned with tier-appropriate controls within 24 hours of SM registration?

Evidence Required: - [ ] Contribution records showing ≥2 substantive submissions per year to CIS AI workloads, CSA AI Safety Initiative, or sector ISACs (FS-ISAC, H-ISAC, IT-ISAC AI working groups) - [ ] Evidence of adoption or citation of contributed baselines by the recipient body - [ ] Maintenance records showing internal practice stays aligned with the published external version (not diverged) - [ ] Auto-provisioning trigger configuration: SM-Software inventory registration event fires IaC provisioning workflow within 24 hours - [ ] Tier-change event handling: when an artifact's tier is upgraded in SM inventory, hardening-profile upgrade triggers automatically, not on stale cached tier - [ ] Evidence that at least one new artifact was auto-provisioned within the 24-hour SLA in the last quarter

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Industry hardening baseline contributions per year | 0 | ___ | ≥2 | ☐ | | | New AI/HAI software artifacts auto-provisioned with tier-appropriate hardening within 24h of SM registration | % | % | 100% | ☐ | | | Contributed baselines maintained upstream (internal practice aligned with published version) | ☐ yes / ☐ no |, | yes | ☐ | | | Adaptive-policy change log traceable to source signals, machine-readable format confirmed | ☐ yes / ☐ no |, | yes | ☐ | |

Metric Collection Guidance: - Contribution count: Count published contributions with a named recipient body and a contribution artifact per calendar year. Source: contribution log - Auto-provisioning SLA: Compare SM registration timestamps against IaC provisioning completion timestamps; count within 24h / total. Source: inventory × IaC provisioning telemetry - Maintenance alignment: Review the most recent version of each contributed baseline; confirm it reflects current internal practice. Source: contribution log × practice review - Change log format: Confirm policy change log is machine-readable (JSON/YAML) and each entry has a source signal reference field populated. Source: policy change log audit

Evidence Location: __ Validation Date: __ Notes: ___

Summary Scorecard

Level	Question	Score (0.0 / 0.33 / 0.67 / 1.0)
L1	Q1: Compute/Runtime Envelope	___
L1	Q2: Build-Time and Model-Supply-Chain	___
L1	Q3: Engineering-Endpoint and Data-Flow	___
L2	Q4: Tier-Conditional Hardening Calibration	___
L2	Q5: Zero-Trust and Enhanced DLP for Critical-Tier	___
L2	Q6: Classification-Label Enforcement in Pipelines	___
L3	Q7: Hardening-as-Code IaC Modules	___
L3	Q8: Adaptive Policy Tightening	___
L3	Q9: Industry Baseline Contributions	___

L1 Score (avg Q1–Q3): ___ L2 Score (avg Q4–Q6): ___ L3 Score (avg Q7–Q9): ___ Overall Score (L1×0.5 + L2×0.3 + L3×0.2): ___

Document Version: HAIAMM v3.0 Practice: Environment Hardening (EH) Domain: Software Questionnaire Date: 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