The 72-hour TSA cyber-incident clock: what surface-transport operators need pre-staged

A practical guide for motor carriers, freight rail, public transit, and pipeline operators. What TSA's Security Directives actually require when a cyber event hits, and what your incident playbook needs to look like before the clock starts.

Key 102 Consulting · 2026 · Veteran-owned. SAM-registered. Practitioner-led Nexus engagements for TSA, FMCSA, and PHMSA- regulated operators.

---

The clock starts when the event hits, not when you start drafting

It's 11:47 PM on a Wednesday. Your dispatch system stops accepting loads. The screens go black. A note appears demanding payment. Your operations manager has been awake for nineteen hours and is now calling you. Somewhere in that conversation, someone remembers that TSA wants a cyber-incident report within 72 hours.

You hang up. You search your laptop for the incident reporting template. There isn't one. Your last cybersecurity tabletop was seven months ago. Nobody remembers the exact CISA submission URL. The cleared safety officer who used to know this stuff retired in March. It's almost midnight, and a clock you didn't notice starting has already taken nearly an hour off your 72.

This is the position most surface-transport operators are in. Not because they're negligent — because the regulatory shift toward formalized cyber reporting happened recently and the operational muscle memory hasn't caught up. This paper covers what TSA SD-1580 and SD-1582 actually require, what "pre-staged" means in practice, and how to structure your incident playbook so the next time a clock starts you're already running.

What the directives actually require

TSA's Security Directives for surface transportation — SD-1580 series for freight rail, SD-1582 series for passenger transit, and the SD-Pipeline series for pipeline operators — codify several mandatory cyber requirements. The reporting requirement is the most time-sensitive.

The 72-hour clock. A reportable cybersecurity incident must be reported to the Cybersecurity and Infrastructure Security Agency (CISA) within 72 hours of discovery. Discovery is the moment your organization knew, or reasonably should have known, that an incident had occurred. Discovery does not require root-cause clarity, full scope assessment, or confidence about the threat actor. The clock starts when someone in your operations chain reasonably suspects an incident has happened.

The trigger event. "Reportable cybersecurity incident" is defined broadly enough that most operators err on the side of over- reporting once they understand the definition. The categories include:

• Unauthorized access to a system supporting transportation operations
• Disruption to operations from a cyber cause (ransomware, denial-of-service, insider sabotage)
• Compromise of safety systems, dispatch systems, signaling, or control systems
• Discovery of malicious code on systems supporting transportation
• Discovery of unauthorized communications to or from transportation systems
• Loss of data necessary for operations

Notably, this includes events that might affect operations, not only events that have affected operations. A confirmed ransomware foothold on an IT system that could pivot into the OT environment is reportable even if it hasn't yet.

The report content. TSA expects, at minimum: the time of detection, the affected systems, the operational impact (current and projected), the mitigation actions taken, the parties notified, and the operator's point of contact for further communication. Some of these are knowable in the first hour; some take longer. TSA permits initial reports with placeholder values that get updated as the investigation matures.

Additional reporting paths. Surface-transport operators are often layered under multiple regulators. CISA receives the cybersecurity incident report. FMCSA may require notification for motor carriers under specific conditions. PHMSA's pipeline safety controls have separate reporting paths for safety-related cyber events. The Department of Transportation's overarching guidance may apply. A single event can require notifications to three or more federal entities on different clocks.

The Stop Movement Order risk

The 72-hour reporting failure isn't an administrative slap. TSA has the authority — exercised sparingly but exercised — to issue a Stop Movement Order against an operator whose cyber posture is deemed an active threat to the transportation system. A Stop Movement Order means the operator's fleet, trains, or pipeline operations are halted by federal authority.

This is the highest-stakes immediate consequence in any cybersecurity regulatory regime. HIPAA fines accumulate over time. PCI non-compliance puts your acquirer relationship at risk. CMMC non-compliance affects future contract awards. A TSA Stop Movement Order stops revenue and operations within hours.

The Stop Movement Order is rare. The pre-Stop Movement scrutiny — TSA Field Inspections, on-site cybersecurity reviews, mandatory mitigation orders — is less rare. Operators who fail to report within 72 hours are signaling to their regulator that they can't even surface what's happening on their own systems. The signal matters; the implications scale from there.

What surface-transport operators get wrong

Five failure patterns repeat across post-incident reviews:

1. The playbook doesn't exist. The operator has a "cybersecurity program" documented at the policy level — encryption, MFA, access controls — but no specific document that answers "when an incident happens, who calls whom, in what order, with what information template?" The 72 hours is consumed assembling the document the incident requires.

2. The discovery chain is broken. Operations staff who notice the anomaly don't know whom to escalate to. The IT team escalates to the CISO. The CISO escalates to the operations director. The operations director doesn't know about the regulatory reporting clock. By the time the right person is in the room, 12 hours have passed and CISA's clock has already burned through 17% of the window.

3. The submission mechanics are unknown. Where does the report go? CISA's incident reporting portal, but which form? What's the operator's CISA-assigned point of contact, if any? Are there specific email distribution lists for TSA Surface Transportation Office? The submission mechanics get figured out during the incident, which adds hours.

4. Evidence preservation is reactive, not proactive. Logs that existed at 11:47 PM are no longer there at 7:00 AM because retention was set to 8 hours. The forensic story is missing the critical window. TSA, CISA, and any subsequent FCA or insurance investigator all want the same evidence pool, and that pool has already evaporated.

5. The notification list is incomplete. TSA gets the report on hour 71. CISA gets it on hour 70. But the prime contractor whose freight is sitting on the affected line wasn't notified, the BAA- covered parties weren't notified, the cyber insurance carrier wasn't notified within their contractual window, and the state emergency management office wasn't notified. Each of those is a separate clock, with separate consequences for non-notification.

What pre-staged actually means

A pre-staged incident playbook isn't a 60-page binder gathering dust on a shelf. It's a working document an on-shift operations manager can execute in the first 15 minutes of an incident, before the cybersecurity team has full situational awareness.

Six elements distinguish a working playbook from a paper one:

Named roles, current humans. The playbook names the on-call incident commander, deputy commander, communications lead, legal counsel, and external counsel. Names — not "the Director of IT," but Alex Rodriguez (cell: 602-...). The names get updated quarterly because humans rotate.

Discovery-to-escalation tree. When a dispatcher notices that loads aren't coming through, what's the first call they make? Who's the second escalation? Third? Fourth? The tree is documented at the operations level, not buried in IT policy.

CISA / TSA submission templates pre-filled. The reporting forms are pre-filled with the operator's identifiers, point-of- contact data, system inventory excerpts, and any standing language TSA wants. At 11:47 PM the only blanks an operations manager has to fill are the event-specific details — not the operator's UEI or the chief safety officer's title.

72-hour timeline mapped against the operator's clock. Hour 0 trigger; hour 1 escalation; hour 2 incident command stood up; hour 6 first situational-awareness brief; hour 24 mitigation initiated; hour 48 initial regulatory submissions drafted; hour 71 CISA submission filed. Each hour has an owner, an action, and an evidence artifact that should exist by the end of the hour.

Evidence preservation triggered at hour 1. Log retention extended to indefinite for the affected systems; OT control network snapshots taken; physical evidence (badge logs, video, visitor records) preserved. The preservation kickoff isn't a discussion; it's a checkbox in hour 1 of the playbook.

Multi-regulator notification matrix. Each regulator (CISA, TSA Surface Transportation Office, FMCSA, PHMSA where applicable, state EMA, cyber insurance carrier, prime contractor relationships, customer notification chains) gets its own row with its own clock, contact path, and template. The matrix is visible to whoever is running the incident at hour 6, not discovered at hour 60.

Drilling the playbook

A playbook nobody has executed is fiction.

The drill cadence that works for surface-transport operators:

• Quarterly tabletop exercises. A walk-through of a realistic scenario with the incident commander, deputy, communications lead, and operations manager. Two to three hours. Documentation of what worked and what didn't. The tabletop is the cheapest way to find playbook gaps before an event does.

• Annual full live-fire drill. Simulate the discovery of an incident. Activate the incident commander chain. Run the 72-hour clock in compressed time. File the CISA submission template (marked TEST). Notify the cyber insurance carrier (with notice that it's a drill). Measure the actual elapsed hours per stage.

• Post-real-incident debrief. Within 30 days of any real cybersecurity event — not just reportable ones, any event — the playbook is reviewed for what the event taught. Lessons-learned items become playbook revisions before the next quarter.

How Key 102 stages this for Nexus customers

The Key 102 Nexus tier delivers a pre-staged TSA SD-1580/82 incident playbook as the customer's first major deliverable — typically within the first 30 days of engagement. The playbook is authored by a practitioner working in your specific operational context (motor carrier, transit, freight rail, pipeline — each has distinct nuances), populated with your specific identifiers and escalation chains, and delivered as a recipient-verifiable PDF that your TSA inspector can validate independently.

Subsequent quarterly Consultant Review touchpoints exercise the playbook through tabletop scenarios. The Audit Co-Pilot tier extends this with on-call practitioner availability during real incidents — the practitioner who built your playbook is available during the 72-hour window to walk it with you.

The 72-hour clock will start someday. Your playbook either exists in working form before it starts, or you'll be drafting it while the clock runs.

---

Start your TSA / FMCSA / PHMSA prep with Key 102

Key 102 Consulting is veteran-owned, SAM-registered, and based in Phoenix, Arizona. Our Nexus tier delivers practitioner-led readiness across the surface-transportation regulatory stack: TSA SD-1580 / SD-1582 / SD-Pipeline, FMCSA cybersecurity baselines and 49 CFR §395 (ELD), PHMSA pipeline safety controls.

Every artifact — incident playbook, control library, quarterly readiness report, Master Audit Report — carries a named practitioner signature, server-side SHA-256 hash, RFC 3161 TSA timestamp, and a public verify endpoint your TSA inspector can validate independently of Key 102.

UEI: TXQFV5FJX797 Primary NAICS: 541519 (Other Computer Related Services) Additional NAICS: 541512 · 541690 · 611420 PSC Codes: DJ10 · DJ01 · D302 · R499 · U099

Start with a $674 Mission Brief →

The Mission Brief is a 90-minute diagnostic engagement with Tammie and a practitioner. Surface-transport operators walk out with a scoped readiness plan and an initial SD-1580/82 alignment artifact. The $674 credit converts 1:1 into Nexus Guided / Managed / Audit Co-Pilot within 14 days.

---