How to Manage HIPAA, 405(d), and State Compliance Through One MSP
Healthcare organizations rarely struggle because they lack compliance policies. The real problem? Their policies, security controls, risk assessments, vendor reviews, incident procedures, and audit evidence are managed by different teams using different systems.
IT may manage endpoint security. Compliance may maintain HIPAA policies. Legal may track state privacy laws. Internal audit may request evidence. A separate managed security provider may monitor alerts without understanding which systems contain ePHI.
The result is a fragmented compliance program where no one can quickly answer three basic questions:
- Which regulatory obligations apply?
- Which controls are operating effectively?
- Where is the evidence proving that those controls were implemented?
Healthcare compliance managed services address this problem by placing governance, cybersecurity operations, risk management, and evidence collection within one coordinated managed-service model.
But one MSP does not eliminate the healthcare organization’s legal responsibility.
It creates one operating layer for managing that responsibility.
What Does Managing Healthcare Compliance Through One MSP Mean?
Managing compliance through one MSP means using a healthcare-focused managed service provider to coordinate the operational activities that support HIPAA, HICP implementation, healthcare cybersecurity, and applicable state requirements.
The MSP does not simply install security tools. It continuously manages the relationship between:
- Regulatory obligations
- Cybersecurity risks
- Technology assets
- Security controls
- Policies and procedures
- Vendors and business associates
- Compliance evidence
- Remediation activities
- Incident and breach-response workflows
The goal is to create one source of truth for how the organization protects health information and demonstrates reasonable, appropriate, and consistently implemented safeguards.
When the MSP creates, receives, maintains, or transmits PHI on behalf of a covered entity, it will generally operate as a HIPAA business associate.
The relationship must be governed by an appropriate Business Associate Agreement, and relevant HIPAA Security Rule requirements apply directly to the business associate. Subcontractors handling PHI must also be addressed through appropriate downstream obligations.
Outsourcing operations does not outsource accountability. The covered entity must still oversee its business associates, approve policies, make legal decisions, and ensure risks are reduced to reasonable and appropriate levels.
HIPAA, 405(d), and State Laws Are Not the Same Thing
A reliable healthcare compliance outsourcing model begins by separating the three layers.
| Compliance layer | What it does | Legal status | MSP responsibility |
| HIPAA | Establishes federal privacy, security, and breach-notification requirements | Mandatory for regulated entities | Operationalizes safeguards, assessments, monitoring, documentation, and evidence |
| HHS 405(d) HICP | Provides healthcare-specific cybersecurity practices for reducing common threats | Voluntary recognized security practices | Translate HICP practices into technical and operational controls |
| State requirements | Add state-specific medical privacy, consumer privacy, security, and breach obligations | Mandatory where applicable | Track operational requirements and escalate legal interpretations to counsel |
HIPAA Establishes the Regulatory Baseline
The HIPAA Security Rule requires covered entities and business partners to use administrative, physical, and technical protections to secure the confidentiality, integrity, and availability of electronic protected health information. Regulated entities must also safeguard ePHI from reasonably foreseeable dangers, hazards, and improper uses or disclosures.
HIPAA is intentionally risk-based and technology-neutral. It does not prescribe one security product or architecture for every organization.
That flexibility creates a practical challenge.
A hospital must determine what is reasonable and appropriate for its environment, document that reasoning, implement the safeguards, and verify that the safeguards remain effective as its systems, locations, vendors, and threats change.
405(d) HICP Turns Cybersecurity Principles Into Healthcare Practices
The 405(d) Program was established to align cybersecurity approaches across the Healthcare and Public Health Sector. Its HICP publication identifies five major healthcare threats:
- Social engineering
- Ransomware
- Loss or theft of equipment or data
- Insider, accidental, or malicious data loss
- Attacks against network-connected medical devices
HICP connects those threats to ten cybersecurity practices:
- Email protection systems
- Endpoint protection systems
- Access management
- Data protection and loss prevention
- Asset management
- Network management
- Vulnerability management
- Security operations and incident response
- Network-connected medical-device security
- Cybersecurity oversight and governance
HICP includes different technical guidance for smaller organizations and for medium and large healthcare organizations. It is designed to help organizations prioritize cybersecurity investments based on size, resources, threats, and operational complexity.
A critical distinction is often missed in competing articles:
There is no formal “405(d) compliance” certification.
HICP adoption is voluntary. However, while assessing certain penalties, audits, and corrective outcomes, OCR is required by Public Law 116-321 to take into account adequately demonstrated recognized security measures that were in place for at least the preceding 12 months.
This is not immunity from HIPAA enforcement. It is an incentive to implement, and document recognized cybersecurity practices consistently. In one OCR matter, documented 405(d)-aligned practices contributed to a reduction in the proposed civil monetary penalty.
State Laws Create Additional Compliance Overlays
HIPAA does not preempt every state health-privacy or cybersecurity requirement.
More protective state provisions may continue to apply, and healthcare organizations may also handle information that falls outside HIPAA’s definition of PHI.
Examples include:
- California medical privacy requirements governing medical information and patient rights
- New York’s SHIELD Act requirements for reasonable administrative, technical, and physical safeguards
- Texas medical-record privacy requirements under Health and Safety Code Chapter 181
- Washington’s My Health My Data Act for certain consumer health data outside traditional HIPAA coverage
- State-specific breach definitions, reporting recipients, notification content, and deadlines
New York’s SHIELD Act, for example, requires businesses maintaining covered private information to implement reasonable administrative, technical, and physical safeguards. It also expanded the definition of breach to include certain unauthorized access, not only confirmed acquisition.
Washington’s My Health My Data Act addresses health information that may be collected by entities outside HIPAA. It includes requirements involving privacy notices, consent, deletion rights, data sales, and geofencing around healthcare facilities.
An MSP should maintain the control and evidence infrastructure supporting these requirements. Legal counsel and the healthcare organization’s privacy leadership should determine which statutes apply and how ambiguous provisions should be interpreted.
Why Fragmented Compliance Programs Fail
Healthcare organizations often maintain separate workstreams for HIPAA, cybersecurity, state privacy, vendor risk, insurance, and internal audit. That sounds manageable.
Until the same control is evaluated six different ways.
Consider multi-factor authentication. It may be relevant to:
- HIPAA access-control risk mitigation
- HICP access management
- Cyber-insurance underwriting
- A state reasonable-security obligation
- A customer security questionnaire
- Internal security policy
- A future HIPAA Security Rule requirement
When each team assesses MFA separately, the organization creates duplicate questionnaires, conflicting findings, inconsistent scope definitions, and multiple versions of evidence.
A unified MSP model instead uses one control record:
Privileged and remote access must use approved multi-factor authentication across all in-scope systems. That control can then be mapped to every applicable framework and supported by common evidence such as configuration exports, identity-provider reports, exception records, access-review results, and remediation tickets.
This is the foundation of the one control, multiple obligations model.
How One MSP Should Operationalize Healthcare Compliance
1. Build an Accurate Compliance Scope
The MSP should begin with scope, not with a generic HIPAA checklist.
Scope must identify:
- Covered entities and business associates
- Facilities and legal entities
- States in which patients, employees, or consumers are located
- EHR, PACS, laboratory, pharmacy, billing, telehealth, and patient-engagement systems
- Cloud platforms and hosted environments
- Endpoints, servers, network appliances, and medical devices
- Data repositories, backups, archives, and interfaces
- Third parties receiving or accessing PHI
- Non-HIPAA consumer health data
- Data flows across facilities, vendors, and jurisdictions
An incomplete asset or ePHI inventory creates an incomplete risk analysis.
OCR’s January 2026 cybersecurity guidance reinforced that a HIPAA risk analysis must address risks and vulnerabilities affecting all ePHI, including vulnerabilities created by unpatched and obsolete software.
2. Create a Unified Control Framework
The MSP should establish one control library mapped to:
- HIPAA Privacy, Security, and Breach Notification Rules
- NIST SP 800-66 Revision 2
- NIST Cybersecurity Framework 2.0
- HICP practices and sub-practices
- Applicable state requirements
- Cyber-insurance commitments
- Internal policies
- Contractual security requirements
NIST SP 800-66 Revision 2 provides practical guidance for implementing the HIPAA Security Rule and includes mappings to NIST Cybersecurity Framework subcategories and NIST SP 800-53 controls.
The crosswalk should prevent redundant controls while respecting each obligation’s phrasing and evidence requirements.
3. Maintain a Defensible HIPAA Risk Analysis
A vulnerability scan is not a HIPAA risk analysis.
A defensible assessment must connect:
- ePHI assets and data flows
- Threats
- Vulnerabilities
- Existing safeguards
- Likelihood
- Operational and patient-care impact
- Residual risk
- Risk owner
- Treatment decision
- Remediation deadline
Organizational executives must take part in risk acceptance and prioritization, even if the MSP does the technical work.
OCR’s recent Risk Analysis Initiative shows why this matters.
By February 2026, OCR described one settlement as its eleventh enforcement action under that initiative. A March 2026 settlement was identified as the twelfth.
Risk analysis cannot be treated as an annual document created solely for an audit. It must change when the organization acquires a practice, deploys a cloud platform, connects new medical devices, changes an interface architecture, suffers an incident, or introduces a new vendor.
Unify Healthcare Compliance Under One Managed Service
Reduce fragmented HIPAA, HICP, state compliance, security monitoring, and audit evidence workflows with a healthcare-focused MSP model built for regulated clinical environments.
4. Convert HICP Into Managed Security Operations
HICP becomes valuable when the practices are translated into recurring services.
| HICP practice | MSP operating activity | Expected evidence |
| Email protection | Filtering, anti-phishing controls, domain protection, simulations | Configuration reports, simulation results, incident trends |
| Endpoint protection | EDR, anti-malware, hardening, isolation | Coverage reports, alert records, policy exports |
| Access management | MFA, privileged access, joiner-mover-leaver controls | Access reviews, termination logs, MFA reports |
| Data protection | Encryption, DLP, secure transfer, media controls | Encryption status, DLP alerts, exception approvals |
| Asset management | Hardware, software, cloud, ePHI and medical-device inventory | Asset register, ownership, criticality and lifecycle status |
| Network management | Segmentation, firewall governance, secure remote access | Network diagrams, rule reviews, segmentation tests |
| Vulnerability management | Scanning, patching, remediation and exception management | Scan results, patch SLAs, risk-acceptance records |
| Security operations | SIEM, monitoring, triage, escalation and incident response | Alert metrics, investigation records, exercise results |
| Medical-device security | Discovery, classification, isolation and compensating controls | Device inventory, risk tiers, vendor advisories |
| Governance | Metrics, risk oversight, policy management and reporting | Committee minutes, dashboards, policy approvals |
The MSP should report control coverage and effectiveness, not merely the number of tools deployed.
5. Maintain a State Compliance Matrix
State compliance cannot be reduced to one national checklist.
The MSP should maintain a jurisdictional requirements matrix containing:
- Applicable entity and data definitions
- Exemptions for PHI, HIPAA-regulated entities, or both
- Security requirements
- Privacy notice obligations
- Consent and authorization rules
- Consumer access, correction, and deletion rights
- Data-retention requirements
- Geofencing or advertising restrictions
- Breach definitions
- Notification deadlines
- State regulator reporting requirements
- Documentation and evidence expectations
This matrix should be reviewed when the organization enters a new state, launches a patient-facing application, changes tracking technologies, acquires another provider, or begins collecting new consumer health information.
6. Automate Compliance Evidence Collection
Passing an audit depends on evidence. The MSP should continuously collect:
- Identity and MFA reports
- Privileged-access reviews
- Endpoint and EDR coverage
- Encryption status
- Vulnerability and patch reports
- Firewall and network-rule reviews
- Backup-job results
- Restore-test results
- Security-awareness completion
- Incident-response exercises
- Business-associate assessments
- Policy approvals
- Risk-treatment records
- Remediation tickets
- Exception approvals
Evidence must show who performed the activity, what systems were covered, when it occurred, what exceptions were found, and how those exceptions were resolved.
Screenshots without dates, system scope, ownership, or supporting records are weak audit evidence.
7. Integrate Security Incidents With Breach Analysis
The security team determines what happened technically. The privacy and legal teams determine whether the event creates notification obligations.
One MSP should support both workflows without confusing them.
The managed incident process should include:
- Detection and triage
- Containment
- Evidence preservation
- ePHI and data-scope analysis
- Affected-person and jurisdiction analysis
- Business-associate notification
- Legal breach assessment
- Federal and state notification support
- Recovery validation
- Corrective-action tracking
- Post-incident risk-analysis updates
Incident severity and regulatory reportability are not the same decision.
A technically contained event may still create a legal notification obligation, whereas a major outage may not involve unauthorized access to PHI.
8. Establish a Clear Governance Model
The MSP should never become an unaccountable compliance black box.
A practical responsibility model is:
| Activity | Healthcare organization | MSP | Legal or privacy counsel |
| Approve compliance strategy | Accountable | Consulted | Consulted |
| Operate technical safeguards | Informed or responsible | Responsible | Informed |
| Maintain risk register | Accountable | Responsible | Consulted |
| Accept residual risk | Accountable | Consulted | Consulted |
| Determine state-law applicability | Accountable | Supports | Responsible or consulted |
| Determine breach notification | Accountable | Supports investigation | Responsible or consulted |
| Maintain evidence | Accountable | Responsible | Informed |
| Report to executives and board | Accountable | Produces reporting | Consulted |
For mid-sized and large healthcare organizations, governance should include a monthly operational review, quarterly risk committee review, and annual program evaluation.
What Changes Should Healthcare Organizations Prepare?
As of July 2026, the existing HIPAA Security Rule remains in effect. HHS has proposed substantial modifications, but the Security Rule NPRM has not been finalized.
The proposal would introduce or strengthen requirements involving:
- Written asset inventories and network maps
- More specific written risk analyses
- Annual compliance audits
- Encryption of ePHI at rest and in transit, with limited exceptions
- Multi-factor authentication
- Network segmentation
- Vulnerability scans at least every six months
- Penetration testing at least annually
- Separate backup and recovery controls
- Testing of security measures
- Written procedures for restoring certain systems and data within 72 hours
- Business-associate verification and certification requirements
HHS expressly states that the current Security Rule remains in effect while rulemaking continues.
Healthcare organizations should not represent the proposed provisions as current legal requirements.
However, an MSP can use them as a readiness baseline.
Most of these capabilities already support HIPAA risk management, HICP implementation, cyber resilience, insurance readiness, and defensible security operations.
What Should Healthcare Compliance Managed Services Include?
A complete managed service should provide more than an annual assessment. Look for:
- HIPAA risk-analysis management
- HICP implementation and maturity tracking
- Managed GRC platform administration
- State requirements matrix support
- Policy and procedure lifecycle management
- 24/7 security monitoring
- Identity and access governance
- Vulnerability and patch management
- Cloud and network security
- Medical-device security
- Third-party risk management
- Incident and breach-response support
- Backup and recovery testing
- Audit and examination support
- Executive and board reporting
- Remediation program management
The service agreement should define control ownership, escalation paths, evidence-retention periods, reporting frequency, remediation SLAs, subcontractor use, incident-notification requirements, and responsibility for legal interpretation.
How to Evaluate a Healthcare Compliance MSP
Before selecting an MSP, ask:
- Will you sign a Business Associate Agreement?
- Can you map one control to HIPAA, HICP, NIST, and state requirements?
- How do you identify every system containing or affecting ePHI?
- How do you maintain state-law applicability?
- Who owns the HIPAA risk analysis?
- How are risk exceptions documented and approved?
- Can you produce 12 months of control evidence?
- How do you secure privileged access to client environments?
- Which subcontractors can access PHI?
- How do your SOC and compliance teams coordinate during incidents?
- How are medical devices and clinical networks included?
- What metrics are reported to executives and the board?
Avoid providers that promise to “make the organization HIPAA compliant” through a checklist or software subscription alone.
HIPAA compliance depends on the organization’s full environment, workforce, data handling, vendors, security operations, policies, and documented risk decisions.
A 180-Day Implementation Roadmap for HIPAA, HICP, and State Compliance Readiness
Days 1–30: Establish Scope
- Confirm legal entities, facilities, systems, vendors, and jurisdictions
- Execute the BAA and define responsibilities
- Inventory ePHI systems and critical data flows
- Collect existing policies, assessments, audits, and incidents
Days 31–60: Assess Risk and Control Coverage
- Conduct the HIPAA risk analysis
- Assess HICP practice maturity
- Map relevant state requirements
- Identify control and evidence gaps
- Assign risk owners and remediation priorities
Days 61–120: Implement Priority Controls
- Close critical identity, endpoint, vulnerability, backup, and monitoring gaps
- Formalize policies and procedures
- Establish evidence collection
- Build incident and breach-response workflows
- Assess high-risk vendors and business associates
Days 121–180: Validate and Govern
- Test restoration and incident-response procedures
- Review control effectiveness
- Resolve evidence gaps
- Produce the first executive compliance dashboard
- Approve the multi-year security and compliance roadmap
The program should then move into continuous monitoring, quarterly governance, annual reassessment, and event-driven updates.
CapMinds Healthcare Compliance Managed Service
Healthcare compliance requires more than periodic assessments and disconnected security tools.
CapMinds delivers healthcare compliance managed services that unite cybersecurity operations, HIPAA safeguards, HICP implementation support, state-requirement tracking, risk management, and audit evidence under one coordinated service model.
Our healthcare-focused specialists help your organization establish clear control ownership, identify ePHI risks, close security gaps, and maintain defensible documentation across cloud, on-premises, and hybrid environments.
Services can be delivered as a fully managed program or integrated with your internal IT, security, compliance, privacy, and audit teams. CapMinds services include:
- HIPAA security risk analysis and remediation management
- 405(d) HICP control implementation and maturity tracking
- Healthcare GRC, policy, risk register, and evidence management
- State privacy and breach-requirement operational support
- 24/7 security monitoring, incident triage, and response coordination
- Identity, MFA, privileged-access, endpoint, network, and cloud security
- Vulnerability, patch, backup, recovery, and resilience management
- Business associate and third-party risk assessments
- Audit readiness, executive reporting, and compliance monitoring
- Managed infrastructure, interoperability, application support, and More
Move from fragmented compliance activities to one accountable operating model.
Partner with CapMinds to strengthen security controls, improve regulatory readiness, reduce unresolved risk, and give leadership a clearer view of compliance performance across the enterprise with measurable, continuous operational oversight.



