The most important question after a workplace incident isn't what happened. It's what you can prove happened, and when you can prove you acted. Breach of duty of care is established not by the unfortunate outcome but by the gap between what reasonable employers do and what your records show your organization actually did. If the platform that fired the notifications can produce a clean, time-stamped record of every action — message sent, response received, decision made, approval granted — duty of care is defensible. If it can't, every gap in the record becomes a question with no answer.
What "breach of duty of care" actually means
In tort law, a duty-of-care breach has four standard elements: a duty existed, the duty was breached, the breach caused harm, and harm was measurable. The first element rarely gets argued — employers owe a duty of care to employees on premises, and that duty extends to contractors, visitors, and in many jurisdictions to lone workers off-site. The fight is almost always on element two: did the employer take reasonable steps. "Reasonable" is measured against the practices of similar organizations facing similar risks, and the standard isn't fixed. Ten years ago, paper sign-in sheets and a phone tree were defensible. Today they often aren't — and the difference is what's discoverable.
The three records every defense needs
A defensible incident record almost always reduces to three artifacts that the platform should produce automatically:
- The notification log — Who was notified, when, on what channels, what message was sent, and whether delivery was confirmed.
- The response record — Who responded, what status they reported, how long it took, who didn't respond, and how the unaccounted list was resolved.
- The decision trail — Who made each judgment call (approve a visitor, escalate a watchlist match, dispatch a help request, mark all-clear), at what time, and on what information.
Together, these three records reconstruct the incident from the first alert to the final all-clear without anyone having to remember anything. That reconstruction is what proves reasonableness — and reasonableness is what defeats a breach claim.
Who-was-notified-when: the timeline that anchors everything
The single most frequently requested record in a duty-of-care matter is the notification timeline. Discovery requests use a predictable form: "Produce all records of communications sent to employees regarding the incident on [date], including timestamps, recipients, channels, and confirmation of delivery." If the platform fired notifications, that record should exist. If reception called employees personally and nobody wrote it down, the record doesn't exist — and reasonableness becomes a fight over memory.
Castatus Crisis Manager generates the timeline as a byproduct of normal operation. Every Cast logs recipients, the channels each one fired on, the time each response came back (or non-response) from each recipient. The same applies to safety status responses through SafeStatus, watchlist decisions through Visitor Manager, and help requests routed to the Crisis Manager Inbox. The exhibit isn't something the safety team produces under deadline — it already exists.
Per-incident reports versus ad-hoc logs
There's a meaningful difference between a system that retains data and a system that produces incident reports. Retained data requires someone to query, filter, format, and certify the export under deadline pressure. A per-incident report is a single artifact tied to a specific event — the Cast that fired, the responses that came back, the visitors who were onsite, the watchlist decisions made, the help requests routed.
Castatus produces per-incident reports as a default output of the response workflow. When the incident closes, the report is already assembled: timeline, recipients, responses, decisions, approvals. That structure is what regulators, insurers, and litigation counsel actually want. They're not asking for raw data. They're asking for a defensible narrative of who acted, when, and on what information.
SOC 2 Type 2 and why it matters in the lawyers' world
The records have to be trustworthy, not just present. SOC 2 Type 2 is the recognized attestation that an organization's controls around security, availability, processing integrity, confidentiality, and privacy have operated effectively over a measurement period — typically twelve months. For litigation and regulatory review, that distinction matters. A SOC 2 Type 2-compliant platform demonstrates that records weren't tampered with, that access is controlled, and that the audit trail itself is auditable. Castatus maintains SOC 2 Type 2 compliance across the platform. That's not a marketing line — it's the reason opposing counsel can't reasonably challenge whether the records you produce are the records that actually existed.
Common gaps that turn a defense into a problem
Most duty-of-care defenses don't fail because the records don't exist. They fail because the records are scattered across systems that don't connect, written by different people in different formats, and missing the one entry that would have anchored the timeline.
Common gaps:
- Response records that show responses but not the unaccounted list or how it was resolved.
- Visitor logs that don't connect to emergency notifications.
- Help requests that route to a manager's inbox but leave no trace in the platform of record.
- After-action narratives written days later, reconstructed from memory and email.
Each gap is a question opposing counsel will ask, and "we don't have a record of that" is the answer that does the damage.
What to do this week
Pull a recent incident — a drill, a near-miss, a weather event — and try to produce the three records above without consulting anyone. Notification log, response record, decision trail. If you can do it in under thirty minutes, your platform is working. If you can't, the gap you found this afternoon is the same gap you'd be finding under deposition pressure a year from now. The right time to fix it is before the defense rests on it.