To choose managed IT support for a HIPAA-regulated organization, look for a provider that understands the HIPAA Security Rule, will define its responsibilities in writing, supports an ongoing risk-management process, and can demonstrate how it protects electronic protected health information.

Avoid any provider that says a product bundle will “make you compliant.” HIPAA compliance belongs to the covered entity or business associate as an organization. The IT partner supports that responsibility through safeguards, documentation, monitoring, response, and continuous improvement.

Key Takeaways:

Start with risk analysis and data flow, not a generic technology package.
Confirm whether the provider is a business associate and will execute an appropriate Business Associate Agreement.
Evaluate administrative support, technical safeguards, recovery, documentation, and incident response together.
Require clear ownership for every control and every follow-up action.
Ferrum’s Managed Intelligence Provider model helps leaders turn security evidence and operational data into risk decisions.

What does “HIPAA-compliant managed IT” actually mean?

The phrase is commonly used to describe an IT provider that can support organizations subject to HIPAA. It should not imply that the provider can certify or guarantee the client’s compliance.

A qualified provider understands the confidentiality, integrity, and availability of electronic protected health information. It can help identify the systems that create, receive, maintain, or transmit that information and implement reasonable safeguards based on risk.

It should also understand where technology responsibility ends. Workforce training, privacy practices, physical access, sanctions, policies, and leadership oversight cannot be outsourced entirely to an IT company.

1. Begin with a documented security risk analysis

HHS describes risk analysis as foundational to Security Rule compliance. The organization must identify its electronic protected health information, potential threats and vulnerabilities, existing safeguards, likelihood, impact, and risk level.

Ask the provider:

How do you support a risk analysis?
How do you document technical findings?
How are remediation items prioritized and assigned?
How is the analysis revisited when systems, vendors, or operations change?

A scan or automated report may contribute evidence, but it is not the entire risk analysis.

2. Confirm Business Associate Agreement readiness

If the provider creates, receives, maintains, or transmits protected health information on behalf of a covered entity, it may be a business associate. The relationship and permitted use of information should be addressed through a Business Associate Agreement where required.

Have legal or compliance counsel confirm the organization’s obligations. From an evaluation standpoint, a provider that may handle protected health information but refuses to discuss a BAA is a serious warning sign.

The BAA does not replace due diligence. It documents responsibilities; it does not prove that controls are effective.

3. Review identity and access controls

Ask how the provider manages:

Unique user identification
Multi-factor authentication
Role-based and least-privilege access
Privileged administrator accounts
Onboarding, role changes, and termination
Remote and third-party access
Periodic access review
Authentication and sign-in logs

Shared accounts make accountability difficult. Excessive access increases the impact of mistakes and compromise. The provider should be able to explain how access reflects job responsibilities.

4. Review device, network, and cloud safeguards

Electronic protected health information may move across workstations, laptops, servers, email, cloud platforms, applications, mobile devices, and network connections.

The provider should maintain inventory and apply consistent security standards. Depending on risk, that may include encryption, endpoint protection, patch management, secure configuration, network segmentation, managed firewalls, email security, mobile controls, and restricted administrative access.

Ask how exceptions are documented. A control marked “addressable” under the Security Rule is not automatically optional; the organization must make and document a reasonable determination.

5. Evaluate audit logs and security monitoring

Logs can help identify unauthorized access, unusual activity, and the scope of an incident. But collecting logs without reviewing them creates little value.

Clarify:

Which systems generate relevant logs?
How long are they retained?
What activity is monitored?
Who reviews alerts?
What triggers an escalation?
How is the client notified?
How are findings documented?

The monitoring model should fit the environment and the sensitivity of the information.

6. Evaluate patch and vulnerability management

Healthcare organizations often depend on specialized applications and devices that cannot be updated casually. That makes a controlled process more important, not less.

The provider should inventory supported systems, track update status, prioritize urgent vulnerabilities, coordinate maintenance windows, document exceptions, and identify unsupported technology.

Ask how the provider works with clinical software or device vendors when patches require approval or compatibility testing.

7. Evaluate backup, contingency, and recovery capability

HIPAA availability is not achieved by installing backup software. The organization needs a documented plan for maintaining or restoring access to critical information.

Review:

Data and systems included
Backup frequency and retention
Protection of backup copies
Monitoring and failure response
Restoration testing
Recovery order
Recovery time and recovery point objectives
Emergency-mode operations
Communication during an outage

Ask to see evidence of the process, not protected health information.

8. Review incident response and breach coordination

A provider should have a defined process for suspected account compromise, malware, ransomware, unauthorized access, lost devices, and data exposure.

Ask:

How can an incident be reported at any hour?
Who has authority to isolate accounts or devices?
How is evidence preserved?
How are legal, insurance, privacy, and leadership contacts engaged?
How are status updates delivered?
How are corrective actions tracked after the incident?

The provider should not make legal determinations about breach notification unless it is specifically qualified and authorized to do so. Technical investigation should support the organization’s legal and compliance process.

9. Examine documentation and reporting

Compliance depends on demonstrating what the organization decided and did.

Look for maintained inventories, network diagrams, access records, patch and backup reports, risk findings, remediation plans, incident records, policy support, and review notes.

Leadership reporting should summarize open risk, trends, decisions, owners, and target dates. A stack of tool-generated reports is not the same as governance.