White Paper · Healthcare Compliance · New Practice HIPAA

Day-One HIPAA for a New Practice

A practical opening sequence for covered-entity status, risk analysis, vendor contracts, patient rights, training, and incident readiness before the practice relies on systems that handle PHI.

By Lincoln Square Law · 10-minute read

When HIPAA actually starts for a new practice

A new practice should not use the first patient visit as the legal test for whether HIPAA applies. The threshold question is whether the organization is a HIPAA covered entity. A health care provider is a covered entity when it transmits health information electronically in connection with a transaction for which HHS has adopted a standard. In ordinary practice formation, billing, eligibility checks, claims, and related electronic transactions make that determination quickly. The practical consequence is that privacy and security work belongs in the opening plan, not on a list to revisit after the patient schedule fills.

That distinction matters because protected health information is not created by the HIPAA label on a policy manual.

Once a covered provider creates, receives, maintains, or transmits PHI, the Privacy Rule governs permitted uses and disclosures and patient rights, and the Security Rule applies to electronic PHI. A startup can therefore create avoidable exposure before opening day by configuring an EHR, moving demographic data into a cloud system, giving a billing vendor access, or using an intake platform without first deciding how those systems fit the compliance program.

Assign responsibility before the first workflow goes live

HIPAA requires covered entities to designate a privacy official responsible for development and implementation of privacy policies and a security official responsible for development and implementation of Security Rule policies and procedures. A small practice can assign both functions to one qualified person, but the responsibility should be explicit. The point is not a title on an organization chart. Someone must own decisions about access, vendors, incident escalation, patient requests, training, and documentation.

Write a short implementation calendar around that ownership. Before go-live, identify the systems that will contain PHI, the vendors that can reach them, the members of the workforce who need access, and the patient-facing processes that must work on day one. Then record who is responsible for each item and the date it was completed. That record becomes evidence that the program existed before an incident, rather than being assembled after one.

Build the risk analysis from the actual environment

The Security Rule requires an accurate and thorough assessment of potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI (45 C.F.R. 164.308(a)(1)(ii)(A)). HHS guidance emphasizes that the analysis must cover all ePHI and be appropriate to the organization’s size, complexity, capabilities, costs, and risks. A template that lists generic threats without identifying where the practice stores or transmits ePHI is not a useful substitute for the required analysis.

Start with an inventory and data-flow map. Include the EHR, practice-management and billing platforms, email, cloud drives, scanners, imaging systems, phones and tablets, remote-access tools, backups, patient messaging, online forms, AI documentation tools, and vendor connections. For each, identify what ePHI it handles, who can access it, how access is authenticated, where data is backed up, and what happens when an account or device is lost. Then identify threats and vulnerabilities, estimate likelihood and impact on a defined scale, and connect material risks to a risk-management plan with owners and completion dates.

Do not confuse the current Security Rule with the 2025 proposed cybersecurity rule. As of this writing, HHS still describes the cybersecurity rule as a proposal. The proposal would make measures such as multifactor authentication broadly mandatory and would add more prescriptive analysis and testing requirements. Under the rule currently in force, the practice still must select reasonable and appropriate safeguards based on its analysis. MFA, encryption, tested backups, and strong identity controls are sensible recommendations in most modern practice environments, but the legal analysis should say which measures are current requirements, which implementation specifications are addressable, and which measures are recommendations or proposed future requirements.

Contract with vendors before giving them PHI

A business associate agreement is required when a person or organization performs functions or services for the covered entity that involve creating, receiving, maintaining, or transmitting PHI and no exception applies. The contract must contain the required HIPAA terms, and the practice should have it executed before the vendor receives PHI. The vendor list should be developed from the data-flow inventory rather than memory. EHR and billing companies are obvious. Managed IT, cloud hosting, transcription, document destruction, consulting, and AI tools may require the same analysis depending on what they do and what information they handle.

A BAA is not a substitute for diligence. Before approval, determine what data the vendor receives, where it is stored, whether subcontractors are used, how incidents are reported, how access is terminated, and how data is returned or destroyed at the end of the relationship. Those questions support both the Security Rule risk analysis and contract negotiation. If a vendor insists that its service is not subject to HIPAA, do not accept the label without testing the actual data flow and function.

Make the Privacy Rule operational, not decorative

Before the first patient encounter, the practice should be able to deliver its Notice of Privacy Practices in the manner required by 45 C.F.R. 164.520, post the notice where required, and make a good-faith effort to obtain acknowledgment of receipt for direct treatment relationships. The notice should match what the practice actually does. It should not promise security practices, communication methods, or restrictions the office has not implemented.

The same is true for patient rights. Build a route for access requests, amendments, restrictions, confidential communications, and accountings where applicable. The designated privacy official should know who receives the request, how identity is verified, how the deadline is tracked, how records are produced, and when counsel or another specialist needs to be involved. A right that exists only in a policy binder is not an operational process.

Train the workforce on the workflows they will use

The Privacy Rule requires training for workforce members on the covered entity’s privacy policies and procedures as necessary and appropriate for their functions, and the Security Rule requires a security awareness and training program. A new practice should train before employees are turned loose in production systems. The training should be tied to the office’s actual risks: account sharing, phishing, texting, remote work, minimum-necessary access, patient identity verification, use of personal devices, and what to do when something goes wrong.

Keep evidence. Record the training date, the material covered, and who completed it. Pair training with access provisioning so a role receives only the access needed for its work. When a person changes roles or leaves, update access promptly. This is where a small practice can convert written compliance into a repeatable control.

Plan for an incident before there is one

Opening-day readiness includes an incident path. Staff should know whom to call for a lost device, misdirected email, suspicious login, ransomware alert, or disclosure to the wrong person. The response process should preserve evidence, stop further exposure when possible, document what happened, and route the event for a breach-risk assessment under the Breach Notification Rule when required. Do not build the plan around the assumption that every security event is a reportable breach, or that no event is reportable until someone proves harm. The regulations use their own definitions and assessment framework.

The fastest way to make the plan usable is to test it. Walk through one scenario before opening and document the gaps: who can disable an account, where vendor contacts are kept, how backups are reached, who has authority to engage forensic help, and how patient or regulator communications would be approved. A tabletop exercise is not required for every small startup, but it is a practical way to learn whether the written plan can be executed.

A 30-day implementation sequence

For a practice approaching launch, the work can be sequenced without turning the opening into a compliance project with no end. First, decide covered-entity status and designate privacy and security responsibility. Second, inventory systems, data flows, and vendors. Third, complete the initial risk analysis and risk-management plan. Fourth, execute required BAAs and close high-priority access or configuration gaps. Fifth, finalize the Notice of Privacy Practices, patient-rights workflows, privacy and security policies, and incident process. Sixth, provision role-based access and train the workforce. Finally, test a patient-access request and one incident scenario before opening.

That sequence is deliberately evidence driven. Each step creates a document, configuration record, contract, training record, or test result that can be maintained. HHS requires Security Rule documentation to be retained for six years from creation or the date it last was in effect, whichever is later. A new practice that begins with this discipline can update the program as systems and staffing change instead of reconstructing its history after a complaint or breach.

What should be reviewed again after opening

Day-one compliance is the beginning of the program. Review the risk analysis and related documentation when environmental or operational changes affect ePHI. Reassess vendors when services change. Train new workforce members and update training when policies materially change. Test backups and incident contacts. Review access when roles change. Track patient-rights requests and complaints for patterns that reveal a process problem.

The objective is not to predict every future rule. It is to have a current, documented system that can absorb change.

HHS’s pending Security Rule proposal is a useful signal of the controls regulators consider important, but a practice should not describe proposed requirements as current law. Build a strong current program, monitor final rulemaking, and document why the safeguards chosen are reasonable and appropriate for the practice’s actual risks.