Sector-Specific Risk Management Practices Mapped to SWT3 Witness Procedures
Who this is for: Critical infrastructure sector risk officers, CISA regional leads, sector-specific agencies (DOE, DHS, EPA), ICS/OT security teams deploying AI in operational environments, and compliance officers responsible for AI risk management across regulated CI sectors.
Critical Assessor Notice: Boundaries of Cryptographic Evidence
SWT3 witness anchors prove that specific operational controls were active at a specific point in time. They do not replace the assessor's independent judgment, professional expertise, or regulatory authority. Assessors must verify that anchored evidence is sufficient, appropriate, and relevant to the specific assessment context. Each regulatory framework retains its own assessment authority, methodology, and determination standards.
Status: Concept Note Stage
The NIST AI RMF Critical Infrastructure Profile is currently at the concept note stage (April 2026). The profile structure, sector coverage, and specific requirements are under active development. This crosswalk reflects the published concept note and will be updated as NIST releases drafts and final guidance. Mappings may change as the profile matures.
On April 7, 2026, NIST released a concept note for developing an AI RMF Profile for Trustworthy Use of AI in Critical Infrastructure. The profile extends the NIST AI Risk Management Framework (AI 100-1) with sector-specific guidance for operators whose AI systems affect physical safety, public health, and national security.
| Source Document | NIST Concept Note: AI RMF Profile on Trustworthy AI in Critical Infrastructure (April 7, 2026) |
| Profile Structure | Four AI RMF functions: GOVERN, MAP, MEASURE, MANAGE |
| CI Sectors Covered | All 16 PPD-21 sectors -- initial focus on Energy, Water, Healthcare, Financial Services, Transportation, Defense |
| Relationship to AI RMF | Sector-specific profile layered on NIST AI 100-1. Does not replace the base framework -- adds CI-specific implementation guidance and risk tolerances. |
| Key Emphasis Areas | Safety-critical AI behavior, fail-safe operation, adversarial robustness, supply chain integrity, continuous monitoring, human oversight |
| SWT3 Procedures Mapped | 10 primary procedures across GOVERN, MAP, MEASURE, and MANAGE functions |
AI systems deployed in critical infrastructure face risk categories that are qualitatively different from general-purpose AI. The CI profile addresses four categories of heightened risk:
AI decisions in CI environments can have direct physical consequences -- grid load management, water treatment dosing, traffic signal optimization, and clinical decision support all operate in domains where incorrect outputs may cause bodily harm or loss of life. The CI profile requires operators to demonstrate that AI systems have been tested under realistic failure conditions and that safe state transitions are documented and exercised.
Critical infrastructure sectors are deeply interdependent. An AI failure in the energy sector can cascade into water treatment, telecommunications, and healthcare. The CI profile emphasizes that operators must account for cross-sector dependencies when assessing AI risk, and must maintain evidence that their AI systems degrade gracefully rather than propagating failures across interconnected systems.
AI systems in CI environments may be exploited by insiders to amplify the impact of malicious actions -- for example, manipulating a predictive maintenance model to mask equipment degradation or altering a fraud detection threshold to enable financial crimes. The CI profile calls for audit traceability, access controls, and model integrity verification as countermeasures.
Nation-state and advanced persistent threat actors specifically target CI AI systems. Adversarial inputs crafted to deceive anomaly detection, intrusion detection, or predictive models represent a category of risk that requires robustness testing beyond what general-purpose AI deployments typically undergo. The CI profile requires documented adversarial testing campaigns and continuous security monitoring of AI model behavior.
The following table maps key CI profile requirements to SWT3 witness procedures. Each procedure generates a cryptographic witness anchor that serves as independently verifiable compliance evidence.
| CI Profile Area | SWT3 Procedure | What Is Witnessed | AI RMF Function |
|---|---|---|---|
| Governance framework | AI-GOV.1 | Governance policy attestation with review date, policy version, and approval authority | GOVERN 1.1, 1.2 |
| Adversarial robustness | AI-SEC.1 | Security scan results with threat classification and severity distribution | MEASURE 2.6 |
| Continuous monitoring | AI-DRIFT.1 | Model drift detection with metric delta, baseline comparison, and threshold status | MEASURE 2.6, MANAGE 4.1 |
| Robustness testing | AI-ROBUST.1 | Perturbation survival rate, attack vector tested, confidence interval under stress | MEASURE 2.5, 2.6 |
| Human oversight | AI-HITL.1 | Human review completion with reviewer role, decision outcome, and override flag | MANAGE 2.2 |
| Fail-safe operation | AI-SAFE.1 | Safe state transition with trigger code, actions suspended, and recovery status | MANAGE 4.1 |
| Supply chain risk | AI-SUPPLY.1 | Supplier compliance assessment with vendor count, verified count, and risk score | GOVERN 1.5, MEASURE 3.1 |
| Audit traceability | AI-AUDIT.1 | Tamper-evident audit log integrity verification with entry count and hash chain | GOVERN 1.7 |
| Performance benchmarks | AI-PERF.1 | Performance metrics against declared accuracy thresholds and benchmark datasets | MEASURE 2.5 |
| Inference provenance | AI-INF.1 | Prompt/response hash capture with model identifier and clearing level | GOVERN 1.7, MAP 1.1 |
CI profile context: The GOVERN function requires CI operators to establish and maintain AI governance structures that account for sector-specific risk tolerances, regulatory obligations, and safety requirements. For critical infrastructure, governance is not optional -- it is the foundation on which all other risk management activities rest.
What SWT3 witnesses: witness_governance() records the governance policy version, review date, approval authority, and policy scope. The anchor provides a timestamped, cryptographic record that a governance framework was in place and had been reviewed by an authorized party at the time the anchor was minted.
AI-GOV.1 anchors demonstrate that governance policies exist and are actively maintained. The review_date field shows currency. Cross-reference with AI-AUDIT.1 anchors to demonstrate that governance decisions are captured in tamper-evident logs.
CI profile context: Critical infrastructure AI must withstand adversarial inputs, sensor noise, data corruption, and out-of-distribution conditions. The MEASURE function requires operators to demonstrate that AI models have been tested under realistic perturbation scenarios relevant to their sector -- not just standard benchmark datasets.
What SWT3 witnesses: witness_robustness() records the perturbation type tested, survival rate, confidence interval under stress, and the attack vector category. Each anchor represents a single robustness evaluation, creating a longitudinal record of testing cadence and results.
AI-ROBUST.1 anchors show perturbation types tested and the model's survival rate under each. For CI assessments, examiners will look for sector-relevant perturbation types (e.g., sensor drift for energy, adversarial inputs for defense). A consistent cadence of anchors demonstrates ongoing robustness monitoring rather than one-time testing.
CI profile context: The MANAGE function requires that AI systems in critical infrastructure support graceful degradation and fail-safe operation. When an AI component fails, produces unreliable outputs, or exceeds its operating envelope, the system must transition to a known safe state without cascading failures across interconnected infrastructure.
What SWT3 witnesses: witness_safe_state() records the trigger code (manual, threshold, chain_break, policy, external), the number of actions suspended, and whether a recovery mechanism is available. This creates an auditable record of every safe state transition, including whether the transition was proactive (threshold-based) or reactive (triggered by a failure event).
AI-SAFE.1 anchors prove that stop/interrupt mechanisms exist and have been exercised. The trigger_code field distinguishes proactive transitions from reactive ones. Recovery_available confirms the system can resume normal operations. For CI assessments, examiners will verify that safe state transitions do not propagate failures to dependent systems.
CI profile context: Continuous monitoring is a cornerstone of the MANAGE function for critical infrastructure. AI models deployed in CI environments are subject to concept drift, data drift, and environmental changes that may not be present in training data. The CI profile requires operators to demonstrate that drift is detected, measured, and acted upon before model performance degrades to unsafe levels.
What SWT3 witnesses: witness_drift() records the drift metric name, current value, baseline value, threshold, and whether the threshold was exceeded. Each anchor captures a point-in-time measurement that can be queried to reconstruct drift trajectories over time.
AI-DRIFT.1 anchors demonstrate continuous monitoring cadence and threshold configuration. For CI assessments, examiners will look for evidence that drift thresholds are calibrated to sector-specific safety margins -- not generic defaults. A series of anchors with threshold_exceeded=false demonstrates that the model remains within its operating envelope.
The following Python examples demonstrate how CI operators can integrate SWT3 witnessing into their AI pipelines. Each example produces a cryptographic witness anchor that serves as compliance evidence for the corresponding CI profile requirement.
from swt3_ai import Witness
w = Witness(tenant="energy-grid-ops", api_key="YOUR_KEY")
# Record governance policy review (AI-GOV.1)
w.witness_governance(
policy_version="v3.1",
review_date="2026-08-15",
approval_authority="Chief Risk Officer"
)# Record adversarial robustness evaluation (AI-ROBUST.1)
w.witness_robustness(
perturbation_type="sensor_noise",
survival_rate=0.97,
attack_vector="gaussian_perturbation",
confidence_interval=0.95
)# Record safe state transition after threshold breach (AI-SAFE.1)
w.witness_safe_state(
trigger="threshold",
actions_suspended=3,
recovery_available=True
)# Record drift measurement for continuous monitoring (AI-DRIFT.1)
w.witness_drift(
metric="prediction_accuracy",
current=0.91,
baseline=0.95,
threshold=0.88,
model_id="load-forecast-v2"
)
# Flush all buffered anchors to the witness ledger
w.flush()