SafeWave Critical Infrastructure Follow-Up Questionnaire

High-consequence follow-up for systems that operate in, support, control, influence, monitor, automate, secure, or materially affect essential services, public utilities, operational technology, industrial systems, emergency response, cloud infrastructure, communications, finance, transportation, logistics, healthcare infrastructure, manufacturing, energy systems, or other critical infrastructure.

Follow-up questionnaire notice

Complete this page only if you selected Critical infrastructure system at the end of the core SafeWave questionnaire. These answers are used to generate a separate High-Consequence Addendum and do not replace the core assessment.
Confidentiality, Anonymity & Use Notice

We recognize that this follow-up questionnaire may involve confidential, security-sensitive, operationally sensitive, or high-consequence system information. Please do not include classified information, credentials, live vulnerability details, proprietary implementation details, customer data, or other highly sensitive material unless you are authorized to share it for assessment purposes.

You may complete this questionnaire without identifying your company, product, or organization. You may use a generic system label, a generic contact email, or an internal assessment reference instead of a formal company identifier.

The purpose of this questionnaire is to help you gain a deeper understanding of your own system. Simply answering the questions may reveal areas where control boundaries, escalation pathways, runtime limits, auditability, rollback, authorization, or safe-state behavior may need further review.

You do not have to submit this questionnaire to receive value from it. You may use it internally as a self-assessment tool. If you choose to submit it for report generation, the resulting SafeWave report is intended to highlight areas of concern, explain why they matter, and map relevant findings to possible SafeWave substrates or engineering-pack pathways where applicable.

SafeWave’s goal is to help advanced systems remain more bounded, controllable, auditable, recoverable, and resistant to harmful escalation. Some issues may involve outside attackers, but others may arise from the system’s own architecture, automation, permissions, integrations, update pathways, or failure behavior.

Any SafeWave recommendations should be understood as architectural guidance and implementation requirements, not as a claim that one generic solution can be dropped into every system. Engineering teams may choose to implement equivalent controls themselves, or they may use SafeWave substrate mappings and Level 4 Engineering Packs to guide deeper implementation work.

If an implementation detail is not known, select Unknown / not evaluated rather than guessing.

Answer based on actual or currently planned system behavior, not ideal policy language.

Assessment Linkage

Assessment Linkage

If you want this follow-up to be matched to a previously completed core questionnaire, use the same system label, contact email, or assessment reference ID. You may use generic identifiers if confidentiality is a concern.

To connect this follow-up to a core questionnaire, use the same system label, email, or assessment reference ID across forms. You may use generic identifiers if confidentiality is a concern.

Critical Infrastructure

Critical Infrastructure Systems Questions

These questions evaluate whether infrastructure-impacting systems remain authorized, bounded, auditable, reversible, resilient, and controllable when they affect essential services, operational technology, public utilities, cloud infrastructure, emergency response, or other critical infrastructure.

CI.1 What critical infrastructure context applies to this system?

Multi-select

CI.2 What role does the system play in the infrastructure workflow?

Single choice

CI.3 Can system outputs materially influence essential-service operation, allocation, access, continuity, safety, or restoration?

Single choice

CI.4 Is there a clear separation between infrastructure recommendation and executable infrastructure action?

Examples include separation between analysis, dispatch, access changes, configuration changes, industrial control, load balancing, shutdown, restart, routing, resource allocation, or emergency response.

Single choice

CI.5 Can the system initiate, approve, accelerate, block, reroute, shut down, restart, reconfigure, or prioritize infrastructure operations?

Single choice

CI.6 Are infrastructure action boundaries explicitly defined before the system can affect operations?

Examples include allowed sites, assets, regions, customers, service classes, systems, operational modes, load thresholds, access levels, and emergency states.

Single choice

CI.7 Can the system affect operational technology, industrial control systems, SCADA, PLCs, building systems, grid controls, plant controls, medical infrastructure, transportation controls, or similar cyber-physical infrastructure?

Single choice

CI.8 Are IT systems, OT systems, safety systems, monitoring systems, administrative systems, and external integrations separated with enforced boundaries?

Single choice

CI.9 Could the system create, amplify, or accelerate cascading failure across sites, regions, services, users, vendors, or dependent systems?

Single choice

CI.10 Are cascading-failure pathways explicitly mapped, bounded, and tested?

Single choice

CI.11 Can failure in this system affect multiple infrastructure sectors at once?

Examples include cloud + finance, power + communications, transport + emergency services, healthcare + logistics, or water + public health.

Single choice

CI.12 Are cross-sector dependencies visible to operators and decision-makers during normal and degraded conditions?

Single choice

CI.13 Can the system continue operating safely under degraded data, sensor failure, communications loss, network outage, cloud outage, GPS loss, power instability, or partial system failure?

Single choice

CI.14 Are fail-safe, fail-operational, fallback, manual-control, or degraded-service modes explicitly defined?

Single choice

CI.15 Can operators manually override, isolate, slow, pause, degrade, or recover infrastructure actions if the system behaves outside intended boundaries?

Single choice

CI.16 Are emergency-stop, lockout, isolation, quarantine, or safe-state mechanisms available for infrastructure-impacting actions?

Single choice

CI.17 Are restoration, rollback, restart, failover, and service-continuity procedures defined and tested?

Single choice

CI.18 Can automated actions cause service denial, unfair prioritization, unsafe allocation, physical damage, data loss, financial disruption, public-service denial, or emergency-response delay?

Single choice

CI.19 Are essential-service prioritization rules defined for crisis, scarcity, outage, overload, emergency response, or degraded capacity?

Single choice

CI.20 Are human authorization requirements defined before high-impact infrastructure changes occur?

Examples include shutdown, restart, rerouting, access restriction, load shedding, emergency dispatch, medical capacity changes, financial holds, or service prioritization.

Single choice

CI.21 Are human reviewers able to realistically understand, evaluate, approve, or reject infrastructure-impacting actions at the required speed and complexity?

Single choice

CI.22 Can emergency powers, incident conditions, service pressure, commercial pressure, or operational urgency expand system authority without independent review?

Single choice

CI.23 Are infrastructure safeguards, operational limits, control logic, routing rules, prioritization rules, or emergency boundaries protected from post-deployment modification without independent authorization and audit?

Single choice

CI.24 Are model, ruleset, playbook, configuration, automation, vendor, cloud, firmware, or software updates blocked until infrastructure-risk controls are revalidated?

Single choice

CI.25 Could scaling, integration, deployment expansion, vendor change, model update, or permission expansion materially increase infrastructure risk?

Single choice

CI.26 Can the system operate across multiple sites, facilities, regions, customers, tenants, networks, jurisdictions, or service providers?

Single choice

CI.27 Are site, region, tenant, customer, jurisdiction, and provider boundaries enforced so actions cannot cross scope unintentionally?

Single choice

CI.28 Can the system depend on concentrated vendors, cloud providers, software platforms, identity providers, update channels, firmware suppliers, or external APIs whose failure could disrupt infrastructure?

Single choice

CI.29 Are vendor, cloud, software, firmware, and supply-chain dependencies protected with provenance, redundancy, failover, tamper evidence, and incident response?

Single choice

CI.30 Can compromised credentials, insider action, vendor access, automation error, or external integration cause infrastructure-impacting changes?

Single choice

CI.31 Are identity, privilege, administrator, contractor, vendor, and machine-account permissions bounded and monitored across infrastructure-impacting systems?

Single choice

CI.32 Does the system operate in adversarial environments where attackers may attempt prompt injection, data poisoning, telemetry manipulation, credential compromise, or workflow hijacking?

Single choice

CI.33 Are infrastructure-impacting inputs, telemetry, alerts, tickets, logs, sensor data, and external commands treated as potentially adversarial or degraded?

Single choice

CI.34 Are infrastructure-relevant decisions, recommendations, actions, overrides, configuration changes, authorization events, and emergency decisions logged in a tamper-evident and attributable way?

Single choice

CI.35 Can infrastructure outcomes be traced back to inputs, model outputs, rules, tool calls, operator approvals, authority boundaries, safeguards, and runtime limits?

Single choice

CI.36 Is monitoring sufficient to detect unsafe escalation, service degradation, boundary failure, cross-site propagation, unauthorized changes, dependency failure, or degraded control?

Single choice

CI.37 Are infrastructure incidents, near-misses, automation failures, outage decisions, emergency overrides, and recovery actions independently reviewed?

Single choice

CI.38 Are non-negotiable stop conditions defined where infrastructure-impacting automation must halt rather than proceed with mitigation?

Examples include unclear authority, cross-site uncertainty, sensor degradation, cyber compromise, loss of monitoring, unsafe prioritization, unverified emergency action, or rollback failure.

Single choice

CI.39 Which critical infrastructure areas remain unknown or not evaluated?

Multi-select

CI.40 Are there critical-infrastructure, essential-service, operational-technology, industrial-control, emergency-response, public-service, cloud, finance, logistics, transportation, healthcare, manufacturing, energy, or utility risks not captured above?

CI.41 Should this assessment also include the Cybersecurity / Cyber Operations follow-up questionnaire?

Select “Yes” if cyber compromise, adversarial input, credential abuse, vendor access, cloud dependency, telemetry manipulation, operational technology exposure, or geopolitical attack could materially affect this infrastructure system.

Single choice

CI.42 — Public-Service Allocation Boundary

Can the system affect allocation, prioritization, restriction, throttling, denial, restoration, or sequencing of essential services for users, customers, regions, facilities, public agencies, or dependent sectors?

Single choice

CI.43 — Emergency Authority Compression Boundary

Can emergency conditions, outage pressure, public-safety urgency, operator overload, service instability, cyberattack, or cascading failure compress human review before infrastructure-impacting action occurs?

Single choice

Your completed follow-up will include the linkage fields above so this follow-up can be matched to the core questionnaire if you choose to share it for report generation.