A change request that realigns future work with the plan after performance has already drifted away from it.
Corrective action is one of the three ordinary categories of change request, alongside preventive action and defect repair, and it is the one that looks backwards. Something has already gone off plan, and the request changes how the remaining work will be done so the plan can still be met. Two things follow from that. It does not alter the baseline, so performance after it is approved is still measured against the same document, and it is not a fix for a delivered defect, which is a quality finding and belongs in the defect repair category. Corrective actions are usually raised off the back of an issue log entry, which is why an issue log with no change requests behind it is worth looking at twice.
See also
The named group holding authority to approve or reject a change request, and the only body that can move an approved change into the baseline.
The list of events that have already occurred and are affecting the work, each with an owner and a resolution date. Likelihood no longer applies.
Where this comes up
Predictive work gets an ending for free, the day the thing is handed over. Iterative work has to manufacture one, which is why so much of it never formally ends at all.
Three types, separated by one variable: how much authority the office holds. Supportive advises, controlling requires, directive runs the work. Level is a second axis and a different question.