Get Defensible HIPAA IT Compliance in 60–90 Days for Healthcare IT Teams

Get Defensible HIPAA IT Compliance in 60–90 Days for Healthcare IT Teams

HIPAA IT compliance requires documented administrative, physical, and technical safeguards that protect electronic protected health information, backed by a written risk analysis and retained evidence for audits. The HIPAA Security Rule and NIST SP 800-66 Rev. 2 are the two references that matter most for getting this right. If you haven't started, your next move is a formal risk assessment or a call to a healthcare-savvy IT partner.

---

TL;DR:

• Most IT teams fail to fully inventory every system and data flow that handles ePHI, risking incomplete protection and audit violations.
• Implementing multi-factor authentication, full-disk encryption, and verified restore tests should be prioritized within the first 60 days to prevent common breach causes.
• Every vendor that accesses ePHI must have a signed business associate agreement with clear breach notification and security responsibilities before access begins.
• Regular, at least annual, risk assessments are essential, including thorough asset inventories, threat analysis, control mapping, and remediation plans.
• Documentation of policies, training completion, breach logs, and backup tests must be organized and retained for a minimum of six years to ensure audit readiness and swift response.

---

Table of Contents

• Who Has to Comply, and What Counts as ePHI
• The Security Rule, Translated Into IT Language
• Running a Defensible Risk Analysis
• Technical Controls That Actually Hold Up Under Review
• Managing Vendors and Business Associate Agreements
• Incident Response and Breach Notification
• Documentation, Retention, and Staying Audit Ready
• A 30-90-180 Day Implementation Roadmap
• What Trips Up Most Compliance Programs
• How Great Plains Networking Supports Your Compliance Program
• Where to Verify These Rules Directly
• Sources

Who Has to Comply, and What Counts as ePHI

Two categories fall under HIPAA's IT rules: covered entities (providers, health plans, clearinghouses) and business associates, which is any vendor that creates, receives, maintains, or transmits electronic protected health information (ePHI) on a covered entity's behalf. The moment an IT vendor touches patient data, backs up a server containing it, or remotely manages a system that stores it, that vendor becomes a business associate and needs a signed agreement before touching anything.

ePHI is broader than most IT teams assume. It's not just chart notes. Common systems that hold it include:

• Electronic health record (EHR) and practice management platforms
• Scheduling and patient portal software
• Backup repositories and disaster recovery snapshots
• Firewall, server, and application logs that reference patient identifiers
• Fax servers, scanners, and copier hard drives

Start by mapping every system and every data flow into an asset inventory. You cannot protect what you haven't inventoried, and OCR investigators ask for this list first.

The Security Rule, Translated Into IT Language

The Security Rule organizes obligations into three buckets, and each one maps to specific, ownable IT work. HHS frames these as administrative, physical, and technical safeguards, and NIST SP 800-66 Rev. 2 breaks each one into implementable controls rather than legal language.

Administrative safeguards cover the paperwork and governance side, but they still land on IT's desk:

• A documented, repeatable risk analysis process
• A named security official responsible for the program
• Written policies on access, workforce clearance, and sanctions for violations
• Training that's actually delivered and logged, not just referenced in an employee handbook
• A contingency plan covering data backup, disaster recovery, and emergency operation

Physical safeguards protect the hardware and the space around it: locked server rooms, workstation placement that limits screen exposure, device inventory logs, and documented media disposal procedures for retired drives and old copiers.

Technical safeguards are where most IT teams spend their time: access control tied to unique user IDs, audit controls that log who touched what, integrity controls that detect tampering, transmission security for data in motion, and authentication strong enough to confirm the person logging in is who they claim to be.

NIST's own framing treats these three categories as interconnected rather than independent boxes to check — encryption without access control, or training without enforcement, leaves the same door open.

Pro Tip: Build one spreadsheet that lists every Security Rule requirement in one column and the specific control, owner, and evidence file in the next three columns. That single document becomes your audit response kit.

Running a Defensible Risk Analysis

A risk analysis (often called an SRA) isn't a form you fill out once and file away. It's the backbone of your entire compliance posture, and OCR asks for it in nearly every investigation. A defensible SRA includes:

1. A complete asset inventory of systems, applications, and vendors touching ePHI
2. A threat and vulnerability analysis specific to your environment, not a generic template
3. Likelihood and impact scoring for each identified risk
4. A control mapping showing which safeguard addresses which risk
5. A remediation plan with owners and target dates for anything unresolved

Run the full SRA at least annually, and re-run targeted pieces of it after any major change: an EHR migration, a security incident, a new cloud vendor, or a significant network redesign. Waiting until next year's calendar date to reassess after a breach is a common and avoidable mistake.

One detail trips up more IT teams than anything else: "addressable" specifications under the Security Rule are not optional. You must either implement the control as written or document a reasonable equivalent alternative, with your reasoning recorded. Skipping the documentation is one of the most common findings when OCR reviews a practice's files. Our own risk assessment playbook walks through how to structure this so nothing gets missed.

Technical Controls That Actually Hold Up Under Review

This is the section where policy meets configuration. Here's what each technical safeguard looks like in practice.

Access control means every user gets a unique ID, permissions follow role-based rules (front desk staff shouldn't see the same data as billing), privileged accounts get extra scrutiny, and idle workstations log off automatically.

Authentication should require multi-factor authentication on every account that can touch ePHI, full stop. For administrator and IT accounts, push toward phishing-resistant methods like hardware security keys rather than SMS codes, which remain vulnerable to interception.

Encryption needs to cover data at rest and in transit. This is also where email trips people up constantly: standard consumer email like Gmail or a basic Outlook account is not HIPAA compliant by default, because it lacks a signed BAA, dedicated audit logging, and the encryption configuration ePHI requires. Use a secure patient portal or an email platform with a vendor-provided BAA and proper encryption settings instead.

Audit logging needs to be turned on, centralized somewhere searchable, retained for your documentation period, and actually reviewed on a schedule rather than left to accumulate.

Backups should follow the 3-2-1 rule: three copies, two different media types, one copy offsite. Encrypt every backup copy and document actual restore tests, not just successful backup jobs, since a backup that has never been restored is a hypothesis, not a safeguard.

Endpoints need full-disk encryption, mobile device management enrollment, endpoint detection and response, and automated patching. OCR enforcement records show unencrypted lost laptops and phones showing up again and again as the cause of reportable breaches — it's one of the most preventable failure points in the entire rule.

Managing Vendors and Business Associate Agreements

Any vendor that touches ePHI needs a signed BAA before that access begins, not after. That list is longer than most teams expect: cloud email providers, backup and cloud storage services, managed IT providers, EHR vendors, billing and clearinghouse services, and telehealth platforms all belong on it.

When reviewing a BAA, confirm it spells out permitted uses of the data, requires subcontractors to sign equivalent agreements, sets breach reporting timelines, and clearly states the vendor's own security responsibilities. Build a short onboarding checklist and keep the evidence on file:

• Signed BAA with subcontractor flow-down language
• Vendor's security documentation or SOC 2 report
• Breach notification terms and timing commitments
• Annual review date and renewal owner

Our guide to Business Associate Agreements covers the clauses worth pushing back on before signing.

Incident Response and Breach Notification

When something goes wrong, the first hour matters as much as the first week. Immediate technical steps should include:

1. Contain the affected system without destroying evidence, isolating rather than wiping
2. Preserve logs, disk images, and a timeline of events before anything gets overwritten
3. Run the four-factor risk assessment (nature of the data exposed, who accessed it, whether it was actually viewed, and how much the risk was mitigated) to decide if notification is required
4. If notification thresholds are met, HHS OCR requires timely notice after discovery
5. Route the incident through a defined escalation chart naming who leads containment, who handles legal and notification, and who talks to affected patients

Table-top exercises before an incident happens are worth more than any policy document sitting in a drive.

Documentation, Retention, and Staying Audit Ready

OCR investigations move fast, and the practices that struggle are the ones scrambling to produce records instead of pulling them from a folder. Keep these on hand at all times:

• Current and prior risk analyses
• Written security policies and procedures
• Training completion records
• Signed BAAs for every applicable vendor
• Incident and breach logs
• Backup restore test results and audit-log review notes

Retain HIPAA-related documentation for six years from creation or last effective date, whichever is later. Store everything in one organized, access-controlled repository, not scattered across individual inboxes.

Pro Tip: Run a mock audit twice a year: pull your evidence package cold, as if OCR asked for it today, and time how long it takes to assemble. If it takes more than an hour, your documentation system needs work.

A 30-90-180 Day Implementation Roadmap

Compliance work has to be sequenced, or it stalls under its own weight. Here's a realistic order of operations that prioritizes the highest-risk gaps first.

Days 1 through 60, focus on stopping the bleeding:

1. Complete the asset inventory and identify every system touching ePHI
2. Roll out MFA on every account with ePHI access
3. Enable full-disk encryption on all endpoints
4. Validate that backups are running and test one restore
5. Get urgent BAAs signed with any vendor currently missing one
6. Patch the most critical known vulnerabilities

Days 90 through 180, build the documented program:

• Complete or refresh the formal SRA with full control mapping
• Finalize written policies covering access, sanctions, and contingency planning
• Automate log collection and set a recurring review cadence
• Deliver staff training and log completion
• Review every vendor BAA against the checklist above
• Run at least one incident-response table-top exercise

If you bring in a managed IT provider for this work, expect specific deliverables in return: a written risk assessment report, documented policies, signed BAAs on file, a backup and recovery plan with restore test logs, and defined response times for security incidents. Ask to see sample evidence templates before signing anything. Practices we've supported through this process at Great Plains Networking's dental and medical IT team typically reach a defensible technical posture inside 60 to 90 days, with full documentation catching up over the following months.

What Trips Up Most Compliance Programs

The mistakes that repeat across audits aren't exotic. Teams skip documenting why an addressable control wasn't implemented as written. Backups run successfully for years without anyone confirming a restore actually works. BAAs get promised verbally and never signed. If you fix one thing this quarter, make it this: run the risk analysis and turn on MFA and encryption everywhere ePHI lives. Everything else in the Security Rule builds on that foundation.

— Nicholas

How Great Plains Networking Supports Your Compliance Program

Great Plains Networking gives Oklahoma healthcare practices a faster path to a defensible security posture than building a compliance program from scratch with internal staff stretched thin. Managed IT support can wrap around the exact controls covered here: 24/7 monitoring that catches issues before they become incidents, risk assessment support, BAA execution with documented responsibilities spelled out, encrypted backup and recovery with tested restores, and timely response when something needs attention.

If your practice hasn't run a formal risk analysis in the last year, or you're not sure your backups have ever been restored under real conditions, that's the gap to close first. Dental practices in the area can start with our free HIPAA and cyber insurance audit, and any healthcare practice in Norman, Moore, or Oklahoma City can reach our managed IT support team for a straightforward conversation about where your current setup stands, with no long-term contract required to get started.

Where to Verify These Rules Directly

For primary-source detail beyond this checklist, consult the HHS Security Rule summary, NIST SP 800-66 Rev. 2, and HHS security guidance materials.

This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.

Sources

• Summary of the HIPAA Security Rule
• SP 800-66 Rev. 2: Implementing the HIPAA Security Rule

Recommended

• HIPAA Risk Assessment Steps: A Compliance Officer's Playbook