Most common HITRUST corrective action plans

Which HITRUST corrective action plans come up most often

The most frequent corrective action plan (CAP) in 2024 was a Third-Party Assurance requirement to review service level agreements at least annually against monitoring records, according to the HITRUST 2025 Trust Report. It was followed by a Network Protection requirement on managing and monitoring network service providers, a requirement to define how often audit logs are reviewed, how reviews are documented and who performs them, and a Vulnerability Management requirement on secure coding guidelines that prevent common flaws such as injection and cross-site scripting. If your validated assessment is failing or a customer has asked for your HITRUST report, these four are the first places to check your evidence.

The organization owns each control and the fix. An implementation partner can help prepare systems, logs, configurations and evidence, but it cannot decide that a control is operating. Start by pulling the last twelve months of SLA reviews for your critical third parties and confirming that each review is dated, signed and linked to monitoring data. Then confirm who reviews audit logs, how often, and where the review record lives. Ask your development leads to show the secure coding standard in use and the scanning results that test it. Access and continuity items follow the same pattern: a dated, owned record is what an assessor will test.

Only a HITRUST Authorized External Assessor can perform the validated assessment, and HITRUST performs central quality assurance before any report is issued. Before the fieldwork window opens, confirm with your assessor which requirement statements they will sample, whether a gap or CAP would apply under your assessment type, and what evidence they will accept for each. The HITRUST Assessment Handbook sets out these assessment rules and is the document to check your plan against.

Which requirements sit at the top of the CAP list

The HITRUST 2025 Trust Report ranks the requirements that most often need a corrective action plan in 2024. The cards below cover the top-ranked items and the domains they sit in, so you can check your own control set against the same patterns before an assessment begins.

Annual third-party SLA review

The most frequent CAP in 2024 was a Third-Party Assurance requirement to review service level agreements at least annually and compare them against monitoring records. Assessors look for a dated review of each vendor SLA, with the findings tied to the performance reports you actually collected. A signed SLA on file with no review record is the typical gap. Check that every material vendor has a review cycle and a named owner.

Network service provider monitoring

The second most frequent CAP was a Network Protection requirement on managing and monitoring network service providers. Network Protection accounted for 7.3% of failing domains in 2024. Organizations that outsource connectivity, firewall management or managed detection need evidence that the provider's activity is monitored, reviewed and recorded, not only contracted. Confirm who reviews provider access logs and how often.

Defined audit log review

The third most frequent CAP required organizations to define how often audit logs are reviewed, how each review is documented and who performs it. Audit Logging & Monitoring accounted for 9.8% of failing domains, tied for second. Logs being collected is not enough; the assessor will look for a written frequency, a named reviewer and dated records of findings. Confirm that your logging procedure states all three.

Secure coding guidelines

The fourth most frequent CAP was a Vulnerability Management requirement for secure coding guidelines that prevent common flaws such as injection and cross-site scripting. The guidance must be written, published to development teams and applied in practice. Assessors often test it by reviewing code review records or scanner results against the stated guidelines. Confirm the guideline covers the flaw classes your applications actually face.

Access reviews and account controls

Three of the top 10 requirements needing a CAP were in Access Control. They covered account lockout, reviewing access when a person changes role or leaves, and at least annual review of accounts and privileges. Each requirement needs a dated review record and evidence that access was changed when it should have been. Pull a sample of recent role changes and departures to test whether access was removed on time.

Formal authorization of new systems

The eighth most frequent CAP was a Risk Management requirement that management formally authorize new systems and review those authorizations. Risk Management accounted for 9.8% of failing domains, tied for second. Assessors look for a signed authorization decision before go-live and a later review of that decision. Check whether your change process produces this record for every new system, including cloud services adopted by individual teams.

Continuity planning requirements

The ninth most frequent CAP was a Business Continuity & Disaster Recovery requirement on continuity planning. The domain accounted for 4.9% of failing domains in 2024. Assessors expect a documented plan that names recovery roles and has been reviewed or exercised, not a plan that predates the current environment. Confirm the plan reflects your current systems and that its last review date is recorded.

Open source software usage

The tenth most frequent CAP sat in Data Protection & Privacy, which the Trust Report named the lowest scoring i1 domain in 2023 and tied lowest for r2 in 2024. The requirement concerns how the organization governs open source software it uses. Organizations running self-hosted open-source platforms should keep an inventory of components, their licenses and their update status, and confirm the policy that governs their use.

How the failing domains line up with these CAPs

Third-Party Assurance produced the most frequent CAP in the 2024 data, while Network Protection carried the second most frequent one. Both involve oversight of parties outside your direct control, so the work is largely about proving that monitoring happens and is recorded. The 2025 Trust Report's domain table is the place to confirm the Third-Party Assurance share of failing domains, since this tab uses only the Network Protection figure.

Annual SLA review: Show that service level agreements are reviewed at least once a year and that the review is compared against the monitoring records you already keep.
Service provider monitoring: Document how network service providers are managed and monitored, including who reviews their access and output.
Network Protection share: Network Protection made up 7.3% of failing domains in 2024, so it fails less often than logging or risk management but still appears in a meaningful number of reports.
Evidence trail: Keep dated review records, sign-offs and provider reports together so an assessor can trace each requirement to a result without interviews.

Check that every third party in scope has a current agreement, a named reviewer and at least one monitoring record for the period under test.

What fixing a CAP involves, step by step

The sequence confirms each gap against its requirement, assigns ownership, builds a working control with a recurring record, runs it long enough to generate evidence, and hands that evidence to an independent assessor for validation. Each step ends with a named output the next step depends on.

Confirm the gap against the requirement text
Start by re-reading the requirement statement that the assessor scored, not a summary of it. Compare what the assessor found against what the organization actually runs today, and separate missing procedures from procedures that exist but were not followed. The output is a short gap statement for each failing requirement, naming the specific element that is absent, such as no defined review frequency or no record of who reviewed. Anyone who has access to the requirement in MyCSF should be able to check the statement against the assessor's finding.
Assign a single accountable owner
Name one person who is accountable for closing each CAP, plus the technical contributors who will build or operate the control. For the most common CAPs, this is often the owner of the system, service or process the requirement covers, such as the vendor management lead for third-party SLA reviews or the platform owner for log review. The output is a written ownership record with the owner's name, role and the date the plan was approved by management. Confirm that the owner has the authority to change the process and the budget to run it.
Write the procedure and the recurring record
Write the procedure that will run from now on, and define the record it produces each time it runs. For log review, this means stating how often logs are reviewed, how each review is documented and who performs it. For third-party SLAs, it means defining the review cadence and the monitoring records that are compared against each agreement. The output is an approved procedure and a blank template or system record that the team will fill in. The procedure should be specific enough that a new staff member could run it without asking the author.
Implement the supporting configuration
Turn the procedure into working configuration in the systems that support it. Examples include enabling log forwarding to a central store, setting account review tooling, or adding secure coding checks to the build pipeline. This is the step where open-source tools, such as log collectors, identity management consoles or static analysis scanners, are often deployed inside the organization's own environment. The output is a configuration record, a change ticket or pipeline evidence that shows the control exists. Confirm with your tool vendors which features are available in the version you run, rather than assuming them.
Run the control and collect its records
Operate the procedure for the period the plan specifies, and file every record it produces in one evidence location. This is where the control becomes provable, because a procedure on paper without completed records will not satisfy an assessor. Keep the reviewer's sign-off, exception notes and follow-up actions with the records. The output is a dated set of completed records that shows the control ran as written. Track any missed cycles openly, since an assessor will look for them. How long this step takes depends on the organization's environment and the cadence it chose, so confirm the expected duration in the written plan.
Check the evidence against the requirement
Before submitting anything, have someone other than the operator compare the collected records with the requirement statement and the gap statement from the first step. Confirm that each element the assessor flagged is now demonstrated by a record, and that the records are complete, dated and attributable. The output is an internal evidence review with a pass or rework decision for each CAP. Items that still fall short go back to the procedure or the operating step, not to a narrative explanation.
Hand the evidence to the independent assessor
Provide the completed evidence package to the assessor for validation. The organization owns the controls and the evidence, an implementation partner can help prepare them, but only the independent assessor reviews the evidence and reports the result. HITRUST performs central quality assurance before any report is issued. The output is the assessor's documented validation of the closed CAP, which feeds into the next assessment or interim review. Ask the assessor, before starting, which evidence format and sample periods they expect.

Why third-party reviews and log reviews fail the assessor

Most organizations that fail these requirements do have a procedure, and that is the problem. The Third-Party Assurance requirement asks for at least annual review of service level agreements against monitoring records, and the Audit Logging & Monitoring requirement asks you to define how often logs are reviewed, how each review is documented and who performs it. Assessors test whether the review happened, not whether a document says it should. A policy stating that SLAs are reviewed yearly, with no dated review record, no named reviewer and no trail of follow-up, gives the assessor nothing to sample. Before fieldwork, confirm for each requirement which records would prove the review occurred, who signs them, and where they are stored.

For third-party reviews, the sample usually starts with the vendor inventory. The assessor picks in-scope service providers, then asks for the current SLA, the monitoring data that measures it (uptime reports, incident tickets, security attestations received), and the dated record showing someone compared the two. Gaps appear when SLAs were signed but nobody compared them to delivered performance, or when monitoring data exists in a vendor portal that the organization never exported. The fix is to assign an owner per provider, schedule the review in your ticketing or GRC tool, and keep the completed review, its findings and any escalation together. For audit logs, the assessor typically samples log sources in scope and asks for the review record for a period, showing who reviewed the logs, what they checked, and what they did with alerts. Logs that are collected and retained but never reviewed, or alerts that are raised and closed without a recorded disposition, are the usual failure. Confirm your log review cadence against your own written procedure and do not add frequencies the requirement does not state. Your own documented schedule is what the assessor will test against.

Both requirements fail on the same missing link: follow-up. When a SLA review finds a breach or a monitoring alert shows a network service provider behaving outside expectations, the assessor expects a recorded decision, such as a remediation request, a contract action or a documented risk acceptance, and evidence that it was tracked to closure. Test this before the assessment: pick one recent vendor issue or log alert and trace it from detection to reviewer to outcome. If you cannot produce that trail in under a day, the process needs a ticket template, a named owner and a closure field. An implementation partner can help build those records and the review calendar, but the organization must perform and sign the reviews. The independent assessor decides whether the evidence meets the requirement.

What an implementation partner can prepare and what stays internal

Corrective action plans usually trace back to a missing procedure, a log that nobody reviewed or a control that ran without evidence. An implementation partner can build the systems, templates and records that close those gaps, but the organization keeps ownership of each control and of every decision to accept or close a finding.

Evidence collection setup

A partner can configure where control evidence is captured, named and stored so that each requirement statement has a dated, traceable artifact. This matters because many failed requirements had a control that operated but left no record an assessor could sample. Your team still owns the control itself and decides which artifacts represent it. Check that the evidence owner, retention location and review date are named for every requirement before fieldwork starts. Only the independent assessor issues the report.

Procedure drafting

Many corrective action plans ask for a procedure that defines how often a control runs, how it is documented and who performs it. A partner can draft those procedures from your current practice and the requirement text. The organization must approve the wording, confirm it matches what staff actually do and assign the accountable role. An untested procedure on paper will fail the same way a missing one does.

Self-hosted logging and access evidence

A partner can deploy self-hosted log aggregation and identity tooling inside your own environment so that audit records and access reviews are produced automatically and kept under your control. This addresses the audit logging and access control gaps that recur in corrective action plans. Your security team still decides which events are reviewed, what counts as an anomaly and who signs off on each review. Confirm that the chosen platform supports the export and retention you need before committing to it.

Secure coding pipeline checks

A partner can add static analysis, dependency scanning and secure coding gates to your build pipeline so that common flaws such as injection and cross-site scripting are checked before release. The corrective action plan is about having written secure coding guidelines and proof that they are enforced. Developers and the application owner still own the guidelines, triage findings and decide whether a risk is accepted. Ask for pipeline run records as the evidence format.

Continuity documentation

A partner can help draft continuity plans, recovery procedures and test records that match the systems in scope. Continuity findings often come from plans that were never exercised or never tied to current infrastructure. Your business owners must set recovery priorities, approve the plan and run the exercises. Check that the plan names the people who decide when it is activated, since assessors test that roles were assigned, not just written down.

CAP tracking and closure records

A partner can set up a tracker that links each open corrective action plan to its owner, due date, remediation evidence and status. This makes progress visible before the r2 interim assessment. Your leadership still decides whether a finding is closed, whether residual risk is accepted and who signs that decision. The tracker supports the process; it does not replace the independent assessor's review of the evidence.

Questions buyers ask about HITRUST CAPs

Does a corrective action plan mean my HITRUST certification has failed?

No. A corrective action plan (CAP) is a written remediation commitment for a requirement that scored below what the assessment needs, and it does not by itself mean the certification has failed. Whether a CAP is required, or whether the result is only a gap, depends on the assessment type and the score, so the rules that decide this are set out in HITRUST's assessment materials. Read the CAP carefully: it names the requirement, the planned fix, the owner and the dates. Ask your assessor to confirm how the CAP affects your report before you describe the outcome to a customer.

How long does it take to close a HITRUST CAP?

The time to close a CAP depends on the requirement and on your environment, and no fixed duration applies to every case. A vendor review cycle, a logging change or a new access review process each runs on a different clock. Several CAPs cover requirements that must operate over a period, such as an annual review or periodic log reviews, so the evidence has to show the control working, not just being written down. Confirm the target dates and the evidence each milestone will produce in the written plan, and check them against the r2 interim timing if you hold an r2.

Can our own team prepare the evidence for a CAP?

Yes, in most cases your own team can prepare the evidence, provided it has the right access and time. Typical work includes writing the procedure, setting up the review, keeping the records and collecting samples in the format an assessor will test. The organization owns its controls and the CAP, and only an independent assessor can test the result and report it. Teams often struggle less with the writing and more with running the control consistently over the required period and proving it happened. Check whether you have a named owner for each CAP item and someone who can gather evidence on schedule.

What does fixing a CAP require from our engineering and security teams?

Each CAP draws on a different mix of people. The work usually needs:

Security or compliance staff to define the procedure, owner and review cadence
Platform or application engineers to change configuration, logging, access or coding practices
System owners and HR or identity staff to run access reviews and account changes
Vendor management to collect and review third-party service level agreements and monitoring records

Estimate the hours per CAP from its requirement, and record who does each task. Capacity planning matters more than the total: a single engineer who owns logging, access and secure coding can become the bottleneck.

How do CAPs affect the r2 interim assessment?

An r2 interim assessment is due in the 90 days before the first anniversary of the r2 certification, and it is where HITRUST checks progress on CAPs that were open at certification. Your CAP milestones should be scheduled so that the evidence for each item exists before the interim fieldwork begins. A CAP that has not produced working evidence by then is a risk to your renewal timing. Confirm with your assessor exactly how interim progress is tested and which records they will request, and keep those records in one place from the first day.

What drives the cost of a remediation partner for CAPs?

Cost depends on scope, not on a standard rate. The main drivers are the number and complexity of CAP items, how many systems and third parties are in scope, whether the work is a one-time build or ongoing operation, and how much of your current tooling and logging already works. Ask for a fixed-scope quote that lists each CAP item, the deliverables, the handover of evidence and any retained support after the work ends. Remember that a partner prepares systems and evidence but does not issue assessment reports, and that the external assessor's fees are a separate cost.

Should we hire a remediation partner or handle CAPs internally?

Choose based on the gap between your current evidence and what an assessor will test. If your teams already run logging, access reviews and vendor reviews on a schedule, internal ownership is often practical. If the CAPs touch platforms you do not yet operate well, an outside partner can plan, implement and document the changes inside your own infrastructure. DeployOpen works on fixed-scope engagements in the client's own environment and prepares systems and evidence for assessment, while the organization keeps ownership of its controls. Ask any partner to show how it will hand over the evidence and runbooks so your team can sustain them.

How to use this list before your next assessment

Use the eight requirement areas in this list as a readiness checklist before fieldwork begins. For each area, pull the evidence you would show an assessor today: the signed third-party SLA and the monitoring records that prove someone checked it, the audit log review record with its reviewer and frequency, the access review export with dated sign-offs, the secure coding standard and the scan results behind it, the system authorization records, and the most recent continuity test. If you cannot name the owner and the date for any item, treat that requirement as a likely gap rather than a finished control. The purpose of the review is to find weaknesses while you can still fix them, not to confirm what you hoped was true.

Once the gaps are listed, sort each one into one of two paths. A gap that can be closed with a short, verifiable action before fieldwork, such as producing a missing review record for a period that is already over, belongs in the fix-first queue. A gap that needs sustained operation over time, such as a new recurring review cycle that has not yet produced enough history, may need a corrective action plan. The HITRUST Assessment Handbook is the authoritative source for when a CAP is required, what it must contain and how it is handled, so check your decisions against it and against your assessor's interpretation before you act on them. Do not rely on this page or on any partner's summary for those rules.

If you bring in a partner to help with the review, ask for a written scope before any work starts. The scope should name which of the eight areas are covered, which systems and evidence sources will be examined, what the partner will deliver (for example, a gap register or a remediation plan), who on your side owns each item, and what the partner will not do. The partner prepares systems and evidence; your organization owns the controls, and only an independent HITRUST External Assessor issues the validated report. A written scope makes it clear who is responsible for each gap and protects both sides when the review ends.

How DeployOpen scopes, implements and prepares CAP evidence

DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, then prepares the systems, controls and evidence that address the requirements most often flagged for corrective action. We do not issue HITRUST reports or certifications. Your organization owns its controls, and an authorized external assessor performs the validated assessment.

How we scope

We agree a written scope listing which HITRUST requirements, systems and environments the corrective action work covers.
Scope usually names the specific gaps, such as log review, access reviews or third-party SLA monitoring, to be remediated.
Engagements are fixed-scope, so deliverables and timelines are confirmed in writing before any work begins.

How we build

We configure self-hosted tooling for log collection, review records and access review workflows inside your cloud accounts or data centers.
We document procedures that name the review frequency, the reviewer and the record each review must produce.
We test each control against its intended result and record what passed, what failed and what was corrected.

How we hand over

You receive procedures, configuration records, review templates and an evidence index mapped to each corrective action item.
Evidence is organized by requirement so your team and your assessor can trace each claim to a dated artifact.
Your staff are trained to run recurring reviews and to produce the records an assessor will sample.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
A retainer can keep review cycles running through the period an interim or validated assessment checks progress.
Ask us to confirm in writing which evidence is ours to prepare and which decisions remain with your organization.

The most common HITRUST corrective action plans