A home-security incident does not end when the alarm is cleared, the visitor leaves, or the police report is filed. The next job is to find out what worked, what failed, who owned each response step, and which changes must be tested before the system goes back into normal use.
This worksheet is for a burglary attempt, package theft, suspicious visitor, false alarm, lockout, camera outage, missed notification, monitoring call, or any event that exposed a gap in the household’s security plan. It is an operating review, not a blame exercise. Record evidence separately, state uncertainty plainly, and assign each corrective action to one named owner.
Start with a one-page incident brief
Write the brief before discussing causes or fixes. It should let a household member who was not present understand the event without opening camera clips, chat threads, or support tickets.
- Incident name: a neutral label such as “garage side-door alarm, 14 August.”
- Review owner: the person responsible for collecting records and closing actions.
- Start and end: use the best supported times and mark any uncertainty.
- Locations: list the doors, windows, rooms, driveway, yard, or shared areas involved.
- System state: armed mode, bypassed zones, maintenance work, internet state, and power state.
- People involved: household members, guests, keyholders, responders, installers, and support staff.
- Outcome: injury, entry, damage, loss, false dispatch, missed alert, lockout, or no loss.
- External records: police, fire, medical, insurer, monitoring, property manager, or provider reference numbers.
Do not place alarm codes, passwords, recovery codes, full identity documents, or unredacted access credentials in the brief. Point to the protected record instead.
Freeze facts before choosing a cause
An after-action review becomes unreliable when the household starts with a preferred explanation. First separate observed facts, reported statements, system records, and assumptions.
| Record | What belongs here | What does not |
|---|---|---|
| Observed | Door found open, siren heard, package missing, device offline | Why the event occurred |
| System | Sensor state, arm event, alert delivery, clip ID, battery warning | Events absent from the exported log |
| Reported | A household member’s or responder’s account with time and name | Anonymous recollection presented as fact |
| Assumed | A possible explanation clearly labeled for testing | A conclusion copied into the factual timeline |
Record conflicts rather than forcing agreement. A camera timestamp, phone notification, monitoring record, and eyewitness may each use a different clock or describe a different stage of the same event.
Review the protection chain in order
Work through the chain from deterrence to recovery. A strong result in one stage does not cancel a failure in another.
1. Deterrence and physical resistance
- Were doors, windows, gates, and locks in the expected state?
- Did lighting, signs, visible cameras, or occupied-home cues work as planned?
- Did the event expose weak hardware, poor alignment, an easy bypass, or an unmanaged key?
- Was any emergency exit made harder by the security setup?
2. Detection
- Which device first detected the event?
- Which device should have detected it but did not?
- Were zones armed, bypassed, offline, open, tampered, or in test mode?
- Did pet settings, activity zones, schedules, or automation conditions change detection?
- Were battery, range, placement, weather, glare, or door-fit warnings already present?
3. Alert delivery
- Which push, SMS, email, siren, chime, or call arrived first?
- Who received it, on which device, and how long after the triggering event?
- Did Focus modes, notification permissions, battery saving, lost service, or a signed-out account suppress delivery?
- Did the alert name the right home, zone, camera, and event type?
- Could the recipient distinguish urgent action from routine activity?
If delivery was late or inconsistent, run the separate home-security alert delay test after the immediate corrective work.
4. Verification
- What record let the household decide whether the event was real?
- Were clips available, complete, correctly timed, and safe to view?
- Could a household member check the scene without taking an unsafe action?
- Did two-way audio, live view, door state, or a second camera add useful context?
- Was any conclusion based on a missing clip or a thumbnail that did not show the full event?
5. Escalation and response
- Who made the first decision, and was that person the assigned owner?
- Were backup contacts reached when the first contact did not respond?
- Did the household follow its safe call, leave, shelter, or wait procedure?
- Did monitoring or emergency responders receive the correct address, zone, access note, and contact order?
- Were neighbors, property staff, or local keyholders asked to do anything unsafe?
Use the alert-escalation plan and emergency-contact plan to repair response ownership without storing secrets in shared documents.
6. Evidence and recovery
- Were original clips, images, logs, receipts, and messages preserved before editing or sharing?
- Who received a copy, through which channel, and when?
- Were exposed codes, keys, accounts, or devices disabled or changed?
- Was temporary coverage installed while equipment or doors were being repaired?
- Were monitoring, insurer, property, and provider cases recorded and assigned?
Score outcomes without hiding partial failures
Give each control one of four results. Avoid a single pass or fail for the whole system.
- Worked: performed as documented and produced a useful result.
- Worked with friction: succeeded, but delay, confusion, or manual recovery increased risk.
- Did not work: failed to perform the assigned job.
- Not tested or unknown: the incident did not exercise the control or the record is incomplete.
Score physical security, detection, alerting, verification, household response, monitoring, evidence, access recovery, and service recovery separately. This prevents a clear camera clip from masking a failed door sensor, or a fast monitoring call from masking the wrong contact list.
Find contributing conditions, not a single convenient cause
Most incidents involve several conditions. A door sensor may have been bypassed because of a fit problem, while the bypass stayed in place because no owner checked the armed-zone summary. Capture both.
People and ownership
- No named owner for arming, maintenance, exports, or escalation.
- Household members understood the same alert differently.
- A backup administrator lacked the access needed to act.
- Old guests, contractors, or former residents retained access.
Process
- A test, maintenance, or bypass state was not closed.
- Low-battery, offline, or open-zone warnings were deferred without a deadline.
- The contact order, address note, or responder instructions were stale.
- No one had rehearsed the first five minutes of the response.
Device and installation
- Placement, alignment, range, weather, power, or network conditions exceeded the tested setup.
- A firmware, app, hub, or router change altered behavior.
- The installed model did not support an assumed feature.
- A camera field of view or privacy zone removed needed context.
Service and external dependency
- A cloud, cellular, internet, phone, power, or monitoring path was unavailable.
- A plan or account state did not include the expected function.
- A provider, installer, property manager, or responder record was incomplete.
- The household had no tested fallback when the primary service failed.
Build a corrective-action register
“Be more careful” is not an action. Every item needs a change, owner, deadline, evidence of completion, and a test.
| Field | Required entry |
|---|---|
| Gap | The specific failed or weak control |
| Risk | What could happen if it remains open |
| Action | The physical, account, process, or service change |
| Owner | One person accountable for closure |
| Due date | A date, not “soon” |
| Completion evidence | Photo, setting export, receipt, support note, or updated procedure |
| Acceptance test | The exact trigger and expected result |
| Rollback | How to recover if the change creates a new failure |
| Status | Open, blocked, ready to test, passed, or reopened |
Prioritize safety and exposed access first, then detection, alerting, response, evidence, and convenience. A cosmetic camera adjustment should not displace a known lock, sensor, code, or dispatch problem.
Protect privacy during the review
- Keep original evidence read-only and limit who can access it.
- Redact faces, license plates, addresses, phone numbers, and account identifiers when they are not needed.
- Do not paste access codes, alarm passwords, or recovery credentials into the action register.
- Record who shared each file and the purpose of the share.
- Set a review date for deleting working copies that no longer have an operational, legal, or insurance purpose.
- Do not publish footage of neighbors, children, guests, workers, or responders as part of a public incident recap.
45-minute incident after-action drill
Run this drill only after urgent safety, evidence, access, and reporting work is complete. Tell monitoring contacts and household members that it is a test. Do not trigger an emergency response.
- Minutes 0–5 — Brief: read the one-page incident brief and state the review boundary.
- Minutes 5–10 — Facts: identify five supported facts, two uncertainties, and any conflicting records.
- Minutes 10–18 — Protection chain: score deterrence, detection, alerting, verification, response, and recovery.
- Minutes 18–25 — Causes: list contributing people, process, device, installation, and service conditions.
- Minutes 25–33 — Actions: assign owners, dates, completion evidence, and acceptance tests.
- Minutes 33–40 — Safe test: exercise one repaired alert or zone using provider-approved test mode.
- Minutes 40–45 — Close: confirm the system left test mode, active zones are restored, owners accept their actions, and the next review date is recorded.
Use the test-mode exit checklist before declaring the drill complete. Reopen any action whose acceptance test fails or creates a new alert, access, privacy, or outage problem.
Closure criteria
Close the review only when immediate safety and access issues are resolved, original evidence is protected, external case numbers are recorded, every corrective action has an owner, high-risk changes have passed a realistic test, the system has returned to its intended armed and monitoring state, and the household knows what changed.
Some long-term actions may remain open. That is acceptable when the risk, temporary control, owner, due date, and next review are explicit. What matters is that no serious gap disappears into meeting notes.
Frequently asked questions
When should we run an after-action review?
Run one after an event that caused harm, loss, dispatch, a missed alert, a lockout, an outage, or a near miss that exposed a meaningful gap. Wait until immediate safety, evidence preservation, and urgent access recovery are complete.
Is this the same as an incident timeline?
No. A timeline reconstructs events and timestamps. An after-action review evaluates controls, ownership, contributing conditions, corrective actions, and acceptance tests. Keep the two records linked but separate.
Should every device failure be called the root cause?
No. Record the device failure and the conditions around it. A missed alert may also involve placement, maintenance, account permissions, notification settings, unclear ownership, or an untested fallback.
Who should own corrective actions?
Assign each action to one named person who has the access and authority to complete it. Other people may help, but shared ownership without one accountable person often leaves the gap open.
How do we know a fix is complete?
Require completion evidence and a realistic acceptance test. A changed setting or replaced device is not closed until the expected sensor, alert, access, recording, response, and recovery behavior has been checked.