Change software permissions according to the lawful operating structure, each person's job, and the actual closing sequence. Inventory accounts and recovery methods first, approve the new access, test essential workflows, and then revoke access that is no longer justified. Buying business assets does not automatically authorize unrestricted access to every clinical or financial system.
What systems belong in the access inventory?
Include every system that can affect patient information, money, staff, brand assets, or business continuity. The obvious list starts with the electronic health record, booking software, point of sale, payment processor, accounting, and payroll. Add email, website hosting, domains, social accounts, business profiles, telephone services, device portals, backups, and outsourced support.
For each system, identify the contracting entity, account owner, administrators, users, vendor contacts, connected applications, recovery destination, and change-of-control conditions. A login list without these relationships can miss the person who controls password resets or a vendor integration that retains independent access.
The FTC’s Start with Security guidance emphasizes building security into business practices and limiting access appropriately. The transaction-specific inventory here is an original working method. It should be adapted by the practice’s authorized technical, legal, and operational personnel rather than treated as a substitute for a security assessment.
How should permissions follow the post-closing operating model?
Start with responsibilities and authority, then configure software to support them. A billing user may need payment and benefit information without needing broad clinical permissions. A marketing agency may need access to approved creative materials without receiving unrestricted access to patient records or payroll.
For regulated entities, the HHS Security Rule summary discusses workforce security and information access management for electronic protected health information. Applicability and implementation require a fact-specific assessment. Do not assume a cash-pay practice is outside every privacy obligation, or that a management-company acquisition transfers professional decision-making authority.
Record the approved role, access purpose, authorizing person, effective date, and review date. If the two-entity transaction structure involves separate professional and management entities, the system plan must reflect that separation. A convenient administrator setting cannot resolve a legal or contractual ownership question.
What does a useful permission matrix show?
The matrix should make unnecessary access visible without exposing authentication secrets. Describe capabilities rather than storing passwords, recovery codes, or private keys in the transaction data room. Keep sensitive recovery material in the authorized security process and share it only through an appropriate controlled channel.
| System | Capability to review | Evidence of completion |
|---|---|---|
| Clinical records | View, edit, export, user administration | Approved role and access test |
| Payments | Refunds, bank changes, settlement reports | Authorized account configuration |
| Payroll | Employee information and payment changes | Restricted role assignment |
| Brand accounts | Ownership, publishing, recovery | Platform-confirmed ownership transfer |
| Vendor integrations | Data access and automated actions | Reviewed connection and contract |
Use named individual access where the system supports it, with appropriate authentication controls. Shared credentials obscure who performed an action and complicate departure handling. Where a platform creates a constraint, document it and obtain a supportable mitigation rather than concealing the exception.
How do vendor contracts change the access plan?
Technical access and contractual permission are different. A seller may be able to hand over a login even though the vendor requires assignment consent or a new agreement. Conversely, a valid contract transfer can still leave the buyer unable to administer the system if the recovery method remains tied to the seller’s personal account.
HHS cloud-computing guidance explains that covered relationships and responsibilities can involve both the customer and cloud provider. It does not mean the vendor assumes every responsibility for access, availability, or compliance. Review the actual agreement and any required business associate arrangements with qualified advisors.
Confirm migration rights, support contacts, administrator changes, export capability, retention, deletion, and the continuing need for seller access. A vendor’s sales assurance is weaker than a documented, tested transition procedure. Keep contractual issues assigned to the right professional instead of asking front-desk staff to improvise a workaround on closing day.
What should be tested before access is revoked?
Test the authorized operating workflows with appropriate non-sensitive test information where possible. Confirm that the right people can schedule, document, bill, reconcile, manage users, and recover access within their approved roles. The test should establish both what a role can do and what it cannot do.
For example, an approved billing role should not gain an unintended ability to change bank details simply because that permission was convenient for the previous owner. A departing seller’s account should not remain the only route for restoring access to a domain or essential application.
- Confirm approved roles and contractual prerequisites.
- Create or transfer authorized access through the vendor’s supported process.
- Test essential workflows and permission boundaries.
- Verify protected recovery and emergency access arrangements.
- Revoke or narrow access that no longer has an approved purpose.
- Document verification and assign unresolved exceptions.
Perform this work in a sequence approved for the transaction. Premature revocation can interrupt operations, while indefinite shared access leaves responsibility unclear.
How should temporary seller and consultant access be handled?
Give temporary access a purpose, scope, owner, and end date. A transition-services agreement might justify limited support after closing, but it should not silently preserve every administrator privilege. The technical configuration should match the approved services and information-sharing arrangements.
Review whether the person needs current operational access, historical reports, a supervised support session, or a different delivery method. Avoid creating a broad user account merely because it is easier than defining the task. Maintain appropriate logs and a reliable way to remove access when the permitted support ends.
The Med Spa Continuity Risk Map helps connect this issue to the seller’s actual duties. If the practice cannot function without the former owner logging in indefinitely, that is an unresolved continuity dependency. Name the dependency and fund a solution rather than treating an extended password-sharing arrangement as a completed transition.
Which hidden access paths are easy to overlook?
Look beyond the list of active human users. Connected applications, automation accounts, payment integrations, API credentials, backup administrators, external support tools, and recovery emails can retain control after the visible owner account changes. Have an authorized technical professional identify and review those paths.
For illustration, suppose the transition inventory finds 18 human accounts, five administrator assignments, and four vendor connections. Removing three administrator assignments does not establish that access is secure; the remaining roles, connected applications, and recovery routes still require review. These invented counts illustrate why a single total is an incomplete control measure.
Include devices used to receive authentication prompts and the handling of business information on personally owned equipment. Do not copy personal accounts into the buyer’s environment. The diligence guide places the access review alongside the contracts, records, and operational responsibilities that determine what can actually transfer.
How do you verify the handover after closing?
Compare the implemented configuration with the approved matrix and preserve a dated completion record. Review outstanding vendor actions, temporary access expirations, permission exceptions, and recovery tests. Check actual audit evidence rather than assuming an email saying transfer complete proves the platform changed.
Follow up when roles change, staff leave, a vendor is replaced, or a new integration is connected. Access is an ongoing operating responsibility. A sale may trigger a concentrated review, but the same controls should continue after the transaction team leaves.
Bring material exceptions to the authorized security, clinical, legal, and operational decision-makers. The operations hub connects access discipline with the wider work of making a practice understandable and transferable. The objective is a functioning business with appropriate accountability, not the maximum number of privileges transferred to the buyer or the fastest possible removal of every seller account.
What else do owners and buyers ask?
Should the seller give the buyer a spreadsheet of passwords?
A general transaction data room is not an appropriate place for authentication secrets. Inventory systems, roles, ownership, and required transfer actions without publishing credentials. Use the vendor's supported account-transfer process and an authorized secure method for any necessary recovery material, with access limited to the people responsible for the handover.
Can the buyer become administrator of the clinical system immediately?
That depends on the lawful operating structure, information rights, contracts, and approved role. Technical capability is not the same as legal authority. Have the appropriate advisors and clinical leadership define access before configuring it, then test the permissions against the specific tasks the buyer or management team is allowed to perform.
Why should recovery email and phone settings be checked?
They may allow someone to regain control even after the visible account owner or password changes. They can also leave the practice unable to recover a critical system when the former owner is unavailable. Review and test recovery through the approved security process without exposing recovery codes in ordinary transaction materials.
Does using a cloud vendor remove the practice's access responsibilities?
No blanket assumption is safe. Responsibilities depend on the service, applicable rules, agreements, and actual configuration. A vendor may protect part of the infrastructure while the customer still controls users, permissions, and recovery. Review both sides of that arrangement and document who performs each required action during and after closing.
Which sources support this guide?
Sources were checked during research. Regulations, lender policies, and market conditions can change. Use the linked primary material and your advisors to confirm applicability.
- Start with Security: A Guide for Business — Federal Trade Commission
- Summary of the HIPAA Security Rule — U.S. Department of Health and Human Services
- Guidance on HIPAA and Cloud Computing — U.S. Department of Health and Human Services
Educational analysis prepared with AI-assisted research for The Med Spa Broker. “Last reviewed” records the source and editorial check date; it does not imply review by an attorney, clinician, or independent appraiser. Read our editorial standards.