Your HITRUST report arrives, the certification is granted, and a list of corrective action plans comes with it. For many teams, the CAP list is the first part of the result they did not plan for. It is also the part that decides how smoothly the rest of the certification period goes.
A corrective action plan is a commitment to fix a specific weakness by a specific date. HITRUST expects it to be worked, not filed. Progress is checked later in the cycle, and an unworked CAP becomes a harder conversation each time it comes up.
This article explains where CAPs come from, what separates a useful CAP from a placeholder, and how to manage them through to closure.
Where CAPs come from
HITRUST's assessment methodology defines when a corrective action plan is required. In broad terms, CAPs are required for requirement statements that score below the levels HITRUST sets, within the scope of a certified assessment. Your assessor and HITRUST's quality assurance process identify which requirement statements need one, and the CAPs are recorded in MyCSF as part of the assessment.
The exact triggers differ by assessment type and change between versions of the methodology. Rather than predicting them from a summary, ask your assessor early in fieldwork which of your weaker requirement statements are likely to need CAPs. That gives you time to plan the remediation while the evidence is fresh.
In an r2, scores reflect maturity levels from policy to managed, so a CAP can arise from weak documentation as easily as from a missing control. Our article on r2 maturity scoring explains how those levels combine.
CAPs are not the same as low scores
Not every low score produces a required CAP. HITRUST's methodology, not your own judgment, decides which ones are required. But nothing stops you from tracking improvement plans for other weak areas alongside the required CAPs. If a requirement statement scored poorly at the measured level and you intend to improve it, a voluntary plan with an owner and a date is good practice.
What a good CAP contains
HITRUST's MyCSF sets the fields a CAP records. Whatever the form, a CAP that holds up when someone reviews it later answers six questions.
What is the weakness? Describe the gap in terms of the requirement statement: which element is missing, at which maturity level, for which part of the scope. "Access reviews do not cover the reporting database" is useful. "Improve access reviews" is not.
Why did it happen? A short root cause. Was the control never designed for that system, or designed and not performed? The answer changes the fix.
What will you do? Concrete corrective actions, in order. Each should produce something an assessor could inspect.
Who owns it? A named role, and the person currently in that role. Ownership by team name drifts.
When will it be done? A scheduled completion date, and interim milestones for anything longer than a few weeks.
How will you show it is fixed? The evidence you expect to produce when the CAP closes: a revised procedure, a configuration export, a set of completed review records.
The last question is the one most often left out, and the one that matters most later. A CAP that defines its own closure evidence can be closed cleanly. A CAP that does not invites a debate about whether it is really done.
Setting dates you can meet
CAP dates are commitments, and missed commitments are visible. Three habits help.
Separate quick fixes from structural ones. A missing procedure document can be written and approved in weeks. A control that needs a new tool, a new integration or a change to how teams work takes longer. Give each its honest timeline.
Allow for operating history. For an implemented control, writing the procedure and switching it on is not the end. The control needs to run long enough to produce the records an assessor will test. A quarterly control fixed in month ten will have one occurrence to show at a month-12 check. Build that into the date.
Leave margin before the next check. If you hold an r2, the interim assessment reviews CAP progress. Aim to close CAPs well before it, not in the week before.
Managing CAPs through the cycle
Treat CAPs as a small program with its own cadence.
Track them where they will be checked
CAP status lives in MyCSF, and that is where your assessor will look. Keep it current there. If you also track CAPs in an internal tool, make the MyCSF record the one you update first, so the two never disagree.
Review them on a schedule
A monthly CAP review is usually enough. For each open CAP, confirm the owner still holds the role, check milestones against dates and record any changes with a reason. The review itself is evidence that the CAPs are being managed.
Close them with evidence
When the corrective action is complete, gather the closure evidence the CAP defined and attach it before marking the CAP closed. Close against the requirement statement, not against the task list. If the requirement covers three systems, all three need to show the fix.
Expect them to be checked
For an r2, the interim assessment includes a review of CAP progress. For any assessment type, the next validated assessment will test the same requirement statements again. A CAP that was closed on paper but not in practice will surface as a low score on the same requirement, which is a weaker position than the original gap.
CAPs and risk acceptance
Sometimes a fix is not worth making. The control would cost more than the risk it addresses, or the system in question is being retired. That is a legitimate decision, but it is a different decision from a CAP.
A required CAP is HITRUST's mechanism, and its rules decide whether a weakness can be handled another way. Do not quietly reclassify a required CAP as an accepted risk. If you believe remediation is not justified, raise it with your assessor and record the reasoning in your risk register. Our article on risk treatment options covers how to document an acceptance properly.
Common CAP mistakes
Restating the requirement. "Implement multi-factor authentication for all remote access" is the requirement, not a plan. The plan names the systems, the method and the steps.
Owners who left. A CAP owned by someone who changed roles six months ago has effectively stalled.
No milestones. A single date a year out gives no warning when the work falls behind.
Closing without the full scope. The fix covers production but not the second environment that was also in scope.
Fixing the symptom. A one-off remediation of the systems sampled, with no change to the process that let the gap appear, tends to recur.
The HITRUST framework page summarizes the assessment types and how CAPs fit into each cycle. If you are still ahead of your first assessment, our guide to preparing for a validated assessment covers how a readiness assessment can surface likely CAPs early.
How TrustLynce helps
The readiness dashboard shows open gaps per framework, with owners, so CAP progress is visible between reviews. The risk register records treatment plans and any risk acceptance alongside the controls they relate to.