HIPAA compliance for SaaS and cloud vendors starts with business associate status
When a health care customer asks to put ePHI on your platform, the first question is not which certificate you hold. HIPAA has no certification. HHS states that no Security Rule standard requires an entity to certify compliance and that it does not endorse private certifications. Your obligations come from status: a software or cloud company that creates, receives, maintains or transmits ePHI for a covered entity is a business associate, and it must meet the Security Rule's standards and implementation specifications in its own right. HHS's cloud guidance is explicit that this holds even when the provider stores only encrypted ePHI and never holds the key. Two core obligations follow: a signed business associate agreement with the customer, and your own risk analysis. OCR's cloud guidance says the cloud configuration you choose affects the risk analysis of every party, so the customer's assessment depends on yours.
Direct liability matters just as much. Business associates are directly liable to OCR for Security Rule failures, and the cloud guidance says a provider is both contractually liable under the BAA and directly liable under the HIPAA Rules. Your position is therefore not only a contract question for sales or legal. Confirm with counsel which of your entities signs the BAA and whether any affiliate or subcontractor also touches ePHI, since a subcontractor doing that work for you is itself a business associate. The answer changes with the scope of the service, the volume of ePHI, the subcontractors you use and the mix of covered and non-covered customers on the same platform. A single-tenant deployment for one hospital system and a multi-tenant product serving hundreds of practices need different risk analyses, and both need to be written down.
Your organization owns its controls and the decisions above. An implementation partner can prepare systems, configurations and evidence, such as access records, backup tests and risk analysis documentation, but it does not sign the BAA or attest to your compliance. Only an independent assessor can issue a report, and HHS does not recognize any private certificate as proof. Before a customer's security review, ask your assessor or counsel which evidence they will accept, and map each BAA promise to a control you can show.
What the vendor owns, what the customer owns
A software or cloud company that creates, receives, maintains or transmits ePHI for a covered entity is a business associate. It must comply with the Security Rule's standards and implementation specifications under 45 CFR 164.302, and it is directly liable to the HHS Office for Civil Rights (OCR) for Security Rule failures, separately from whatever its contract says. Its obligations apply to its own systems, workforce and any subcontractors that touch ePHI for it.
- Own risk analysis: The vendor must perform a risk analysis of the systems that hold or process ePHI, and it must maintain risk management measures that follow from it.
- Security Rule compliance: Required safeguards apply to the vendor's platform, and addressable specifications need documented decisions and equivalent measures where chosen.
- Breach notice: The vendor must notify affected covered entities of a breach without unreasonable delay and within 60 calendar days of discovery.
- Direct liability to OCR: Regulators can act against the vendor directly, not only through the customer.
- Subcontractor flow-down: Subcontractors that handle ePHI for the vendor are also business associates and need their own agreements.
Before signing, ask the vendor to show its current risk analysis summary, its breach notice procedure and its list of subcontractors that touch ePHI.
The covered entity remains responsible for its own compliance with the Security Rule, even when a vendor hosts its records. It decides which data goes into the service, who may access it, how the service is configured and whether the vendor's safeguards are adequate for its risk. A vendor's certificate or attestation does not transfer those decisions away from the customer.
- Own risk analysis: The covered entity must assess the ePHI it places with the vendor and record the risks and measures that follow.
- Configuration choices: Settings such as who holds administrative rights, how encryption keys are managed and which data is retained shape the risk picture for every party.
- Business associate agreement: The covered entity must have a BAA in place with the vendor before ePHI is shared, with terms that reflect the Security Rule.
- Access and user management: The customer manages its own workforce accounts, role assignments and offboarding inside the platform.
- Vendor oversight: The covered entity should review the vendor's assurances and act when a vendor fails to meet its BAA terms.
Check that the BAA and service level agreement name who manages each configuration setting, because gaps between the two documents are where disputes usually start.
OCR's cloud guidance states that the cloud configuration used affects the risk analysis and risk management plans of all parties. A deployment choice made by one side can therefore change the risk picture for the other, so neither party can assess its exposure in isolation. This is the area where the vendor's and the customer's documentation most often disagree.
- Encryption and key handling: Who controls encryption keys, and how they are rotated and stored, changes what the vendor can read and what the customer must protect.
- Tenancy and hosting model: Multi-tenant, dedicated or customer-hosted deployments carry different isolation and patching duties.
- Logging and retention: The scope of audit logs and how long they are kept determines what each party can investigate after an incident.
- Backup and recovery: Backup frequency, restoration testing and where copies are stored must be agreed and documented by both sides.
- Data return and deletion: The steps for returning or destroying ePHI at termination should name the responsible party for each step.
Ask for a written responsibility matrix that both parties sign, and confirm that each party's risk analysis references the same configuration.
OCR's cloud guidance says the customer and the cloud provider must sign a HIPAA-compliant business associate agreement, and that the provider is both contractually liable under it and directly liable under the HIPAA Rules. The BAA sets the baseline, and the service level agreement fills in operational detail. Terms that are vague in either document usually become the first point of contention after an incident.
- BAA content: The agreement should cover the vendor's Security Rule obligations, permitted uses and disclosures, and the incident reporting clause.
- SLA topics: OCR's guidance lists availability and reliability, backup and data recovery, how data is returned after termination, security responsibility, and use, retention and disclosure limits.
- Subcontractor terms: The agreement should require the vendor to bind its subcontractors to the same obligations.
- Breach timing: Confirm that the contract restates the 60 calendar day outer limit and sets an earlier target where the customer needs one.
- Verification: Ask whether the vendor will provide written evidence of its safeguards and how often, noting that the 2025 proposal would require written verification at least every 12 months.
Have healthcare counsel review the BAA and SLA together, and confirm that neither document contradicts the other.
What a BAA and SLA must cover for HIPAA customers
Health care customers will expect a signed business associate agreement before any ePHI moves to your platform, and an service level agreement that addresses the operational questions OCR raises for cloud arrangements. The cards below cover the contract pieces that connect the vendor's legal duties to the security work behind them. Have counsel review the final wording of every clause.
The business associate agreement and its signature
A cloud service provider that creates, receives, maintains or transmits ePHI for a customer is a business associate, even if it stores only encrypted data and holds no key. OCR's cloud guidance says the customer and the provider must sign a HIPAA-compliant business associate agreement before the relationship starts handling PHI. Check that the agreement names the Security Rule safeguards you actually operate, not only a general promise to comply. Confirm the signature is in place for every customer environment, including pilots and test data copied from production.
Contractual and direct liability
A business associate must comply with the Security Rule's standards and implementation specifications and is directly liable to OCR for failures, independent of what the contract says. Under OCR's cloud guidance, a provider is also contractually liable under the business associate agreement. The contract should describe how each liability is allocated, including indemnities, caps and carve-outs for breaches. Ask counsel to confirm that the cap language does not leave the customer without a remedy for a security failure that the vendor caused.
Availability, backup and data recovery terms
OCR's cloud guidance lists availability and reliability, plus backup and data recovery, as service level topics relevant to HIPAA. The SLA should state the uptime commitment, how backups are taken and tested, and the recovery expectations a customer can measure. Define how restoration is verified, not only how it is scheduled. Ask for the historical restoration test results you would expect to see during a customer security review.
Data return and deletion after termination
OCR's cloud guidance identifies how data is returned after termination as a required SLA topic. The contract should say in what format the customer receives its ePHI, how long the vendor has to deliver it, and how the vendor certifies deletion from production, backups and archives. Clarify whether any residual copies remain for legal hold and how long they persist. Confirm that these steps are tested in an exit exercise, not only written into the contract.
Security responsibility and shared controls
OCR's cloud guidance states that the cloud configuration used affects the risk analysis and risk management plans of every party. The SLA should separate what the provider operates, such as the hypervisor, managed database patching and network controls, from what the customer configures, such as user access, encryption settings and logging. A responsibility matrix attached to the agreement makes that split reviewable. Ask the vendor to show the matrix matches the actual configuration of the environment it hosts for you.
Use, retention, disclosure and subcontractor flow-down
The agreement must limit how the vendor may use, retain and disclose ePHI, and OCR's cloud guidance treats these limits as an SLA topic. Subcontractors that create, receive, maintain or transmit ePHI for the vendor are business associates too, so the vendor must bind them to the same restrictions in writing. Breach notice to the covered entity is due without unreasonable delay and within 60 calendar days of discovery, so the contract should set a shorter, specific deadline and name who receives the notice. Ask for the current list of subcontractors that touch ePHI.
What makes HIPAA compliance for SaaS vendors cost more or take longer
For a SaaS or cloud vendor, the cost of HIPAA Security Rule work rarely comes from the rule's text alone. It comes from how many customers, systems, subcontractors and environments the vendor must evidence, and how mature that evidence is. The six drivers below are the ones that most often expand scope, and each one can be shaped by design and contract decisions made early.
Covered entity customers and BAA negotiations
Each covered entity customer typically requires a business associate agreement, and many larger customers send their own template. Every negotiated clause on breach notice, subcontractor flow-down, data return and security responsibility adds legal review and internal sign-off time. Control this by maintaining one standard BAA with a short list of pre-approved deviations, and by confirming early which SLA topics OCR's cloud guidance lists, such as availability, backup, data return and retention limits, so they are not discovered mid-negotiation.
Number and type of ePHI data stores
Every database, object store, log pipeline, backup, analytics warehouse and support ticket system that holds ePHI widens the risk analysis, the access reviews and the encryption evidence. A vendor that cannot list where ePHI lives will spend the most time on this item. Control it by tagging data stores by data classification, limiting which services may hold ePHI, and keeping a current inventory that the risk analysis is built from.
Multi-tenant architecture
In a multi-tenant platform, one customer's ePHI shares infrastructure with others, so the vendor must show logical separation, tenant-scoped access controls and audit records that tie each action to a tenant. Assessors ask how a single misconfigured query or role would be caught. Control it by enforcing tenant identifiers at the data access layer, testing cross-tenant access paths, and deciding early whether any customer needs dedicated infrastructure, since dedicated tenancy multiplies environments and evidence.
Number of subcontractors
Cloud hosts, support tools, email providers and logging vendors that touch ePHI are business associates of the vendor, and the vendor must have agreements with them. Each subcontractor adds a contract to track, a risk review and a breach notification path that must fit the 60-calendar-day outer limit. Control this by minimizing which subcontractors receive ePHI, requiring written flow-down terms before any data moves, and keeping a register that records the service, the data involved and the agreement date.
Evidence maturity
A vendor with written policies, dated risk analysis updates, training records, access review logs and tested incident procedures can answer a customer questionnaire in days. A vendor that must create these records while a deal is open spends months on it. Control this by producing evidence as a routine output of operations, assigning an owner to each Security Rule documentation item, and keeping six-year records as the rule requires so that older proof is still available when a customer asks.
Number of environments
Production, staging, disaster recovery, sandbox and customer-specific deployments each need access controls, encryption, logging and a documented risk position if they can hold ePHI. Copying production data into a test environment is a frequent source of unplanned scope. Control this by keeping synthetic or de-identified data in non-production environments, applying the same safeguards to any environment that holds ePHI, and recording each environment in the risk analysis so the count is known in advance.
Who gets paid for what when a vendor prepares for customer HIPAA reviews
This table compares the cost components a SaaS or cloud vendor meets when customers review its HIPAA Security Rule posture, who is paid for each, whether it is one-time or recurring, and what drives it up. Use it to build a written scope and request separate quotes so no component is assumed to be included in another. No prices are stated because none were supplied, and the figures you receive should come from the written scope.
| Cost component | Who is paid | One-time or recurring, and what drives it |
|---|---|---|
| Internal engineering and compliance staff | Your own employees (salaried time, not invoiced) | Recurring. Driven by the number of customer questionnaires, the number of product environments in scope, and how often configurations change. |
| Implementation partner for systems and evidence | External firm such as DeployOpen, under a fixed-scope written agreement | Mostly one-time for hardening, logging and documentation, then recurring for retainers. Driven by the number of systems, integrations and environments, and the state of existing evidence. |
| Independent assessor or auditor, if commissioned | External assessor selected and paid by the vendor or the customer | One-time per assessment cycle, and recurring if the assessment is repeated. Driven by scope, report type and whether the customer requires a specific assessor. HHS does not endorse any third-party HIPAA certificate. |
| Security tooling and hosting | Software vendors and cloud or data center providers | Recurring subscriptions or infrastructure charges. Driven by log volume, scanning frequency, retention periods and whether tools are self-hosted or licensed. |
| Legal review of business associate agreements and SLAs | Outside counsel or in-house legal time | One-time for template negotiation, then recurring for customer-specific agreements. Driven by the number of customers with bespoke terms and the subcontractors that need flow-down terms. |
| Penetration testing and security testing | External testing firm or internal team | Recurring, usually annual or after major changes. Driven by the attack surface, the depth of testing and the remediation cycle that follows findings. |
| Customer-requested evidence packages | Internal staff, with help from partners if requested | Recurring per customer review. Driven by how many customers ask for custom artifacts, such as risk analysis summaries, policy extracts and incident procedures. |
How a vendor gets ready for its first customer security review
The sequence below takes a SaaS or cloud company from an undefined set of ePHI systems to a customer package it can defend, with each phase producing a record the next phase depends on. It is the preparation work a vendor does before a health care customer's security team starts asking questions.
Scope the ePHI systems and data flows
Start by listing every system that creates, receives, maintains or transmits electronic protected health information for a covered entity or another business associate. Include production applications, databases, backups, logging, support tools, analytics copies and any environment where test data may contain real patient records. Engineering and product owners do this with the security lead, and the output is a system and data flow inventory that shows where ePHI enters, moves and rests. You know the step is done when every system on the inventory has a named owner and someone outside the engineering team has checked the list for gaps.
Perform and document the risk analysis
Using the inventory, identify threats and vulnerabilities to ePHI, assess the likelihood and impact of each, and record the current safeguards that reduce them. The vendor's security official leads this work, and it must reflect the cloud configuration actually in use, since OCR's cloud guidance says that configuration affects the risk analysis and risk management plans of every party. The output is a written risk analysis and a risk management plan that assigns each identified risk to an action, an owner and a decision. The step is complete when the document is dated, approved by leadership and linked to the systems on the inventory.
Map subcontractors and business associate agreements
List every cloud provider, hosting service, monitoring tool, support vendor and contractor that touches ePHI on the vendor's behalf. Each one that creates, receives, maintains or transmits ePHI is itself a business associate, so the vendor must confirm that each has signed a business associate agreement that flows down the required protections. Legal and procurement own the contract review, and the output is a subcontractor register that records the agreement, its signature date and the incident reporting terms. The step is done when no ePHI-touching vendor appears on the inventory without a matching agreement on file.
Implement and evidence the safeguards
Close the gaps the risk management plan identified by putting the Security Rule safeguards in place: access control, audit logging, encryption in transit and at rest, authentication, backup and recovery, workforce training and sanctions, and written policies. Engineering, operations and HR carry out the work, and each safeguard should produce evidence that can be shown later, such as configuration exports, access reviews, training records and restore test results. Where an addressable specification is not adopted, the vendor needs a documented decision and an equivalent measure. The output is a control set with its evidence stored in a known location, and the step closes when each safeguard can be traced to a risk it addresses.
Prepare the customer security package
Assemble the documents a customer's security and privacy team will request, including the current risk analysis summary, policies, the subcontractor register, the signed business associate agreement template, the service level terms covering availability, backup, data return and security responsibility, and recent test or scan results. Confirm which items are internal documents that can be shared under nondisclosure terms and which are summaries. The output is a versioned package with a cover statement that describes scope and limits. The vendor should not describe the package as a HIPAA certificate, because HHS does not recognize such certifications. The step is done when a named person can answer for each document.
Handle the customer security review
When a customer sends its questionnaire or audit request, route each question to the owner of the matching evidence, answer from the package rather than from memory, and record every answer and the document it cites. Where a customer asks for a result the vendor cannot give, such as a certification, the vendor states what it has and what it does not. Any independent assessment the vendor commissions is a separate engagement, and only the assessor issues its own report. The output is a completed questionnaire, a log of open requests and agreed remediation items with owners. The review is finished when the customer confirms it has what it needs or the open items are written into the contract terms.
What customers will ask a SaaS vendor to see
A health care customer that engages a SaaS or cloud vendor will usually ask for a folder of written evidence rather than a certificate. The core items are the vendor's current risk analysis summary and risk management plan, since OCR treats each business associate as obligated to perform its own risk analysis and states that the cloud configuration affects everyone's risk analysis. Expect requests for written security policies and procedures, the business associate agreement, and a current list of subcontractors that create, receive, maintain or transmit ePHI on the vendor's behalf, because those subcontractors are also business associates. Confirm internally that these documents exist, are dated, have named owners and match the system the customer will actually use.
Customers will also ask how the vendor responds when something goes wrong. Prepare the incident response plan, the breach notice procedure that meets the 60-calendar-day outer limit for notifying covered entities, and a record of the most recent backup restoration test, not just the backup schedule. Describe encryption in transit and at rest, key management, and access control for administrators and support staff, including how multi-factor authentication and audit logging are configured. Name the file or configuration source for each claim, such as the key settings in the infrastructure-as-code repository, so the answer can be checked.
A SOC 2 report, an ISO 27001 certificate or a third-party HIPAA assessment letter can support these answers, but none of them is a HIPAA certification. HHS does not recognize private certifications, and no Security Rule standard requires one. Describe such a report as independent evidence covering specific controls over a stated period, and state its scope and period plainly. Do not present it, or any seal or badge, as proof of HIPAA compliance. Ask your assessor exactly what the letter covers and what it excludes, and confirm that your business associate agreement and sales materials use the same language.
What usually delays SaaS HIPAA reviews and how to avoid it
Most delayed HIPAA reviews for software and cloud vendors trace back to a short list of gaps: missing analysis, unclear data paths, late paperwork, unmanaged subcontractors and sales promises the product cannot back up. Each card names one gap, why a customer's reviewer will stop on it, and what the vendor should have ready before the first security questionnaire arrives.
An undocumented risk analysis
A vendor that handles ePHI for a covered entity or business associate must perform its own risk analysis, and OCR's cloud guidance says the cloud configuration used affects the risk analysis and risk management plans of all parties. Customers often ask for this document first. If it exists only as a verbal assurance or an outdated spreadsheet, the review stalls. Before sharing it, confirm it is dated, covers the production environment as deployed, lists threats and the controls chosen for each, and records who approved the risk management plan.
Unclear data flow maps
Reviewers need to know where ePHI is created, received, stored, transmitted and deleted, including logs, backups, support tickets and analytics exports. When a vendor cannot show that path, the reviewer cannot judge which safeguards apply where. An illustrative example: an intake form sends data to a queue, a database, a nightly backup and a support tool, and the map lists only the first. Keep one current diagram per product, tie each hop to an encryption and access control, and state which systems hold ePHI and which do not.
A BAA signed after data arrived
A cloud service provider that creates, receives, maintains or transmits ePHI for a covered entity is a business associate, and OCR's cloud guidance says the customer and provider must sign a HIPAA-compliant business associate agreement. A vendor that receives PHI during a pilot, proof of concept or data migration before the agreement is signed creates a compliance gap the customer must explain to its own compliance team. Agree the BAA before any test data containing real patient information is loaded, and use synthetic data for trials until it is in place.
Subcontractors without flow-down
A subcontractor that creates, receives, maintains or transmits PHI for a business associate is also a business associate. Hosting providers, support desks, email relays, logging services and offshore development teams all count if they touch ePHI. Reviewers ask for a current subcontractor list and proof that each subcontract carries the same Security Rule obligations and breach reporting duties the customer's BAA requires. Keep that list with contract dates and review it whenever a new service is added.
Sales claims the platform cannot support
Sales decks and questionnaire answers that say a product is HIPAA certified, fully encrypted or compliant by default create the largest credibility problem. HHS does not recognize private certifications, and no Security Rule standard requires certification, so a claim of certification invites scrutiny of everything else. Before a sales team uses a phrase, the engineering and security leads should confirm it against the configuration the customer will actually receive, and the vendor should state which controls are the customer's own responsibility.
Missing audit and recovery terms
OCR's cloud guidance lists service level agreement topics relevant to HIPAA, including availability and reliability, backup and data recovery, how data is returned after termination, security responsibility, and use, retention and disclosure limits. Reviewers often find that the master agreement covers price and uptime but not these items. Before the first review, draft a HIPAA addendum or SLA schedule that answers each topic in writing, and confirm the backup restoration and data return procedures with the engineering team so the text describes what the platform does.
Who does what: vendor, implementation partner and independent assessor
The vendor is the business associate. Under the Security Rule, a cloud service provider or software company that creates, receives, maintains or transmits ePHI for a covered entity must comply with the standards and implementation specifications itself, and OCR's cloud guidance says the provider is directly liable for Security Rule failures. The vendor therefore owns the risk analysis, the risk management plan, the written policies, the workforce training, the business associate agreements with its own subcontractors, and the decisions about how each addressable specification is handled and documented.
- Risk analysis: The vendor must run its own risk analysis, and the cloud configuration it chooses changes that analysis and its risk management plan.
- Policies and workforce: Written procedures, sanctions, training and access reviews are performed and signed off by the vendor's staff.
- Contract terms: The vendor signs the BAA with each customer and flows requirements down to its subcontractors.
- Breach duties: The vendor must notify covered entities without unreasonable delay and within 60 calendar days of discovery.
- Decision records: The vendor decides and documents why each addressable specification is met, or why an equivalent measure is used.
Before relying on any vendor claim, check whether the vendor can name the person who owns its risk analysis and show the most recent version.
An implementation partner helps the vendor build and document the environment that the vendor's controls run in. DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks, and it prepares systems, controls and evidence for compliance assessments. It does not decide the organization's risk acceptance, does not sign the BAA on the vendor's behalf as an authority on its obligations, and does not issue reports or certificates.
- Systems work: Hardening, logging, backup and recovery, and access configuration are built to the scope agreed in writing.
- Evidence preparation: Configuration records, test results and runbooks are organized so the vendor and its assessor can review them.
- Testing: Security testing of applications, APIs and infrastructure can be scoped as a separate engagement.
- Documentation handover: The vendor receives the documents it needs to own and maintain the environment after delivery.
- Ongoing support: Retainers for upgrades and continuous testing are available as separate, written agreements.
Ask the partner to list in writing which deliverables are systems, which are evidence, and which remain the vendor's decisions.
An independent assessor or auditor is the only party that can issue an audit report, attestation or certification that a customer can rely on as third-party evidence. HHS states that it does not endorse or recognize private organizations' certifications, and that a certificate does not prevent OCR from later finding a violation. The assessor tests the vendor's controls against an agreed scope and reports its own findings, independent of the people who built the environment.
- Independence: The assessor must not design or operate the controls it tests, which is why it stays separate from implementation work.
- Scope and sampling: The assessor defines what it tests and how much evidence it samples, based on its own procedures.
- Report ownership: Any report is issued in the assessor's name and describes only what it examined and for what period.
- Limits: A report does not replace the vendor's own risk analysis or its duty to comply with the Security Rule.
- Engagement terms: Ask whether the assessor has a conflict of interest with any implementation work done for the same vendor.
Confirm the assessor's scope statement and the report's date range before presenting it to a customer.
Questions SaaS and cloud vendors ask about HIPAA
Is there an official HIPAA certification for SaaS or cloud vendors?
No. There is no official HIPAA certification. HHS states that no Security Rule standard requires an entity to certify compliance, and it does not endorse or recognize private certifications, which also do not stop HHS from later finding a violation. What customers can reasonably ask for is evidence: a current risk analysis, written policies, a signed business associate agreement, and, where a customer wants independent testing, a report from a qualified third-party assessor. Treat any vendor that advertises a HIPAA certificate or seal as making a claim to verify, not as proof. Your organization owns its safeguards, an implementation partner can prepare systems and evidence, and only an independent auditor or assessor issues a report.
Must a SaaS vendor sign a BAA with every healthcare customer?
Yes, when the vendor creates, receives, maintains or transmits ePHI for that customer, the vendor is a business associate and the parties need a HIPAA-compliant business associate agreement. OCR's cloud guidance says the customer and the cloud provider must sign one, and the provider is both contractually liable under it and directly liable under the HIPAA Rules. The agreement is usually a standard template across customers, but its terms still need review for each relationship. Subcontractors that handle ePHI for you, such as hosting or support providers, are also business associates and need their own agreements with you. Confirm with counsel which of your features touch PHI before you assume a customer is out of scope.
Does encrypting ePHI in the cloud remove business associate status?
No. A cloud service provider that stores or processes ePHI for a covered entity is a business associate even if it holds only encrypted data and does not have the encryption key. HHS's cloud guidance makes this point directly. Encryption is still a strong safeguard and reduces what an attacker can read, but it changes the risk analysis rather than the legal status. The provider must still comply with the Security Rule's standards and implementation specifications, sign a business associate agreement, and remain directly liable to OCR for Security Rule failures. Ask counsel to confirm how your service model maps to this guidance.
How long does HIPAA readiness take for a SaaS product?
The honest answer depends on the inputs, and no timeline should be quoted without a written scope. The main drivers are how many systems hold or move ePHI, how much of the stack is inherited from a cloud provider, whether a current risk analysis exists, how mature your policies, access reviews, logging and backup are, and how many customer security questionnaires and BAA negotiations run in parallel. Products with a single, well-documented environment usually move faster than multi-tenant platforms with many integrations. Ask any partner to break down the effort by phase and by evidence item, and to state the assumptions behind each estimate.
Can an in-house team handle HIPAA compliance without outside help?
Often yes, if the team has security, compliance and engineering skills and the time to keep evidence current. The Security Rule does not require a particular staffing model. What usually decides the question is ownership: someone must be named as the security official, must run and update the risk analysis, must maintain policies and training records, and must answer customer audits. Outside help makes sense when no one has done a formal risk analysis before, when customer questionnaires outpace staff capacity, or when an independent technical test is needed. An implementation partner can prepare systems, configuration and evidence, but accountability for the controls stays with your organization.
What does the 2025 proposed Security Rule change mean for vendors?
The January 2025 proposal would make several changes that reach vendors directly. Business associates would have to give covered entities written verification of their technical safeguards at least once every 12 months. The proposal also covers asset inventories, mandatory encryption and multi-factor authentication, and periodic testing, with the details set out in the proposed rule itself. As of October 2026 it has not been finalized, and the latest Unified Agenda lists final action as projected for July 2027. Until a final rule is published, current obligations apply. Build the capabilities now so that verification and evidence can be produced on request, and confirm the final text before you commit to specific control designs.
What should a SaaS vendor ask its cloud provider for in an SLA?
The HHS cloud guidance lists the service level agreement topics that matter for HIPAA. Ask the provider to commit to availability and reliability, backup and data recovery, how and when data is returned or deleted after termination, a clear split of security responsibilities, and limits on how the provider may use, retain and disclose ePHI. Each topic should match the business associate agreement and your own risk analysis. The configuration you choose also changes your risk picture, so review how the provider's shared responsibility model applies to each service you use. Confirm the exact terms in writing with the provider rather than relying on marketing material.
Does DeployOpen certify SaaS products as HIPAA compliant?
No. DeployOpen plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, and it can prepare systems and evidence for a HIPAA assessment. It does not issue audit reports, attestations or certifications, and it does not act as your security official or business associate. Scope, deliverables and timelines are agreed in writing before work starts, and any quote follows from that written scope. Your organization keeps ownership of its risk analysis, policies and customer commitments, and an independent assessor is the party that can report on the results.
How DeployOpen prepares HIPAA-ready platforms
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. For SaaS and cloud vendors preparing ePHI systems for HIPAA review, the work prepares systems and evidence for the vendor's own risk analysis and customer assessments, while the vendor owns its controls and independent assessors issue any reports.
How we scope
- Written scope defines which ePHI systems, environments, subcontractors and customer-facing documents are in the engagement.
- Scope lists the business associate agreement and SLA topics the vendor must answer for customers, such as backup and data return.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
How we build
- Platforms are deployed in the client's own infrastructure with encryption, access control, audit logging and backup configured to the agreed scope.
- Configuration is hardened and integrated with the vendor's identity, logging and monitoring tools, then tested before handover.
- Security testing of applications, APIs and infrastructure can be run against the built environment to support the vendor's risk analysis.
How we hand over
- Documentation maps each configured safeguard to the Security Rule standard it supports, so the vendor can show its reasoning.
- Evidence packages include configuration records, test results and runbooks that the vendor's own assessor or customer can review.
- Handover covers administration, backup restoration and incident procedures, with the vendor retaining ownership of its policies and controls.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can keep configurations, backups and evidence current as the platform and the vendor's customer requirements change.
- Confirm with DeployOpen in the written scope which support and testing services apply to your environment and contracts.
