How Should a Clinic Perform an RPM Vendor Security Review in 2026?

What an RPM Vendor Security Review Actually Tests

A remote patient monitoring vendor security review is a structured assessment of whether a company can protect patient data, clinical records, device telemetry, and care-coordination services from misuse, loss, or unauthorized access. It is more than collecting a security questionnaire or asking whether a vendor has a HIPAA compliance statement. A useful review tests how the vendor identifies assets, controls privileged access, monitors systems, manages vendors, responds to incidents, and demonstrates that its safeguards work in practice. For clinics and care networks, the review should also examine how RPM data moves among devices, cloud services, clinicians, patients, and business associates. The central question is not simply, “Is the vendor secure?” but “Can this vendor explain, with evidence, how it reduces specific risks to the patients and organizations entrusted to it?”

Also worth reading: What Security Questions Should Buyers Ask an RPM Vendor in 2026? · What Are the Proposed 2027 RPM Billing Changes Every Clinic Should Review Before January 1? · How Can Healthcare AI Agent Security Scale Across Care Networks?

The review should be risk-based because devices and data flows differ considerably between RPM programs. A continuous glucose-monitor workflow may involve a prescribed sensor, a patient phone, a cellular connection, a device cloud, a clinical dashboard, and an EHR integration. A blood-pressure program may collect readings manually or automatically through a connected cuff, but it may not use the same device-management controls. A network reviewing several vendors should compare each vendor against the role it actually performs rather than applying one universal score. As of September 28, 2026, clinics should pay particular attention to identity controls, software-update integrity, third-party concentration, incident notification, data export, and the vendor’s ability to support downstream HIPAA obligations.

A strong review produces traceable evidence. That evidence may include architecture diagrams, recent independent audit results, penetration-test summaries, vulnerability-remediation metrics, access-review records, backup test results, and incident-response exercises. Certifications can support a review, but they should not replace technical and operational questions because an attestation describes a defined system, period, and scope. The review should document the exact product and version under consideration, including integrations, mobile applications, cloud regions, and connected devices. This prevents a clinic from approving a secure enterprise platform while an older API, unsupported device model, or separately administered tenant remains outside the assessed scope.

HIPAA, Privacy, and Data-Use Boundaries

RPM programs can create several categories of regulated information: protected health information, personally identifiable information, device identifiers, location data, appointment details, clinician notes, and information about a person’s treatment status. The review should determine which data each service collects, why each data element is needed, where it is stored, how long it is retained, and whether it is combined with other information. A vendor may operate as a business associate for some functions while acting as a provider, administrator, or other entity for others. Clinic counsel should confirm the appropriate agreements rather than relying on the vendor’s marketing label. Privacy notices and consent documents should also match actual data practices, especially when a vendor uses information for advertising, product analytics, research, or model training.

HIPAA compliance is necessary, but a security review should go beyond a signed Business Associate Agreement. Agreements establish duties and remedies, yet they do not prove that encryption keys are managed correctly, that terminated users lose access promptly, or that backups can be restored. The vendor should explain whether data is encrypted in transit and at rest, how keys are generated and rotated, and whether customers can control decryption. The clinic should also test the vendor’s support for data access, amendment, accounting, export, and deletion requests, recognizing that legal retention duties can require data to remain available for defined periods. These processes need clear owners and response times, not only policy language.

Minimum necessary use deserves special attention in care coordination. Patient-pulse data should be relevant to the program’s clinical purpose, while optional analytics or marketing should not silently expand the collection boundary. Vendors should distinguish operational telemetry from identifiable health data, identify subprocessors that can receive data, and disclose whether de-identification is performed before analytics. For a care network, centralized analytics may be operationally useful, but it can also create concentration and privacy risk when many clinics, patients, and device types feed one platform. A review should therefore ask whether customers can limit fields, users, retention periods, and downstream access. It should verify that deactivation of a patient or program stops unnecessary processing without compromising legally required clinical records.

Technical Controls That Require Direct Evidence

Identity and access management is usually the first area to test because excessive permissions can expose many records even when no vulnerability is exploited. A vendor should use unique identities, multifactor authentication for workforce accounts, strong password policies, role-based access, and documented processes for joining, reviewing, and terminating personnel. Administrative accounts should be limited, separately monitored, and protected with stronger authentication where appropriate. The clinic should request evidence that customer access is tenant-isolated and that support personnel cannot browse customer data without an approved, logged, and time-limited reason. Quarterly access reviews are a useful benchmark, although the correct frequency depends on the sensitivity of the environment and the vendor’s risk model.

Software supply-chain controls matter because RPM often depends on device firmware, operating systems, mobile applications, libraries, update services, and cloud infrastructure. The 2024 XZ Utils backdoor serves as a reminder that a compromise can enter through software components that are not obvious from an application’s visible interface. The U.S. Cybersecurity and Infrastructure Security Agency published an advisory in March 2024 concerning malicious code in XZ Utils data-compression libraries and warned about the associated supply-chain risk. RPM buyers should ask whether products contain third-party or open-source components, how dependencies are inventoried, how release artifacts are signed, and whether builds are reproducible or otherwise controlled. Vendors should also state how quickly they patch a critical flaw and whether customers receive a compensating control while a full update is rolling out.

Device security requires evidence covering procurement, provisioning, updates, retirement, and lost-device handling. The review should establish whether sensors and gateways are uniquely identifiable, whether enrollment tokens expire, and whether a patient can remove or substitute a device. Automatic updates are helpful, but the vendor should also provide a way to detect devices that remain on unsupported firmware. A clinic may reasonably set a policy of no remediation for a known critical vendor vulnerability, no patient enrollment for an unsupported device, and no sensitive data transfer through an unmanaged gateway. These thresholds should be written into contract exhibits or security requirements so that risk decisions are not made informally during an incident.

Encryption alone does not settle the question of who can read data. The vendor should distinguish encryption used to protect stored records from end-to-end encryption in which only designated endpoints can decrypt content. It should also explain the location and ownership of encryption keys, privileged recovery mechanisms, and backup encryption. Evidence may come from recent independent audits, such as a SOC 2 report, but the clinic should read the system description, subservice organizations, exceptions, test periods, and complementary user-entity controls. A report covering only one product or one corporate boundary may not cover the specific mobile app, device cloud, integration service, or regional hosting environment used by the clinic.

Incident Response, Availability, and Patient Safety

An RPM vendor security review should test what happens when the technology fails, not only when an attacker enters it. Care operations may depend on alerts reaching a clinician, current readings reaching a dashboard, and a disruption being escalated to the right team. The vendor should provide a documented incident-response plan with defined severity levels, on-call coverage, forensic preservation, containment, recovery, and notification procedures. The contract should specify how quickly the vendor will notify the clinic after discovering a confirmed or reasonably suspected security incident. A 24-hour initial notice is a practical starting point for many healthcare deployments, but the final period should reflect incident severity, applicable law, contractual duties, and the information needed for customer notices.

Availability tests should include more than asking whether the vendor claims 99.9% uptime. A 99.9% service-level target permits roughly 8 hours and 46 minutes of unavailability during a 365-day year, before other contractual exclusions; it does not guarantee that clinical workflows remain usable. The review should identify acceptable downtime, planned-maintenance windows, status communication, and the maximum tolerable interruption for each RPM function. A clinic may require an alert backlog to be processed within a defined time, an export path for critical data, and a tested method for moving patients to a backup workflow. The vendor should explain whether it can provide affected records, timestamps, users, device identifiers, and audit logs needed for incident analysis.

Recovery objectives need to fit the clinical setting. Information that supports same-day medication or triage decisions may need faster recovery than historical trend data, while archived records may be governed by a different retention schedule. The clinic should ask for backup frequency, geographic separation, immutable copies where appropriate, restoration tests, and recovery time and recovery point objectives. It should also determine whether a customer can retrieve its data before contract termination and whether the export is complete, machine-readable, and usable without the vendor. For distributed care networks, a recovery exercise should cover identity services, integrations, device enrollment, alert delivery, and communications with multiple clinics rather than testing only one dashboard component.

Patient safety and security intersect when bad data, delayed alerts, or compromised accounts can cause clinical harm. The review should examine alert routing, threshold configuration, escalation timers, clock synchronization, and the handling of duplicate, missing, or implausible readings. It should not assume that a cyber incident is limited to confidentiality loss. A compromised account could change a threshold, suppress an alert, expose a patient’s location, or delay an intervention. Contracts and procedures should define who may change clinical rules, how changes are tested and approved, and how the clinic can audit those changes. A vendor may offer strong technical controls, but a poorly designed workflow can still undermine them.

Practical Steps for a Clinic or Care Network

Begin by defining the scope before requesting documents. Identify the vendor, product, version, device models, data types, patient volume, users, integrations, hosting regions, and business functions involved. A phased RPM rollout with 500 patients and one clinic has different exposure from a network program with 25,000 patients, multiple EHRs, and several subcontractors. The clinic should create a risk register ranking issues by likelihood, potential harm, data sensitivity, and detectability. As a practical initial threshold, a critical issue should be blocked or isolated before deployment; a high issue should have a dated remediation plan; and a medium issue should be accepted by an accountable owner with a review date.

Next, request evidence in a standard packet and compare answers across vendors. Useful materials include the latest SOC 2 Type II report, penetration-test or vulnerability-assessment summary, secure-development overview, disaster-recovery test summary, access-control policy, incident-response policy, business-associate agreement, subprocessors list, and product-specific security architecture. The packet should identify its period and exclusions, because evidence older than 12 months may not describe the current environment. The review team can then hold a 60-to-90-minute session with security, engineering, privacy, support, and clinical-operations representatives. Ask for demonstrations, screenshots, sample logs, or workflow explanations when a document is ambiguous, but avoid requesting patient data, real credentials, or unnecessary access to another customer’s environment.

A pilot should be treated as a controlled evaluation rather than an indefinite free trial. Limit access to a small patient group, use test or synthetic records where possible, monitor permissions and integrations, and document expected alert and data-export behavior. A 30-day pilot may reveal onboarding and access problems, while a 90-day pilot can capture routine operations and some maintenance activity. The clinic should define acceptance criteria in advance, such as successful user provisioning, timely alert delivery, tested exports, no unresolved critical findings, and documented recovery procedures. If the vendor cannot support a scoped pilot, that may itself indicate operational or transparency risk.

Finally, record the decision and make it revisitable. The approval record should list accepted risks, rejected risks, compensating controls, evidence locations, responsible owners, and the next review date. A material change—such as a new device, EHR integration, subprocessor, hosting region, acquisition, or material architecture change—should trigger an updated review. Smaller releases can be managed through vendor monitoring, but the clinic should receive release notes and vulnerability notices. A one-time questionnaire is not enough because the threat environment, software dependencies, and vendor environment continue to change after procurement.

Comparing Review Options and Alternatives

A clinic can obtain useful security information through several methods, but each has trade-offs. The table below compares a questionnaire-led process, a formal audit, a penetration test, and a risk-based operational review. The best choice is usually a combination rather than one method used in isolation.

For a smaller clinic with a limited budget, a scored questionnaire can be a sensible first pass, especially when supplemented with contract review and direct questions about data handling. For a larger care network, a formal audit may be justified for a platform supporting critical workflows, but the clinic should confirm that the audit scope matches its actual deployment. A penetration test can reveal exploitable weaknesses, yet a clean test does not mean the product is safe to operate. The strongest assessment connects technical evidence to patient impact, workflow resilience, privacy obligations, and the vendor’s ability to provide usable remediation.

Alternatives to full in-house review include using a qualified healthcare cybersecurity consultant, engaging a managed security service, or joining a vendor assessment program offered by a purchasing group. These options can reduce staffing demands, but they do not transfer accountability to the consultant or purchasing group. The clinic remains responsible for selecting the product, setting requirements, reviewing residual risk, and monitoring performance. Avoid using a generic “security score” as the sole decision rule because scoring weights can reward documentation volume rather than actual protection. Ask what changed, what was tested, which exceptions were found, and whether the vendor accepted corrective action.

Common Mistakes and Warning Signs

One common mistake is treating a HIPAA statement, SOC 2 badge, or encryption claim as proof of comprehensive security. A SOC 2 report can provide valuable control evidence, but it is based on a defined system and period and may include complementary controls that the customer must implement. Another mistake is asking only whether a vendor has “penetration testing” without requesting the test date, scope, methods, critical findings, and remediation status. A test completed three years ago may describe an architecture that no longer exists. Similarly, a vendor’s promise to use “bank-level encryption” is not a substitute for specifying algorithms, key ownership, endpoint behavior, retention, and backup coverage.

Other mistakes arise from testing the vendor’s enterprise product while ignoring the actual RPM service. The approved product may exclude a mobile application, device cloud, API, support portal, or integration managed by a subcontractor. The review should also separate contractual commitments from current technical practice. A contract may promise deletion within 30 days, while an operational export process may require 90 days or lack a field needed for the customer’s legal obligations. Ask how the promise is measured, who verifies it, and what happens when an exception is granted.

Warning signs include refusing to identify subprocessors, declining to provide recent independent evidence, using unclear incident language, prohibiting customers from exporting data, requiring broad support access, or describing updates as automatic without a rollback or unsupported-device process. A vendor may have legitimate confidentiality restrictions, so a refusal to provide another customer’s data is not itself a problem. A refusal to describe its own controls, affected product, remediation history, or contractual notification path is more concerning. Escalate unresolved critical findings immediately and avoid enrolling additional patients until an accountable executive and technical owner understand the risk.

Timing, Cost, and Procurement Decisions

A vendor review should begin before a contract is signed, not after a device has been distributed to patients. Early review allows the clinic to negotiate data ownership, breach-notice periods, audit rights, export formats, service levels, and remediation duties. For a low-risk pilot, a lightweight review may be completed in 2 to 4 weeks. A deployment involving clinical alerts, multiple integrations, sensitive location data, or a large care network may require 8 to 12 weeks or longer. The timeline should account for vendor evidence, security testing, legal review, clinical workflow design, and remediation, not merely the time needed to complete a questionnaire.

Costs vary by scope and market. Internal review may require 40 to 100 staff hours when security, legal, clinical, and procurement teams participate. Independent security assessments can range from several thousand dollars for a focused review to tens of thousands or more for broad technical testing, formal audits, and operational exercises. Penetration tests, cloud configuration reviews, mobile-application testing, and device assessments can add separate costs. These figures are planning ranges rather than vendor quotes, and they should be compared with the likely impact of downtime, data exposure, notification, contractual penalties, and patient-care disruption. A low-cost review that ignores integrations and clinical failure modes may be a poor investment.

Set a deployment gate that matches the risk. A reasonable default is to require no unresolved critical vulnerabilities, documented remediation for high findings, tested recovery for the highest-impact workflow, and a signed agreement covering data use, incident notice, subcontractor accountability, and exit assistance. If the vendor cannot meet those conditions, reduce the scope, use a compensating control, delay enrollment, or select another option. The goal is not to create an impossible checklist; it is to make the security decision explicit, evidence-based, and connected to what the RPM program is expected to do for patients.

For getpulse.care and similar B2B care-coordination platforms, the relevant point is that software can organize patient-pulse information and support clinical teams without making automated claims about safety, diagnosis, or universal compliance. A purchasing clinic should evaluate the actual configuration, documentation, contracts, and operational performance of any vendor, including getpulse.care if it is being considered. No marketing description or third-party assessment should be treated as a guarantee that every deployment will be secure. The most defensible review records what is known, what remains uncertain, and who will act when conditions change.