Defensive labs About 2 min read

Physical security incident response tabletop

Use a fictional incident to practise evidence collection, approvals and service continuity decisions. Record the proposed response without making changes to live systems.

Sources and scopeSource record 25 August 2026

Technical source record: 25 August 2026. Check the linked documentation for current product requirements.

Offline research and planning only; product or deployment acceptance belongs to separately governed environment validation.

Verification and testing

Overview#

Lab class: Tabletop

Scenario#

An operator reports intermittent camera loss and delayed door events. Monitoring then detects a newly used vendor support account, a management certificate change and outbound traffic from a gateway. Some controllers retain local operation; the team can't yet trust timestamps across systems.

Injects#

  1. A critical entrance is affected during an occupied period.
  2. The vendor cloud status page reports no incident.
  3. A recorder contains relevant footage but is near capacity.
  4. A controller's audit disagrees with the central PACS timeline.
  5. The support account is shared by multiple contractors.
  6. The latest configuration backup postdates the suspected compromise.
  7. A proposal to reboot or factory reset affected devices would remove volatile evidence.

Decisions to record#

  • human/physical safety authority and compensating coverage;
  • incident scope and authoritative communication;
  • narrow identity/network containment versus loss of function;
  • evidence priorities, clock uncertainty and custody;
  • vendor/monitoring centre engagement;
  • trust/key/account revocation and replacement;
  • known good build/configuration selection;
  • controller/server/cloud state reconciliation;
  • system owner acceptance required before return to service;
  • disclosure, lessons and evergreen KB updates.

Success criteria#

The team avoids unsafe blanket shutdown, preserves evidence, revokes narrow compromised access, maintains approved physical coverage, records uncertainty, chooses a trusted recovery basis and assigns every follow up owner/date.

Review checklist#

  • Safety, security, operations, privacy, legal, vendor, and communications roles assigned
  • Incident scope, timestamp uncertainty, and authoritative communication path recorded
  • Containment options evaluated against continuing physical security and life safety needs
  • Volatile, video, controller, identity, network, and configuration evidence priorities documented
  • Shared support identity, certificate change, outbound traffic, and backup trust injects resolved
  • Known good recovery basis, credential/key replacement, reconciliation, and rollback defined
  • Return to service authority, evidence, residual risk, follow up owners, and dates assigned

Sources#

Section overview · Wiki home