How to Write a Corrective Action: Key Steps and an Example Plan
A corrective action that isn't specific, owned, and dated is just a suggestion someone will forget by next week.
A corrective action is the documented fix that follows an incident report: the step, or set of steps, taken to address the root cause of a hazard rather than just its symptoms. Writing one well starts with a clear incident report that captures what happened and why, since a vague starting point almost always produces a vague fix. From there, the action itself needs to name exactly what will change, who is responsible for it, and how the fix will be confirmed to have worked.
What Is a Corrective Action?
A corrective action is a documented, assigned step taken to eliminate the cause of a hazard or incident so it doesn't happen again. It's different from a quick fix: a quick fix clears the immediate danger, while a corrective action addresses why the danger existed in the first place.
Why It Matters
An incident report that ends without a corrective action just describes a problem that will recur. Writing the action down, with an owner and a deadline attached, is what turns a near-miss or a hazard into an actual improvement instead of a story people tell after the next one happens.
From report to fix
How to Write a Corrective Action
Writing a corrective action that actually gets carried out follows a fairly consistent shape, whether the hazard is a loose guardrail or a recurring near-miss.
Start from the detailed observations and factual data captured in the incident report, not from memory. A clearly defined problem gives everyone involved the same starting point, so the fix that follows addresses the actual hazard rather than a version of it that got fuzzy in the retelling.
Once the problem is written down plainly, bring in the people who actually work in that area. Cross-departmental input tends to surface fixes a single department would have missed, and it also makes ownership less of an afterthought once a solution is picked.
Set a specific timeline for each phase of the fix and assign it to someone with the authority to actually see it through. Check progress against that timeline on purpose, not by accident, so a fix that's stalling gets caught and adjusted before the deadline slips.
Better fixes come from more than one desk
Bring the Right People to the Table
The person who wrote the incident report usually isn't the only person who understands the hazard. Cross-departmental input, from maintenance, from the crew working the area, from whoever inherits the fix, tends to surface a better solution than one person guessing alone at a desk.
A five-minute conversation before drafting the action often saves a rewrite later.
Ownership beats good intentions
Assign It to a Person, Not a Team
"Facilities" doesn't install a safety gate; a named person does. Whoever picks up the corrective action should be someone in the room when it's assigned, not someone who finds out about it secondhand once the deadline has already passed.
What separates a real fix from a formality
Key Information to Include in a Corrective Action
A corrective action is only as useful as the specifics behind it. These five pieces of information are what make the difference between a fix that happens and one that quietly stalls.
State exactly what needs to be done, using clear, actionable verbs like "Install," "Replace," or "Redesign," not vague language like "address" or "look into."
Example: "Install a self-closing safety gate at the top of the mezzanine ladder."
A corrective action without a name attached to it rarely gets done. Assign a specific individual, not a department, to own the completion of the fix.
Example: "Site Maintenance Manager (Alex R.)"
Set a specific completion date based on the level of risk the hazard presents, not on whoever happens to be free that week.
High risk: immediate or within 24 hours. Medium risk: 7 days. Low risk: 30 days.
Note any tools, budget, or outside contractors needed to finish the fix. This is what prevents a good plan from stalling out because nobody ordered the part it depended on.
Example: requires purchase of industrial-grade non-slip adhesive strips and a heat gun for application.
Explain how someone will confirm the fix actually worked and didn't introduce a new hazard in the process. This is the step most often skipped, and the one that catches a fix that looked fine on paper but didn't hold up.
Example: "Safety officer to inspect the area 48 hours after installation to confirm the adhesive is cured and effectively preventing slips."
Where fixes fall apart
Common Mistakes When Writing Corrective Actions
Most corrective actions that stall don't fail because the fix was wrong, they fail because of how the action itself was written.
- Vague action language, like "improve signage" instead of naming the sign, the location, and the wording
- No named owner, so a "team" is accountable and, in practice, nobody is
- A deadline that ignores risk level, treating a high-risk hazard with the same timeline as a minor one
- Skipping verification, so a fix that didn't actually work goes unnoticed until it fails again
- Treating the symptom, clearing the immediate hazard without addressing why it happened
Getting everyone on the same page
Sign-Off Should Involve More Than One Person
A corrective action that's only reviewed by the person who wrote it tends to inherit that person's blind spots. Once a fix is drafted, a second set of eyes, ideally someone from the affected trade or department, should confirm it actually addresses the hazard before it's logged as complete.
Sign-off is quick to build into the process now and expensive to add after a fix has already failed.
Seeing it in practice
Example Corrective Action Plan
Hazard identified: trip and impalement risk due to protruding rebar in the Zone B stairwell. Here's how that hazard moved from an immediate fix to a permanent one.
Turn a one-off fix into a standard
Try Our Corrective Action Form Builder
View corrective action templates, forms, and examples, then set up a builder that captures ownership, deadlines, and verification every time.