HIPAA Compliance Solutions

The HIPAA Security Rule establishes national standards for protecting electronic protected health information (ePHI) that a covered entity or business associate creates, receives, maintains, or transmits. Per the U.S. Department of Health and Human Services, the rule requires appropriate administrative, physical, and technical safeguards to ensure the confidentiality, integrity, and availability of ePHI. Three groups must comply: covered entities (health plans, clearinghouses, and providers who transmit health information electronically), business associates (vendors and subcontractors that handle ePHI on a covered entity's behalf, directly liable since the 2013 Omnibus Final Rule implemented the HITECH Act), and subcontractors of business associates, who need their own chain of written agreements.

HHS designed the Security Rule to be scalable and technology neutral. It does not dictate specific products; it directs regulated entities to consider their size, resources, the complexity of their environment, and the results of their risk analysis when selecting security measures. That flexibility is also the trap. "Reasonable and appropriate" is judged against a documented risk analysis, so a practice that skips the analysis has no defense for any safeguard decision it made, or failed to make.

The three safeguard categories

The Security Rule organizes its requirements into three safeguard sections. Administrative safeguards at 45 CFR 164.308 cover the security management process (risk analysis, risk management, sanction policy, information system activity review), assigned security responsibility (a designated security official at 164.308(a)(2)), workforce security and information access management, security awareness and training, security incident procedures, contingency planning, evaluation, and business associate contracts. Physical safeguards at 164.310 cover facility access controls, workstation use and security, and device and media controls, including required media disposal and media re-use specifications. Technical safeguards at 164.312 cover access control (unique user identification and emergency access procedure are required; automatic logoff and encryption are addressable), audit controls, integrity, person or entity authentication, and transmission security.

Required vs addressable: the most misunderstood part

Regulated entities must comply with every Security Rule standard, but individual implementation specifications are labeled either required or addressable. HHS is explicit: addressable does not mean optional. Where an addressable specification is reasonable and appropriate for your organization, you must adopt it. Where it is not, the rule lets you adopt an alternative measure that achieves the purpose of the standard, and you must document why the specification was not reasonable and appropriate and why your alternative is, per 45 CFR 164.306(d). That documentation requirement is where most self-managed programs fail.

Encryption is the highest-stakes example. Encryption of ePHI at rest and in transit is technically addressable, but because encryption renders protected health information unreadable, indecipherable, and unusable to unauthorized persons, encrypted PHI that is breached may fall outside the Breach Notification Rule's notification requirement for unsecured PHI. Skipping encryption therefore converts every incident into a potential notifiable breach. We treat encryption as effectively required for every healthcare client, and document the reasoning either way.

The risk analysis is the foundation

Under the Security Management Process standard, 45 CFR 164.308(a)(1)(ii)(A) requires every regulated entity to conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of the ePHI it holds. OCR's Guidance on Risk Analysis states that the risk analysis is the first step in identifying and implementing safeguards that comply with the Security Rule: it is foundational, and every other safeguard decision flows from it. The analysis must answer where all your ePHI lives (including ePHI you create, receive, maintain, or transmit), what the external sources of ePHI are (vendors, consultants, billing companies, cloud services), and what human, natural, and environmental threats face the information systems that contain ePHI.

Three companion specifications sit alongside the risk analysis and all three are required, not addressable: risk management (164.308(a)(1)(ii)(B), security measures sufficient to reduce risks to a reasonable and appropriate level), sanction policy (164.308(a)(1)(ii)(C)), and information system activity review (164.308(a)(1)(ii)(D), regular review of audit logs, access reports, and security incident tracking reports). The risk analysis is also not a one-time event: the Evaluation standard at 164.308(a)(8) requires periodic technical and non-technical evaluation, and 164.306(e) requires re-evaluation in response to environmental or operational changes. In practice most organizations re-run the analysis annually and after any material change: a new EHR, a merger, a new telehealth platform, a move to a new facility.

HHS and ONC publish a free HIPAA Security Risk Assessment (SRA) Tool for small and medium practices. It is a reasonable self-check, but it is not a substitute for an engagement that maps your actual environment, tests your controls, and produces evidence an auditor or OCR investigator will accept.

Business Associate Agreements

Before a covered entity may permit a business associate to create, receive, maintain, or transmit ePHI on its behalf, it must obtain satisfactory assurances that the business associate will appropriately safeguard the information, in writing. That written contract is the business associate agreement (BAA), required by 45 CFR 164.308(b) with content requirements at 164.314. Per HHS, the BAA must require the business associate to implement the administrative, physical, and technical safeguards of the Security Rule with respect to ePHI; report any security incident of which it becomes aware and, under the Breach Notification Rule at 164.410, notify the covered entity of a breach without unreasonable delay and no later than 60 days after discovery; ensure any subcontractors that touch ePHI agree to the same restrictions in writing; make records available to the Secretary of HHS for compliance review; and return or destroy all ePHI at termination where feasible.

Because the HITECH Act made business associates directly liable under the Security Rule, a BAA is no longer just risk transfer. Your billing company, your EHR hosting vendor, your IT provider, your shredding service, and your transcription service all carry direct obligation. Two questions we field often: does a BAA cover data stored by a cloud vendor outside the agreement's scope (no), and does an IT provider that cannot access ePHI need one (usually not, because the access test controls). If your IT provider has administrative access to your servers, EHR workstations, or backups, it is a business associate and needs a written BAA.

Breach notification basics

The Breach Notification Rule defines a breach as, generally, an impermissible use or disclosure under the Privacy Rule that compromises the security or privacy of PHI. An impermissible use or disclosure is presumed to be a breach unless the covered entity or business associate demonstrates a low probability that the PHI has been compromised, based on a documented risk assessment of at least four factors: the nature and extent of the PHI involved and its likelihood of re-identification, the unauthorized person who used or received the PHI, whether the PHI was actually acquired or viewed, and the extent to which the risk has been mitigated. The burden of proof is on the regulated entity, and that demonstration rests on your documented four-factor assessment.

If notification is required, the clocks are: individuals notified without unreasonable delay and no later than 60 days after discovery of a breach of unsecured PHI, by first-class mail or email if the individual agreed to electronic notice; breaches affecting 500 or more individuals reported to the Secretary of HHS without unreasonable delay and no later than 60 days after discovery, with prominent media outlets notified for a breach affecting more than 500 residents of a state or jurisdiction; breaches affecting fewer than 500 individuals may be reported annually within 60 days after the end of the calendar year; and business associates must notify the affected covered entity within 60 days of discovery.

Separating IT operations from compliance oversight

A question that comes up on nearly every first call: can the existing IT provider handle HIPAA compliance? We recommend separating IT operations from compliance oversight. Compliance requires evaluating the safeguards your IT provider operates, and having your IT provider audit its own work is a conflict of interest. An independent assessor produces the objective evidence OCR expects. The two roles divide cleanly: the IT provider keeps the systems running, patches applied, and backups tested; the compliance assessor judges whether those safeguards actually meet the Security Rule and documents the evidence. Both matter, and both are represented in the deliverables above.

Training, texting, email, and the rest of the safeguard stack

The Security Awareness and Training standard at 45 CFR 164.308(a)(5) requires training all workforce members on your security policies and procedures. Video-based courses with quizzes carry continuing education credit, and HIPAA-specific training covers PHI handling, phishing prevention, and password management alongside the security reminders, malware protection, and log-in monitoring the standard names. Outside of formal training, the everyday channels carry compliance weight too: secure messaging for clinical communication, encrypted email for referral and billing correspondence, and analytics environments handled so that health-related website or dashboard data that can identify a visitor is treated as ePHI in your risk analysis.

If your website collects health-related information that identifies a visitor (an IP address paired with an appointment condition, for example), that data may be ePHI and the security safeguards apply to how it is collected, transmitted, and stored. This is a fast-moving area under OCR enforcement, and it belongs in your annual analysis rather than on a someday list. The same discipline applies to business intelligence dashboards that draw from EHR data: if the dashboard environment can identify a patient, it is in scope.

How does HIPAA relate to other frameworks? The Security Rule is outcome-based and technology neutral; NIST publishes the control catalogs and guidance HHS references, including NIST SP 800-66 for HIPAA and NIST SP 800-30 for risk assessment. A single control implementation can satisfy multiple mandates when mapped correctly. If your organization also handles controlled unclassified information under defense contracts, the same risk-analysis discipline runs through our CMMC practice.

What a HIPAA risk assessment costs

It depends on the number of systems that touch ePHI, the number of locations, and how much documentation already exists. We quote fixed-scope engagements after a scoping call, and the first call is free. For a fast, low-commitment first look, the $497 HIPAA Quick Scan gives you a 30-minute rapid readiness check with written findings in 7 days. Call Penny at 919-348-4912 or use the contact form to scope either one.

How an engagement runs

Every engagement is scoped on a first call and delivered by practitioners, remote-first across all 50 states. The shape of a typical risk assessment engagement: discovery call and scoping (ePHI inventory, systems that touch it, vendors, facilities); risk analysis to 45 CFR 164.308(a)(1) using NIST SP 800-30 methodology and NIST SP 800-66 mapping; gap analysis against each administrative, physical, and technical safeguard standard; technical validation (configuration review, patch state, access controls, audit logging, encryption, backup and recovery testing); a risk management plan with findings ranked by risk, a remediation roadmap, and addressable-specification decisions documented; and policies, workforce training, and BAAs brought current with a reassessment cadence set.

You receive a documented risk analysis that answers the questions OCR's guidance expects: where ePHI lives, who touches it, what threatens it, and what safeguards were chosen in response. A written remediation plan ranked by risk level, with each addressable implementation specification decision documented as 164.306(d) requires. Evidence packages an auditor can follow: control mapping to NIST SP 800-66 and cross-references to NIST SP 800-53 control families. And a reassessment cadence aligned to the Evaluation standard, so the analysis stays current when your environment changes.

Practices that need an executive-level security function without a full-time hire can attach the assessment to an ongoing vCISO engagement: the named vCISO can serve as security officer of record for HIPAA under 45 CFR 164.308(a)(2), with formal designation documentation. Petronella Technology Group, Inc. has advised healthcare organizations since 2002, combining AI-powered compliance tooling with hands-on cybersecurity engineering, led by Craig Petronella, NC Licensed Digital Forensic Examiner #604180, CMMC Registered Practitioner, CCNA, CWNE, and holder of an MIT AI certificate, with 30+ years of experience. The firm is a Cyber AB Registered Provider Organization (RPO #1449) and has held BBB A+ accreditation since 2003.

Headquartered in Raleigh at 5540 Centerview Dr., Suite 200, Petronella provides in-person and remote HIPAA compliance services throughout the Research Triangle and remote-first across all 50 states. Who this is for: medical practices, business associates, dental and specialty practices, health tech and telehealth companies, billing and transcription vendors, and law firms handling health records.