Twelve hours to report: the pipeline directive that set the clock for everyone

The week

When ransomware shut down Colonial Pipeline in early May 2021, it exposed an awkward fact. The federal government had no binding cybersecurity rules for the pipeline sector at all. Pipelines carry fuel that much of the economy depends on, yet the industry had relied on voluntary guidelines: good advice that companies could follow, or not.

The attack itself had unfolded fast. Colonial found the intrusion early on May 7 and shut down its pipeline system as a precaution. The line runs from Texas to the New York area and, by the company’s own description, carries roughly 45% of the fuel consumed on the East Coast. Restart began on the evening of May 12, but panic buying and empty filling stations in the Southeast lasted for days.

Two further facts shaped the policy response. Colonial’s chief executive confirmed that the company had paid a ransom of about $4.4 million in bitcoin. And the shutdown was largely precautionary. The ransomware had hit the company’s business network, not the systems that control the flow of fuel. Colonial stopped the pipeline while it established whether those systems were safe. Much of the disruption came from uncertainty rather than damage.

Federal policy was already moving. On May 12, President Biden had signed Executive Order 14028 on improving the nation’s cybersecurity. It dealt mainly with federal agencies and their software suppliers, though, and could not bind a private pipeline operator. TSA’s authority could.

That changed quickly. On May 27, 2021, the Department of Homeland Security announced that the Transportation Security Administration, better known to most people for airport checkpoints but also responsible for the security of pipelines, had issued Security Directive Pipeline-2021-01. It was TSA’s first mandatory cybersecurity requirement for the pipeline sector. A security directive is a binding order that TSA can issue quickly in response to a threat, without the long public comment process that ordinary regulations go through.

TSA’s role in pipelines dated to the agency’s creation after the September 2001 attacks, when it took on security responsibility across transportation modes. For two decades that role was mostly about physical security and voluntary cooperation. Its Pipeline Security Guidelines, last revised in March 2018, included a cybersecurity section, but operators were not required to follow it. A December 2018 GAO review had found that TSA had no documented process for regularly updating those guidelines. Several operators GAO interviewed also questioned whether TSA staff had enough cyber expertise to assess their programs.

The emergency route had its own mechanics. Under 49 U.S.C. 114(l)(2), TSA can issue a directive immediately, without notice and comment, when it judges one is needed at once. Such a directive lapses after 90 days unless the Transportation Security Oversight Board ratifies it. The board, whose members include the Secretaries of Homeland Security and Transportation and the Attorney General, ratified Pipeline-2021-01 on July 3, 2021. The directive took effect on May 28 and was written to expire after one year.

The order came less than three weeks after the attack on Colonial. Ransomware is malicious software that locks an organization’s computer systems, usually by scrambling its data, until a ransom is paid.

The directive asked for three things from owners and operators of critical pipelines. First, they had to report confirmed and potential cybersecurity incidents to CISA, the Cybersecurity and Infrastructure Security Agency, within 12 hours. Note the word “potential”: companies had to report suspicions as well as certainties.

Second, they had to designate a cybersecurity coordinator available around the clock, a named person the government could reach at any hour.

Third, they had to review their practices against TSA’s pipeline security guidelines, identify gaps and remediation measures, and report the results within 30 days. Operators were being asked to mark their own homework against the existing standard, write down where they fell short and how they would fix it, and send it in within a month.

A second directive in July 2021 added specific mitigation requirements, concrete protective steps rather than reporting and review alone.

That second directive, effective July 26, 2021, was handled differently. DHS designated it Sensitive Security Information, so its text went only to operators and others with a need to know. GAO later summarized its main features: mandatory mitigation measures, a cybersecurity contingency and response plan, and an annual review of each operator’s cybersecurity architecture. The May directive had been public. The detailed technical requirements that followed were not.

The May announcement had also said TSA was considering follow-on mandatory measures. Operators therefore read the first directive as an opening move, and they were right.

On its face, this was a narrow rule for one industry. In practice, it set a pattern that regulators in banking, securities, healthcare and critical infrastructure would follow over the next few years: when something serious happens, impose short, fixed obligations and a clock.

Suppose it is 2 a.m. on a Saturday and a monitoring system at a regional utility flags something odd: an administrator account is logging in to servers it never normally touches. The analyst on duty is not sure whether it is an attack or an engineer working late. Under a rule like the one TSA issued in May 2021, that uncertainty does not stop the clock. If this is a potential incident on a covered system, the government expects to hear about it within hours, not after the facts are tidy.

Incident reporting rules ask organizations to make consequential decisions, fast, at the moment they know least.

The directive was narrow, applying only to operators TSA designated as critical. Its significance was what it started: a regulator answering a serious incident with short, fixed obligations instead of new guidance. Over the next two years the pattern spread across sectors. The directive is best read through its three components. Each became a template, and each demands a different internal capability, whether you write such rules or must answer to several of them: the clock, the coordinator, and the gap assessment.

Why governments want to hear early

Regulators care about speed because one organization’s incident is often an early warning for others.

Attackers rarely stop at one company. They reuse the same tools, the same weaknesses and the same tricks across many victims in a sector. If the first victim tells the government quickly, the government can warn the second, third and fourth before they are hit. The analogy is public health: a hospital that reports the first cases of an unusual illness allows authorities to alert other hospitals before an outbreak spreads. A report that arrives weeks later, however accurate, warns nobody.

There is a second reason. When critical services such as fuel, power or payments are disrupted, the government may need to act itself, coordinating with other agencies, reassuring the public or preparing for knock-on effects. It cannot do that if it learns about the problem from the news.

Both reasons explain why the directive valued early, partial information over late, complete information. The trade makes sense for the government. For the organization, it creates real operational and legal pressure.

What a report actually triggers

A report to CISA starts a process, and the reporting organization rarely sees all of it. Analysts look for technical indicators in the report: malicious file signatures, internet addresses used by the attacker, the method of entry. Those indicators can be stripped of the victim’s identity and passed to other operators, to sector information-sharing groups and to partner agencies. When a pattern matters, CISA and its partners can publish an advisory naming the technique and the fix.

For an early report to help anyone, three things must hold. The report must include something technically useful, even if incomplete. The agency must have analysts able to read it quickly. And the warning must reach other operators while it still matters. Weakness in any one link turns a 12-hour report into paperwork.

The case against early reporting

The general case against short reporting clocks is strong and deserves an answer. Early reports are often wrong. A report filed at hour ten may describe an incident that turns out, by day five, to be an engineer’s misconfiguration. If the agency acts on bad early data, it can warn the wrong people about the wrong thing. Reporting also pulls skilled staff away from containment during the hours when containment matters most.

A second objection concerns the flow of information. Operators report in, and many feel little comes back. When reporting is a one-way obligation, companies come to treat it as a compliance cost and write the thinnest report they can defend. Thin reports help no one.

Both objections are real. Each points to a design fix rather than a reason to abandon the clock. A short initial notice with a few required fields, followed by updates, limits the burden. A clear statement that early reports may be revised without penalty reduces the incentive to hedge. And a regulator that shares sector-level findings back gives operators a reason to report well. Where those features are missing, the case for a short clock weakens. Where they are present, it holds.

How an incident actually moves through an organization

The three components make more sense once you follow an incident from the first flicker to the filed notice. The path is similar in a pipeline company, a hospital or a bank.

It usually begins with a machine, not a person. Security software watches activity across computers and networks and raises an alert when something looks wrong. Most alerts are harmless: an employee mistyping a password, a new piece of software behaving unusually, a test. A security analyst, often working in a security operations center (a team, in-house or outsourced, that watches these alerts around the clock), looks at each one and decides whether it deserves more attention.

If it does, the analyst opens an investigation: whether the account is really being used by its owner, whether anything has been copied or changed, whether other machines are involved. This stage can take minutes or days. At some point, someone has to make a judgment call: this is a real incident, and it touches systems that matter.

From there, the situation climbs a ladder. The security leader is told. Then, depending on severity, legal counsel, the communications team, the chief executive and sometimes the board. Each rung adds people with different concerns: the technical team wants to contain the attacker, lawyers want to protect the organization’s position, communications wants to prepare for questions, and executives want to know what it means for customers and operations.

Reporting rules cut across this ladder and do not wait for the organization to finish climbing it. The three components of the directive are really about preparation: knowing in advance when the clock starts, who holds the decision, and what the organization already knows about its own weaknesses.

Where the hours actually go

Most of the delay in an incident happens before anyone senior is told. Organizations that review past incidents usually find the same pattern. The alert fired promptly. It then waited in a queue overnight, or was closed as a false positive and reopened a day later, or went to a manager who was on leave. A reporting clock exposes those gaps because it measures elapsed time, not effort.

Outsourcing adds another hand-off. Many mid-sized operators, banks and hospitals pay a managed security provider to watch alerts at night. The contract governs how fast that provider must tell the client, and through what channel. A contract that allows a four-hour notice window, or permits email-only notice, can consume a third of a 12-hour clock before the client’s own staff are awake. Terms for escalation speed, phone contact and named recipients belong in the same review as the reporting register.

When the incident starts somewhere else

Many serious incidents of recent years began at a supplier, as the 2023 compromise of the MOVEit file-transfer software and the 2024 attack on Change Healthcare showed. Here the organization learns of the incident from someone else, often with few details. Reporting rules differ on whether, and from when, a client must report a vendor’s incident. A prudent working assumption, to be confirmed with counsel, is that a vendor’s notice can start the client’s own clock if covered systems or data are affected.

Vendor contracts should therefore require prompt notice, cooperation with the client’s regulators and access to the facts the client will need for its own report. Many older contracts promise only notice “without unreasonable delay,” which is far too loose when the client has 24 or 36 hours.

The clock: short deadlines and an unclear start

Twelve hours is very short. In the first hours of an incident, an organization often does not know whether an event is malicious, how far it has spread, or what has been affected. The directive covered potential incidents too, so operators had to report before they had answers. That was a deliberate choice: the government valued early warning over accurate detail.

Every reporting rule raises the question of when the clock starts. Is it when an alert fires, when an analyst confirms suspicious activity, or when leadership is told? An “alert” here is an automated warning from security software; it may be a real attack or a false alarm. Without written definitions, the clock either starts too late, risking non-compliance, or the organization over-reports, flooding the regulator with noise and its own executives with false alarms. A workable definition ties the start to a specific event, such as a security analyst confirming malicious activity on a covered system, and names who may make that confirmation.

The template spread quickly, each version with its own trigger. In November 2021, the federal banking agencies finalized a 36-hour notice rule. Banking organizations must tell their primary federal regulator within 36 hours of determining that a significant computer-security incident has occurred, with compliance from May 2022. In March 2022, Congress passed the Cyber Incident Reporting for Critical Infrastructure Act, directing CISA to require reports of substantial incidents within 72 hours and ransom payments within 24 hours. In July 2023, the SEC required public companies to disclose material cybersecurity incidents within four business days of determining materiality. New York’s Department of Financial Services already required 72-hour notice and later added a 24-hour rule for extortion payments. HIPAA breach notification works on a different logic altogether, with a 60-day outer limit.

Notice how the triggers differ. The banking rule runs from “determining” that a significant incident has occurred. The SEC rule runs from determining that an incident is “material,” a legal term meaning important enough that a reasonable investor would want to know. Some clocks start on the incident; others start on a payment. HIPAA, the US law protecting health information, concerns breaches of patient data rather than disruption, and gives far longer.

Discovery, determination and belief

The wording of the trigger matters as much as the number of hours. Clocks fall into roughly three families. Some run from identification or discovery of an incident, as the TSA directives did. Some run from a determination. The banking agencies’ 36-hour rule works this way, and so does the electric sector’s CIP-008-6 standard, which requires initial notice within one hour of determining that a reportable incident occurred. Others run from a reasonable belief, as NCUA’s 72-hour rule for federally insured credit unions has done since September 2023.

A determination-based clock gives the organization room to investigate, but only if the determination is made honestly and promptly. Regulators reviewing a slow report will ask whether the determination itself was delayed. A discovery-based clock offers no such room and pushes the organization toward reporting suspicion. Neither design is wrong. They demand different internal disciplines: a timely decision process for the first, a low threshold and a fast notice template for the second.

Different organizations, different registers

The register looks different by type of organization. A federally insured credit union starts with NCUA’s 72-hour rule, adds state breach-notification laws for members’ personal data, and tracks what its core processor must tell it. A national bank answers to the 36-hour rule. Its bank service providers must, under the same rule, notify it as soon as possible when an incident disrupts covered services for four hours or more.

A broker-dealer has SEC and FINRA expectations and, since the 2024 amendments to Regulation S-P, duties to notify affected customers within 30 days of becoming aware of unauthorized access to sensitive customer information. A health system weighs HIPAA breach notification, state law and contractual duties to payers and partners. A county may owe notices under state law and, where it holds criminal justice information, to the state agency that administers its access. A federal civilian agency reports to CISA within one hour under the federal incident notification guidelines.

One incident, many clocks

A bank holding company with a public listing, a New York license and an insurance subsidiary could face several clocks for one event, each starting at a different moment and going to a different recipient. Suppose such a company discovers ransomware on a Thursday evening. Its banking regulator expects notice within 36 hours of the bank determining the incident is significant. New York’s regulator has its own 72-hour clock. If the company considers paying, a separate 24-hour clock for extortion payments comes into view. And if the incident turns out to be material to investors, the SEC’s four-business-day clock starts once that determination is made. Each recipient wants different information in a different format.

Separate procedures for each rule fail under pressure. What works is a single incident classification step that evaluates every applicable rule at once, supported by a register of obligations listing each trigger, deadline, threshold and recipient.

The cost of over-reporting

Short clocks with low thresholds have a predictable side effect. Organizations report more events that turn out to be nothing. For the regulator, that means more noise to sort. For the organization, each report creates a record, a follow-up conversation and sometimes an examiner’s question months later. Some compliance teams respond by raising their internal threshold, which brings back the risk of a late report.

A better response separates the decision from the paperwork. Decide quickly, using a written threshold illustrated with sample scenarios. Then file a short initial notice and correct it as facts develop. Most regimes expect updates. The banking agencies described the 36-hour notice as an early alert that need not include a detailed assessment, and NCUA said much the same of its 72-hour notice. An initial notice can be brief and qualified, provided it is honest about what is not yet known.

The coordinator: a named person, always reachable

The requirement to designate a cybersecurity coordinator available at all times looks administrative. It answered a real problem. During a crisis, government agencies need to know whom to call, and that person needs the authority and knowledge to answer. Many organizations had security leaders but no primary and backup contact registered with government, and no arrangement for nights and holidays. Colonial itself had been hit on a Friday.

Internally, the coordinator is the natural owner of the reporting decision, the person with authority to start the clock. Making that work requires pre-agreed escalation paths to legal, communications and executive leadership, and a decision log that records when each threshold was assessed, by whom and on what facts. An escalation path is simply a written list of who must be told what, and when, as a situation grows more serious.

Regulators reviewing a late report later will ask exactly those questions, and a contemporaneous log answers them better than recollection. “Contemporaneous” means written at the time, not reconstructed afterward. Months after an incident, memories blur and people disagree about who knew what on which day. A timestamped log, kept as events unfold, settles those arguments and shows a regulator that decisions were made in good faith.

Templates help too. Each recipient wants different fields. Having pre-drafted notices for each, with the factual sections left blank, saves hours when hours are what the rule allows. Some organizations rehearse the reporting decision as a distinct inject in tabletop exercises, timing how long it takes from first alert to a filed notice. A tabletop exercise is a structured discussion in which leaders walk through a made-up crisis around a table; an “inject” is a new development the facilitator introduces partway through, such as “a regulator is on the phone asking for an update.”

What the role needs to work

A coordinator designation fails in predictable ways. The named person changes jobs and the registration is never updated. The backup lives in the same city and takes the same holiday. The contact number is a desk phone in a building the incident has made unusable. Ransomware also tends to take down email, directory services and sometimes voice systems. A playbook that assumes corporate email works will fail on the first morning.

The fixes are mundane. Register a primary and at least one backup with each regulator, and review the registrations on a calendar, with an owner. Keep an out-of-band channel, such as a separate messaging service and printed contact lists, that does not depend on the corporate network. Keep an offline copy of the reporting register and the notice templates. TSA’s later rail directives required the coordinator to be a U.S. citizen eligible for a security clearance, a reminder that some regimes care who the person is as well as whether someone answers.

Authority, counsel and privilege

The coordinator’s authority must be real. If every reporting decision needs sign-off from the general counsel and the chief executive, the coordinator is a switchboard. The clock runs while approvals are chased. A workable design lets the coordinator file an initial notice on defined facts, with legal informed in parallel rather than in sequence.

Lawyers often want incident work routed through outside counsel, to protect privilege over forensic findings. The instinct is sound, but it has limits. In litigation after Capital One’s 2019 breach, a federal court in 2020 ordered the bank to produce a forensic report it had argued was protected. Privilege arrangements also cannot pause a regulatory deadline. The reporting decision and the privileged investigation should run on separate tracks, with each notice limited to facts the organization can stand behind.

Small organizations and shared roles

A community bank, a rural hospital or a small municipal utility may have one security professional, or none. For them, a round-the-clock coordinator is a staffing problem. The options are a rotation shared with IT leadership, a managed provider that handles first response, or an arrangement with a parent company or shared service organization.

A provider can watch alerts and gather facts. It should not make the reporting decision, which carries legal consequences for the client. The coordinator role can be shared, but the authority to start the clock should stay inside the organization.

The gap assessment: self-review with a deadline

The third component required operators to assess themselves against existing guidelines and report gaps within 30 days. That turned voluntary guidance into a documented baseline, and gave the regulator a sector-wide view of where weaknesses lay.

For operators, this was in some ways the most demanding requirement. It required honest internal evaluation on a short timeline, and it created a written record regulators could later compare against actual practice. Admitting a gap creates a duty to fix it. Claiming compliance that does not exist creates a different and worse problem. General counsel will recognize the dilemma: a candid self-assessment is a document that may be read by regulators, auditors and, after an incident, possibly by litigants.

Organizations that already kept a current assessment against a recognized framework, with evidence attached to each control, found the requirement manageable. Those that did not had to build one in a month. A “framework” here is a published checklist of security practices; a “control” is an individual safeguard on that list, such as requiring strong passwords or keeping backups offline. “Evidence” means proof the control actually works, such as a configuration report or test result, rather than a policy saying it should.

What a regulator does with the answers

Self-assessments collected across a sector give the regulator something it rarely has: a comparable view of where many operators fall short on the same controls. If most report the same gap, a follow-on requirement can target it. TSA signaled exactly that path when it announced that further mandatory measures were under consideration. The assessment also gives the regulator a baseline for later inspections, and that baseline is where the operator’s exposure lies.

Confidentiality matters here. TSA treated the detailed July directive as Sensitive Security Information, and operators’ submissions raised similar concerns. Federal reporting regimes have struggled with this. In 2023 the DHS-led Cyber Incident Reporting Council recommended exempting cyber incident information reported to the government from Freedom of Information Act requests. Organizations should ask counsel what protections apply to their own submissions before they write them.

Choosing the yardstick

The pipeline directive named TSA’s own guidelines as the yardstick. Other sectors use different ones, and the choice shapes the work. Many organizations map their controls to the NIST Cybersecurity Framework, which most regulators recognize. Banks long used the FFIEC Cybersecurity Assessment Tool, which the FFIEC retired at the end of August 2025, pointing institutions to NIST CSF 2.0 and CISA’s Cybersecurity Performance Goals. Health systems face the HIPAA Security Rule’s risk analysis requirement. Federal agencies work to NIST SP 800-53 controls under FISMA.

An organization subject to several regimes should keep one control library and map each control to every framework it answers to. The mapping is tedious to build and easy to maintain. It lets one piece of evidence, such as a quarterly restore test from offline backups, satisfy several requests at once.

Two operators, one request

Take two mid-sized operators that receive the same 30-day request. The first has kept a spreadsheet for years listing each item in the relevant guidelines, whether it is in place, who owns it, and a link to proof such as a recent test report. Its team spends a week checking that the entries are current, a few days writing up the gaps it already knew about, and sends the response with time to spare.

The second has never done this. Its team spends the first two weeks just finding out who knows what. Engineers in different regions give different answers to the same question. Some items cannot be verified at all in the time available. The final document is hedged and incomplete, and its leaders are left uneasy about what they have signed. Neither company is necessarily less secure than the other, but only one of them can show it.

The template spread here too. Later rules increasingly asked organizations to document their programs, test them and certify the results, with senior officials signing. The capability that matters is a living control assessment, maintained continuously and mapped to each framework a regulator might cite, so that a 30-day request becomes an export instead of a project.

The honesty problem

Short deadlines invite optimistic answers. A team asked to grade itself in 30 days, knowing the grade goes to a regulator, may round up. A control that is partly in place becomes “implemented.” A plan with no budget becomes “in progress.” Those answers turn into liabilities when a later incident shows the control was missing.

DHS’s inspector general found, in a 2023 audit, that TSA had not ensured in a timely way that all critical pipeline operators met the July 2021 directive. Several had not met one or more of its requirements. The finding concerned the regulator’s follow-up, but it shows how far a sector can be from the standard it has been told to meet.

Two practices help. Each status claim should cite evidence that someone outside the control owner’s team has checked. And partial implementation should be recorded as partial, with a dated remediation plan. A regulator can work with an honest gap and a plan. It has far less patience with a claim of compliance that later proves false.

What a late report costs

Legal and regulatory risk. Missing a reporting deadline is a compliance failure in its own right, separate from the incident. An organization can handle an attack well technically and still face regulatory criticism for telling the right people too late.

Personal accountability. As rules increasingly ask senior officials to sign certifications, cybersecurity becomes a matter of individual as well as corporate responsibility.

Reputation. Public disclosure rules mean the market and customers may learn of an incident on a fixed timetable. The quality of that first statement shapes trust for months.

Cost and staff. Building a reporting process once is cheap. Improvising it during every incident is expensive and exhausting, and it pulls the most knowledgeable people away from fixing the actual problem.

How personal accountability has played out

Two widely reported cases show the range. In October 2022 a federal jury convicted Uber’s former chief security officer of obstruction and concealment over his handling of a 2016 breach. That case involved active concealment from the Federal Trade Commission, which is very different from a late report, but security leaders everywhere took note.

In October 2023 the SEC sued SolarWinds and its chief information security officer over disclosures before and after the Sunburst intrusion. A federal judge dismissed most of the claims in July 2024, and the SEC dropped the rest in November 2025. The two cases point in different directions. Concealment can carry personal criminal risk. Disclosure judgments made in good faith are much harder to attack when the reasoning was written down at the time. The decision log is what separates the two in the record.

The cost that never appears on an invoice

Reporting failures also damage the relationship with the supervisor, and that relationship has practical value. An examiner who trusts a bank’s incident process will give it latitude in the next incident. One who learned of an incident from the news will not. The same holds for a state health department or a federal grant agency. Goodwill of this kind is hard to measure and slow to rebuild.

The prepared bank, and where others fall short

A well-prepared regional bank can tell you, on a single page, every reporting obligation it faces, what triggers each, how long it has, and who receives the notice. It has named a coordinator and a backup, both reachable on holidays. It keeps a running decision log template ready to open the moment an incident starts. Its draft notices sit in a shared folder. And it has rehearsed the process at least once a year, with a stopwatch.

The equivalent picture differs by sector. A prepared health system keeps the same register, but its longest clocks concern patient data and its most urgent decisions concern clinical disruption. It adds a decision path for diverting ambulances and switching to downtime procedures. A prepared county has agreed in advance which office speaks for it, since an elected board, a sheriff and a clerk may each hold data and each want to control the message. A prepared broker-dealer has mapped which events trigger customer notices under Regulation S-P and which would trigger a filing by a listed parent company.

The common feature is that preparation happens before the incident, by people who know the rules, and is tested by the people who will have to use it. A process written by compliance and never rehearsed by the security team fails at the first ambiguous alert.

The gaps elsewhere tend to be the same few:

• Undefined start times. Nobody has agreed in writing when the clock starts, so the question is argued during the incident.
• One rule at a time. Separate teams track separate regulations and never compare notes until a real event forces them together.
• A coordinator in name only. A person is listed but lacks the authority to make the reporting call, or has no backup.
• Memory instead of records. No contemporaneous log, so decisions cannot be explained later.
• Assessment as a one-off project. A self-review is produced for a deadline and then left to go stale.

Most of these gaps are cheap to close. A register takes days to build. A decision log template takes an afternoon. A coordinator registration takes a phone call. The expensive part is the rehearsal, because it takes senior people away from other work for half a day. That half day is the best value in the program, since it exposes every assumption that will not hold at 2 a.m.

Before the next 2 a.m. alert

1. Do we have a single list of every incident reporting obligation we face, with its trigger, deadline, threshold and recipient?
2. For each one, have we defined in writing exactly when the clock starts, and who decides?
3. Who is our named coordinator, who is the backup, and could a regulator reach one of them at 2 a.m. on a holiday?
4. When did we last time ourselves, in an exercise, from first alert to a filed notice?
5. If a regulator asked for a self-assessment against a recognized framework within 30 days, could we produce it from what we already have?

An exercise built around those questions should use the organization’s own systems and a realistic, ambiguous start: an alert on a weekend, a vendor email with few details, a key person unavailable. Time each step. Record when each reporting threshold was considered and by whom. Then compare the log with the register, and fix whatever the stopwatch reveals before the next real alert arrives.

With hindsight

TSA lengthened the pipeline reporting window from 12 to 24 hours in May 2022, revised its pipeline directives that summer to be more performance-based after industry objected to prescriptive requirements, and in late 2024 proposed formal rules for pipeline and rail cybersecurity. “Performance-based” rules say what outcome must be achieved and leave companies to choose how; “prescriptive” rules spell out the specific steps. The shift reflects a recurring tension between regulators who want certainty and operators who know their own systems best. The 2021 directive now reads as the first move in an effort that has still not settled.

The details of that first year are instructive. The May 2022 renewal, known as Pipeline-2021-01B, made the change from 12 to 24 hours. TSA said the change aligned pipelines with the timelines already applied to other surface transportation and aviation operators. The renewal also narrowed the definition of a reportable incident, and the series was extended again in 2023.

The July 2022 revision of the second directive replaced fixed technical requirements with outcomes. Operators had to submit a cybersecurity implementation plan for TSA approval and run an assessment program with an annual plan. Later revisions kept that approach.

Oversight caught up more slowly. A September 2023 audit by the DHS Office of Inspector General found that the 2021 directives should strengthen pipeline security. It also found that TSA had not ensured, in a timely way, that all critical operators met their requirements. By then the template had spread across TSA’s own remit. In December 2021 it had issued directives with 24-hour reporting and coordinator requirements for higher-risk railroads and rail transit. Its November 2024 proposed rule, which would make such requirements permanent for pipelines and rail, took comments into February 2025.

CISA proposed its rule under the 2022 reporting law in April 2024; the final rule missed its statutory deadline of October 2025 and, as of this writing, has still not been published, so organizations should check its status. One of the most significant reporting regimes for critical infrastructure is therefore still not in final form years after Congress asked for it.

CISA’s own timeline slipped more than once. In 2025 the agency set a target of May 2026 for the final rule. That date passed too, and in early 2026 CISA held town hall meetings seeking further input on implementation. The statutory clocks are fixed by the 2022 law: 72 hours for covered incidents and 24 hours for ransom payments. What remains open is who is covered and what a report must contain.

The scale of the patchwork was documented in September 2023, when the DHS-chaired Cyber Incident Reporting Council counted 45 federal incident reporting requirements administered by 22 agencies. It recommended common definitions, a model reporting format and the removal of legal barriers to sharing reports between agencies. Some regulators moved toward CISA’s terms on their own. NCUA, for one, built its 2023 credit union rule on CIRCIA’s definitions.

Congress and regulators repeatedly acknowledged that overlapping reporting requirements burden companies at the worst moment of an incident, and harmonization has been achieved only in part. That means executives should not expect the patchwork of clocks to simplify soon. Each new rule is more likely to add a line to the register than to replace one.

Personal accountability also took a less dramatic course than many feared in 2023. The SEC’s case against SolarWinds and its security chief, the most closely watched test, ended in dismissal in November 2025. The incentive to document decisions as they are made has not weakened as a result. A record written at the time remains the best evidence of good faith.

Organizations that built one classification process covering all their obligations, with clear decision rights and a documented log, have absorbed each new rule as an update instead of a reinvention. A rule-by-rule approach turns every new regulation into a project and every incident into a scramble. A single process, owned by a named person, rehearsed and recorded, turns new rules into routine maintenance and lets the people who understand the technology spend the first hours of an incident on stopping it.