The Runbook We Used on Ourselves First.
Before we sell you a 2026 HIPAA Security Rule readiness engagement, we want you to see the work. This is the runbook we used to get our own environment to the bar the rule sets. Phase by phase, what we did, what we found, and what changed. Free to read, free to download, yours to adapt for your own practice if you want to do this without us.
We did the work on ourselves first because we figured a healthcare technology company asking small practices to upgrade their security posture should be able to show its own.
Why a Public Runbook
Most security vendors will not show you their work. They will show you logos. We are not going to list a hundred client logos here because we have not earned that yet, and even when we have, the logos do not tell you whether we know what we are doing. The runbook does. If our process holds up under your reading, that is the proof. If it does not, you have learned something useful before you ever sent us a dollar.
Phase 0: Inventory and Scope
What we did
Built a complete asset inventory of every device, account, application, and data store that touches the business. Wrote it down. Categorized each entry by whether it touches sensitive data and what the regulatory frame is for that data. Drew a network map showing how data actually moves between assets, not how the diagrams in old vendor proposals say it moves.
What we found
We found assets we had forgotten about. A test workstation that had not been decommissioned. A SaaS tool a former contractor signed us up for. A mailing list with stale subscribers. None of those are exotic; every practice we have reviewed has the same pattern. The work is the inventory itself.
Phase 1: Identity and Access
What we did
Enforced multi-factor authentication on every account that can reach business systems from outside the network. Microsoft 365, the password manager, GitHub, the cloud hosts, the support tooling. Set up conditional access rules that block legacy authentication protocols that bypass two-factor login (MFA). Reviewed every administrative account and either removed unnecessary admin rights or rotated the credentials.
What we found
Two service accounts that did not need admin rights and a personal email address still authorized as a recovery contact for a system that should not have personal email anywhere near it. Both fixed. Neither would have been caught without the explicit account-by-account review.
Phase 2: Endpoint and Email
What we did
Deployed threat-watching software (EDR) on every workstation and server, with central monitoring and alerting. Enforced full-disk encryption everywhere and verified each device. Hardened email with anti-impersonation rules, link scanning, attachment sandboxing, and DMARC alignment so a spoofed message gets rejected at the gateway, not in someone’s inbox.
What we found
One workstation reported encryption as enabled but the recovery key had not been escrowed correctly, which would have failed the audit even though the disk was encrypted. Fixed in 20 minutes once we knew. The lesson: enabled is not the same as documented.
Phase 3: Backup and Recovery
What we did
Architected backups with immutable, isolated copies that cannot be reached from inside the network by an attacker who has already compromised an admin account. Tested restores on a schedule. Documented Recovery Time and Recovery Point objectives that match how long a real outage would actually be tolerable.
What we found
Our first restore test took longer than our stated RTO. We tightened the architecture, retested, and updated the documented objective to match what the new architecture actually delivers. The lesson: untested restore objectives are aspirational. Tested ones are real.
Phase 4: Documentation and Policy
What we did
Wrote the policies the rule expects: security policy, incident response plan, sanction policy, contingency plan, BAA template, vendor management policy. Reviewed each with counsel. Signed and dated. Set a calendar reminder to review each annually, not when an audit shows up.
What we found
Several policies we had templates for but had never read carefully. Reading them carefully surfaced inconsistencies between what the policy said and what the technical control actually did. The fix was usually to bring the policy in line with reality, not the other way around. The lesson: policy that does not match the environment is worse than no policy at all.
Phase 5: Workforce Training and Drills
What we did
Built a security awareness training program with documented completion records. Ran a tabletop incident response drill where leadership walked through a simulated ransomware event and recorded the decisions. Documented what each role would do in the first hour, the first eight hours, and the first 24 hours of an incident.
What we found
The drill surfaced a gap in our communication tree: who calls the cyber insurance carrier, in what order, with what information ready. Now documented and rehearsed. The lesson: a tabletop drill turns abstract policy into muscle memory before the real thing happens.
Adapt This for Your Own Practice
Every section above maps directly to a section of the 2026 HIPAA Security Rule. If your practice has the bandwidth to work through this on your own, the runbook is enough to get you started. If your office manager would rather have a written gap list and a scoped engagement, that is what the Cyber Insurance Review and the follow-on readiness engagement deliver.
Either path works. We just want the work to be visible before you trust us with yours.