PHMSA Pipeline Damage Notification

It captures the core details an operator needs after excavation damage to a gas or hazardous-liquid pipeline: incident timing, asset type, location, impact, immediate actions, and reporting status. The template is structured around the information typically needed to support internal review and PHMSA follow-up. It is not a general incident report, so it stays focused on pipeline damage notification. That makes it easier to route the right details to operations, compliance, and safety.

Use it as soon as excavation damage is discovered or suspected, especially when the event may trigger reporting timelines under 49 CFR Part 191. It is useful whether the damage was found by the excavator, the operator, or a third party. If the event is unrelated to excavation or does not involve a regulated pipeline asset, a different incident form may be more appropriate. The goal is to document the facts while they are still current.

It is usually completed by operations, damage prevention, compliance, or an incident coordinator who can confirm the facts with the field team. The person entering the form should know the asset identifier, location, one-call ticket details, and whether injury, release, or service interruption occurred. A submitter acknowledgment field helps confirm accountability for the record. If multiple people contribute, one owner should still be responsible for final review.

Yes. The form is designed to create a clear record of what happened, when it was reported, and whether follow-up is required. That supports internal audit trail needs and helps teams show how the notification was handled. It does not replace the actual regulatory filing process, but it organizes the facts needed to complete it. Keeping the timeline fields explicit also reduces confusion during review.

Common issues include leaving the incident time vague, skipping the one-call ticket number, and using free-text descriptions where a structured field would be clearer. Another mistake is collecting too much narrative before confirming basic facts like the asset type or whether a release occurred. Teams also sometimes forget to record who discovered the damage and what immediate actions were taken. Those details matter because they shape both the response and the follow-up review.

Yes. You can add operator-specific asset codes, internal escalation contacts, or region-specific review steps without changing the core reporting fields. If your process needs conditional logic, you can show injury, release, or service interruption details only when those answers are yes. That keeps the form shorter and reduces unnecessary data collection. It also helps align the template with your internal workflow.

This template works well with ticketing, incident management, and document storage systems because it produces structured fields rather than a single long narrative. You can route submissions to compliance, operations, and legal review, then store the record with an audit trail. If your workflow uses one-call or GIS references, those can be linked or mapped into downstream systems. The key is to preserve the original submission and any follow-up notes.

Email and chat make it easy to miss required facts, lose the timeline, or end up with conflicting versions of the event. This template standardizes the fields, makes required versus optional items clear, and supports progressive disclosure for details that only apply in some cases. It also gives the team one place to confirm what happened and what was done next. That is especially useful when the event may need formal review or reporting.