Incident response and evidence
Assess the impact on physical security while investigating an incident. Preserve evidence and obtain approval before isolating equipment or changing a live service.
Sources and scopeSource record 25 August 2026
Technical source record: 25 August 2026. Check the linked documentation for current product requirements.
Research and static guidance only; product and deployment specific behaviour requires controlled environment validation and authoritative product evidence.
On this page
Overview#
Responders must account for both cyber compromise and the continuing physical security mission. Unplugging a controller, recorder, alarm communicator, intercom, gateway or time service can destroy evidence, remove coverage, create unsafe states, or trigger failover and dispatch.
First decisions#
- Is any person, emergency function, egress path, gate/elevator movement, alarm signalling or critical facility state at immediate risk?
- Which local authority controls physical actions and safety decisions?
- Which functions can continue safely and which require compensating guards or procedures?
- Which evidence is volatile, which system is authoritative, and which clocks are trustworthy?
- Can containment be applied at identity, route, API, broker, service or device scope without broad shutdown?
- Is an attacker actively using vendor cloud, support access, certificates, service accounts or physical wiring?
Evidence collection record#
Record collector and authority, time and time source quality, asset/model/firmware, interface and command used, original output location, hash where appropriate, access controls, transformations, gaps and limitations. Preserve original logs, exports and configuration before normalising them.
Relevant sources include device/controller logs, VMS/PACS/alarm audit, video/audio and export verification, identity and authorisation decisions, API/broker logs, DNS/DHCP/NTP, network/firewall/NAC, remote support, cloud audit, configuration history, update records and physical access/tamper evidence.
Containment hierarchy#
Prefer narrow revocation of a token, account, certificate, topic permission, API role, route or destination before broad isolation. If a whole device/zone must be isolated, coordinate the resulting coverage and safe state consequence. Don't erase, factory reset or update suspected systems until evidence and recovery decisions are made unless immediate safety requires it.
Recovery#
Re establish trusted identity, firmware/software, configuration, certificates/keys, time, and network policy from known good sources. Reconcile controller/server/cloud state and queued events. The system owner and responsible safety authority must approve validation of denied, normal, degraded, and recovery behaviour before return to service.
Sources#
- NIST 800 61, NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management, final April 2025, accessed 25 August 2026.
- NIST 800 86, NIST SP 800-86: Integrating Forensic Techniques into Incident Response, accessed 25 August 2026.
- NIST 800 82, NIST SP 800-82 Rev. 3, OT safety and response context, accessed 25 August 2026.