HIPAA Security Rule: Requirements, 2026 Checklist and Updates

The HIPAA Security Rule is the federal standard that tells you how to protect electronic protected health information, and it is the part of HIPAA that OCR investigates most aggressively when a breach happens. It sets requirements across three areas of safeguards: administrative, physical, and technical. If your organization creates, receives, stores, or transmits ePHI in any electronic form, this rule applies to you whether you are a hospital, a digital health startup, or a vendor building the software those groups depend on.

At Arkenea, we have spent 15 years building HIPAA compliant web and mobile applications for healthcare providers, and the pattern we see over and over is the same. Teams treat the Security Rule as a box to tick near launch, when it is really a set of architectural decisions that should shape the product from the first sprint.

This guide walks through what the rule requires, gives you a working checklist, explains the major update proposed in 2025 and why it is now delayed, and shows what compliance looks like when you build software rather than simply buy it.

What the HIPAA Security Rule actually requires

The Security Rule requires every regulated entity to ensure the confidentiality, integrity, and availability of all ePHI it handles. Confidentiality means the information is not disclosed to unauthorized people. Integrity means the data is not altered or destroyed without authorization. Availability means authorized users can reach the information when they need it.

Those three properties are the whole point of the rule, and every safeguard maps back to one or more of them. The rule sits at 45 CFR Part 160 and Part 164, Subparts A and C, and it applies only to electronic PHI. Paper records and spoken conversations fall under the Privacy Rule instead, which is a separate part of HIPAA that many teams conflate with the Security Rule.

The rule is deliberately technology neutral. Rather than naming specific products, it asks you to select reasonable and appropriate measures based on your size, complexity, technical setup, cost, and the risks you actually face. That flexibility is a gift and a trap: it lets a two person clinic and a national health plan follow the same rule, but it also means you cannot copy someone else’s controls and assume you are covered.

Who counts as a covered entity or business associate

Covered entities are health plans, healthcare clearinghouses, and healthcare providers who transmit health information electronically. Business associates are the vendors and subcontractors who handle ePHI on a covered entity’s behalf, which includes most software companies, hosting providers, billing services, and analytics firms in healthcare.

Since the HITECH Act, business associates carry direct liability under the Security Rule, so a software vendor can be investigated and penalized by OCR on its own, not just through its client.

This distinction matters more than most founders expect. If you are building a telehealth platform or a remote monitoring app, you are almost certainly a business associate the moment you touch patient data. That means you need a Business Associate Agreement with every covered entity you serve, and you need to meet the Security Rule as an organization, not just ship a feature that looks secure.

Required versus addressable, and why addressable does not mean optional

Every implementation specification in the Security Rule is labeled either required or addressable, and this is the single most misread part of the regulation. Required specifications must be implemented, full stop. Addressable specifications ask you to assess whether the measure is reasonable and appropriate for your environment.

Here is the part teams get wrong: addressable does not mean you can skip it. If you decide an addressable specification does not fit, you must document why, then implement an equivalent alternative that achieves the same protection. Encryption of ePHI is the classic example, currently addressable, yet OCR has repeatedly penalized entities that left data unencrypted without a defensible, documented reason. Treating addressable as optional is one of the fastest routes to a finding during an investigation.

The three categories of safeguards

The Security Rule organizes its requirements into administrative, physical, and technical safeguards. Administrative safeguards are the policies and management processes that run your security program. Physical safeguards protect the hardware and facilities where ePHI lives. Technical safeguards are the controls built into your systems and software.

The categories overlap in practice, and a single control often satisfies more than one. Encryption, for instance, is a technical safeguard that also supports the integrity and confidentiality goals the administrative risk analysis identifies. The sections below break down what each category asks for and how it shows up in real systems.

Administrative safeguards

Administrative safeguards are the largest category and the foundation everything else rests on. They begin with the security management process, which requires a risk analysis, a risk management plan, a sanction policy for workforce violations, and regular review of system activity. Every regulated entity must also name a security official who owns the program.

The remaining standards cover workforce security and access management, security awareness and training, incident response procedures, and contingency planning for emergencies. You also need periodic evaluations to confirm your safeguards still work, and written contracts with every business associate that touches your data. These are not one time tasks; the rule expects them to be living processes that you revisit as your systems and threats change.

Physical safeguards

Physical safeguards protect the places and devices where ePHI is stored or accessed. Facility access controls limit who can enter server rooms, offices, and data centers, and they require you to document how you grant and revoke that access. Workstation security policies govern how laptops, tablets, and desktops are positioned, used, and locked down.

Device and media controls cover the full lifecycle of hardware that holds ePHI, from receipt to disposal. That includes wiping drives before disposal, tracking movement of equipment, and keeping backups before you retire a device. In a cloud environment, much of this shifts to your hosting provider, but you remain responsible for confirming through the Business Associate Agreement that they handle it correctly.

Technical safeguards

Technical safeguards are where software teams do most of their work, and they translate the rule’s goals into code and configuration. The rule names five standards: access control, audit controls, integrity, person or entity authentication, and transmission security. Each one has a direct implementation in a well designed healthcare application.

Access control means unique user identification, automatic logoff, and encryption and decryption of ePHI at the data level. Audit controls require you to record and examine activity in systems that contain ePHI, which in practice means immutable, reviewable logs. Integrity controls protect data from improper alteration or destruction, often through checksums, versioning, and database constraints.

Authentication verifies that a person or system is who they claim to be, which today points strongly toward multifactor authentication rather than passwords alone. Transmission security protects ePHI as it moves across networks, which means TLS for data in transit and careful handling of any integration that carries patient data to a third party.

When we built the UMG telemedicine platform, live video consultations, Surescripts electronic prescribing, and EHR integration all moved ePHI between endpoints, so transmission security and authentication were architectural decisions made early rather than patches added late.

Risk analysis is the requirement OCR enforces most

If you do only one thing well under the Security Rule, make it the risk analysis. OCR’s enforcement record shows that a missing or inadequate risk analysis is the most common finding behind multimillion dollar penalties, and in 2024 the agency launched a dedicated Risk Analysis Initiative to pursue exactly this failure.

A risk analysis is not a questionnaire or a vendor’s compliance certificate. It is an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of the ePHI your organization holds.

The enforcement numbers make the point concrete. In April 2026, OCR settled four ransomware investigations for a combined $1,165,000, affecting more than 427,000 individuals, and every one cited a failure to conduct an accurate and thorough risk analysis.

Those settlements ranged from a $225,000 penalty against Consociate Health after a phishing attack to a $375,000 penalty against Assured Imaging. OCR Director Paula Stannard framed the lesson plainly: implementing the Security Rule before a breach is a regulated entity’s best chance to prevent or reduce the damage of an attack.

A defensible risk analysis follows a clear sequence, and walking through it step by step is the surest way to satisfy an auditor. First, inventory every technology asset and map where ePHI is created, received, maintained, and transmitted, because you cannot protect data whose location you cannot describe. Second, identify the threats and vulnerabilities to each of those assets, from ransomware and phishing to insider misuse and unpatched software.

Third, assess the likelihood and impact of each threat to produce a realistic risk level rather than a generic score. Fourth, document the security measures you will implement to reduce each risk, and record why you chose them. Fifth, review and update the analysis on a regular schedule and whenever your systems change, because a risk analysis from three years ago describes a system you no longer run. This is the record OCR asks for first, and the entities that produce it quickly tend to fare far better in an investigation.

HIPAA Security Rule compliance checklist

The checklist below organizes the rule’s standards into actions you can assign, track, and verify. It is not a shortcut around the risk analysis, which remains the step that determines how each item applies to you. Use it as the working backbone of your compliance program, and keep documentation for every item, because in an OCR investigation an undocumented control is treated as a control that does not exist.

Administrative safeguards checklist

1. Conduct an accurate and thorough risk analysis covering all ePHI, and repeat it on a set schedule.
2. Implement a risk management plan that reduces each identified risk to a reasonable level.
3. Designate a named security official responsible for the program.
4. Apply a sanction policy for workforce members who violate security policies.
5. Review information system activity, including audit logs and access reports, on a regular basis.
6. Authorize and control workforce access to ePHI based on job role, and revoke it promptly when roles change.
7. Deliver security awareness training, including protection against malicious software and login monitoring.
8. Establish and test incident response procedures for detecting and reporting security events.
9. Build a contingency plan with data backup, disaster recovery, and emergency mode operation.
10. Evaluate your safeguards periodically to confirm they still meet the rule.
11. Execute a Business Associate Agreement with every vendor that handles ePHI.

Physical safeguards checklist

1. Control physical access to facilities and server rooms, and log who is granted entry.
2. Set workstation use policies that define acceptable functions and secure positioning of screens.
3. Secure workstations against unauthorized physical access.
4. Govern the receipt, movement, reuse, and disposal of hardware and media that store ePHI.
5. Wipe or destroy data on devices before disposal, and keep a retrievable backup where needed.

Technical safeguards checklist

1. Assign a unique identifier to every user who accesses ePHI.
2. Enforce automatic logoff after a defined period of inactivity.
3. Encrypt ePHI at rest and in transit, and document your decision for any addressable encryption specification.
4. Record and review audit logs for all systems that contain ePHI.
5. Protect data integrity with mechanisms that detect improper alteration or destruction.
6. Authenticate users and systems, moving to multifactor authentication for access to ePHI.
7. Secure all transmission of ePHI with current transport encryption such as TLS.
8. Establish emergency access procedures so authorized staff can reach ePHI during an outage.

The 2025 proposed overhaul and where it stands in 2026

In January 2025, OCR published a Notice of Proposed Rulemaking that would be the first major update to the Security Rule since 2013. The proposed rule reflects how much the threat environment has shifted, and its central move is to make the rule far more prescriptive. The comment period closed in March 2025, and the proposal drew heavy engagement from across the healthcare sector.

The most consequential change is the proposed removal of the addressable versus required distinction. Under the proposal, nearly all implementation specifications would become required, with only narrow exceptions. That single change would end the common practice of documenting encryption or multifactor authentication as addressable and then declining to implement it.

The proposal layers on a set of specific technical mandates that read like a modern security baseline. The table below summarizes the changes that matter most for organizations that build or operate healthcare software.

Then the timeline changed. In mid 2026, HHS pushed the expected completion of the final rule from May 2026 to July 2027, moved the rulemaking from the final rule stage to long term actions, and removed it from the 2026 Agency Rule List. HHS has signaled that it still intends to finalize at least some of the proposed amendments, likely the less contested provisions that deliver the highest risk reduction, rather than the full package as written.

The delay is not a reason to wait. Every provision in the proposal already reflects what OCR treats as reasonable and appropriate during current enforcement, so the addressable encryption and authentication controls it would mandate are the same ones investigators already expect.

Building toward asset inventories, encryption everywhere, multifactor authentication, and network segmentation now means you are compliant today and ready whenever the final rule lands. Teams that treat 2027 as a deadline to start planning are misreading how enforcement already works.

What compliance looks like when you build software, not just buy it

Most guides on the Security Rule are written for compliance officers who adopt finished tools. The picture is different when you are building the software itself, because then the safeguards are not settings you configure but architecture you design. This is where a checklist mindset falls short and an engineering mindset takes over.

Designing safeguards into the architecture

The cheapest time to satisfy the Security Rule is before you write the first line of code, and the most expensive time is after a breach. Access control, audit logging, encryption, and authentication all become simple when the data model and service boundaries are designed with them in mind. They become painful retrofits when a product was built to move fast and worry about compliance later.

When we built a custom cloud EHR for Hamilton Physical Therapy across its eight locations, role based access and audit trails had to live inside the workflow, not bolt onto it, because clinicians will route around security that slows them down. The same principle held on the UMG telemedicine build, where authentication and transmission security wrapped every video session and electronic prescription. In both cases the safeguards were invisible to the end user precisely because they were designed in rather than added on.

Build versus buy, and where each makes sense

A frequent question from founders and practice owners is whether to build custom software or adopt an existing HIPAA ready platform. The honest answer depends on how differentiated your workflow is and how much control you need over the data. The table below lays out the tradeoffs we walk clients through.

Neither answer is universally right. A small practice that needs standard scheduling and records is usually better served buying a proven platform. A company whose product is the software, such as a digital health startup or a group building a differentiated care model, almost always needs to build, because its workflow and its data control are the business.

Realistic timelines and costs

Compliance work is real engineering effort, and pretending otherwise sets projects up to fail. For a custom healthcare application, the safeguards described here typically add meaningful scope to design, development, and testing rather than a fixed line item at the end. A production ready, HIPAA compliant application usually takes several months of focused work, and a realistic range for a substantial platform runs from 6-12 months depending on integrations and clinical complexity.

The cost driver that surprises teams most is not any single control but the discipline the rule demands across the whole lifecycle. Audit logging, encryption, access management, backup and recovery, and the documentation that proves they exist all carry ongoing effort, not just an upfront build. Budgeting for that from the start is far cheaper than the alternative, since the OCR settlements above show what an unaddressed risk analysis can cost after the fact.

Common misconceptions that create compliance risk

Several assumptions about the Security Rule are widespread, comfortable, and wrong, and each one has put organizations into an OCR investigation. Correcting them early is one of the highest value things a healthcare team can do.

The first is that using a HIPAA eligible cloud provider makes your application compliant. It does not. A provider such as AWS or Azure will sign a Business Associate Agreement and secure the infrastructure, but the confidentiality, integrity, and availability of ePHI inside your application remains your responsibility through the controls you build on top.

The second is that a Business Associate Agreement transfers your liability to the vendor. It defines responsibilities and creates obligations, but each party remains directly accountable under the rule for the ePHI it handles. A signed BAA is necessary, yet it is not a shield against your own compliance gaps.

The third is that small organizations are too minor to be targeted or penalized. The 2026 settlements included entities with fewer than 10,000 affected individuals, and ransomware groups routinely hit small practices precisely because their defenses are thinner. The rule scales to your size, but it does not exempt you for being small.

Frequently asked questions

What is the difference between the HIPAA Privacy Rule and the Security Rule?

The Privacy Rule governs all protected health information in any form, including paper and spoken communication, and it sets the rules for how PHI may be used and disclosed. The Security Rule applies only to electronic PHI and defines how that data must be protected through administrative, physical, and technical safeguards. Most organizations must comply with both, and confusing the two is a common source of gaps.

Who has to comply with the HIPAA Security Rule?

Covered entities, meaning health plans, clearinghouses, and providers who transmit health data electronically, must comply, as must their business associates. Business associates include most software vendors, hosting providers, and service firms that handle ePHI, and since the HITECH Act they carry direct liability. If your product touches patient data on behalf of a covered entity, the rule applies to you directly.

Is encryption required under the HIPAA Security Rule?

Encryption is currently an addressable specification, which means you must implement it or document why an equivalent alternative is reasonable and appropriate. In practice, OCR expects encryption of ePHI at rest and in transit, and the absence of it without a documented justification has led to penalties. The 2025 proposed update would make encryption an outright requirement, so building toward it now is the safe path.

How often do I need to perform a risk analysis?

The rule requires the risk analysis to be accurate and thorough and kept current, which means you review and update it on a regular schedule and whenever your systems or threats change materially. A single analysis at launch does not satisfy the rule for years afterward. Because inadequate risk analysis is the leading cause of enforcement penalties, treating it as an annual and event driven process is the defensible standard.

What happens if I violate the HIPAA Security Rule?

OCR can impose civil monetary penalties that scale with the level of culpability, and settlements frequently reach hundreds of thousands or millions of dollars, as the 2026 ransomware cases show. Penalties are commonly paired with a corrective action plan and years of OCR monitoring. Willful neglect that goes uncorrected carries the highest penalties, while entities that can show a current risk analysis and reasonable safeguards tend to fare far better.

When do the new 2025 HIPAA Security Rule changes take effect?

As of mid 2026, the final rule has been delayed, with HHS now targeting July 2027 and signaling it may finalize only part of the original proposal. There is no active compliance deadline yet, but the controls in the proposal already reflect current OCR enforcement expectations. Building toward encryption, multifactor authentication, asset inventories, and network segmentation now keeps you compliant today and prepared for whatever version is finalized.

Where to go from here

The Security Rule rewards organizations that treat it as an engineering and governance discipline rather than a document they produce before an audit. Start with an honest risk analysis, close the gaps it reveals, and design your systems so that the required safeguards are part of the architecture rather than additions to it. That approach satisfies the rule today and positions you for the stricter standard coming in the years ahead.

If you are building or planning a healthcare application and want the Security Rule handled as part of the design rather than a scramble before launch, that is the work we do at Arkenea. Fifteen years of building HIPAA compliant software for providers and health companies has taught us that compliance done early is cheaper, faster, and far less risky than compliance done under investigation.