How to turn healthcare security findings into a remediation plan

A security assessment can identify a weakness without making the next step obvious. “Update the system” leaves several questions unanswered: which system, who is responsible, what could go wrong during the change, and how will the team know the issue is resolved?

A useful remediation plan connects each finding to an action, an owner and evidence of the result. Here is a practical way to make that connection.

Start with the risk behind the finding

Read the finding alongside its scope and supporting evidence. Which system or workflow is affected? What information could be exposed? Which safeguards are already in place?

For a HIPAA Security Risk Analysis, the broader question is risk to the electronic protected health information your organization handles. HHS guidance considers the environment, threats, vulnerabilities, existing safeguards and potential impact. A finding from a technical test can inform that work, but it does not describe the whole organization’s risk by itself.

Source: HHS guidance on risk analysis.

Write an action someone can carry out

A short working record can keep the team aligned. For each finding, record:

• The affected system or workflow and the evidence behind the finding.
• Why the issue has its assigned priority.
• The person responsible for the next action.
• The planned change and any approval or service dependency.
• The target date and next review date.
• What evidence will show whether the action worked.

Prioritize using your organization’s risk criteria. A severity label can help start the discussion; the actual exposure, affected information and available safeguards should inform the decision.

An example: an outdated remote-access service

Suppose an assessment identifies an outdated remote-access service on a server.

“Patch the server” is too broad for a useful handoff. A clearer plan might say:

• Confirm the affected server, service version and exposure.
• Have the technology owner evaluate the update, dependencies and recovery plan.
• Agree on an appropriate maintenance window and any interim protection needed.
• Apply the approved change.
• Confirm the installed version and repeat the relevant check.
• Record the result, including anything that remains unresolved.

The compliance lead can then review the result with the technology owner. If the update cannot happen yet, record why, what protection is being used in the meantime, and when the decision will be reviewed. Avoid letting a dependency turn into an item with no owner or next date.

Close the finding with evidence

Completing a task and resolving a finding are different events. Keep the original evidence, the change record and the verification result together. An update ticket marked complete may show that work happened; a follow-up check helps establish whether it addressed the weakness.

NIST’s technical testing guidance connects assessment findings with analysis and mitigation. Use the verification method that fits the original finding and agreed scope. If the check still finds the issue, revise the action and keep the item open.

Source: NIST SP 800-115, Technical Guide to Information Security Testing and Assessment.

Keep the plan useful as things change

Review the plan when systems, services or relevant risks change. HHS describes risk analysis as an ongoing process. Your working records should make it easy to see unresolved items, upcoming reviews and the evidence supporting completed work.

You do not need a longer list of findings to begin. Choose one unresolved item and check whether the record answers three questions: who acts next, when will the team review it, and what would demonstrate that the action worked?

If your team needs to assess its broader risks, explore Medcurity’s Security Risk Analysis service.

Talk with Medcurity about the assessment scope and next steps that fit your organization.