What to outsource for HIPAA and what to keep in-house
If a customer, payer or contract now asks for HIPAA Security Rule evidence, the first thing to settle is what you can hand to a partner and what you must still own. Your organization keeps accountability for its safeguards, the designated security official role, risk decisions, workforce decisions and business associate agreements. Implementation partners and managed service providers can prepare systems, draft documentation, build technical controls and run monitoring, but they do not take over the obligation. HIPAA has no certification, so the claim you can make rests only on your own evaluation or on the work of an outside evaluator, and neither a vendor badge nor a partner's sign-off substitutes for either.
The exact split depends on three things: the scope of systems that create, receive, maintain or transmit ePHI, where that data physically lives, and what staff you already have. A practice with one hosted electronic health record and no internal IT team will hand far more to a managed provider than a health system running its own data centers. Start by listing every system and vendor that touches ePHI, then mark each activity as owned, prepared or operated by a third party. Confirm with each vendor which controls it actually runs, because cloud and hosting terms set the boundary. Microsoft's Azure guidance, for example, states that a business associate agreement does not make a customer compliant on its own. The HHS summary of the Security Rule is the natural starting point for the duties you cannot delegate.
The rest of this page maps that split. It covers the duties that stay in-house, the external evaluation you can commission, managed service provider responsibilities, cloud shared responsibility and the business associate agreements every vendor handling PHI must sign. Use it to draft a written responsibility matrix before you request quotes, because a partner can only price work that is defined in writing, and the matrix shows which evidence each party is accountable for producing.
Who does what: your team, vendors and outside evaluators
Your organization owns the Security Rule. The HIPAA security official, a role the Security Rule requires you to designate, is accountable for the program, and that accountability cannot be transferred to a vendor. Compliance leads and system owners carry the day-to-day work: they decide which risks to accept, approve policies, and make sure workforce members follow them. Under 45 CFR 164.308(a)(8), you must also evaluate your security safeguards periodically, and that evaluation can be run internally or by an outside organization.
- Security official: Designates responsibility for the program, approves the risk management plan, and signs off on the safeguards you choose.
- Compliance lead: Maintains policies, tracks open risks and keeps the documentation that the Security Rule requires you to retain.
- System owners: Configure access, logging, encryption and backups for the ePHI systems they run, and record the configuration as evidence.
- Workforce managers: Handle onboarding, training and access removal when people change roles or leave.
- Independence boundary: Internal staff can perform the evaluation, but their findings are management's own assessment, not an independent opinion.
Before you hire anyone, confirm which of these duties you can staff internally and which you need to document as your own decisions.
Vendors and consultants can prepare systems, controls and evidence, but they do not take over your obligations. An implementation partner, such as DeployOpen, plans, configures and documents the safeguards, and it may help you gather the evidence your risk analysis and evaluation need. A managed service provider operates parts of your environment, and a cloud provider operates the infrastructure beneath it. Each of these parties falls under business associate rules when it creates, receives, maintains or transmits ePHI for you, which means a written business associate agreement must be in place before it touches that data (45 CFR 164.308(b)).
- Implementation partner: Prepares systems, runs the safeguard build and assembles evidence. It does not issue audit reports or certificates.
- Managed service provider: Operates monitoring, patching or backups under a contract, and must meet the Security Rule for the ePHI it handles.
- Cloud provider: Secures the underlying infrastructure under a shared responsibility model. Your configuration choices still shape your risk analysis.
- Subcontractors: Any party a business associate uses for ePHI must be bound by equivalent assurances.
- Independence boundary: A vendor that configures a control should not be the only party that tests it.
Ask each vendor which safeguards it performs, which it leaves to you, and whether it will sign a business associate agreement before receiving any ePHI.
An external evaluator tests whether your program works, and it gives you a view you cannot produce yourself. The HHS FAQ on certification states that the evaluation can be done internally or by an external organization that provides evaluation or certification services. Under the Security Rule, however, no standard requires you to obtain a certificate, and HHS does not endorse or recognize private certifications. An outside firm can report its findings to you, but it cannot make you compliant or issue a HIPAA certificate that binds OCR.
- Scope agreement: Define the systems, sites and standards covered before testing starts, in writing.
- Independent testing: Assessors review evidence and test controls without building them, which protects the value of the opinion.
- Findings and remediation: The evaluator reports gaps, and your team decides which to fix, accept or document.
- Evidence retention: You keep the reports and remediation records, since OCR may ask for them during an investigation or audit.
- Independence boundary: A firm that designed or implemented the controls it is assessing has a conflict, so separate the implementation and assessment roles.
Confirm the evaluator's independence, the exact scope of its report, and whether the report will be used as your internal evaluation record.
Which HIPAA duties you cannot outsource
A partner can prepare evidence, draft documents and run technical work, but several Security Rule duties remain with the covered entity or business associate. The cards below describe what stays with your organization and what a partner can prepare for each one.
Designating the security official
The Security Rule requires you to name one individual responsible for developing and implementing its policies and procedures. That designation is an internal decision, and the named person must have the authority to act. An outside consultant can draft the role description, document duties and support the work, but your organization must name the person and record it. Check that the designation is written down and that the named person knows the scope of the role.
Accepting residual risk
A risk analysis identifies threats to ePHI, but deciding how much risk to keep is a management decision. A partner can document each risk, rank it and propose treatment options, yet the accepting executive must sign off on what remains open and why. Ask who in your organization holds that authority and how acceptances are reviewed when systems or vendors change.
Approving and owning policies
Written policies and procedures must cover each Security Rule requirement, and the covered entity or business associate is accountable for them. A consultant can produce templates, map policies to safeguards and track revisions. Leadership still has to approve the final text, enforce it and update it when operations change. Confirm that policies carry a named owner, an approval date and a review cycle.
Deciding addressable specifications
For each addressable implementation specification, the entity must assess whether it is reasonable and appropriate under 45 CFR 164.306(d). If it is not, the entity must document why and implement an equivalent alternative if one is reasonable. A partner can test options, measure costs and draft the rationale. The decision and its documentation belong to your organization, so ask for the reasoning in writing before accepting any exception.
Directing workforce access and sanctions
Your organization decides who may access ePHI, approves role assignments and applies sanctions for policy violations. A partner can configure identity tools, produce access review reports and set up audit logs. Managers and HR still make the decisions about grants, removals and discipline. Confirm that each access grant has an approver and that access reviews produce records someone signs.
Signing and managing business associate agreements
A covered entity may let a business associate handle ePHI only after obtaining satisfactory assurances in a written contract or other arrangement. Only your organization, or the counterparty you contract with, can sign that agreement. A partner can map where ePHI flows, list every vendor and subcontractor and prepare the evidence reviewers ask for. Ask who holds the signed agreements and when each one was last reviewed.
How business associate agreements and cloud shared responsibility split PHI duties
A covered entity may let a business associate create, receive, maintain or transmit electronic protected health information only after it obtains satisfactory assurances that the business associate will safeguard that ePHI, and those assurances must be documented in a written contract or other arrangement (45 CFR 164.308(b)). The business associate agreement is therefore the paper that makes outsourcing lawful, but it does not move the work. Each business associate must run its own risk analysis, must comply with the Security Rule's standards and implementation specifications, and is directly liable to OCR for Security Rule failures. A vendor that hosts or touches PHI cannot treat the contract as the end of its obligations, and a covered entity cannot treat the contract as proof that its vendor is safe.
Cloud hosting adds a second layer. OCR's cloud guidance says the cloud configuration an organization chooses affects the risk analysis and risk management plans of every party involved, so the provider's platform, the customer's application and the customer's settings each shape the risk picture. Microsoft's own HIPAA documentation makes the same point: using Azure does not automatically make a solution compliant, Microsoft does not inspect or approve customer applications, and customers remain responsible for their own compliance program. For healthcare software-as-a-service, the customer signs its BAA with the SaaS provider, not with the cloud platform beneath it, so the chain of contracts can be longer than buyers expect.
Before relying on any split of duties, ask each provider in writing for its current BAA, its shared responsibility documentation for the services you will use, and its list of subcontractors that handle PHI. Confirm which controls the provider operates, which you configure, and which you must evidence yourself, such as access reviews, audit log retention and encryption key management. Terms change, so record the version and date you reviewed and set a calendar check to re-read them. Where a gap appears, plan for it in your own risk management plan rather than assuming the provider covers it.
How to scope an outsourced HIPAA engagement in writing
This sequence gives you a written scope that shows which ePHI systems are in play, which duties stay with your organization, what each partner delivers, and what evidence proves it. Work starts only after the BAA and data handling terms are settled.
Confirm the ePHI systems and data flows
Start by listing every system that creates, receives, maintains or transmits electronic protected health information, including cloud tenants, endpoints, backups, email, billing platforms and any vendor-hosted application. Map where the data moves between them and who can reach it. The output is a written inventory with data flow diagrams that both your team and the prospective partner sign off on. Confirm the cloud configuration in use, because OCR's cloud guidance notes that configuration shapes the risk analysis of every party. The step is complete when no ePHI location is left unnamed.
Decide which functions stay internal
Split the Security Rule work into functions that stay with your organization and functions you may hand to an outside party. Duties tied to accountability, such as naming the security official and approving risk management decisions, should be documented as internal. Operational tasks like configuration, monitoring or evidence collection may be candidates for outside help. The output is a responsibility matrix that lists each function, its owner and whether it is internal, delegated or shared. Confirm this matrix with legal and compliance before any outside party is engaged.
Define each partner's deliverables and evidence
For every external party, write the deliverables in concrete terms: documents, configurations, reports, training records or test results. Name the evidence that will prove each deliverable was performed, such as change records, access reviews or signed policy acknowledgments. Be clear that a DeployOpen engagement prepares systems, controls and evidence, and that an independent auditor or assessor is the only party that issues audit reports or certifications. The output is a deliverables schedule that your team can check item by item.
Set the handover and documentation format
Agree on how work products will be delivered and stored. Specify file formats, the system of record for policies and risk documents, naming conventions, version control, and who holds administrative credentials at the end of the engagement. Require that the partner transfer documentation, runbooks and configuration records in a form your staff can maintain without the partner. The output is a handover plan with named recipients and a storage location. Confirm that ePHI is never stored in project tools that fall outside your BAA.
Agree on acceptance criteria
Define in advance what counts as a completed deliverable. For each item, state the test or check that confirms it meets the agreed scope, who performs the check, and who signs acceptance. Include how open findings will be recorded and whether any accepted risk must be documented with a rationale. The output is an acceptance criteria table attached to the scope. Without it, disputes about completion tend to surface only after work has been performed, so agree these terms before the work starts.
Confirm the BAA and data handling terms
Before any partner touches PHI, confirm that a written business associate agreement or equivalent arrangement exists, as the Security Rule requires satisfactory assurances for business associates handling ePHI. Check that the contract covers permitted uses, safeguards, subcontractor flow-down, incident reporting and return or destruction of ePHI at the end of the relationship. Confirm where the partner will access data and whether any remote or offshore access is involved. The output is a signed agreement on file. Do not grant access until this is complete.
Fix the scope in writing before work starts
Turn the outputs of the previous steps into a single fixed-scope document covering systems, responsibilities, deliverables, evidence, handover, acceptance criteria and data terms. DeployOpen agrees scope, deliverables and timelines in writing before work begins, and a quote follows from that written scope. Review the document with counsel and your security official, then sign it. The output is an approved statement of work that defines what the partner will and will not do, including a clear statement that no audit report or certification is included unless an independent assessor performs one separately.
How to choose a HIPAA consultant or managed service provider
Consultants, implementation partners and managed service providers can prepare systems, policies and evidence, but the covered entity or business associate keeps the obligations. The cards below are questions to put to any outside party before you hand over access, scope or budget. None of them can certify HIPAA compliance, so treat any claim of a HIPAA certification as a reason to ask harder questions.
Is a BAA signed before any PHI access?
Under 45 CFR 164.308(b), a covered entity may let a business associate create, receive, maintain or transmit ePHI only after satisfactory assurances are documented in a written contract or other arrangement. Ask for the signed business associate agreement before the vendor sees a ticket, log file or backup containing PHI, and confirm that subcontractors who touch PHI are also bound. Check that the agreement covers the Security Rule duties listed in 45 CFR 164.314(a), not just a generic confidentiality clause. No signed BAA means no PHI access.
Is the scope written with deliverables?
Ask for a written statement of which systems, facilities, applications and cloud accounts are in scope, which HIPAA standards each deliverable addresses, and what the entity receives at the end. A fixed-scope agreement should name the risk analysis output, the risk management plan, policy drafts, configuration baselines and test results. Vague language such as "HIPAA support" makes it impossible to tell later what was bought, what was delivered and what remains open.
Who are the named people and their experience?
Ask for the names, roles and HIPAA or security experience of the staff who will touch your environment, not only the sales lead. Confirm whether work is done by employees or subcontractors, and whether the people reviewing your risk analysis have hands-on experience with the systems you run. Ask how the team is supervised and who you contact when a named person leaves the engagement during the work.
Is the split of responsibilities documented?
Require a written responsibility matrix that states which duties the entity keeps, such as naming the security official, approving risk decisions, workforce sign-off and accepting residual risk, and which duties the provider performs, such as monitoring, patching or backup testing. Cloud and hosting providers have their own shared responsibility model, and Microsoft notes that a BAA does not make a customer compliant. Mark any gap in the matrix before work begins, because gaps are where incidents and audit findings appear.
Do you own the documentation you receive?
Confirm in the contract that policies, procedures, risk analyses, configuration records, logs and test reports are delivered to the entity in editable form and belong to it. Ask how long the provider keeps copies after the engagement ends and how records are returned or destroyed under the BAA. Documentation under 45 CFR 164.316 must be retained for six years and kept available to the people who must act on it, so you cannot depend on a provider's portal to hold it.
Can you verify their references and claims?
Ask for references from organizations of similar type and size, and check them directly rather than through the provider's own contact. Ask which HHS and NIST sources the provider uses as its method, such as the HHS risk analysis guidance or NIST SP 800-66 Rev. 2, and whether it can explain how it tailors them. Be wary of any claim of HIPAA certification or official endorsement, because HHS states that it does not endorse or recognize private certifications.
What an outside assessment can and cannot show about HIPAA
An outside evaluation can tell you whether your safeguards hold up against the Security Rule, but it cannot tell you that you are compliant in a way that binds OCR. HHS does not endorse or recognize private certifications, and it states that no Security Rule standard requires an entity to certify compliance. A certificate, seal or attestation from a private firm therefore does not prevent OCR from later finding a violation. Treat any external review as an independent input to your risk analysis, not as a legal finding of compliance. The HHS FAQ on certification is the first source to read before a vendor offers you a badge.
The split of work matters most here. If the partner that designed your policies, configured your audit logs and chose your encryption settings is also the only party that tests them, the evaluation tests its own homework. Ask for the evaluator to be independent of the implementation team, and ask who wrote the test procedures. Keep the internal evaluation under your security official, which HHS allows to be done internally or by an external organization, and bring in an outside evaluator to challenge the results. Write down which party did which test so OCR can see the separation if it asks.
OCR's own audit program shows what regulators look at. Its 2024 to 2025 HIPAA audits reviewed 50 covered entities and business associates for the Security Rule provisions most relevant to hacking and ransomware, so those provisions are where an outside reviewer should spend the most time. Before you buy an assessment, confirm in writing which Security Rule standards it will test, which evidence it will sample, and whether it will examine your business associate agreements and the cloud configuration your vendors manage. An assessment that skips those areas will not support the claims you need to make to a customer or regulator.
Mistakes that make outsourced HIPAA work cost more or fail
Most outsourced HIPAA problems come from unclear ownership, not from weak vendors. The cards below cover the points where contracts, decisions and evidence drift apart, and the simple checks that keep the split between your team, vendors and consultants clear.
Starting work before a BAA is signed
Any vendor, consultant or managed service provider that creates, receives, maintains or transmits ePHI for you needs satisfactory assurances in place before it touches that data. A covered entity may allow a business associate to handle ePHI only after those assurances are documented in a written contract or other arrangement. If a consultant reviews a real EHR export or logs in with PHI access before the agreement is signed, you may have to unwind the access, document the gap and explain it later. Fix it by making the business associate agreement a condition of the statement of work, and check that the scope names every system the vendor will reach.
Outsourcing risk decisions without owner sign-off
A consultant can run the risk analysis and recommend controls, but accepting a residual risk is a business decision that stays with the entity. When the vendor's report is filed without a named owner approving each accepted risk, the risk management plan has no accountable person behind it. The delay shows up later, during an OCR inquiry or a breach response, when no one can say who chose to accept a gap. Fix it by assigning a named executive to sign each risk acceptance and keeping those signatures with the risk register.
Leaving evidence in the vendor's systems
Logs, policy documents, training records, access reviews and risk analysis workpapers are your compliance evidence, and the documentation standard expects you to keep them available and retained. When a consultant stores them only in its own ticketing tool or document library, you lose access the day the contract ends or the vendor changes platforms. Fix it by requiring that every deliverable is delivered into a repository you control, with a retention period and an export test written into the contract before work begins.
Blurred lines between the MSP and your team
A managed service provider may patch servers, monitor alerts and manage backups, but many safeguards still need an internal owner for decisions such as who gets access, how incidents are escalated and when a breach assessment starts. If the responsibility matrix says the MSP handles access reviews, nobody may notice that terminated staff still have accounts. Fix it by writing a responsibility matrix that lists each Security Rule activity, the party that performs it and the party that approves it, then reviewing it at each renewal.
Changing cloud configuration without updating the analysis
OCR's cloud guidance says the cloud configuration affects the risk analysis and risk management plans of every party. When an engineer enables a new storage service, adds a region or changes encryption settings, the earlier risk analysis no longer describes the system that holds ePHI. Consultants often deliver a clean assessment, then nobody reruns it after the next change window. Fix it by adding a trigger to your change process so that any change touching ePHI systems is reviewed against the current risk analysis before it goes live.
Treating an assessment as a certificate
A consultant's report shows what was tested on a given date. It is not a HIPAA certificate, and HHS states that it does not endorse or recognize private certifications, which do not prevent later enforcement findings. Organizations that buy a badge and stop maintaining controls often fail when OCR asks for current documentation. Fix it by asking the consultant to write its scope, sample dates and limitations on the report's cover, and by planning the next review as part of your own compliance program.
Questions buyers ask before outsourcing HIPAA work
Can we outsource the HIPAA security official role?
Partly. The Security Rule requires a covered entity or business associate to designate one security official, and that person's responsibilities stay with your organization even when an outside consultant or fractional officer does much of the day-to-day work. The named individual should be accountable internally, have authority to direct security decisions, and be documented as the official. An outside person who accesses PHI also needs a business associate agreement. Confirm with your counsel how the designation and accountability will be written into your policies before signing a statement of work.
Do we need a BAA with a consultant who sees PHI?
Yes, if the consultant creates, receives, maintains or transmits ePHI on your behalf. A covered entity may let a business associate handle ePHI only after obtaining satisfactory assurances documented in a written contract or other arrangement under 45 CFR 164.308(b). That applies to a consultant who reviews systems containing PHI, receives exports for a risk analysis, or has administrative access to a hosted environment. A consultant that only reviews policies and never touches ePHI may not need one, but confirm the access model in writing. Ask the firm how it limits PHI access and where that access is logged.
Can a managed service provider make us HIPAA compliant?
No. A managed service provider can run controls you assign to it, but it cannot make your organization compliant on its own. Microsoft states that a BAA does not make a customer HIPAA compliant and that customers remain responsible for their own compliance program, and the same principle applies to other providers. Each business associate must perform its own risk analysis, and the configuration you choose affects everyone's risk analysis under OCR's cloud guidance. Ask the provider which Security Rule safeguards it operates, which remain yours, and what evidence it will deliver each month.
What does the work need from our team?
Your team has to supply decisions, access and knowledge that no outside party can supply for you. Expect to name owners for each safeguard, approve written policies and procedures, provide system inventories and data flow information, decide how to treat each addressable specification, and manage workforce training and access reviews. Your technical staff will need time to implement changes and to test backups and monitoring. Ask any firm to list these client-side tasks in its scope document so the internal effort is visible before you commit.
Can we do HIPAA work ourselves?
Often yes, especially for a small organization with a limited set of systems. HHS provides a free risk analysis tool, and the 405(d) Health Industry Cybersecurity Practices guidance is written to be tailored after a risk assessment rather than applied as a fixed checklist. The Security Rule does not require outside help. The hard part is consistency: documentation must be kept current, addressable decisions must be recorded with reasons, and technical controls must be tested. Consider outside help where you lack staff with security expertise, where your environment is complex, or where a regulator or contract requires independent evaluation.
Does an outside firm give us a HIPAA certificate?
No. HHS states that no Security Rule standard requires an entity to certify compliance, and HHS does not endorse or recognize private organizations' certifications. A firm can evaluate your controls and report findings, and HHS FAQ guidance says the evaluation can be done internally or by an external organization that provides evaluation or certification services. Such a report does not prevent OCR from later finding a violation. Ask any provider to describe its deliverable precisely, and treat any offer of a HIPAA certificate as a warning sign.
What changes if the proposed rule is finalized?
The proposed rule has not been finalized, so current Security Rule requirements still apply. HHS proposed a major revision on January 6, 2025 (90 FR 898, RIN 0945-AA22) with comments due March 7, 2025. The latest Unified Agenda lists it under Long-Term Actions with final action projected for July 2027, so timing could change. Because the proposal would tighten requirements, any outsourcing contract should allow scope changes, have a clear process for updating policies and controls, and name who pays for rework if requirements change.
How DeployOpen scopes HIPAA work and what it hands over
DeployOpen helps organizations split HIPAA Security Rule work between their own staff, vendors and outside specialists by first agreeing in writing which safeguards, systems and evidence are in scope. We then plan, implement and document the self-hosted open-source platforms and controls inside your own infrastructure, while your organization keeps ownership of its controls and decisions.
How we scope
- Engagements are fixed-scope, with the systems, ePHI locations and safeguards in scope agreed in writing before work starts.
- The written scope separates duties DeployOpen can prepare from duties your workforce or named security official must own.
- We confirm which business associate agreements, vendor contracts and cloud shared responsibility boundaries apply to each in-scope system.
How we build
- We implement and configure self-hosted open-source platforms inside your cloud accounts, data centers or air-gapped networks.
- Technical safeguards such as access control, audit logging and encryption are configured and tested against the agreed scope.
- Security testing can be included where the written scope calls for it, with findings tracked to remediation.
How we hand over
- You receive documentation of configurations, responsibilities and the evidence each in-scope safeguard produces.
- Outsourced duties and the parties accountable for them are recorded so your risk analysis and risk management plan can reference them.
- Handover includes a clear list of items your team must confirm, approve or perform itself, because an outside party cannot issue your certification or determine your compliance.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
- Retainers can cover platform maintenance, evidence refreshes and periodic review of the outsourced and in-house split as your environment changes.
- Ask any provider, including DeployOpen, to confirm in writing who signs the business associate terms and who keeps accountability for each duty.
