The Security Rule, from the top

The Security Rule has a reputation for being impenetrable, and the reputation is undeserved. It is a short rule with a clear architecture, and once you see the architecture, every requirement in it has an address. The reason it feels impenetrable is that almost everyone starts reading in the middle, at the safeguard lists, and skips the section that explains what the lists mean.

This page is the map. Start here, then go wherever your question lives.

What it covers, and what it does not

The Security Rule applies to covered entities and business associates (45 CFR 164.302), and it protects exactly one thing: electronic protected health information. ePHI, not PHI at large. Paper charts and spoken conversations are the Privacy Rule’s territory. The moment health information is created, received, maintained, or transmitted electronically, this rule attaches.

For an ABA clinic that distinction is nearly academic, because your operation runs on ePHI: the practice management system, the data collection platform, the tablets, the session videos, the portal, the billing. The rule was written in 2003 for server rooms. Your server room is a backpack.

The four duties

Everything in the rule hangs off four general requirements (45 CFR 164.306(a)). A covered entity or business associate must:

1. Ensure the confidentiality, integrity, and availability of all the ePHI it creates, receives, maintains, or transmits. All three properties, all of the data. Confidentiality is secrecy, integrity is the data staying right, availability is the data being there when needed. Ransomware, note, attacks all three at once.

2. Protect against reasonably anticipated threats or hazards to the security or integrity of that information. Reasonably anticipated is the operative phrase: the rule does not demand you defeat every conceivable attack, and it does not excuse you from the ones any honest assessment would have predicted.

3. Protect against reasonably anticipated uses or disclosures that the Privacy Rule does not permit. The Security Rule is the Privacy Rule’s enforcement arm for electronic data.

4. Ensure workforce compliance. Your program has to reach the people, not just the systems.

Read those four again and notice what they are: outcomes. The rule commits you to results, then spends the rest of its length describing the machinery you build to get there.

The flexibility clause, which is the whole point

45 CFR 164.306(b) is the most important paragraph in the rule and the least quoted. It says, first, that you may use any security measures that allow you to reasonably and appropriately implement the standards. Any. The rule names no products, mandates no technologies, and blesses no vendor’s checklist.

Second, it says that in deciding what is reasonable and appropriate, you must take into account four factors: your size, complexity, and capabilities; your technical infrastructure, hardware, and software security capabilities; the costs of security measures; and the probability and criticality of the potential risks to your ePHI (45 CFR 164.306(b)(2)).

This is the clause that makes the rule survivable for a twelve-person clinic. You are not held to a hospital’s answer. You are held to an honest answer for an operation of your size, your systems, your budget, and your actual risks, which is why the risk analysis is the foundation of everything: the four factors are unanswerable until you have done it.

The flexibility is real, and it has a price. A rule that never tells you exactly what to buy can never be satisfied by buying something. It is satisfied by decisions, and decisions have to exist in writing.

Standards, specifications, and the two labels

The rule’s requirements come in two sizes. Standards are the outcomes you must achieve. Implementation specifications are the specific measures under a standard, and each carries one of two labels (45 CFR 164.306(d)): required, meaning implement it, no analysis and no alternative; or addressable, meaning assess it against your environment, then implement it, or document why it is not reasonable and appropriate and implement an equivalent alternative where one is.

“A rule that never tells you exactly what to buy can never be satisfied by buying something.”

Addressable has never meant optional, and the misunderstanding is expensive enough that it has its own page, with a table of every specification and its label.

Two traps in the structure are worth naming here. Six standards have no implementation specifications at all; they are obligations in themselves, with no menu underneath. And everything in the organizational and documentation sections (45 CFR 164.314, 164.316) is required, with no addressable path anywhere in them.

The three safeguard families

The safeguards are organized by what they touch: people and process, places and things, systems and software.

Administrative safeguards (45 CFR 164.308) are the largest family, more than half the rule, and the one OCR actually cites. The program lives here: the security management process with its required risk analysis and risk management, the named security official, workforce authorization and termination, access management, training, incident procedures, the contingency plan, periodic evaluation, and the business associate machinery.

Physical safeguards (45 CFR 164.310) protect the places where ePHI lives: facility access, workstation use and security, and device and media controls, including the required disposal and media re-use procedures. For a clinic whose workstations ride into living rooms and schools, this family reads differently than its authors imagined, and that is exactly why it deserves attention rather than dismissal.

Technical safeguards (45 CFR 164.312) are the systems themselves: access control, audit controls, integrity, authentication, and transmission security. Written up in full here.

Behind all three sit the requirements everyone forgets to count. Organizational requirements (45 CFR 164.314) dictate what your business associate agreements must contain. And the documentation standard (45 CFR 164.316) requires your policies, procedures, and required records to exist in writing, be retained for six years from creation or last effective date, be available to the people who need them, and be reviewed and updated as your operations change. This last section is where paper programs go to die: the rule does not just require you to decide, it requires the decision to still be findable six years later.

The property the whole rule has

Put the pieces together and the Security Rule has a single shape: know your risks (the analysis), decide what is reasonable and appropriate for your operation (the four factors), act on the decisions (the safeguards), write everything down (the documentation standard), and keep all of it current as your clinic changes (45 CFR 164.306(e), which requires ongoing review and modification of your measures).

Which means the rule cannot be complied with once. It is a loop, not a checklist, and every enforcement pattern OCR runs traces back to an entity that treated it as a checklist: an analysis from three years ago, a policy folder nobody opened, safeguards nobody re-examined after the clinic doubled.

What may change

The January 2025 proposed rule (90 FR 800) would rebuild much of this architecture: the addressable category eliminated, encryption and multi factor authentication mandated, a written asset inventory and network map required, and specific testing and review cadences imposed. It is a proposal, not law; no final rule has issued, and the federal agenda currently shows final action in mid 2027, a date that has already moved and may move again.

The practical reading has not changed all year: OCR enforces the rule that exists, and the proposal is mostly a list of what honest risk analyses already conclude. Build to the current rule honestly and the proposal, whatever becomes of it, is an adjustment rather than an earthquake.