Patient-Reported Outcomes Platform Vendor Security Risk Assessment Checklist

A patient-reported outcomes platform may collect sensitive health information through surveys, symptom trackers, and other digital tools. Before using one, assess what data it handles, how the vendor protects it, and whether the arrangement requires a business associate agreement (BAA).

Use this checklist to guide your review. HIPAA requirements depend on the parties’ roles and the services performed; recommended procurement safeguards can go further than the federal baseline.

What patient-reported data does the platform collect and where does it flow?

Start by listing the data the platform collects, creates, receives, maintains, or transmits. Patient responses may include symptoms, diagnoses, treatment effects, medication use, and functional status. Linked with identifiers, this information may be protected health information (PHI).

• Identify direct identifiers, such as name, date of birth, email address, and medical record number, as well as potentially identifying metadata such as IP addresses or device identifiers.
• Map how data moves from the patient’s device through the platform, integrations, hosting environment, analytics tools, support systems, backups, and any subcontractors.
• Document where data is stored, which locations or environments are in scope, and whether it is encrypted in transit and at rest.
• Confirm whether the platform sends information to advertising, analytics, or other third-party services. HHS explains that information about a person’s use of a health-related app, combined with identifying information, may constitute PHI when disclosed by a regulated entity. See HHS guidance on online tracking technologies.
• Ask whether the vendor handles identifiable PHI, limited data sets, or information de-identified under HIPAA. Do not treat removing names alone as proof that data is de-identified; HHS describes the applicable methods in its de-identification guidance.

How does the vendor limit access and secondary use of patient data?

Review who can access patient data and what each person or service is permitted to do with it. Ask the vendor to explain how it limits workforce and subcontractor access to the information needed for their assigned work.

• Check whether role-based access control (RBAC), unique user accounts, strong authentication, and timely access removal are used. RBAC is a useful assessment criterion; HIPAA requires appropriate access safeguards but does not prescribe a particular RBAC design.
• Ask how the vendor monitors privileged accounts, support access, and emergency access, and how it reviews access logs for suspicious activity.
• Confirm that the contract and BAA define permitted uses and disclosures, prohibit unauthorized secondary uses, and address security incident and breach reporting.
• Ask for a complete list of subcontractors that handle PHI and how the vendor imposes subcontractor safeguards. HIPAA requires business associates to obtain appropriate written assurances from subcontractors that handle PHI.
• Require the vendor to explain whether it uses responses for product improvement, research, analytics, or model training. Such uses are not automatically permitted simply because a vendor provides the platform; confirm that the proposed use is authorized and appropriately documented.

HHS states that a business associate’s uses and disclosures must be governed by its agreement and applicable HIPAA requirements. Its Business Associates guidance describes BAA provisions and subcontractor obligations. The HIPAA minimum necessary standard applies where required; it does not apply to every permitted use or disclosure, such as certain treatment disclosures. See HHS guidance on the minimum necessary requirement.

Which security controls should the assessment cover?

Evaluate administrative, physical, and technical safeguards in light of the data, platform design, and risks. HIPAA requires regulated entities to conduct risk analysis and implement reasonable and appropriate safeguards; it does not prescribe one universal security configuration for every vendor.

• Risk management: Ask how the vendor identifies threats and vulnerabilities, assigns risk, and tracks corrective action through vulnerability remediation.
• Identity and access: Review user identification, authentication, authorization, access reviews, and procedures for disabling accounts.
• Audit logging: Check whether relevant system activity is recorded, protected from inappropriate alteration, and reviewed to detect security incidents.
• Data protection: Review encryption in transit and at rest, key management, data separation, and secure handling of exports. Evaluate safeguards in context rather than assuming that a specific technical measure is universally mandated.
• Secure operations: Ask about security testing, software updates, vulnerability response timelines, change management, and incident response.
• Availability and recovery: Assess backup protections, restoration testing, contingency planning, and service availability commitments.
• Physical and workforce safeguards: Review controls over facilities and devices, workforce security practices, and security awareness processes.

Use the HHS guidance on risk analysis to frame the review around confidentiality, integrity, and availability. The HHS summary of the Security Rule describes its administrative, physical, and technical safeguard standards.

What evidence should vendors provide and how should findings be tracked?

Ask for evidence that supports the vendor’s answers and matches the services, systems, and data in scope. HIPAA does not expressly require a vendor to provide security documentation or permit a customer audit in every arrangement. HHS notes that customers may negotiate additional assurances based on their own risk analysis. See HHS guidance on HIPAA and cloud computing.

• Request a current security overview, relevant policies, and a description of the vendor’s risk assessment and risk management processes.
• Ask for appropriate independent assessment reports or summaries, such as a relevant SOC 2 report or security testing summary, and review their scope, date, exceptions, and remediation status.
• Request evidence of access reviews, audit logging, incident response exercises, backup testing, and vulnerability remediation, as appropriate to your risk review.
• Review the BAA, subcontractor list, incident notification commitments, and contract provisions for audit rights or other assurance mechanisms.
• Record each finding with its risk level, supporting evidence, owner, required corrective action, due date, and closure evidence. Document accepted risks and the decision-maker’s approval.

A report, attestation, or security certification is evidence about particular controls or a defined scope; it is not, by itself, proof that the organization or platform is “HIPAA certified” or compliant in every respect. Use evidence to support your own risk decision.

When is a business associate agreement required?

A vendor generally qualifies as a business associate when it performs a function or service on behalf of a HIPAA covered entity or business associate that involves creating, receiving, maintaining, or transmitting PHI. A platform vendor that hosts or processes identifiable patient responses for a covered provider will commonly meet this definition.

Before allowing the vendor to handle PHI on the organization’s behalf, establish a written BAA that describes permitted and required uses and disclosures, requires appropriate safeguards, addresses incident reporting, and covers subcontractors. A cloud provider may still be a business associate when it stores only encrypted ePHI and does not hold the encryption key. See HHS guidance on cloud computing and HHS Business Associates guidance.

If the vendor receives only information de-identified in accordance with HIPAA, it is not a business associate with respect to that information solely on that basis. However, a business associate’s de-identification of PHI on a customer’s behalf must be authorized by the BAA. Confirm the data and service arrangement rather than relying only on a vendor’s label.

How should data retention, deletion, and platform exit be addressed?

Define how long patient data and related copies may be retained, what happens when the service ends, and how the organization can retrieve its records in a usable format. Address production systems, backups, exports, caches, and data held by subcontractors.

• Specify a return or deletion process, responsibilities, timing, and an agreed method for documenting completion, such as a data deletion attestation.
• Require the vendor to explain any backup or legal hold exceptions, how long they last, and how protections remain in place until deletion is complete.
• Plan for data export, transition assistance, and continued access during the exit period so the organization can maintain access to needed records.
• Align the BAA and service contract on return or destruction of PHI. HHS’s model business associate agreement addresses return or destruction at termination and continued protections where that is infeasible.

Do not confuse clinical-record retention with HIPAA documentation retention. HIPAA’s Privacy Rule does not set a general medical-record retention period; state law and other requirements may apply. Separately, required Security Rule documentation has a six-year retention period. See HHS guidance on medical-record retention and HHS Security Rule documentation guidance.

When should the vendor risk assessment be repeated?

Repeat or update the assessment when meaningful changes could affect risk, such as a new platform feature, integration, subcontractor, hosting arrangement, data use, security incident, or material control finding. Reassess before expanding the service to new data types or purposes.

HIPAA does not prescribe one fixed annual schedule for every risk assessment. HHS describes risk analysis as an ongoing process and says the frequency of comprehensive reviews can vary with the organization and its circumstances. Set a review schedule appropriate to your risk, and update it when changes indicate that existing safeguards may no longer be adequate. See HHS guidance on risk analysis.

In short, map patient data flows, verify access and permitted use, assess safeguards with supporting evidence, put required BAA protections in place, and plan for secure exit and ongoing reassessment.

FAQs

When does a patient-reported outcomes platform vendor qualify as a business associate?

The vendor generally qualifies when it performs a service on behalf of a HIPAA covered entity or business associate that involves creating, receiving, maintaining, or transmitting PHI. A platform that hosts or processes identifiable patient responses for a covered provider commonly meets this definition. A vendor handling only properly de-identified information may not be a business associate for that information. See HHS Business Associates guidance.

Can a vendor use patient responses to train models or perform analytics?

Not automatically. If responses are PHI, the vendor’s use must be permitted by the applicable agreement and HIPAA requirements. Specify whether the vendor may perform analytics or model training, what data it may use, whether the data must be de-identified, and whether the vendor may retain or reuse resulting data. De-identification itself must be authorized when a business associate performs it on the covered entity’s behalf.

What evidence should a vendor provide to support its security assessment?

Request evidence relevant to the platform’s scope and risks, such as a security overview, risk-management information, independent assessment reports, security testing summaries, vulnerability remediation records, access-review evidence, and incident response or backup testing documentation. HIPAA does not expressly require vendors to provide a customer with these materials in every case, so document the assurances agreed in the contract and BAA.

How can an organization verify that patient data is deleted after contract termination?

Agree in advance on the deletion scope, timeline, backup exceptions, subcontractor responsibilities, and evidence of completion. Request a written data deletion attestation and confirm that it covers copies in production systems, exports, and subcontractor environments, while addressing backups that cannot be immediately purged. The BAA should also address return or destruction of PHI and any infeasibility exceptions.