Evidence boundary: NIST incident-response and recovery guidance integrates preparation, detection, response, recovery, and improvement into present organizational risk management. Operational-technology guidance adds safety and availability constraints. Neither demonstrates autonomous incident response in a century-scale closed habitat. This lesson provides civil-and-defensive principles, not live incident instructions, forensic certification, medical advice, or legal process. It excludes offensive intrusion, autonomous weapons, weapon integration, and actionable exploitation instructions. High-consequence cyber, safety, rights, and dual-use decisions require two-person review whenever physically possible.
Plain-language summary
On Earth, an organization can call a vendor, national response team, insurer, regulator, laboratory, police service, or cloud provider. A generation ship may receive advice only after a delay, or never. It must recognize incidents, keep people alive, preserve enough evidence to learn, restore trustworthy service, and resolve responsibility using onboard institutions.
The first question is not “who attacked us?” It is “what essential service is at risk, what do we actually know, and what action reduces total harm?” A radiation fault, worn sensor, mistaken update, malicious insider, compromised toolchain, and poisoned AI model can produce similar symptoms.
Good response separates immediate safety from attribution. It contains only as much as necessary, makes uncertainty visible, protects private and civic rights, preserves an appeal path, and returns emergency powers after the incident. Recovery ends when service and trust are independently re-established—not merely when devices reboot.
Prepare before the alarm
NIST SP 800-61 Revision 3 treats incident response as part of cybersecurity risk management across the Cybersecurity Framework’s Govern, Identify, Protect, Detect, Respond, and Recover functions. That matters because response capability cannot be improvised after the only copy of a procedure or key has been corrupted.
Preparation should establish:
- essential services, minimum-safe states, and maximum tolerable outages;
- local incident roles, alternates, succession, and conflicts-of-interest rules;
- authority to isolate, override, inspect, restore, and reconnect;
- conditions and expiry for emergency powers;
- private, safe reporting and protection against retaliation;
- independent sensors, logs, time sources, and evidence stores;
- known-good software, configurations, hardware, documentation, keys, and tools;
- medical, psychological, fatigue, and accessibility support for responders;
- communication plans for residents and separated zones;
- recovery priorities and explicit do-not-reconnect conditions; and
- exercises that include unavailable experts, broken automation, and ambiguous cause.
Response staff must know the physical process. An information-technology team should not disconnect a controller without understanding how the plant fails. A process operator should not erase a suspect device merely to restore convenience. The incident structure needs cybersecurity, safety, operations, maintenance, governance, privacy, and affected-community representation.
Detect without pretending certainty
An alert is an observation produced by a detector under assumptions. It is not a verdict.
Detection should compare several evidence classes:
- physical measurements and independent instruments;
- command, network, identity, and configuration records;
- software and firmware integrity checks;
- operator reports and observed behavior;
- maintenance, calibration, and manufacturing history;
- expected process relationships and invariant limits; and
- changes in AI models, retrieval data, or automated recommendations.
Record what was observed, by which instrument, under which calibration and clock, and who interpreted it. Preserve contradictory evidence. If two oxygen sensors disagree, do not silently choose the one that matches the dashboard. If a signed log conflicts with a physical witness, investigate both.
Triage should express confidence and consequence separately. A low-confidence indicator of catastrophic life-support danger may justify a reversible precaution. A high-confidence integrity fault in a nonessential archive may allow slower investigation. Avoid premature attribution, which can turn technical ambiguity into political conflict.
Stabilize life, then contain deliberately
Containment can stop propagation, but it can also remove service. NIST SP 800-82 emphasizes that OT decisions must respect safety, availability, performance, and physical-process timing.
Use a hierarchy:
- protect people from immediate physical hazard;
- move the affected service toward a predefined minimum-safe mode;
- restrict suspect identities, conduits, functions, or changes at the narrowest effective boundary;
- preserve independent observability and communication;
- protect recovery material from the suspected cause; and
- reassess continuously as evidence changes.
A broad shutdown may be justified, but should not be automatic. Isolation should have a declared owner, reason, expected duration, review time, and exit criteria. Residents need truthful status without publication of private medical data or details that would make the incident worse.
Emergency access is especially dangerous. A break-glass credential should be narrow, time-limited, logged, and reviewed. No incident should create a permanent unaccountable administrator.
Preserve evidence without sacrificing survival
Evidence helps distinguish defect, error, malicious action, and institutional failure. It supports repair, accountability, and future design. Yet preserving a disk image is secondary to keeping air or water safe.
Before changing a suspect system, where time permits:
- capture volatile state and relevant process conditions;
- identify the collector, tool, time basis, and method;
- preserve originals or clearly mark any transformation;
- calculate integrity checks and store copies across independent zones;
- record gaps, failed collection, and uncertainty;
- limit access to private or legally sensitive material; and
- maintain a chain of custody that can be challenged.
Digital evidence does not interpret itself. Clocks can disagree, logs can be incomplete, sensors can drift, and administrators can have legitimate reasons for unusual actions. Due process requires separating containment from guilt and providing an independent forum for contested findings.
Investigate locally and test competing explanations
Build a timeline with explicit uncertainty. For each event, distinguish observation, inference, hypothesis, and decision. Maintain several plausible explanations until evidence separates them.
A disciplined investigation asks:
- What changed before the unsafe state?
- Which independent observations corroborate it?
- Could one common dependency explain multiple symptoms?
- Did the response itself alter or destroy evidence?
- What assumptions were inherited from software, vendors, or past governance?
- Which people or systems benefit from one interpretation?
- What evidence would falsify each hypothesis?
Adversarial testing belongs in a contained cyber range or representative test article. It should reproduce defensive conditions without teaching or exercising offensive intrusion against live systems. Investigators should not “prove” a theory by experimenting on active life support.
Restore from a bounded base
Recovery is not a return to the exact pre-incident state if that state was vulnerable or already compromised. Define a recovery point: a known, documented configuration whose residual risks are understood.
Recovery may require:
- replacing suspect hardware or sensors;
- booting from independently protected firmware;
- rebuilding software with preserved tools and source;
- restoring data while separating executable content;
- rotating keys and narrowing privileges;
- recalibrating against physical references;
- manually reconstructing disputed records;
- monitoring with independent instruments; and
- maintaining the affected zone in degraded service until evidence is sufficient.
NIST SP 800-184 frames recovery around planning, playbooks, testing, improvement, and restoration of capabilities. For a ship, the decisive constraint is local closure: spares, readers, compilers, keys, calibration standards, and competent people must exist onboard.
Attest and reconnect
Attestation reports properties of a component or state under a defined mechanism. It does not establish that the whole zone is safe. Reconnection should combine:
- verified hardware and firmware state;
- known software and configuration;
- validated data and schema migration;
- independent physical health observations;
- narrowed identities and refreshed credentials;
- observation through a restricted conduit;
- a staged increase in privileges and traffic; and
- an immediate return-to-isolation path.
The incident commander should not be the sole authority certifying recovery. Safety owners, operators, security reviewers, and an independent rights or governance reviewer should sign the record appropriate to consequence. High-consequence reconnection requires two qualified people and cannot be delegated to AI.
LLMs in the response room
An offline LLM can search controlled manuals, summarize large logs, translate between disciplines, propose competing hypotheses, or draft a status report. It can also confabulate a timeline, follow poisoned log text, misread technical evidence, reveal private information, or cause tired humans to converge too early.
Controls should require source citations and exact record locations, preserve model version and retrieval set, label inferences, redact secrets and private data, and test recommendations against deterministic tools and physical evidence. The model should have no direct access to actuators, identity revocation, evidence deletion, or deployment. It cannot determine guilt, command the response, approve restoration, or count as an independent reviewer. Teams must rehearse with AI absent and with deliberately unreliable advisory output.
Learn without creating surveillance
After minimum safe service is stable, review the technical cause, organizational conditions, decision quality, human workload, rights impacts, and response-induced harm. Publish a resident-readable account consistent with privacy and remaining security needs. Track corrective actions to owners and tests.
More logging is not always the answer. Collect evidence tied to declared hazards and retention periods. Delete or de-identify data that no longer serves a legitimate purpose. An incident cannot become a blank check for permanent monitoring.
Evidence ledger
- L11-05-A — Incident response is a cross-lifecycle risk-management capability, not a single containment phase. Basis: observed in current NIST guidance. Readiness: operational in present organizations; major scale-up for autonomous habitats. Confidence: strong.
- L11-05-B — OT containment and recovery must balance cyber risk with physical safety and availability. Basis: observed and normative. Readiness: operational in bounded industrial contexts. Confidence: strong.
- L11-05-C — A generation ship must preserve local incident command, trust recovery, evidence interpretation, and succession after loss of Earth. Basis: proposed requirement. Readiness: early research as an integrated capability. Confidence: supported.
- L11-05-D — Mixed crews should repeatedly isolate a compromised zone, maintain minimum safe service, rebuild, and safely rejoin. Basis: normative decision gate. Readiness: proposed; no cited generation-ship demonstration. Confidence: supported.
- L11-05-E — Due process, privacy, appeal, and expiry of emergency authority are incident-resilience requirements. Basis: normative. Readiness: proposed for this context. Confidence: supported; governance implementation remains contested.
- L11-05-F — Offline evidence-linked LLMs may assist analysis but add poisoning, confabulation, privacy, and overreliance risk. Basis: observed risk taxonomy and proposed use. Readiness: early research for high-consequence response. Confidence: supported.
Linked corpus claims: claim-12-01, claim-12-05, claim-12-06, claim-12-08, and claim-12-10. See the claim registry for each record's current evidence grade and independent-review state.
Assumptions and limits
- Cause and attacker are not assumed; faults, mistakes, malicious acts, and institutional failures remain competing explanations.
- Life safety can justify urgent reversible action, not permanent suspension of rights.
- Evidence preservation is bounded by immediate safety, privacy, and available resources.
- A cryptographic integrity result or attestation is not whole-system proof.
- Recovery guidance must be tailored to the physical process and independently reviewed.
- LLMs remain offline-capable, evidence-linked, logged, non-authoritative, removable, and barred from actuation, guilt, revocation, and reconnection authority.
- No offensive method, live exploitation instruction, autonomous weapon, or weapon integration is in scope.
What would change this conclusion?
Confidence would improve through repeated blind exercises in representative closed habitats: ambiguous anomaly, central services unavailable, one insider hypothesis, one physical fault, one poisoned AI evidence source, limited spares, and residents exercising appeal rights. Teams must maintain essential service, preserve and challenge evidence, rebuild locally, reconnect in stages, and retire emergency powers. Failure to do those things without outside rescue is a wait/do-not-launch result, not a training score to explain away.
Sources and locators
- S01 — NIST SP 800-61 Revision 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management (opens external site in a new tab). Locator: CSF 2.0 Community Profile covering Govern, Identify, Protect, Detect, Respond, Recover, preparation, communication, analysis, mitigation, recovery, and improvement; April 2025; accessed 2026-07-25.
- S02 — NIST SP 800-184, Guide for Cybersecurity Event Recovery (opens external site in a new tab). Locator: sections 2–4 on recovery planning, playbooks, testing, metrics, restoration, and improvement; December 2016; accessed 2026-07-25.
- S03 — NIST SP 800-82 Revision 3, Guide to Operational Technology Security (opens external site in a new tab). Locator: OT safety, availability, timing, incident response, contingency planning, and recovery considerations; September 2023; accessed 2026-07-25.
- S04 — NIST SP 800-160 Volume 2 Revision 1, Developing Cyber-Resilient Systems (opens external site in a new tab). Locator: anticipate, withstand, recover, adapt; cyber-resiliency techniques and design principles; December 2021; accessed 2026-07-25.
- S05 — NIST SP 800-86, Guide to Integrating Forensic Techniques into Incident Response (opens external site in a new tab). Locator: sections 2–3 and media, operating-system, network, and application evidence chapters; August 2006; accessed 2026-07-25.
- S06 — NIST SP 800-53 Revision 5, Security and Privacy Controls (opens external site in a new tab). Locator: Incident Response, Contingency Planning, Audit and Accountability, Identification and Authentication, Privacy, and System Integrity control families; September 2020, updates through 2025; accessed 2026-07-25.
- S07 — NIST AI 600-1, Generative Artificial Intelligence Profile (opens external site in a new tab). Locator: confabulation, data privacy, information integrity, human-AI configuration, and value-chain risk sections; July 2024; accessed 2026-07-25.
- S08 — NIST AI 100-2 E2025, Adversarial Machine Learning (opens external site in a new tab). Locator: poisoning and misuse taxonomy, attacker goals and capabilities, lifecycle stages, and mitigation limits; March 2025; accessed 2026-07-25.
Editorial record
- Prepared by: GShips Project
- Last edited: 2026-07-25
- Status: Substantive editorial draft
- Independent domain review: Pending; high-consequence cyber, safety, forensic, governance, rights, and dual-use claims require explicit two-person review before publication
- Required review: incident response, operational technology, safety engineering, digital forensics, human factors, governance, privacy, and AI/autonomy
- Reviewer: No independent reviewer assigned
- Conflicts: Maintainer intends to explore a commercial venture based on some GShips work; no entity, funding, customer, sponsor, or partner relationship currently exists
- Relationship boundary: Independent educational synthesis; citations do not imply affiliation, endorsement, partnership, or adoption by NASA, NIST, CISA, IETF, or any named organization
- Scope boundary: Civil and defensive resilience only; offensive intrusion, autonomous weapons, weapon integration, and actionable exploitation instructions are excluded
- Corrections: Suggest a correction