Reducing Access-Related Compliance Findings in Healthcare Audits

Healthcare systems can have access policies, MFA, account reviews, and offboarding procedures in place and still receive audit findings. An account may remain active after an employee leaves, a vendor may retain access after a contract ends, or a review may take place without a record of who completed it, what they checked, and what action followed. 

A January 2026 HHS-OIG cybersecurity audit showed how weak access control can play out. Auditors used credentials captured through a simulated phishing campaign to gain access to a hospital account-management application that lacked strong identification and authentication controls, including multi-factor authentication (MFA).

Reducing access-related compliance findings in healthcare audits requires more than correcting the accounts included in an auditor’s sample. Compliance and audit teams need to identify why the control failed, document the corrective action, test whether the change works, and retain evidence for the next review. In this guide, we break down that entire process.

Why Access-Related Findings Occur

Access-related findings commonly begin with one of the following issues:

• Access changes do not reach every system: A role change or departure may be recorded in one platform while access remains active in an EHR, VPN, administrative portal, or separately managed application.

• Temporary access has no clear owner or end date: Vendor, contractor, emergency, and project accounts may remain active when nobody records who owns the access or when it should be reviewed or removed.

• Authentication differs across access routes: MFA may protect the main remote connection while a legacy application, vendor account, or administrative portal still relies only on a password.

• Access reviews leave incomplete evidence: Teams may review permissions without recording who completed the review, what they checked, which exceptions they found, or what action followed.

• System activity is recorded but not reviewed consistently: Logs and access reports may exist without a documented process showing who reviews them, how often reviews occur, and how identified issues are handled.

• Exceptions remain open without review: Legacy systems, emergency accounts, and temporary bypasses can remain in place without a recorded reason, owner, approval, compensating control, or future review date.

How to Remediate an Access-Related Finding

Once the issue is identified, the next step is to correct it and verify that the fix is working. Here is how healthcare organizations can go about it:

Confirm the Scope of the Finding

Start with the exact wording of the finding rather than a general description of the problem. Record the policy, control, or requirement involved, along with the users, accounts, systems, locations, and audit period affected.

The record should also identify the sample reviewed by the auditor and the exception or missing evidence identified. The sample may reveal a wider issue, but that should be confirmed through further review rather than assumed. Compliance teams may need to check similar accounts, systems, departments, or facilities to establish the actual scope.

Identify the Type of Control Failure

The next step is to determine whether the problem lies in the design, operation, or documentation of the control. A design gap means that no suitable process existed or that the existing process did not address the risk. An operating gap means the process existed but was not followed consistently. 

A documentation gap means the control may have operated, but the organization retained no approval, result, exception record, or evidence of follow-up. More than one type of failure may apply. Rewriting a policy will not correct inconsistent practice, while removing an account will not fix missing review evidence.

Address Any Immediate Exposure

If the finding reveals active or unnecessary access, the organization should address it promptly. This may involve disabling an account, removing excessive permissions, resetting credentials, ending expired vendor access, restricting a connection, or applying a temporary control until the permanent correction is ready.

However, not every audit finding represents an active security incident. A finding may concern an old account, a process weakness, or incomplete documentation. The response should match the risk that currently exists rather than treating every exception as a confirmed breach.

Find the Root Cause

Look beyond the person or account included in the finding. The cause may involve unclear ownership between HR, IT, and application teams, approvals handled through email without a central record, or workforce changes that did not reach every system.

Other causes may include legacy technology limitations, missing expiry dates, outdated procedures, or no defined process for retaining evidence. The corrective action should address the actual cause. Otherwise, the organization may fix the auditor’s sample while the same weakness remains elsewhere.

Create and Implement a Corrective Action Plan

The plan should state what will change, who owns the work, and how completion will be demonstrated. It should identify the finding, affected scope, root cause, corrective action, accountable owner, supporting teams, and target completion date.

It should also define the evidence that must be retained, how the correction will be tested, and any limitation or exception that will remain. The target date should reflect the level of risk, any current exposure, technical dependencies, internal policy, and requirements set by the auditor, regulator, or internal governance process.

Test and Close the Finding

Approval of a new policy or technical change does not close the finding. The organization should test whether the control now works as intended by repeating the relevant test, reviewing a fresh sample, or checking recent access changes and supporting records.

The closure record should show what changed, who completed and approved it, what evidence was reviewed, how the correction was tested, and whether any risk remains. OCR’s audit protocol examines both the policies an organization has adopted and how those policies are employed, so the final evidence must show operation rather than intent alone.

What Documentation Should Support the Remediation?

Remediation is easier to defend when each step leaves a clear record. In April 2025, Northeast Radiology agreed to a $350,000 settlement and two years of OCR monitoring. Its corrective action plan included developing a written process for regularly reviewing audit logs, access reports, and security incident tracking reports.

The exact evidence will depend on the finding, but the remediation record should usually cover the following:

Documentation	What It Should Show
Finding and scope record	The requirement involved, affected users and systems, audit period, sample reviewed, and exception identified
Access policy and ownership	How access is approved, changed, reviewed, and removed, along with who owns each step
User, account, and entitlement records	Which users and accounts are in scope, what access they hold, and whether it matches their current role
Approval and access-change records	Who approved access and when it was granted, changed, disabled, or removed
Review and activity records	What was reviewed, who completed the review, which issues were found, and what action followed
Exception records	The reason, owner, approval, compensating control, and review or expiry date
Remediation and closure records	What changed, how it was tested, the result, any remaining risk, and who approved closure

How to Prevent Repeat Findings

Once the finding is closed, the focus shifts to preventing the same weakness from returning in the same system or appearing elsewhere. To do that, healthcare organizations should:

• Connect access changes to workforce and vendor events: Role changes, departures, contract completion, and vendor offboarding should trigger updates across every affected system.

• Reconcile accounts across systems: Compare HR, identity, EHR, VPN, vendor, and standalone application records to catch access missed by one process.

• Assign a clear owner to each control: One person or team should be accountable for operating the control, resolving exceptions, and escalating overdue actions.

• Re-test remediated controls after closure: A finding may pass its initial closure test but fail again once normal operations resume or systems change.

• Track recurring issues across the healthcare system: Compare findings across facilities, departments, and applications to identify repeated causes, overdue actions, and controls that continue to fail.

How PureVPN for Teams Can Help

PureVPN for Teams can help healthcare organizations with corrective actions involving remote access through a VPN. Administrators can manage users from one dashboard. MFA and SSO support VPN sign-in, while SCIM provisioning can synchronize user access with supported directories such as Google Workspace and Microsoft 365.

Device posture checks can assess whether a device meets configured requirements before allowing a connection. A dedicated IP or Team Server can also provide a predictable source IP that the healthcare organization can add to its own EHR or application allowlist. Session activity reporting can support review of VPN connections and user sessions. 

Note: PureVPN for Teams can support corrective action at the remote-access layer, but it does not replace application permissions, control reviews, identity governance, or closure evidence.

Frequently Asked Questions