Dental Practice Acquisition IT Due Diligence Checklist

Start with the technology that keeps the practice clinically and financially usable. That normally includes the practice-management system, imaging software and image repository, servers or hosted environments, workstations, operatories, intraoral and panoramic or CBCT devices, scanners, printers, payment devices, phones, internet circuits, firewall, switches, wireless access points, remote-access tools, email, Microsoft 365 or Google Workspace, domains, websites, backup platforms, security products, and vendor portals. The purpose is not to count equipment; it is to identify dependencies that could stop patient care or prevent the buyer from controlling the environment after closing.

For each item, record the owner, administrator, physical or cloud location, age or lifecycle status when known, current support vendor, renewal date, contract or license identifier, authentication method, whether MFA is enabled, where documentation is stored, and whether the buyer has confirmed that the service or license can continue after the transaction. A seller's spreadsheet is a starting point, not proof. Request screenshots, invoices, contracts, portal exports, device inventories, and vendor confirmation for the systems that matter most.

Begin while there is still enough time to make the purchase agreement, transition plan, and closing checklist reflect what is discovered. Waiting until the week before closing can turn a solvable issue into an emergency: a non-transferable software agreement, an unsupported server, a domain controlled by a former marketing vendor, an internet circuit that cannot be assigned quickly, or an imaging database with no tested recovery path.

Sequence the review in two passes. The first pass identifies deal-level risks and dependencies that could affect price, timing, closing conditions, or professional advice. The second pass creates the operational cutover plan: which accounts change hands, which vendors are contacted, what credentials rotate, what systems are backed up, what is tested before the first patient day, and what contingency is available if a transfer is delayed. Keep the technical findings separate from legal conclusions and route contract, privacy, record-ownership, and transaction questions to qualified counsel.

HHS risk-analysis guidance says the Security Rule scope includes all ePHI that a regulated entity creates, receives, maintains, or transmits and that an organization should identify where that ePHI is stored, received, maintained, or transmitted. For acquisition diligence, translate that into a data-flow inventory. Map the practice-management database, images, scanned documents, prescriptions, claims, insurance files, email, cloud portals, file shares, backups, exports, removable media, remote support paths, and vendor systems that handle patient information.

Then look for data that sits outside the obvious systems. A front-desk workstation may contain exports on the desktop. A departing owner may have administrative email forwarded to a personal mailbox. A local imaging computer may contain the only copy of an older database. A marketing, billing, transcription, cloud, or IT vendor may receive data under a business associate relationship. The inventory should distinguish authoritative systems from convenience copies so the buyer knows what must be preserved, migrated, secured, or removed during the transition.

Do not assume that buying the practice automatically transfers every technology agreement. Dental software, imaging platforms, cloud subscriptions, support plans, phone systems, internet services, merchant services, domains, security products, and equipment leases can each have different assignment, ownership-change, notice, or re-enrollment rules. Ask the seller for the current agreement and then obtain written guidance from the vendor for the exact product and transaction structure.

The operational question is simple: who will be able to open a support ticket and administer the system the morning after closing? Create a transfer matrix showing vendor, account owner, billing owner, technical administrator, renewal date, transfer requirement, planned transfer date, and fallback contact. Include integrations that may depend on a third-party credential or license. If a license cannot transfer, the buyer should know the replacement cost, lead time, migration path, and downtime risk before the deal is operationally committed.

The HIPAA Privacy Rule's definition of health care operations includes, under specified conditions, the sale, transfer, merger, or consolidation of all or part of a covered entity with another covered entity, or with an entity that will become a covered entity after the transaction, as well as due diligence related to that activity. That provision is useful context for healthcare transactions, but it is not a blanket permission to give every bidder unrestricted access to patient records.

The parties should have privacy and transaction counsel confirm that the proposed diligence activity fits the applicable HIPAA pathway and any other legal or contractual restrictions. From an IT perspective, use the minimum data and access needed for the approved purpose, prefer controlled exports or supervised access over broad administrator credentials, document who receives access, and remove temporary diligence access when it is no longer required. If counsel or the privacy officer defines a narrower process, the technical team should implement that process rather than invent its own interpretation.

HHS describes risk analysis as foundational to Security Rule compliance and says it is an ongoing process. Its current guidance specifically lists a change in ownership as an example of a changing business environment in which potential risk should be analyzed to ensure ePHI remains reasonably and appropriately protected. An acquisition can change administrators, vendors, locations, networks, business processes, remote access, cloud services, and responsibility for security controls all at once.

That means the buyer should not simply file the seller's previous risk analysis and call the issue complete. Compare the documented environment with what was actually discovered, identify new or inherited vulnerabilities, determine whether existing safeguards still make sense, and assign remediation owners and deadlines. The Security Rule does not prescribe one universal risk-analysis methodology, so the review should match the size, complexity, and actual systems of the acquired practice while still being accurate, thorough, and documented.

Ask for evidence rather than yes-or-no answers. Useful artifacts include an asset inventory, patch and vulnerability-management records, endpoint-protection coverage, MFA configuration for remote and administrative access, user and administrator lists, remote-access tools, firewall and network diagrams, security-alert or log-retention practices, recent risk assessments, incident-response documentation, security awareness records, cyber-insurance control attestations, and a list of third parties with privileged or remote access.

HHS's healthcare Cybersecurity Performance Goals are voluntary, not new HIPAA mandates, but they provide a practical diligence lens. The current goals emphasize items such as MFA, prompt credential revocation, unique credentials, separation of privileged accounts, incident planning, backup strategies, vendor/supplier cybersecurity requirements, asset inventory, third-party incident reporting, network segmentation, and centralized logging. Use those items to expose gaps that could become the buyer's problem after closing, then prioritize remediation according to actual risk.

A backup job showing a green check is not the same as a recoverable practice. Identify exactly what is protected, how often recovery points are created, where copies are stored, who controls the backup account, how long data is retained, whether production credentials can delete recovery copies, and whether the practice has completed a representative restore. Include the practice-management database, imaging repository, shared documents, critical server configuration, and any unique local data that is not already protected by a cloud application's own service model.

Request evidence of a restore test and, when possible, conduct a pre-close recovery exercise on a representative system or data set. Confirm the credentials, encryption keys, vendor assistance, replacement hardware, internet bandwidth, and application steps needed to make restored data usable. In Florida, the Board of Dentistry's current dental-record rule also says electronic dental records may be maintained electronically when a secure backup copy is maintained and updated within a time frame not exceeding 72 hours. That state requirement is another reason to verify the actual backup process instead of accepting a verbal assurance.

Florida Administrative Code Rule 64B5-17.002 requires a dentist to maintain written dental records for at least four years from the date the patient was last examined or treated. The rule also addresses record transfer or release: the releasing or transferring dentist must retain the original records or copies and note to whom the records were released or transferred and the authority for the release. It further addresses ownership and responsibility for records within dental practices.

Those requirements make patient-record handling a transaction workstream, not merely a database-copy task. The buyer, seller, dentists of record, and counsel should determine who is responsible for legacy records, how access requests will be handled, what records or copies must be retained, how electronic and paper records are transferred, and how the technology system will preserve the required information. IT can preserve data and audit the transfer, but it should not decide legal record ownership or retention responsibility on its own.

Request the practice's documented security incidents, breach assessments, ransomware or phishing events, lost-device events, unauthorized access reports, vendor incidents, cyber-insurance claims, and remediation records for an appropriate diligence period defined with counsel. The goal is not to label every past event a reportable breach. It is to understand whether known incidents were investigated, whether required notifications were handled, whether root causes were corrected, and whether unresolved obligations or technical weaknesses may carry into the acquired environment.

Current HHS breach-reporting guidance distinguishes breaches affecting 500 or more individuals from smaller breaches and sets different reporting timing to the Secretary. Because whether an event is a reportable breach depends on the facts and applicable law, have privacy counsel review uncertain or unresolved incidents. The IT team should preserve logs and evidence, identify affected systems and accounts, and verify that remediations such as credential rotation, patching, MFA, backup protection, or access removal were actually implemented.

Create a privileged-access register before closing. It should cover domain registrars, DNS, website and hosting, Microsoft 365 or Google Workspace, practice-management administration, imaging administration, servers, virtualization, firewall, switches, Wi-Fi, backup platform, endpoint security, remote monitoring, phones, internet carrier portals, cloud storage, vendor portals, payment systems, and any identity provider. Record whether the account belongs to the practice, the seller personally, an employee, or an outside vendor.

Plan credential rotation so the buyer gains control without creating avoidable downtime. Where possible, create buyer-owned administrator accounts before close under an approved transition process, verify MFA and recovery methods, then remove or reduce seller and former-vendor access at the agreed cutover time. Do not simply change every password at midnight without testing dependencies; service accounts, integrations, scanners, backup agents, and scheduled jobs may use credentials that need a coordinated change.

Build a runbook for the last business day under the seller and the first business day under the buyer. Include final verified backups, export or snapshot checkpoints, administrator-account transfer, credential rotation, email and domain ownership, vendor contacts, support authorization, internet and phone ownership, payment systems, user access, practice-management and imaging launch tests, printer and scanner checks, remote access, security monitoring, and confirmation that backup jobs still run after account changes.

Rehearse the failure paths as well. Decide what happens if the software vendor has not completed the ownership change, the internet carrier transfer is delayed, a critical password is missing, an imaging workstation fails, or a cloud account remains under the seller's billing identity. A documented fallback might be a vendor escalation, temporary approved access, a read-only workflow, a replacement circuit, or a delayed noncritical change. The objective is continuity without leaving old privileged access in place indefinitely.

During the first week, collect the asset, software, vendor, contract, administrator, and data-flow inventories. Identify where ePHI resides, which systems are clinically critical, who owns each account, and which contracts or licenses need direct vendor confirmation. Escalate missing ownership documents, unsupported systems, unresolved incidents, or inaccessible administrator accounts early enough to affect the transaction plan.

During the second and third weeks, validate security controls, backup and restore capability, internet and network dependencies, software and imaging workflows, vendor transfer requirements, record-retention responsibilities, cyber-insurance considerations, and the post-close risk-analysis plan. Convert each finding into an owner, due date, and decision: remediate before close, make it a closing dependency, budget it for post-close, or accept it through the appropriate business and professional process.

During the final week, freeze unnecessary changes and rehearse the cutover. Confirm final backup checkpoints, buyer-owned administrative access, support authorization, credential-rotation sequence, first-day user list, vendor escalation contacts, monitoring, restore access, and a short clinical-operational test for every system the practice needs to see patients. The buyer should leave diligence with a controlled transition plan, not merely a folder of screenshots.