The HIPAA Security Rule: safeguards, evidence, and automation
The HIPAA Security Rule is the part of the Health Insurance Portability and Accountability Act that sets specific requirements for protecting electronic protected health information, organized into administrative, physical, and technical safeguards. It applies to covered entities, meaning health plans, health care clearinghouses, and most health care providers, and to their business associates, the vendors and contractors that create, receive, maintain, or transmit electronic protected health information on a covered entity's behalf. The Rule does not offer a certification; compliance is a legal obligation enforced by the HHS Office for Civil Rights, not a credential an organization earns.
What the HIPAA Security Rule is
HIPAA is a broader statute with several distinct rules underneath it: a Privacy Rule governing health information generally, a Breach Notification Rule added later, and the Security Rule specifically, which addresses the administrative, physical, and technical protection of electronic protected health information, commonly shortened to ePHI. The Security Rule is codified in federal regulation at 45 CFR Part 164, Subpart C, and organizations were first required to comply with it in 2005.
The Health Information Technology for Economic and Clinical Health Act, enacted in 2009 and generally known as HITECH, reshaped the Rule significantly: it extended direct legal liability to business associates, who previously answered only to the covered entities that hired them, and it added the Breach Notification Rule requiring covered entities and business associates to report breaches of unsecured ePHI. A further Omnibus Rule in 2013 tightened business associate obligations again.
The Security Rule organizes its requirements into three categories of safeguards: administrative, the largest group, covering the security management process, workforce training, access management, contingency planning, and business associate agreements; physical, covering facility access controls, workstation security, and device and media handling; and technical, covering access control, audit logging, data integrity, and transmission security enforced through technology. Every implementation specification under each standard is labeled either required, meaning it must be implemented exactly as written, or addressable, meaning the organization must assess whether it is reasonable and appropriate and then implement it, implement an equivalent alternative, or document why neither applies. Addressable is frequently misread as optional; it is not, and OCR expects a documented decision either way.
Who needs the HIPAA Security Rule
A covered entity is a health plan, a health care clearinghouse, or a health care provider that transmits health information electronically in connection with a transaction HHS has standardized, which in practice reaches nearly every provider handling insurance claims today.
- Health systems, hospitals, and physician practices that create or maintain patient records electronically.
- Health plans and payers processing claims, eligibility, and enrollment data.
- Business associates: cloud hosting providers, billing and electronic health record software vendors, telehealth platforms, and any other vendor that touches ePHI on a covered entity's behalf under a signed Business Associate Agreement.
- Subcontractors of business associates, since HITECH extended the same direct obligations down the vendor chain rather than stopping at the first tier.
Any company building software that stores, transmits, or displays patient health information for a healthcare customer needs to treat the HIPAA Security Rule as a design requirement from the start of the build, not a paperwork exercise added at the end.
HIPAA Security Rule requirements, by safeguard category
Each safeguard category groups a set of standards, and each standard breaks down further into required or addressable implementation specifications.
| Safeguard category | What it covers | Example implementation specifications |
|---|---|---|
| Administrative | Governance, workforce, and process controls that manage how security is run | Security management process including the risk analysis, workforce training and sanctions, access authorization, contingency planning, business associate agreements |
| Physical | Controls over the physical spaces and devices where ePHI is stored or accessed | Facility access controls, workstation use and security policies, device and media disposal and reuse controls |
| Technical | Controls enforced through technology on systems that touch ePHI | Unique user identification and access control, audit controls and logging, data integrity controls, transmission security |
Every other safeguard in the Rule assumes an accurate risk analysis exists underneath it. Skipping the analysis, or documenting it superficially, is the single most common finding when the HHS Office for Civil Rights investigates a covered entity or business associate.
The HIPAA Security Rule compliance process, step by step
Compliance under the Security Rule is a continuing program rather than a project with a finish line, but the initial buildout follows a fairly consistent sequence.
- Determine covered entity or business associate status: Confirm which obligations apply and identify every system that creates, receives, maintains, or transmits ePHI.
- Conduct the security risk analysis: Identify where ePHI lives, the threats and vulnerabilities to it, and the likelihood and impact of each; typically four to eight weeks for a first pass at an organization of moderate size.
- Risk management: Prioritize the gaps the analysis surfaced and build a remediation plan with owners and dates, commonly running four to twelve weeks alongside the earliest fixes.
- Implement administrative safeguards: Policies, sanction procedures, workforce training, and access authorization processes, alongside signed Business Associate Agreements with every vendor that touches ePHI.
- Implement physical safeguards: Facility access controls, workstation policies, and device and media handling procedures.
- Implement technical safeguards: Access controls, audit logging, encryption in transit, and integrity controls on systems and databases holding ePHI.
- Document and train: Written policies, an incident response plan, and workforce training records, since OCR treats undocumented practice as unproven practice.
- Reassess: Repeat the risk analysis on a regular cycle and after any material change to systems, staff, or the threat environment; this is a continuing obligation, not a one-time project.
How long does HIPAA Security Rule compliance take and what does it cost?
Ranges below assume an organization of moderate size building a program largely from scratch; a small practice with a handful of systems will land at the low end, and a multi-facility health system will exceed the high end.
An initial risk analysis and remediation program commonly runs three to six months, longer if a legacy system needs to be re-architected for encryption or access control. Ongoing maintenance, an annual risk analysis refresh, workforce training, and continuous monitoring, is a continuing program rather than a one-time milestone.
A professionally conducted risk analysis commonly runs fifteen thousand to sixty thousand dollars depending on organization size and the number of systems touching ePHI. Remediation costs vary widely, often twenty thousand to one hundred fifty thousand dollars or more, driven mostly by whatever encryption, logging, or access-control infrastructure was missing going in. An ongoing compliance program, including annual reassessment, workforce training, and monitoring, commonly runs ten thousand to fifty thousand dollars a year after the initial buildout.
ACTA is licensed per environment, and every engagement starts with a conversation. The deterministic evidence generation described later on this page targets the evidence and control-narrative cost above; it does not replace the judgment call a risk analysis itself requires or substitute for legal advice.
Common failure points
OCR's own enforcement history points to a small set of recurring gaps, and they show up in organizations of every size.
- Risk analysis skipped, outdated, or too generic to actually identify where ePHI lives, the single most common finding when OCR investigates a breach.
- Addressable implementation specifications treated as optional rather than documented as implemented, alternatively implemented, or reasonably declined.
- Business Associate Agreements missing, expired, or not extended down the subcontractor chain to every vendor that actually touches ePHI.
- Workforce training delivered once at hire and never repeated or tracked as evidence afterward.
- Portable devices and removable media left unencrypted, a recurring theme in OCR breach investigations involving lost or stolen laptops.
- Audit logs collected but never actually reviewed, so unauthorized access goes unnoticed until a much larger incident forces the question.
How ACTA automates HIPAA Security Rule compliance
ACTA's healthcare policy pack library includes HIPAA alongside HITRUST and HITECH, and like every pack, it ships with every license: a health-tech vendor does not pay a separate fee to add the HIPAA pack on top of whatever else it already runs. The pack is editable YAML, so control narratives can be tuned to a specific environment rather than left as a generic template.
ACTA runs on goRapide, BMD's deterministic causal engine, with no large language models, no agents, and nothing probabilistic anywhere in the compliance path. Re-running the same environment through the same journey, whether for an internal check or the next annual risk analysis refresh, produces identical evidence and identical findings both times, with an inspectable causal chain behind each one, a property directly useful for a requirement that depends on an accurate and repeatable risk analysis.
ACTA generates control narratives and an evidence binder mapped to the administrative, physical, and technical safeguards, built from the live environment rather than assembled by hand when an assessment is due. Evidence never leaves the customer's boundary: the standard build phones home only for a license heartbeat, and the air-gapped build makes no network callback at all, which matters directly for an organization whose evidence is itself built from systems holding protected health information.
Because every pack ships with every license, a health-tech vendor selling into a hospital system, a federal health agency, and a commercial payer in the same quarter can run the HIPAA pack alongside the NIST SP 800-53 control catalog, a FedRAMP authorization effort, and a SOC 2 report in a single deployment rather than three separate tools. Continuous monitoring tracks credential health, evidence freshness, and drift between reassessment cycles, refreshing a stale posture to current in two clicks.
HIPAA and adjacent frameworks
HIPAA vs HITRUST?
HIPAA is a federal law, and the Security Rule specifically is enforced by the HHS Office for Civil Rights; there is no such thing as HIPAA certification. HITRUST CSF is a private, certifiable framework built partly on HIPAA's own requirements alongside NIST controls, ISO 27001, and other frameworks folded into a single control set. An organization can earn HITRUST certification from an authorized assessor, and it is commonly used as market evidence of a mature security program, but passing a HITRUST assessment does not itself constitute HIPAA compliance in a legal sense. OCR still evaluates a covered entity's or business associate's own risk analysis and safeguards on their own terms, independent of any certification the organization holds.
Health-tech vendors selling to federal health agencies, such as the Department of Health and Human Services or the Department of Veterans Affairs, frequently need HIPAA safeguards alongside the NIST SP 800-53 control catalog or a FedRAMP authorization for the underlying cloud platform. The technical safeguards in HIPAA, access control, audit logging, encryption, mirror control families NIST already covers, which gives a real head start but does not substitute for either program's own independent requirements.
Many commercial health-tech vendors also carry a SOC 2 report alongside HIPAA compliance, since enterprise buyers frequently ask for both. The two address different obligations, contractual assurance for one, a federal legal requirement for the other, and neither substitutes for the other, though evidence like access reviews and audit logging is often shared across both efforts. See the rest of the compliance framework library for how HIPAA fits the wider healthcare and federal picture.
Frequently asked questions
HIPAA vs HITRUST?
HIPAA is a federal law enforced by the HHS Office for Civil Rights; there is no HIPAA certification. HITRUST CSF is a private, certifiable framework built partly on HIPAA's own requirements alongside NIST and ISO 27001. An organization can earn HITRUST certification, which is useful market evidence, but it does not itself constitute legal HIPAA compliance.
Do business associates need their own compliance program?
Yes. Since the HITECH Act, business associates are directly liable under the Security Rule, not just contractually obligated through a covered entity. A vendor that creates, receives, maintains, or transmits ePHI has to implement its own administrative, physical, and technical safeguards and can be directly investigated and fined by OCR.
What is the difference between required and addressable specifications?
Required specifications must be implemented exactly as written. Addressable specifications give the organization flexibility: assess whether the specification is reasonable and appropriate, then implement it, implement an equivalent alternative, or document why neither is necessary. Addressable is not the same as optional, and OCR expects a documented decision either way.
What counts as protected health information?
Protected health information is individually identifiable health information: anything relating to a person's health condition, care, or payment for care, combined with an identifier that could tie it back to that person. The Security Rule specifically covers the electronic form of this information, commonly abbreviated ePHI.
How often does a risk analysis need to be updated?
The Security Rule does not set a fixed schedule, but OCR expects it to be an ongoing process, revisited at least annually and again after any material change: a new system, a new vendor, an office move, or a security incident. A risk analysis conducted once and never revisited is one of the most common findings OCR cites.
What is the HIPAA breach notification requirement?
Under the HITECH Act's Breach Notification Rule, a covered entity has to notify affected individuals and HHS following a breach of unsecured PHI, generally within sixty days of discovery, and notify the media as well if the breach affects five hundred or more individuals in a state or jurisdiction.
Does the HIPAA Security Rule apply to paper records?
No, not directly. The Security Rule specifically covers electronic protected health information. Paper records and other physical PHI fall under the broader HIPAA Privacy Rule instead, though many of the same administrative and physical safeguards end up covering both in practice.
What is a covered entity?
A covered entity is a health plan, a health care clearinghouse, or a health care provider that transmits health information electronically in connection with a transaction the Department of Health and Human Services has standardized, which in practice covers nearly every provider handling insurance claims today.
Is encryption required under the HIPAA Security Rule?
Encryption is an addressable specification, not a required one, meaning an organization has to implement it or document a reasonable equivalent alternative and the reasoning behind that choice. In practice, OCR treats unencrypted portable devices and unencrypted data in transit as a difficult position to defend after a breach.