Assessing vendors for HIPAA: what covered entities should ask business associates first
A covered entity whose procurement team now requires HIPAA assurance from a software or hosting vendor has one firm legal starting point: under 45 CFR 164.308(b), it may let a business associate create, receive, maintain or transmit electronic protected health information only after obtaining satisfactory assurances documented in a written contract or other arrangement. No HIPAA certification exists to replace that step. HHS states that it does not endorse or recognize private certifications, so a vendor's certificate cannot stand in for the contract or for the covered entity's own judgment. The organization owns the decision to engage the vendor and the duty to verify it. The vendor owns its own safeguards and its own risk analysis.
The right questions depend on the vendor's data flows, hosting model and subcontractors, so start by asking the vendor to map them. Which systems will hold or touch ePHI, where is it stored and backed up, who administers those systems, and which subcontractors can see the data? Each answer determines which contract terms matter. OCR's cloud guidance notes that the cloud configuration in use affects the risk analysis and risk management plans of every party, so a vendor running on a major cloud provider still needs to explain its own configuration and shared responsibilities. Ask for the service level terms that address availability, backup and recovery, data return after termination, security responsibilities, and limits on use and disclosure. Confirm with the vendor how each term is written in its own agreements, because marketing pages rarely state them precisely.
Next, request the vendor's written risk analysis and risk management plan, and check whether it covers the systems you are buying. Confirm the vendor's incident reporting commitment, since the business associate contract must require it to report security incidents it becomes aware of, including breaches of unsecured PHI. Ask who the vendor notifies, how quickly, and through which channel. Finally, plan for monitoring. The January 2025 proposed rule would require business associates to verify their technical safeguards in writing at least once every 12 months, but that change is not final, so confirm its status before relying on it. Until then, the contract and your own review schedule are the controls that carry the weight.
Which questions to put to a business associate before signing
A covered entity can only let a business associate handle ePHI after it has satisfactory assurances in writing, and those assurances are only as good as the answers behind them. The six areas below cover the questions that test whether a vendor's safeguards match what the contract promises, and each one names the evidence worth asking for.
Scope of ePHI and data flows
Ask the vendor to list every system, dataset and location where your ePHI is created, received, maintained or transmitted, including backups, logs, support tickets and test environments. Ask who can reach each one and from where. A data flow map that omits a copy of ePHI usually means the vendor's risk analysis is incomplete, so treat it as the first gap to close before signing.
The vendor's own risk analysis
Each business associate must perform its own risk analysis, separate from the covered entity's. Ask for the date of the most recent analysis, the scope it covered, the threats it rated highest, and the risk management plan that followed. Confirm whether the analysis reflects the cloud or hosting configuration that will hold your data, since that configuration changes the risk picture for every party.
Security incident reporting
The contract must require the business associate to report security incidents it becomes aware of, including breaches of unsecured PHI. Ask for the vendor's internal escalation path, the named contact for your account, and how quickly staff are expected to notify you after detection. Ask how the vendor tests this process, for example through tabletop exercises that include a client notification step.
Subcontractors and flow-down terms
Ask for a current list of the vendor's subcontractors that touch your ePHI, along with confirmation that each has a written agreement with the same restrictions and safeguards. Ask how the vendor monitors those subcontractors and what it does when one reports an incident. Gaps here are a common route to breaches that the covered entity learns about late, so request copies of the subcontractor terms or a signed attestation that they exist.
Hosting and cloud configuration
Ask which cloud provider, regions, services and configuration will store your ePHI, and whether the provider has signed its own business associate terms. Review the service level agreement for availability, backup and recovery commitments, and the terms for returning or deleting data. OCR's cloud guidance treats these choices as inputs to every party's risk analysis, so confirm that the vendor documented them.
Termination and data return
Before signing, agree how the vendor will end the relationship. Ask how ePHI will be returned in a usable format, how and when it will be destroyed, how the vendor confirms destruction in writing, and what happens to copies held by subcontractors. The contract should also let you end the arrangement if the vendor fails to meet its security requirements, so ask the vendor to describe how performance is measured between audits.
Which cloud SLA terms OCR highlights for HIPAA
Availability and reliability terms set out how reliably the provider keeps the service running and how it reports outages. For ePHI, an outage can stop clinical or billing workflows and delay access to records, so the covered entity needs to know what the provider commits to and how it measures that commitment. OCR's cloud guidance lists this topic as relevant to HIPAA SLAs, which means it belongs in the vendor review rather than only in the procurement file.
- Committed uptime and measurement: Confirm the availability figure, how it is calculated, and what period it covers.
- Exclusions: Check which events are excluded from the commitment, such as scheduled maintenance or customer-caused incidents.
- Status reporting: Ask how outages are announced, how quickly, and through which channel.
- Credits and remedies: Confirm whether service credits are the only remedy and whether they affect the covered entity's right to terminate.
- Configuration effect: A single-region deployment and a multi-region deployment carry different availability risks, and the risk analysis of both parties should reflect the configuration actually chosen.
Confirm that the committed figure matches the architecture you are buying, not the provider's general marketing description.
Backup and recovery terms determine whether ePHI can be restored after deletion, corruption, a ransomware event or a failed region. The Security Rule's contingency planning standard expects a covered entity or business associate to plan for data backup and disaster recovery, so the SLA should show who performs those tasks and what the customer can verify. OCR's cloud guidance treats backup and data recovery as a distinct SLA topic for this reason.
- Backup scope and frequency: Confirm what data is backed up, how often, and whether backups cover configuration and encryption keys.
- Restore objectives: Ask for the recovery time and recovery point the provider commits to, in writing, for each service tier.
- Backup location and protection: Check where copies are stored, whether they are immutable or isolated from production credentials, and how they are encrypted.
- Testing: Ask how often restores are tested and whether the customer can request test results.
- Shared responsibility: Many backup failures come from customer configuration, such as disabled retention settings, so the SLA should state which party owns each setting.
Confirm who holds the restore process in an incident, and whether that person has tested it.
The return and deletion terms govern what happens to ePHI when the contract ends, whether the customer leaves, the provider is replaced, or the relationship is terminated for a security failure. OCR's cloud guidance lists how data is returned after termination as an SLA topic, and the business associate contract terms required by 45 CFR 164.314(a) interact with it. Without clear terms, a covered entity can finish a contract without a complete copy of its records or with copies still held by the provider.
- Export format and timing: Confirm the format in which data is returned, the time window for export, and any fees for exporting.
- Deletion evidence: Ask how the provider deletes data from production, backups and replicas, and what written confirmation it gives.
- Subcontractor copies: Confirm that deletion or return reaches the provider's own subcontractors that hold ePHI.
- Retention during dispute: Check whether the provider can keep data after termination for billing or legal reasons, and on what basis.
- Exit planning: Ask for an exit plan that names the steps and the team responsible, and test it before it is needed.
Confirm that the exit terms work with your own backup strategy, so you can leave without depending on the provider's goodwill.
Security responsibility terms divide the controls between the provider and the customer. OCR's cloud guidance is clear that the configuration used affects the risk analysis and risk management plans of all parties, so the split cannot be assumed from the service name. A covered entity that runs ePHI on a cloud platform still owns access management, encryption choices, logging settings and workforce training, even when the provider runs the physical facilities and the underlying infrastructure.
- Responsibility matrix: Ask for a written matrix that maps each Security Rule safeguard area to the provider, the customer, or both.
- Security incident notice: Confirm that the provider must report security incidents it becomes aware of to the covered entity, as the business associate contract requires under 45 CFR 164.314(a)(2)(i)(C).
- Encryption and key ownership: Confirm who manages encryption keys and whether the customer can control key access.
- Logging access: Check what logs the customer receives, how long they are kept, and whether they can support an investigation.
- Configuration changes: Ask how the provider notifies customers of changes that affect security settings.
Confirm that each responsibility in the matrix has a named owner on your side, because gaps are usually found after an incident.
Use, retention and disclosure terms limit what the provider may do with ePHI. The business associate may use and disclose PHI only as the contract permits, and the SLA should not give the provider broader rights through data analytics, product improvement or support access. OCR's cloud guidance lists use, retention and disclosure limits as a separate SLA topic, so the covered entity should read these terms alongside the business associate agreement rather than relying on a general privacy policy.
- Permitted uses: Confirm that the provider may use ePHI only to deliver the contracted service and for the uses the agreement lists.
- Secondary use: Check whether the provider uses metadata, telemetry or derived data, and whether that data can include ePHI.
- Retention periods: Ask how long the provider keeps logs, backups and support records that may contain ePHI.
- Disclosure requests: Confirm how the provider responds to subpoenas or government requests for customer data, and whether it notifies the covered entity first.
- Support access: Confirm when provider staff may access customer environments, and whether that access is logged and approved by the customer.
Confirm that the agreement, the SLA and the provider's published terms say the same thing about use and retention, and resolve any conflict in writing before signing.
How breach and security incident reporting flows from vendor to covered entity
This sequence shows how a security incident at a business associate becomes a documented notice to the covered entity, and how the covered entity then carries its own breach obligations forward. Each step names who acts and what record proves it happened.
Vendor detects and logs the security incident
The business associate's security team identifies a possible security incident affecting ePHI it creates, receives, maintains or transmits for the covered entity. The vendor should record when it first became aware, what systems and data are involved, and which containment steps were taken. Ask the vendor to show its incident log format during assessment, because the contract duty depends on the vendor knowing it has an incident. The output is a dated incident record that the vendor can produce on request.
Vendor determines whether the event is a breach of unsecured PHI
The business associate reviews the incident against the breach definition and the unsecured PHI concept, including whether the data was encrypted or otherwise rendered unusable under HHS guidance. This is the point where the vendor decides if notice under 164.410 is triggered for the covered entity. Confirm during vendor review how the vendor documents this determination and who signs off on it. The output is a written determination that names the decision maker and the reasoning.
Vendor reports the incident to the covered entity
The contract requires the business associate to report security incidents it becomes aware of to the covered entity, including breaches of unsecured PHI. The report should go to a named contact on the covered entity's side, using the channel written into the business associate agreement. Check that the agreement sets out how and to whom the report goes, since the regulation requires the reporting duty but leaves the mechanics to the parties. The output is a written notice with the facts known at that time.
Covered entity logs and assesses the reported incident
The covered entity's privacy or security official records the notice, confirms which individuals and data sets are involved, and starts its own analysis. The covered entity remains responsible for its own breach determination and notifications, so it should not treat the vendor's report as the final answer. Look for a record that links the vendor notice to the covered entity's incident file. The output is an incident file with the vendor report attached and an open question list.
Covered entity completes its four-factor breach assessment
Where an impermissible use or disclosure of PHI occurred, the covered entity evaluates the probability that PHI was compromised using the factors set out in the Breach Notification Rule. The vendor's facts about the data, the access path and the recipient feed directly into this assessment. Ask the vendor to supply the technical details promptly so the covered entity's analysis is not built on assumptions. The output is a documented risk assessment that either concludes notification is not required or lists the notices to be sent.
Covered entity issues its own notifications
If notification is required, the covered entity notifies affected individuals, and where the thresholds apply, the media and HHS, following its own obligations under the Breach Notification Rule. The business associate's role is to support the covered entity, and the contract should say who pays for and who sends notices. Confirm these allocations in the agreement before an incident happens, not during one. The output is copies of the notices, a log of dates and recipients, and the HHS submission record where one applies.
Both parties document the incident and fix the root cause
The business associate and the covered entity record the incident timeline, the containment and corrective actions, and any changes to safeguards or the contract. The covered entity should keep the documentation under its retention practices, since Security Rule documentation is subject to a six-year retention requirement. Use the outcome to test whether the vendor's risk analysis and risk management plan still match its environment. The output is a closed incident file with corrective actions assigned and verified.
Covered entity reviews the vendor relationship after the incident
The covered entity decides whether the vendor's safeguards, reporting speed and contract terms remain acceptable, and records that decision. Enforcement examples show that regulators look at how covered entities oversaw vendors, not only at what the vendor did. The MMG Fusion settlement announced by HHS on March 5, 2026 is one illustration of enforcement over vendor oversight gaps, and its published terms are worth reading before setting internal review criteria. The output is a documented vendor review decision with any required contract amendment or termination record.
What the proposed annual safeguard verification would change
The January 6, 2025 proposed Security Rule revision (90 FR 898) would require business associates to give covered entities written verification of their technical safeguards at least once every 12 months. As of October 2026, this is a proposal, not a requirement. The current Security Rule does not impose a fixed verification cycle on business associates, so the duty you can enforce today comes from your business associate agreement and the satisfactory assurances described above. The Unified Agenda entry for RIN 0945-AA22 lists the rule as a long-term action with final action projected for July 2027, and that date may move.
Because the final text may differ from the proposal, do not build your vendor program around the annual cycle as settled law. Instead, write a verification term into your contracts now. Specify what the vendor must deliver each year (for example, a written statement of its technical safeguards, the date of its most recent risk analysis, and the scope of systems that hold your ePHI), who signs it, how exceptions are reported, and what happens if the vendor cannot provide it. Ask for the same content in renewal and amendment cycles so the obligation does not depend on a future rulemaking.
Before relying on any requirement from the proposal, read the final rule in the Federal Register and compare it with the proposed text in the 90 FR 898 proposed rule. Confirm the effective date, the compliance date for business associates, and whether the verification language changed. Have your privacy counsel review any contract clause that refers to a rule that is not yet in force, and set a calendar check against the Unified Agenda so your vendor templates are updated when the rule is finalized.
Why vendor certificates prove little on their own
A certificate from a private firm can be a useful input, but it does not settle whether a business associate protects ePHI under the Security Rule. The cards below cover what HHS says about private certifications, what a certificate scope can leave out, and the questions a covered entity should put to the vendor and the issuing body.
HHS does not recognize private certifications
HHS states that no Security Rule standard requires an entity to certify compliance, and that it does not endorse or recognize private organizations' certifications. A certificate therefore carries no regulatory status with OCR. A covered entity cannot treat a vendor's certificate as proof of compliance. Ask the vendor which Security Rule requirements the certificate tests, and keep your own assessment of the business associate on file.
A certificate does not block a finding
Because HHS has said that private certifications do not prevent it from later finding a violation, a clean certificate offers no protection if OCR investigates a breach involving the vendor. Covered entities remain responsible for the satisfactory assurances they obtained before sharing ePHI. Treat the certificate as one input to the assessment, not the end of it.
Scope may leave out ePHI systems
A certificate covers only the systems inside its defined boundary. A vendor may certify its corporate network while the platform that stores your patient records sits outside that boundary, or the reverse. Ask for the system description, confirm that every system holding, transmitting or processing your ePHI is named, and check whether any production environment is excluded.
Subcontractors may sit outside the audit
A business associate's hosting provider, billing partner or support contractor may also create, receive, maintain or transmit ePHI. If those subcontractors are outside the certificate's scope, the report says nothing about them. Ask which subcontractors touch your data, whether each has a written agreement that flows down the same safeguards, and whether they are covered by the report.
Configuration and evidence may be stale
OCR's cloud guidance notes that the cloud configuration in use affects the risk analysis of every party. A report reflects a configuration at one point in time, and a certificate can remain valid while settings drift. Ask for the period the report covers, the date of the most recent evidence, and whether the vendor's own risk analysis reflects the current configuration.
Only independent bodies issue reports
Only an independent auditor, assessor or certification body issues a report or certificate. The vendor's own staff, and any consultant that helped it prepare, cannot. Check who issued the document, whether that body is independent of the vendor, and what the report's stated purpose and limits are. Ask the vendor what the report covers before relying on it.
How to monitor vendors after the contract is signed
This table compares the monitoring activities a covered entity can run on a business associate after the contract is signed, the evidence to request for each, and how often to run it. Cadence is the covered entity's decision, informed by its own risk analysis, since the only frequency in the current discussion is the proposed 12-month written verification that is not yet final. Use the rows as a checklist for building the monitoring calendar.
| Monitoring activity | Evidence to request | How often it occurs |
|---|---|---|
| Contract performance review | Written security status against each contract security requirement, open findings and remediation dates | Set by the covered entity based on its risk analysis; proposed rule would require written technical safeguard verification at least every 12 months, not yet final |
| Incident and breach notice test | Records of past security incident reports to the covered entity, and a documented timeline from detection to notice for a sample event | Periodic test chosen by the covered entity; also triggered after any reported incident |
| Subcontractor changes | Current list of subcontractors handling ePHI, signed flow-down agreements and notice of any new or replaced subcontractor | Each change, plus a periodic reconciliation of the list against the contract |
| SLA reports | Availability, backup and restore test results, and confirmation of data return or deletion terms as defined in the service agreement | Frequency defined in the SLA; the covered entity reviews reports on its own schedule |
| Business associate risk analysis updates | Summary of the vendor's most recent risk analysis and risk management plan, including changes to the cloud configuration used for ePHI | Confirm the vendor's update cycle in the contract; review after material system or configuration changes |
| Cloud configuration changes | Change notices affecting where ePHI is stored, encryption settings, access controls and hosting location | Each change as it occurs, reviewed against the covered entity's risk analysis |
| Termination triggers | Documented criteria such as unremediated security failures, unreported incidents or refusal of assurances, and the exit plan for returning or destroying ePHI | Defined at contract signing; reviewed whenever monitoring findings meet a trigger |
What a covered entity's exposure looks like when vendor oversight fails
Covered entities cannot hand off their Security Rule duties to a vendor, and the exposure from a weak vendor review lands on the covered entity as well as the business associate. Under 45 CFR 164.302, covered entities and business associates both must comply with the Security Rule for electronic protected health information. The HHS Office for Civil Rights (OCR) enforces that obligation through complaint investigations, compliance reviews and audits, and it can examine either party after a breach at a vendor. A covered entity that never obtained satisfactory assurances, or that did obtain a contract and never checked whether the vendor was following it, has a documented gap that OCR can review on its own terms.
The penalty exposure is set by the inflation-adjusted civil money penalty table in 45 CFR 102.3, which applies to penalties assessed on or after January 28, 2026. Per violation, the range runs from $145 for a violation with no knowledge to $2,190,294 for an uncorrected violation resulting from willful neglect, and the calendar-year cap for identical violations is also $2,190,294. Those figures are per violation, so the count of violations, not only the size of the breach, drives the total. Confirm the current table before you use it in an internal risk discussion, because the figures are adjusted over time and the table in force on the date of an assessment is the one that matters.
Vendor review should therefore be treated as a decision with a documented outcome, not an onboarding formality. Before a business associate touches ePHI, the covered entity should be able to show who approved the relationship, what assurances the contract contains, what the vendor's own risk analysis covered and how the vendor will report incidents. Ask the vendor to confirm in writing how it will supply evidence of its safeguards over the life of the contract, and record a named owner for each follow-up. If the answers are vague, the covered entity holds the risk while the vendor holds the systems, and that mismatch is the situation OCR investigators look for.
Common questions about vetting HIPAA business associates
Is there an official HIPAA certification that a business associate can hold?
No. HIPAA has no official certification. HHS states that no Security Rule standard requires an entity to certify compliance, and HHS does not endorse or recognize private organizations' certifications. Such a certification also does not stop HHS from later finding a violation. When a vendor offers a certificate, treat it as one input among several, and ask what scope it covers, who issued it, and whether the assessor examined the systems that will hold your ePHI. The covered entity still needs satisfactory assurances in a written contract under 45 CFR 164.308(b), and the vendor's own risk analysis.
Is a vendor security questionnaire enough to vet a business associate?
A questionnaire is a useful starting point but it is not sufficient on its own. It records what the vendor says it does. A covered entity needs the written contract that binds the vendor to Security Rule obligations, and it needs evidence that supports the answers: the vendor's risk analysis, its risk management plan, its incident response procedure, and its backup and recovery testing. NIST SP 800-66 Rev. 2 describes a process for measuring contract performance and ending the relationship when security requirements are not met, which a one-time questionnaire does not provide. Plan to review answers against documents and to repeat the review as the relationship changes.
What can a covered entity do itself and what should it hand to a consultant?
The covered entity owns its compliance decisions, its contracts and its risk acceptance, and it cannot delegate those duties to a vendor or a consultant. Staff can usually handle inventory of vendors that touch ePHI, contract review against the required terms, and tracking of vendor evidence. Outside help is most useful for technical review of a vendor's cloud configuration, testing of its access controls and logging, and checking whether its risk analysis reflects how ePHI actually moves. Ask any consultant what they will examine, what they will not examine, and what they will deliver in writing. A third-party review supports your decision but does not replace it, and it is not a HIPAA certification.
How long does a HIPAA vendor review take?
No duration is supplied for this process, so the answer depends on your own contract cycle and the vendor's responsiveness. Drivers include how many vendors touch ePHI, whether the vendor has existing documentation, how complex its cloud or hosting setup is, and whether the contract needs legal review. Plan the review as a gate before go-live or before new data flows, not as a task that runs in parallel with procurement. Ask the vendor early for its risk analysis, its breach reporting procedure and its contract template, since missing documents are the most common cause of delay. Confirm timing with your legal and procurement teams before you commit to a date.
What should a business associate hand over during vetting?
A covered entity should request documents that show how the vendor meets its obligations, not only its promises. Ask for:
- A signed business associate agreement that covers the required Security Rule terms and incident reporting duties under 45 CFR 164.314(a)
- The vendor's own risk analysis and risk management plan, since each business associate must perform its own analysis
- A list of subcontractors that will create, receive, maintain or transmit ePHI, and evidence that they have written assurances
- Its incident response and breach notification procedure, including how quickly it reports to you
- Service level terms covering availability, backup and recovery, data return after termination, security responsibility, and use and disclosure limits
- Evidence of recent testing, and any independent assessment reports, with their scope stated
Will a vendor's annual safeguard verification be required?
Not yet. HHS proposed in January 2025 that business associates give covered entities written verification of their technical safeguards at least once every 12 months. As of October 2026, that requirement was proposed, not final, and no final rule has been published. Until the rule is final, your contract should set the verification frequency you need, what the verification must cover, and what happens if the vendor fails it. Writing this into the contract now gives you a clear right to evidence whatever the final rule requires.
What should happen if a vendor reports a security incident?
The business associate must report security incidents it becomes aware of to the covered entity, including breaches of unsecured PHI, and the contract should state the timing and content of that report. Your review should confirm the vendor's detection and escalation steps and who on each side makes the notification decision. Ask how the vendor logs access to ePHI so that it can reconstruct what happened. Agree on contacts and a test of the process before an incident occurs. Your own breach notification duties to individuals and HHS remain yours, so the vendor's report is a start, not the end of your analysis.
Does OCR enforce vendor obligations against covered entities or business associates?
OCR enforces the Security Rule against both covered entities and business associates, and a business associate can be directly liable for its own Security Rule violations. A covered entity can also face penalties when it knew or should have known that a vendor was not meeting its obligations and failed to act. The HHS Audit Program reviews both kinds of organization. Document your vendor assessment decisions, the contract terms you required, and the follow-up you took when evidence fell short. That record is what an investigator will ask to see.
How to choose a consultant or assessor for vendor reviews
A covered entity reviewing a business associate needs two different kinds of help: people who prepare and check evidence, and an independent party whose opinion carries weight. The cards below cover what to check in each, and what to settle in writing before any scope is signed.
Check independence from the vendor
Ask whether the firm has ever built, hosted, administered or resold the vendor's systems, and whether it has a financial stake in the outcome. A firm that configured the environment it then reviews cannot give you an independent view of that environment. Ask for the answer in writing and keep it in the vendor file, since OCR will ask how you selected and oversaw your assessor.
Confirm HIPAA and cloud experience
Look for named staff who have worked on Security Rule risk analyses and on the cloud configurations the vendor actually uses. OCR's cloud guidance says the configuration affects every party's risk analysis, so generic security experience is not enough. Ask for anonymized examples of similar scopes and confirm who will do the hands-on work.
Establish whether a report is issued
Determine early whether the firm will issue an assessment report that you can rely on, or only advise and prepare evidence. Only an independent auditor or assessor issues an assessment report. A consultant's work product is advisory evidence preparation, and it should be labeled that way in the statement of work so that no one later treats it as a third-party attestation.
Settle the scope before signing
Write down which vendor systems, locations and ePHI flows are in scope, which safeguards are tested, and what the deliverables are. Confirm who owns the resulting risk analysis and whether the vendor's own risk analysis is reviewed or replaced. Agree on the testing method, the sampling approach and the date of the evidence cut-off.
Ask how findings reach you
Ask how the firm reports findings, how quickly it escalates a serious gap, and whether it will tell you about incidents it sees during the review. Confirm that the contract requires the vendor to report security incidents to you, as 45 CFR 164.314 requires for business associate contracts, and that the assessor's terms do not block that flow.
Keep certificates in perspective
A vendor's certificate or badge from a private body does not show HIPAA compliance. HHS does not endorse or recognize private certifications for the Security Rule, and such certifications do not prevent a later finding of violation. Treat a certificate as one input, and ask the assessor to explain which HIPAA safeguards it did and did not test.
How DeployOpen works on this
DeployOpen helps organizations that handle ePHI prepare the systems, controls and evidence that a covered entity or business associate asks for when assessing a vendor. We do not issue attestations or certificates; the vendor owns its controls, and any formal review is performed by the assessing party.
How we scope
- Engagements are fixed-scope, with the systems, data flows and vendor relationships in scope agreed in writing before work starts.
- The written scope names which business associate obligations and evidence items are covered, such as contract terms, the risk analysis and breach reporting procedures.
- Scope also records which cloud or hosting configurations the self-hosted platforms run in, since the configuration affects the risk analysis of every party.
How we build
- We configure self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks to match the agreed scope.
- Access control, audit logging, encryption and backup settings are built so that each vendor safeguard can be shown with a configuration record and a log.
- Security testing of applications, APIs and infrastructure is run against the built environment to produce findings the vendor can act on before an assessment.
How we hand over
- Deliverables include documented configurations, a mapping of each evidence item to the contract or safeguard it supports, and the procedures for incident reporting.
- Written runbooks explain how the vendor reports security incidents to the covered entity and how the annual verification evidence is generated and kept.
- Handover covers the evidence an independent assessor would request, so the vendor can see what it has and what remains open.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial engagement ends.
- Support can cover maintaining evidence records, updating runbooks when contract terms or the rule change, and retesting after platform upgrades.
- Confirm with DeployOpen during scoping which support terms, reporting cadence and responsibilities apply to your specific engagement.
