HIPAA in practice
Building a HIPAA programme from a blank page.
Starting from nothing, the hard part is order. Write policies first and they describe systems you have not mapped. Buy tools first and they guard data you have not found. This sequence puts each step where the one before it has produced what it needs, and names the artefact each step leaves behind.
Back to HIPAA services01 · Before you start
Settle your role before anything else
The duties differ for covered entities and business associates.
- Covered entity
- A health plan, a health care clearinghouse, or a provider that bills electronically in standard transactions. Carries the full Privacy Rule, including patient notices and rights.
- Business associate
- A vendor that handles PHI for a covered entity. Carries the full Security Rule, the Privacy Rule duties its contracts impose, and breach reporting to the client.
- Subcontractor
- A vendor's own vendor that touches the PHI. Treated as a business associate of the vendor.
Most technology companies land in the second box. If you are unsure, the questions are on the guides to PHI and to business associate agreements; this page assumes the answer is settled.
02 · The sequence
Nine steps, each feeding the next
What to do, what you end up holding, and what to avoid.
Appoint the officers
Name a security official and a privacy official. In a small company one person may hold both.
- What happens
- Leadership names the roles in writing
- Define their authority and reporting line
- You get
- Signed appointment record
- Role descriptions
- Good practice
- Someone with time and authority, not an intern
- Watch for
- Leaving it to a committee with no single owner
Map the ePHI
Find every system, person, device and vendor that touches PHI, and draw how it flows.
- What happens
- Interview teams and inspect systems
- Trace flows end to end, including backups and logs
- You get
- ePHI inventory
- Data flow diagram
- Good practice
- Owners named for every asset
- Watch for
- Mapping only the production database
Run the risk analysis
Rate the risks to the ePHI you mapped, then plan how to treat each one.
- What happens
- Identify threats and weaknesses per asset
- Rate likelihood and impact
- You get
- Risk analysis report
- Risk register and treatment plan
- Good practice
- A written scoring method
- Watch for
- Substituting a scan report
Write the policies
Turn the treatment plan and the rules into policies and procedures people can follow.
- What happens
- Draft security and privacy policies
- Record decisions on addressable specifications
- You get
- Policy set with approval dates
- Procedures for access, incidents, backups and disposal
- Good practice
- Policies that match what systems actually do
- Watch for
- Downloaded templates nobody has read
Train the workforce
Everyone who can reach PHI learns the rules and their part in them, including management.
- What happens
- Run onboarding and periodic training
- Add role-specific modules for engineers and support
- You get
- Training records with names and dates
- Signed acknowledgements
- Sanction policy
- Good practice
- Short, frequent reminders as well as the annual session
- Watch for
- Training once at launch and never again
Sign the BAAs
Every vendor that handles PHI for you signs a business associate agreement before it gets any.
- What happens
- List vendors from the inventory
- Sign, or stop sending them PHI
- You get
- BAA register
- Signed agreements
- Good practice
- Checking the vendor can actually meet the terms
- Watch for
- Forgetting support tools and email providers
Put the technical safeguards in
Close the gaps the risk register ranked highest first.
- What happens
- Unique accounts, MFA and least privilege
- Encryption, audit logging, backups and restores
- You get
- Configuration evidence
- Updated register showing risks treated
- Good practice
- Log review that actually happens
- Watch for
- Turning on logging nobody reads
Plan for incidents
Decide how a security incident is reported, assessed and, if it is a breach, notified.
- What happens
- Write the response and breach assessment procedure
- Rehearse it with a tabletop exercise
- You get
- Incident response plan
- Contingency and recovery plan
- Exercise record
- Good practice
- Contact lists for clients and their deadlines
- Watch for
- Learning the notification clock during a real breach
Audit and refresh
Check that the programme works as written, fix what does not, and update it when things change.
- What happens
- Periodic evaluation against the rules
- Penetration test and access reviews
- You get
- Evaluation report
- Corrective action log
- Updated risk analysis
- Good practice
- A calendar of reviews with owners
- Watch for
- Treating step nine as the end
03 · What you keep
The record each step leaves
If an investigator asks, these are the documents you hand over.
| Step | Main artefact | Where the duty comes from |
|---|---|---|
| Officers | Appointment of security and privacy officials | Security Rule assigned security responsibility; Privacy Rule personnel designations |
| ePHI map | Inventory and data flow diagram | Needed for an enterprise-wide risk analysis |
| Risk analysis | Dated analysis and risk register | Security management process, required |
| Policies | Approved policies and procedures | Security Rule policies and documentation standard |
| Training | Records, acknowledgements, sanction policy | Security awareness and training; sanction policy |
| BAAs | Signed agreements and a register | Business associate contracts, including subcontractors |
| Safeguards | Configuration evidence, access reviews | Technical safeguards: access, audit, integrity, authentication, transmission |
| Incidents | Response, contingency and breach procedures | Incident procedures, contingency plan, Breach Notification Rule |
| Refresh | Evaluation report and corrective actions | Periodic evaluation |
Keep these for six years from creation or the date they were last in effect, whichever is later. Old versions count.
04 · Why this order
Why the map comes before the policies
Each step consumes what the previous one produced.
Officers come first because someone has to own the decisions. The map comes before the risk analysis because you cannot rate a risk to data you have not found. Policies follow the analysis because they should describe chosen safeguards, not generic ones.
Where teams commonly start instead
Buying a tool, or signing a client's BAA under deadline. Both are understandable. Neither tells you where your PHI is, so the gaps stay hidden until a vendor review or an incident finds them.
Steps five to eight can overlap once the risk register exists. Training, contracts and technical work are often run by different people at the same time. What should not move is the first three.
05 · Keeping it alive
What triggers a refresh
A programme is current only if it follows your changes.
- A new product, feature or system that stores or moves PHI.
- A new vendor, or an existing one that starts handling PHI.
- A move to a new cloud, region or architecture.
- A security incident, whether or not it became a breach.
- A change in law or in HHS guidance.
- Staff turnover in the officer roles.
Sources: 45 CFR Part 160 (definitions); 45 CFR 164.308, 164.310, 164.312 and 164.316 (Security Rule); 45 CFR 164.530 (Privacy Rule administrative requirements); 45 CFR 164.400 to 164.414 (Breach Notification Rule); NIST SP 800-66 Rev. 2.
Programme-building questions
Can one person be both security and privacy official?
Yes, if they have the time and authority for both.
The rules ask that each role be assigned; they do not forbid one person holding both. In a small company that is common. What matters is that the person can make decisions and is named in writing.
Is there an official HIPAA checklist we can follow?
No. HHS publishes rules and guidance, not a pass list.
The rules describe outcomes and leave the method to you, scaled to your size and risks. A sequence like this one is a practical order, not an official test. Your risk analysis decides what each step must contain.
When can we say we are HIPAA compliant?
When you can show it, and with care over the wording.
No agency certifies HIPAA compliance. You can say you have implemented a programme that meets the rules when the steps here are done and evidenced. Many teams prefer wording such as assessed against the HIPAA Security Rule, with a date.
Do we need a penetration test?
The rules do not name one, but evaluation and risk analysis often call for it.
The Security Rule requires periodic technical and non-technical evaluation. A penetration test is a common way to meet the technical part and to check that safeguards work as the risk register assumes.
Start with the map and the risk analysis.
A HIPAA risk assessment covers steps two and three, and leaves a ranked plan for the rest.