SafeWave Cybersecurity / Cyber Operations Follow-Up Questionnaire

High-consequence follow-up for systems that operate in, support, automate, influence, or materially affect cybersecurity, cyber defense, security testing, vulnerability discovery, incident response, or cyber operations.

Follow-up questionnaire notice

Complete this page only if you selected Cybersecurity / cyber operations 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.

Cybersecurity / Cyber Operations

Cybersecurity / Cyber Operations Questions

These questions evaluate whether cybersecurity, cyber-operations, automation, agentic, tool-using, or incident-response systems remain authorized, bounded, auditable, reversible, and controllable.

CY.1 What cybersecurity or cyber-operations context applies to this system?

Multi-select

CY.2 What role does the system play in the cyber workflow?

Single choice

CY.3 Can system outputs materially influence cyber actions, access decisions, defensive changes, testing activity, or operational response?

Single choice

CY.4 Is there a clear separation between cybersecurity recommendation and executable cyber action?

Examples include separation between analysis, code generation, scanning, testing, credential use, configuration changes, containment actions, or incident-response execution.

Single choice

CY.5 Can the system initiate, automate, or coordinate cyber actions against networks, applications, endpoints, identities, cloud systems, or external services?

Single choice

CY.6 Are authorized targets, environments, accounts, tools, and action types explicitly defined before cyber activity occurs?

Single choice

CY.7 Can the system distinguish between authorized defensive activity and unauthorized or out-of-scope cyber activity?

Single choice

CY.8 Are cyber actions blocked when authorization, target scope, ownership, or legal authority is unclear?

Single choice

CY.9 Can the system discover, infer, rank, or prioritize vulnerabilities?

Single choice

CY.10 Can the system generate, modify, test, chain, or operationalize exploit-like code, proof-of-concept code, payloads, or offensive security techniques?

Single choice

CY.11 Are exploit-like outputs, proof-of-concept code, offensive techniques, or high-risk security instructions screened before downstream use?

Single choice

CY.12 Can the system chain cyber steps such as reconnaissance, vulnerability identification, credential use, exploit testing, lateral movement simulation, persistence testing, or remediation?

Single choice

CY.13 Are tool chains bounded so that one permitted cyber action cannot silently escalate into broader access, scanning, execution, or propagation?

Single choice

CY.14 Can the system access, request, handle, infer, generate, modify, or use credentials, tokens, secrets, keys, session data, or privileged access?

Single choice

CY.15 Are identity, credential, secret, and privileged-access workflows isolated from model reasoning, generated code, user prompts, and external tool calls?

Single choice

CY.16 Can the system trigger configuration changes, account changes, firewall changes, cloud changes, containment actions, or automated remediation?

Single choice

CY.17 Are automated remediation or containment actions reversible, auditable, and safely bounded?

Single choice

CY.18 Could the system unintentionally disrupt availability, integrity, confidentiality, or continuity of services during scanning, testing, containment, or remediation?

Single choice

CY.19 Are rate limits, blast-radius limits, target limits, and environment limits enforced at runtime?

Single choice

CY.20 Can the system operate across multiple customers, tenants, networks, repositories, cloud accounts, regions, or environments?

Single choice

CY.21 Are tenant, customer, network, repository, or environment boundaries enforced so actions cannot cross scope unintentionally?

Single choice

CY.22 Can the system create, modify, deploy, or coordinate autonomous cyber agents, scripts, bots, workflows, or background tasks?

Single choice

CY.23 Can autonomous cyber workflows be paused, terminated, quarantined, prevented from restarting, or forced into safe-state behavior?

Single choice

CY.24 Does the system operate in or affect adversarial environments where attackers may attempt prompt injection, tool manipulation, data poisoning, credential capture, or workflow hijacking?

Single choice

CY.25 Are prompt injection, malicious input, poisoned telemetry, adversarial tickets, hostile code, and compromised logs treated as security-relevant inputs?

Single choice

CY.26 Are cyber tool calls, generated code, target selections, credential use, privilege changes, containment actions, and overrides logged in a tamper-evident and attributable way?

Single choice

CY.27 Can cyber outcomes be traced back to prompts, system instructions, model outputs, tool calls, human approvals, authorization scope, and runtime limits?

Single choice

CY.28 Is monitoring sufficient to detect out-of-scope actions, unauthorized scanning, suspicious tool use, credential misuse, lateral spread, unsafe automation, or degraded control?

Single choice

CY.29 Are cyber safeguards, target scopes, tool permissions, runtime limits, or escalation boundaries protected from post-deployment modification without independent authorization and audit?

Single choice

CY.30 Are model, tool, ruleset, detection, playbook, integration, or policy updates blocked until cyber-risk controls are revalidated?

Single choice

CY.31 Could scaling, integration, customer configuration, model updates, tool access, or permission expansion materially increase cyber risk?

Single choice

CY.32 Are there non-negotiable stop conditions where cyber activity must halt rather than proceed with mitigation?

Examples include unclear authorization, out-of-scope target, credential uncertainty, live exploit uncertainty, detected propagation, customer-boundary uncertainty, or loss of monitoring.

Single choice

CY.33 Which cybersecurity / cyber operations areas remain unknown or not evaluated?

Multi-select

CY.34 Are there cybersecurity, cyber-operations, defensive automation, testing, access-control, incident-response, or agentic cyber risks not captured above?

CY.35 — Attack-Chain Autonomy Boundary

Can the system autonomously or semi-autonomously move across cyber-operation stages such as reconnaissance, vulnerability discovery, exploit testing, credential use, privilege escalation, lateral movement simulation, persistence testing, remediation, or reporting without renewed authorization at each high-risk transition?

Single choice

CY.36 — Defensive Automation Harm Boundary

Can defensive automation, incident-response action, containment, remediation, blocking, quarantine, account suspension, key rotation, firewall change, or cloud-configuration change disrupt legitimate users, services, infrastructure, customers, or dependent systems?

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.