Incident Response Guides
Move from generic doctrine to usable rail playbooks.
Start from a solid six-phase response model, then build out a playbook that fits the scenario in front of you.
Response Framework
Keep the six phases close
Define ownership, evidence handling, communications, backups, and OT safety boundaries before an incident happens.
Verify the incident, scope affected systems, establish severity, and preserve the signals needed for decision-making.
Limit spread fast while balancing service continuity and safety for rail operations and dependent systems.
Remove malicious access, close the exploited weakness, and confirm the environment is no longer hostile.
Restore services in controlled phases, validate clean state, and monitor closely for recurrence or hidden impact.
Capture what worked, where friction appeared, and which policy, tooling, or training gaps need to change.
Generate a scenario-specific playbook
No playbook generated yet.
Pick a scenario and generate a guide first. You can then export it, simplify it, or compare it against your own draft.
Compare your own draft
Generate a guide first so there is a baseline to compare against.
Reporting Windows
For a significant incident, send the early warning within 24 hours of becoming aware so the CSIRT or competent authority gets an early signal.
Follow with the incident notification within 72 hours, including severity, impact, and any indicators of compromise available at that stage.
If a personal data breach is likely to create risk for individuals, notify the DPC without undue delay and, where feasible, within 72 hours of awareness.
Under NIS2, expect a final report within one month after the incident notification, then feed the lessons back into controls, comms, and exercises.