Only two of the technical specifications in the HIPAA Security Rule are labelled required. Everything else is addressable, which sounds like permission to skip it and isn't. That split shapes what healthcare compliance software has to do, and it's where most buying conversations go wrong.
Vendors sell dashboards, checklists and reminders. An auditor asks different questions: who touched this record, can you show it, and where is the paperwork explaining why you made the choices you did?
What the HIPAA technical safeguards require
The technical safeguards in 45 CFR 164.312 cover five areas: access control, audit controls, integrity, authentication and transmission security. Each is a short sentence of principle, and the detail sits in the specifications underneath.
Audit controls say surprisingly little. The rule asks you to implement hardware, software or procedural mechanisms that record and examine activity in systems that contain or use electronic protected health information. It doesn't name a product or a log format.
That gap is why two tools can both claim to be compliant and behave very differently when someone asks for a history of who opened a patient file last March.
Which specifications are required and which are addressable
Unique user identification and an emergency access procedure are the two required items. The rest of the technical specifications are addressable, as the table shows.
| Specification | Citation | Status | What it asks for |
|---|---|---|---|
| Unique user identification | 164.312(a)(2)(i) | Required | A distinct name or number for each user, so activity can be tracked |
| Emergency access procedure | 164.312(a)(2)(ii) | Required | A way to reach needed ePHI during an emergency |
| Automatic logoff | 164.312(a)(2)(iii) | Addressable | Ending a session after a set period of inactivity |
| Encryption and decryption | 164.312(a)(2)(iv) | Addressable | A mechanism to encrypt and decrypt ePHI |
| Encryption in transmission | 164.312(e)(2)(ii) | Addressable | Encrypting ePHI sent over a network whenever deemed appropriate |
Addressable means you assess whether the control is reasonable for your setting and act on the answer. It doesn't mean optional, and the assessment itself becomes something you have to be able to show.
Why documentation decides whether you're audit-ready
Under 45 CFR 164.316, security documentation must be kept for six years from the date it was created or last in effect, whichever is later. It also has to be available to the people who carry out the procedures, and it has to be reviewed periodically and updated when environmental or operational changes affect the security of ePHI.
Combine that with the addressable specifications and the picture changes. If you decided an automatic logoff wasn't needed on a clinic workstation, the reasoning has to exist on paper and survive a change of staff.
So the strongest case for compliance software is that it stores decisions, not just tasks. A tool that tracks a checklist but can't show you last year's version of a policy has solved the easy half.
How to judge healthcare compliance software
Start with the questions the rules above imply, and put them to every vendor on your shortlist.
- Does every user get a unique login, and can the tool show what each one did?
- Can you retrieve a policy as it stood on a past date?
- Is there a record of why an addressable control was adopted, changed or declined?
- Who can see the audit trail, and can anyone edit it?
If a demo can't answer these on screen, the polish of the dashboard tells you little. We'd weigh the audit trail and document history above reporting features, because those are what get asked for.
On cost, we haven't verified published pricing for specific products, so we won't quote any. Ask each vendor exactly what moves the price and what sits outside the plan.
When off-the-shelf tools aren't enough

Photo by Ono Kosuki on Pexels
Compliance software manages your obligations. It doesn't make your own patient-facing systems compliant. If your organisation runs a portal, an app or an EHR, the technical safeguards apply inside that product, and no external tool adds a unique-user audit trail to code that wasn't built with one.
That's a design decision made early. Our look at what HIPAA-compliant app development takes covers where those controls get built in, and the piece on EHR software development and compliance covers the usability cost of adding them late.
Portals deserve a specific mention because they put records in front of patients directly. Patient portal development is where login, session and access-logging choices get tested daily.
We designed and built OptimalMD's website, members portal and mobile app end to end, from design through development to launch, and the OptimalMD case study shows how that project fit together. If you're planning a custom build, our apps and SaaS work is the place to start.
Keeping the evidence current
Audit-readiness is a habit more than a purchase. Assign someone to review documentation on a schedule, because the rule expects periodic review and a change in your environment is a trigger for an update.
A new system going live, a move to a new location or a vendor change all qualify. Each should leave a dated note beside the policy it affects, so the history reads as a sequence rather than a pile.
Before any audit, pick a random patient record and trace who accessed it. If you can answer in minutes, the tooling is doing its job.
Frequently asked questions
Is audit logging required under HIPAA?
Yes. The audit controls standard requires hardware, software or procedural mechanisms that record and examine activity in systems containing ePHI. The rule doesn't prescribe a format.
Is encryption required?
Encryption and decryption are listed as addressable specifications, not required ones. You assess whether it's reasonable for your environment and act on the result.
How long do I keep compliance documentation?
Six years from the date it was created or the date it last was in effect, whichever is later.
Cover photo by https://kaboompics.com/ on Pexels
Sources
- 45 CFR 164.312 Technical safeguards — Legal Information Institute, Cornell Law School
- 45 CFR 164.316 Policies and procedures and documentation requirements — Legal Information Institute, Cornell Law School





























