HIPAA Security Rule Readiness — Guide

HIPAA Security Rule Readiness

HIPAA’s Security Rule asks one thing of everyone it covers: protect the electronic protected health information you create, receive, maintain or transmit, in a way that fits your size, your systems and your risks, and be able to show that you did. The pack counts 22 standards and 41 implementation specifications, 19 required and 22 addressable, as the Rule labels them, and the Rule leaves the method to you. The method starts with a risk analysis, because that is what tells you which addressable safeguards are reasonable and appropriate for you. Everything that follows is written down, kept for six years, and reviewed when your environment changes.

Know your role. Know every system that holds electronic patient information. Assess the risk, write it down, and act on it. Keep the record.

Is this for you?

This pack is for you if:

• you run security, IT or compliance at a company that handles patient information for a clinic, a hospital, an insurer or another health organisation, and you need to know what HIPAA expects of you;
• you work at a health provider or plan and have inherited the Security Rule duty without a manual;
• a customer, an auditor or an insurer has asked “are you HIPAA compliant?” and you want to answer with facts and not with a slogan;
• you have a small team, or none, and need to know what to do first.

It does not need a lawyer to read. It does need a lawyer to confirm three things: your role, the terms of your contracts, and any decision that an event is or is not a breach.

Three rules, not one

People say “HIPAA” as if it were one rule. For a security team three parts matter, and they ask different things.

In the rest of this guide, “patient information” means what the Rules call protected health information. “Electronic patient information” means electronic protected health information, which people shorten to ePHI. The Security Rule protects the second kind. Paper is the Privacy Rule’s concern.

Who it binds

The Rules bind two kinds of organisation, and they do not bind anyone else by their own force.

• A covered entity is a health plan, a health care clearinghouse, or a health care provider that sends health information electronically in connection with a standard transaction, such as a claim to an insurer.
• A business associate is a person who handles patient information for a covered entity in the way the definition describes, or who provides one of the listed services, such as legal, accounting or data aggregation, that involves receiving it. A subcontractor that handles patient information for a business associate is a business associate too.

Two things catch people out.

1. Your role comes from what you do, not from what you signed. A company that hosts patient data for a clinic is a business associate on the day it starts, whether or not anyone has signed an agreement. A company that signs an agreement but never touches patient information is not made one by the signature. The pack lists eleven questions, taken from the definitions, in HIPAA Applicability Assessment.
2. A hybrid entity is one legal entity with both kinds of function. A retailer with a pharmacy is the usual case. It designates its health care components in writing, and the Security Rule applies to those components, which must also protect their information from the entity’s other parts as if they were separate legal entities; the designation must include any part that would itself be a covered entity or business associate. If it never designates them, the rules read as applying to the whole entity.

The HIPAA Rules in 45 CFR Parts 160 and 164 apply to covered entities (health plans, health care clearinghouses, and health care providers that transmit health information electronically in connection with standard transactions) and, where the Rules provide, to business associates and their subcontractors. Whether your organisation is one of them is decided by what it does with protected health information, and counsel confirms it. The Security Rule (Subpart C) protects electronic protected health information. The Breach Notification Rule (Subpart D) applies to breaches of unsecured protected health information. This pack does not decide which applies to you.

If none of these describes you, the Rules do not apply to you by your role. A customer’s contract may still ask you to follow the Security Rule, and State law may apply to the health information you hold. Counsel confirms.

What the Security Rule asks

The Security Rule has 22 standards. Under them sit 41 implementation specifications. A standard says what must be achieved. A specification says more about how, and it is one of two kinds.

• Required (19 of the 41). You must implement it. The size of your organisation and the cost may shape how you do it. They do not decide whether you do it.
• Addressable (22 of the 41). You must assess whether it is reasonable and appropriate in your environment. If it is, you implement it. If it is not, you document why, and you implement an equivalent alternative measure if that is reasonable and appropriate.

Addressable does not mean optional. The assessment is required and the decision is required. Where you decide that a specification is not reasonable and appropriate, the written reason is required, and so is an equivalent alternative measure if one is reasonable and appropriate. The pack asks you to record every decision, not only those, because the record is how you show that you assessed. The most common error in this field is to read “addressable” as “we may skip it” and to write nothing down. Security Rule Safeguard Register lists every one of the 41, and the addressable decision record asks for eight things: specification; risks it addresses; the four factors; is it reasonable and appropriate?; decision; the alternative, if any; decided by and on; review.

The Rule does not number its standards and specifications. These counts are the pack’s, taken from the “Required” and “Addressable” labels in the text of the Rule. Some apply only to some organisations: the standard for group health plans, and the specification for a clearinghouse that is part of a larger organisation. Where a standard applies to you, you comply with it as written, and the rest of this guide does not change that.

The 22 standards fall into five families.

The Rule does not say which tools to use. It says that you may use any security measures that let you reasonably and appropriately meet its standards, and it tells you to weigh four things: your size, complexity and capabilities; your technical infrastructure; the cost; and how likely and how serious the risks to patient information are. It sets no intervals for reviewing anything. Where this pack gives an interval, such as 12 months, it is the pack’s default, written as a placeholder you replace, and not the Rule’s.

The risk analysis comes first

Every other decision rests on the risk analysis, which is an accurate and thorough assessment of the risks and weaknesses that affect the confidentiality, integrity and availability of electronic patient information. It tells you which addressable safeguards are reasonable for you, and it tells you where to spend. HHS says that the Rule prescribes no method, and that no single method guarantees compliance. It names the elements any method must achieve, and Security Risk Analysis Method follows them in ten steps: set the scope; collect the data; identify threats; identify vulnerabilities; assess current security measures; rate the likelihood; rate the impact; determine the level of risk; finalise and approve the documentation; review and update.

The analysis must cover all the electronic patient information you create, receive, maintain or transmit, wherever it is. That includes email, exports, backups and laptops, and the places your suppliers hold it, as far as you can see them, and not only the main application. HHS asks you to find out whether vendors create, receive, maintain or transmit it, and each business associate also has its own risk analysis duty. It is rated on the scale of the risk pack (P05 RM-03 and RM-04), and a risk you accept instead of treating is recorded as P05 RM-08 asks. Repeat it every [[12]] months and whenever something material changes: a new system or supplier, a merger, a change of key staff, an incident, or a change in the law.

Suppliers

If a supplier can reach your patient information, you need a written agreement before it does, and the same applies in the other direction: a customer that is a covered entity needs one from you, and you need one from your own subcontractors. Business Associate Agreement Security Terms gives 16 security terms to check in the agreement, each with its source, and eight further terms that are common in practice. Contract wording is the clause library’s (P06-A07), and a supplier is assessed as the supplier pack (P06) sets out. A contract is never signed with a business associate that has not been through those steps.

When an event might be a breach

Most security incidents are not breaches. A security incident is an attempted or successful unauthorised access, use, disclosure, change or destruction of information, or interference with a system. A breach is narrower: patient information acquired, accessed, used or disclosed in a way the Privacy Rule does not permit, that compromises its security or privacy.

The Breach Notification Rule starts from a presumption. An impermissible acquisition, access, use or disclosure is presumed to be a breach unless you show otherwise, and you carry the burden of showing it. The duty to notify arises only for a breach of unsecured patient information. There are three ways to show that no notice is due.

• The patient information was secured: encrypted, or destroyed, as the HHS guidance specifies, and for encryption, with the key not compromised. Then the event is not a breach of unsecured information, though it is still a security incident.
• One of three exclusions applies, such as an unintentional access by a member of the workforce, in good faith and within their authority, with no further misuse.
• A written risk assessment of the four factors shows a low probability that the information has been compromised: the nature and extent of the information; the unauthorised person; acquired or viewed; mitigation.

Breach Assessment & Notification Decision Procedure takes you through eight steps to a signed decision: record the incident and the time of discovery; is it PHI, and was it handled in a way the Privacy Rule does not permit; was the PHI secured; does an exclusion apply; assess the four factors; decide and sign; hand over to the notification procedure; keep the record. Record the time of discovery as soon as you know it, before the assessment is finished, because the notification clocks run from discovery (P09 IM-13). The clocks themselves, and who is told, are in P09 RD-17 to RD-20, and the matrix and templates are P18-A09 and P18-A10. Whether an event is reported is decided as P09 sets out. The assessment feeds that decision and never replaces it.

What you must be able to show

HIPAA is a written-record regime. The Rule asks for policies and procedures in writing and for a written record of any action, activity or assessment it requires. You keep that documentation for six years from the date it was created or the date it was last in effect, whichever is later, so a policy that was replaced stays on file for six years from the day it stopped applying. You make it available to the people who carry out the procedures, and you review and update it. HIPAA Documentation & Evidence Checklist lists 30 records, with the paragraph behind each and a note of whether the Rule says it in writing, HHS guidance says to document it, or the item is the pack’s own practice.

HITECH also asks HHS, when it sets fines or decides how long an audit will be, to consider whether you can show that you have had recognised security practices in place for at least the previous 12 months. Having them is your choice. Being able to show them is the point. HIPAA Security Rule Readiness Self-Assessment has an item for this, in its area “beyond the minimum”.

What the pack does

The pack turns the Rule into things you can do and keep: ten documents.

HIPAA Applicability Assessment and HIPAA Security Rule Readiness Self-Assessment are also free online tools, “Does HIPAA apply to us?” and “How ready are we for HIPAA?”, on the Tools page. The spreadsheets hold the same method.

The order to work in

The document numbers are not the order of use.

Start with the role. If the answer is “neither”, most of the rest does not apply to you by your role, and you have saved yourself the work.

The six decisions leaders must make

Security can prepare all of this, and cannot decide all of it. HIPAA Management Briefing Deck is a short deck for your leaders. It lists these six decisions, each with a named decider, and puts six asks: 5 asks that rest on HD-01, HD-02, HD-03, HD-04, HD-06 and one for the funding of the Priority 1 gaps, which is decided by whoever holds the budget. HD-05 applies only to a hybrid entity, so the deck does not ask it of every reader. Nothing here changes the decision rights of the incident pack (P09).

The readiness check

HIPAA Security Rule Readiness Self-Assessment rates 36 items in ten areas (role and scope, governance, risk analysis and management, workforce and operations, business associates, physical safeguards, technical safeguards, documentation, breach readiness, beyond the minimum). Each item gets one of four levels, Not started, Planned, In place, Operating, or Not applicable with a reason. 31 of the 36 items are blocking: they rest on a standard or a required specification, or on the assessment and record the Rule requires for addressable ones.

Not ready: at least one blocking item is below In place (a blocking gap). Ready, with actions: no blocking gap, but some items are below Operating. Ready: every item is Operating, or does not apply with the reason recorded; Not applicable can be chosen only on SC-02, OR-04 and BR-03, which are written for one role, and on any other item it counts as no answer. Incomplete: some item has no answer. The result is about your records against these items. It is not a finding about the law and it is never a score. “Ready” means every item is recorded as Operating: it does not mean HIPAA ready, and an item marked Not applicable is left out of the result, so confirm each one with counsel.

There is no score and no percentage. The result is a word, plus counts and the names of the blocking gaps. Readiness describes your records against the pack’s items today. It is not a finding that you comply with the law, and nothing in this pack says you do. The tracker (HIPAA Gap & Remediation Tracker) sets due dates for Priority 1, Priority 2, Priority 3 gaps. They are the pack’s defaults and not the Rule’s. Repeat the check every [[6]] months, after a blocking gap is closed, and after a trigger.

How it runs in practice (EXAMPLE)

Take Acme Corp (EXAMPLE), a US software-as-a-service provider with about 250 staff, whose hosted patient-messaging and appointment service is used by about 60 clinics and small hospital groups. It provides a hosted service to clinics and handles their patients’ protected health information on their behalf, so it is a business associate. It is not a health plan, a clearinghouse or a health care provider. Its customers’ contracts, and not the pack, set what it reports to them and by when. Every value here is made up.

Max Okafor (EXAMPLE), Head of Information Security, the security official, is named in writing. The chief technology officer is the executive sponsor. The risk analysis was signed on 12 March 2026, and the last evaluation was on 20 November 2025.

• The role. The answers to the role questions give business associate. The cloud hosting provider and the support ticketing tool are its subcontractors, so they are business associates as well.
• The risk analysis. It rated eight risks on the P05 scale: one Critical, four High, two Medium and one Low. The highest (ER-07) is that the support ticketing tool, which can quote patient details, has no signed agreement yet. The fix is to sign the agreement before further use, or to stop using the tool for tickets that quote patient details.
• The agreements. The review of three agreements against the terms in Business Associate Agreement Security Terms found the hosting agreement missing two terms (its incident clause names breaches but not other security incidents, and sets no time), the ticketing tool with no agreement at all, and a customer clinic’s agreement with nothing missing.
• The readiness check. Of 36 items, three do not apply and 33 were rated. In all, 19 items are below Operating. The result is Not ready, because three blocking items are below In place: “information system activity is reviewed regularly”, “the agreements’ security terms were checked”, “every addressable specification has a decision on record”. Each is Priority 1 on the tracker, with an owner and a due date, and all three go to the executive sponsor at once.
• Three events. Three made-up events show the breach steps. A support export sent to the wrong customer ends as: breach of unsecured PHI: notify under P09 RD-17 to RD-20, and as a business associate the firm tells the covered entity. A support engineer opens a record while troubleshooting ends as: excluded: one of the three exclusions applies, with the facts that support the exclusion on record. A lost laptop with full-disk encryption ends as: not a breach of unsecured PHI: the PHI was secured. It is still a security incident, and it is documented with its outcome.

Read the example as that firm’s own record. It does not say that the firm, or any document in the pack, meets any requirement of the Rules.

Common mistakes

• Treating an addressable specification as optional and writing nothing down.
• Counting a signed agreement as the reason an organisation is a business associate, or its absence as the reason it is not.
• Doing a risk analysis of the main application only, and leaving out email, exports, backups, laptops and suppliers.
• A risk analysis that was done once and not repeated when the environment changed.
• Calling an incident ‘not a breach’ without a written record of why: an exclusion, secured PHI, or the four-factor assessment.
• Keeping a policy only until it is replaced, and losing the old version before six years after it last applied.
• Sharing patient information with a supplier before the agreement is signed.
• Saying ‘we are HIPAA compliant’ or ‘certified’. No certificate of compliance exists in the Rules, HHS does not recognise private certifications, and a customer should be given the facts instead.

Not covered here

• The Privacy Rule, beyond a few pointers. The pack points to minimum necessary, business associate contracts, privacy official, privacy safeguards, privacy policies and documentation. It does not cover notices of privacy practices, patients’ rights to see or correct their records, or the other Privacy Rule duties of a covered entity. Your privacy lead and counsel do.
• 42 CFR Part 2, the separate rules on substance use disorder treatment records. Since 16 February 2026 a Part 2 program must notify of breaches of those records in the same way HIPAA requires for protected health information; ask counsel if you hold such records.
• State health privacy and breach laws, which may be stricter, apply to other holders of health information, and carry their own deadlines.
• Other frameworks. The pack does not say that a safeguard under another framework or standard meets a requirement of the Rules, and holds no table that does.
• Paper records. The Security Rule covers electronic patient information only.
• The text of the proposed rule. See below.

What is proposed to change

In January 2025 HHS published a proposal to change the Security Rule: “HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information”, 90 FR 898. It is a proposal only. Comments closed on 7 March 2025. When this guide was written we found no final rule, and so the pack is written to the current text and applies none of the proposal. Counsel confirms its status before anything is relied on. HIPAA Security Rule Readiness Self-Assessment has an item to watch it, and HIPAA Management Briefing Deck says the same to leaders.

How it fits with the other packs

This pack does not replace any of them. It cites them by ID and leaves them unchanged.

Limits

• Not legal advice. This document helps a security team see what the HIPAA Security Rule and the breach notification rules ask of an organisation like yours, and what it could show. It is not legal advice. It does not say that you are compliant with HIPAA or that you are certified, and the Rules provide no certificate of compliance. Whether HIPAA applies to your organisation, in which role, and what a breach or a contract requires are for counsel to confirm. The notification deadlines are in P09 (RD-17 to RD-20) and P18, and are not repeated here.
• No mapping. This pack does not say which document, record or practice meets a requirement of the HIPAA Rules. Each reference says what its source asks and which CISO Times document helps with that work. Using a document does not by itself show that a requirement is met.
• The intervals are defaults. The review intervals and the gap priority days are the pack’s own. The Rule sets none of them. Only the six-year retention is the Rule’s.
• The files are yours. Every file in the pack stays on your own systems. Nothing you enter in them goes back to the CISO Times.
• The example is not a real firm. Acme Corp (EXAMPLE) is made up and marked EXAMPLE, and so is every value in it.

Sources and references

The pack reads 45 CFR Parts 160 and 164 as the eCFR prints them (current to 6 October 2026); HITECH Act provisions at 42 U.S.C. 17931, 17934 and 17941; HHS Office for Civil Rights guidance on risk analysis, business associates and unsecured protected health information; NIST SP 800-66 Rev. 2 (informative); NIST CSF 2.0; ISO/IEC 27001:2022 incl. Amd 1:2024 (by number and title only); as published and read on 18 October 2026.

• HIPAA, 45 CFR Parts 160 and 164: 160.102 and 160.103 (who the Rules apply to), 164.306 (the general rules of the Security Rule) and 164.402 (what a breach is). HITECH Act, 42 U.S.C. 17931 (the Security Rule’s application to business associates). HHS, Guidance on Risk Analysis. The proposed rule at 90 FR 898 is named as a proposal.
• NIST CSF 2.0: GV.OC-03.
• ISO/IEC 27001:2022: Clause 4.1, Understanding the organization and its context. By number and title only. ISO/IEC 27001 references name the clause or control this document relates to, by number and title only. No text of the standard is reproduced. A reference does not say that meeting a clause or control meets any requirement of the HIPAA Rules, or that your organisation holds a certificate.

A reference says what its source asks, and which CISO Times document helps with that work. It does not say that a document from this pack meets a requirement, and it does not say that an organisation is compliant or certified. The Rules provide no certificate of compliance for an organisation to hold.