Which HIPAA specifications are addressable, and what you must do about them
A customer questionnaire or an OCR request asks how you handled the addressable specifications in your Security Rule program, and the honest answer depends on documentation you may not have. The Security Rule contains 36 implementation specifications, split into 14 required and 22 addressable. An addressable specification is not optional. For each one, you must assess whether it is reasonable and appropriate for your environment. If it is, you implement it. If it is not, you document why, and you implement an equivalent alternative measure where that is reasonable and appropriate, as set out in 45 CFR 164.306(d).
The three outcomes are the core of the decision: adopt the specification, adopt an alternative that achieves the standard's purpose, or document why neither is reasonable and appropriate. The answer differs by organization because your risk analysis drives each choice. The same specification, such as encryption of data at rest, can be required in practice for one entity and handled by a documented alternative for another, depending on the threats and data flows the analysis finds. Confirm with your security official that each decision traces back to a specific risk finding, not to cost or convenience alone.
Build a decision record for every addressable specification. For each one, capture the risk analysis finding it relates to, the assessment, the decision, the implemented measure or alternative, the owner, and the review date. Keep these records as written documentation under 45 CFR 164.316(b)(1), which requires a written record of required assessments and actions, retained for six years. Ask your auditor or consultant to test a sample of these decisions against your actual systems, because an entry that says a control is in place is weak evidence unless the configuration or log shows it.
The three choices the rule allows for an addressable specification
This table compares the three paths the Security Rule allows when an addressable implementation specification applies to your environment. Read each row as a decision: when the path fits, what record must exist, and where weak documentation usually causes an assessor to challenge the choice.
| Path | When it fits | Record that must exist | Main risk if documentation is weak |
|---|---|---|---|
| Implement as written | The risk analysis finds the specification reasonable and appropriate for your systems, data and threats, such as encryption of ePHI on a laptop that leaves the office. | Evidence the control is in place and operating, linked to the risk analysis finding that drove the decision and to the written policy covering it. | The control exists on paper but not in practice, so the assessor finds gaps between the policy and the systems actually running. |
| Implement an equivalent alternative measure | The specification as written is not a good fit, but a different measure achieves the purpose of the standard, such as compensating controls for a legacy system that cannot yet encrypt data at rest. | A written explanation of why the specification is not reasonable and appropriate, a description of the alternative, the reasoning that it meets the standard's purpose, and a dated review trigger. | The alternative cannot be shown to meet the standard's purpose, so the assessor treats the control as missing rather than as an accepted substitute. |
| Document why neither applies | The specification is not reasonable and appropriate and no reasonable alternative exists, so the entity accepts a residual gap that the risk management plan must address. | A documented rationale tied to the risk analysis, approval by the responsible decision maker, and a risk management plan entry that states how the residual risk is monitored and reduced. | Without a clear rationale and sign-off, the omission reads as an unassessed gap, which is the most common reason OCR investigators question addressable decisions. |
Why OCR treats addressable as a duty to decide, not a way to skip
The addressable label gives an entity flexibility in how a safeguard is met, not in whether it is considered. HHS states that the designation does not make an implementation specification optional. For each addressable specification, the entity must either adopt it where it is reasonable and appropriate, or adopt an alternative measure that achieves the purpose of the standard and document why the specification itself was not reasonable and appropriate. Both outcomes require a deliberate decision. Doing nothing, or assuming the specification is 'not needed' because it is labeled addressable, is not one of the two options. Under 45 CFR 164.306(d), the entity must make that assessment for every addressable specification, and the eCFR text of Subpart C is the place to confirm the exact wording before you build a decision template around it.
The risk analysis is the input that drives the decision. OCR's guidance ties outcomes on addressable specifications to what the analysis finds, such as whether personnel should be screened, what data should be backed up and how, whether encryption is warranted, what data needs authentication, and how transmissions should be protected. In practice, a security official should be able to trace each decision back to a documented threat and the risk level assigned to it. An investigator reviewing a decision typically tests three things: whether the assessment actually took place, whether it is current relative to the systems and data in use, and whether the alternative measure really achieves the standard's purpose. A written alternative that does not address the risk it was meant to cover fails the third test even if it looks complete on paper. Confirm your own update triggers for the analysis with your compliance lead, since the rule does not set a fixed interval in the text you are relying on.
How to make and record an addressable decision step by step
This sequence turns each addressable implementation specification into a documented decision that traces from the risk analysis to a tested measure or a reasoned exclusion. The result is a record an OCR investigator can follow from start to finish.
Inventory the addressable specifications in scope
The compliance lead lists every addressable implementation specification that applies to the systems, workforce and data flows in scope, drawing on Appendix A to Subpart C of Part 164 for the full set. Each specification gets its own line, tagged with the standard it belongs to and the systems it touches. The output is a scoped register that names what is in play and what is out of scope, with the scope reason written beside each exclusion. The step is done when the security official signs off that no addressable specification for in-scope systems is missing from the register.
Link each specification to risk analysis findings
The security official matches each register entry to the findings in the current risk analysis, including the threats, vulnerabilities and likelihood and impact ratings that apply to the system it covers. For example, if the analysis rates unauthorized access to a backup server as high, the backup specification is tied to that finding. Entries with no matching finding are flagged for review rather than dropped. The output is a register where every addressable specification points to at least one finding or to a documented statement that no finding applies. The step is done when no entry is left without a reference.
Decide whether the specification is reasonable and appropriate
For each linked entry, the compliance lead and the system owner assess whether implementing the specification as written is reasonable and appropriate, given the risk, the entity's size and capabilities, the cost of the measure and the existing safeguards. OCR's guidance names encryption, backup method, personnel screening and transmission protection as typical decisions of this kind. The output is a recorded yes or no for each entry, with a short reason. The step is done when every addressable entry has one of the three outcomes below assigned, and the reasoning is in plain language a reviewer can follow.
Choose implement, alternative or documented exclusion
The rule allows three paths. If the specification is reasonable and appropriate, the entity implements it. If it is not, the entity implements an equivalent alternative measure that it judges reasonable and appropriate, and documents why the specification itself did not fit. In the third case, the entity documents why neither the specification nor an alternative is needed for the standard's purpose, which HHS treats as a narrow outcome. The output is one chosen path per entry, with the chosen alternative named where it applies. The step is done when no entry is left as a silent omission.
Implement and test the chosen measure
The system owner or implementation partner builds the chosen measure, such as enabling encryption at rest for an identified data store or configuring a documented alternative such as access restriction in place of encryption. The security official or an independent tester then checks that the measure works as described, using configuration exports, test records and sample evidence. Where a testing partner is involved, the scope of the test and who performed it should be written down. The output is a test record showing the measure was in place and functioning on a stated date. The step is done when the record can be produced for each implemented entry.
Record the decision, rationale and date
The compliance lead writes each decision into the policy and procedure set, linking it to the risk analysis finding, the chosen path, the rationale, the test evidence and the date of decision. Under 45 CFR 164.316(b)(1), policies, procedures and required written records must be kept in writing, which may be electronic, so the record should live in a controlled repository with version history. The output is a decision record for every addressable specification. The step is done when a reviewer who did not take part can read one entry and reconstruct why the entity acted as it did.
Schedule review when the risk analysis changes
The security official sets review triggers tied to the risk analysis, such as a new system going live, a material change in data flows, a new vendor handling ePHI, or a security incident that reveals a gap. Each decision record carries its next review point and the name of the owner. The output is a review calendar and a change log that connects every revision of a decision to the risk analysis update that prompted it. The step is done when a fresh risk analysis can be checked against the register and any decision that no longer fits is reopened.
How the risk analysis changes the answer for each addressable specification
OCR's guidance ties each addressable decision to the risk analysis, not to preference or cost alone. The five cards below cover the examples OCR gives, and each one shows which finding points toward adoption and which finding supports a documented alternative.
Personnel screening
Screening decides whether workforce members who reach ePHI are checked before or after access is granted. A finding that a role can change or delete patient records, or that prior access was never verified, pushes the decision toward adoption. A finding that the role only sees de-identified or scheduling data, with access controls and supervision already limiting exposure, can support a documented alternative. Check that the decision names the roles it covers and who reviews it.
Data backup scope and method
Backup is addressable in the sense that the entity decides what ePHI is copied, how often, and where copies are kept. A finding that a ransomware event could halt clinical systems for a long period pushes the decision toward a backup that covers those systems. A finding that a data set is replicated elsewhere or can be rebuilt from source records can support a narrower, documented method. Confirm that the chosen method has been tested by restoring data.
Encryption at rest and in transit
Encryption is the example most often cited, and HHS states it is addressable, not optional. A finding that ePHI sits on laptops, removable media or internet-facing systems without other strong protection pushes the decision toward adoption. A finding that the data stays on a segmented, access-controlled network with equivalent controls can support a documented alternative, but the record must explain why that alternative is equivalent. Ask who signed the decision and when it was last reviewed.
Authentication of ePHI
This specification asks whether the entity needs a way to confirm that ePHI has not been altered or destroyed improperly. A finding that records feed clinical decisions or billing and could be changed by an insider or an attacker pushes the decision toward adoption, through checksums, digital signatures or similar mechanisms. A finding that records are write-protected and changes are logged, with the logs reviewed, can support a documented alternative. Confirm the mechanism is named in the risk management plan.
Protection of transmissions
Transmission security covers ePHI sent over networks, including email, interfaces, file transfers and remote access. A finding that ePHI crosses untrusted networks or reaches third parties in clear form pushes the decision toward adoption, usually through encrypted channels. A finding that traffic runs only on a closed internal network with monitored links can support a documented alternative. Map each transmission path in the risk analysis so that the decision covers every path, not only the main one.
Why encryption is the best-known addressable specification
Encryption is the clearest example of an addressable specification, and it is where many organizations first misread the rule. HHS's 2001 FAQ states that encryption is not mandatory under the Security Rule. It is addressable for access control under 164.312(a)(2)(iv) and for transmission security under 164.312(e)(2)(ii). That means the entity must decide, for stored ePHI and for transmitted ePHI separately, whether encryption is reasonable and appropriate given its risk analysis. Neither decision is made once for the whole organization, and neither can be skipped by silence.
For stored ePHI, the three outcomes are straightforward. If the risk analysis finds encryption reasonable and appropriate, the entity implements it and records the configuration, key management and scope. If it does not, the entity documents why and implements an equivalent alternative that is reasonable and appropriate, such as strict physical controls on drives and backup media combined with access restrictions. For transmitted ePHI, the same three paths apply. The documented alternative must show how it protects the data at the level the risk analysis calls for, not simply that encryption was inconvenient. Confirm with your security official which systems hold stored ePHI and which transmission paths carry it before you record any decision.
The 2025 proposal would remove the addressable category and make encryption required for ePHI at rest and in transit, with limited exceptions. An alternative documented under today's rule may therefore be reviewed against a stricter standard later. Entities that choose an alternative now should record the specific risk analysis findings behind it, the compensating controls and the date of the next review, so that the file is useful under either rule. Check the current status of the proposal with the Unified Agenda entry before you plan changes.
What belongs in the file an investigator will ask for
An addressable decision is only defensible if the file shows what was decided, why, who approved it and that the measure is running. The cards below cover the parts an investigator typically asks for, and each one must already exist when the request arrives.
Written policy governing the decision
Start with the written policy or procedure that sets how the organization decides on addressable specifications, who makes the call and which inputs it uses. Under 45 CFR 164.316(b)(1), Security Rule policies and procedures must be kept in writing, and they may be electronic. Check that the policy names the risk analysis as the input for every addressable decision, so each individual decision points back to a documented rule.
Written record of the assessment and rationale
For each addressable specification, keep a written record of whether it is reasonable and appropriate, and if it is not, why not. The record should tie the reasoning to specific risks found in the risk analysis, such as the data stored, the threats and the compensating controls. A bare statement that a specification was not reasonable is weak evidence on its own.
Evidence the chosen measure is in operation
A documented decision means little if the measure is not running. Keep operating evidence for each adopted specification or equivalent alternative, such as configuration exports, access review records, encryption settings on storage and transmission paths, or training completion logs. Confirm that the evidence reflects the current environment, not the state at the time of the original decision.
Date and approver of each decision
Each decision should record the date it was made, the person or committee that approved it and the version of the risk analysis it relied on. Dated approvals show that the decision was made at a point in time and not reconstructed later. Store approvals in a system with an audit trail so the record can be shown without edits.
Review trigger tied to risk analysis updates
Set a review trigger for every addressable decision so it is revisited when the risk analysis changes, such as a new system, a new data flow, a vendor change or a security incident. The review trigger is what turns a one-time decision into a maintained one. Ask who owns the trigger and how it is logged, since a missing trigger is often the gap an investigator finds first.
Who owns the decision, who prepares the evidence, and who checks it
The covered entity or business associate owns every decision about an addressable implementation specification. The Security Rule places the obligation on the organization itself: it must assess whether a specification is reasonable and appropriate, decide whether to implement it, and where it does not, document why and choose an equivalent alternative measure if one is reasonable and appropriate. No vendor, consultant or auditor can take that decision over.
- Decision ownership: Leadership, usually through the security official, approves each determination and the reasoning behind it, including the risk analysis that supports it.
- Security official accountability: The designated security official is responsible for the Security Rule program, so the decision record should show that official reviewed and accepted each outcome.
- Risk analysis linkage: Each choice should trace back to a documented finding, such as where ePHI lives and how it moves, rather than to general preference.
- Review triggers: Changes to systems, vendors or threats should prompt a fresh look at earlier determinations.
- Internal capacity: Staff who will operate the chosen measures should understand them before they are written into policy.
Confirm that your named security official has signed off on the current determinations and that the file shows the date of each review.
An implementation partner such as DeployOpen prepares the systems that carry out the organization's decisions and assembles the evidence that shows they work. This work is delivered under a written, fixed scope. The partner does not decide whether an addressable specification is reasonable and appropriate, and it does not certify compliance with the Security Rule.
- Preparing systems: Configuring the self-hosted platforms that enforce the chosen measures, such as access controls, audit logging, backup and transmission settings, inside the client's own infrastructure.
- Configuring chosen measures: Implementing exactly what the organization decided, including any documented equivalent alternative, and recording the settings as they were applied.
- Assembling evidence: Collecting configuration exports, change records, test results and log samples that the organization can present to its own reviewers and to an assessor.
- Documentation support: Drafting procedures for the organization's review and approval, not publishing them as the organization's policy on its own authority.
- Scope boundaries: Recording what was built, when, and by whom, so the organization can see where its own decisions end and the partner's work begins.
Confirm in the written scope which decisions remain with your staff and which deliverables the partner will hand over, including the evidence format.
An independent assessor tests the compliance file and reports on what it finds. Depending on the engagement, that may be an external auditor, a firm conducting a third-party HIPAA assessment, or another qualified reviewer. The assessor's work can give the organization an outside view of its file, but it does not replace the organization's own decision, and HHS does not recognize private certifications as proof of compliance.
- Testing the file: Sampling the decision records, risk analysis, configurations and logs to check that they match what the organization says it does.
- Checking reasoning: Asking whether the stated basis for an addressable determination is consistent with the risk analysis and with the organization's actual environment.
- Issuing reports: Only the assessor issues a report or attestation, and its scope and limits should be stated in that report.
- Limits of assurance: A clean report does not prevent OCR from later finding a violation, so the organization keeps responsibility for ongoing decisions.
- Independence: The assessor should not design the controls it later tests.
Confirm the assessment scope in writing and ask whether the report will state its limitations and the period it covers.
Common questions about addressable HIPAA specifications
Does addressable mean we can skip a HIPAA control?
No. An addressable implementation specification is not optional. For each one, you must assess whether it is reasonable and appropriate for your environment. If it is, you implement it. If it is not, you document why and adopt an equivalent alternative measure, provided that alternative is reasonable and appropriate and achieves the purpose of the standard. Under 45 CFR 164.306(d), the decision itself is the requirement. Doing nothing and writing nothing down is the outcome OCR is least likely to accept. Your risk analysis is the record that supports whichever choice you make.
Do we need outside help to make addressable decisions?
The rule does not require outside help. The organization owns the decision, and the security official and leadership must be able to explain it. Outside help is usually a question of capacity and independence. A consultant or implementation partner can prepare the risk analysis inputs, map where ePHI lives, draft the decision records and test the chosen measures. Only an independent assessor can give a third-party view of whether your decisions hold up. Ask any partner to state in writing which parts they perform and which decisions remain yours.
How much documentation do addressable decisions take, and what drives it?
The effort depends mainly on how many specifications your risk analysis touches and how many systems hold ePHI. Each addressable decision needs a written record: the assessment, the conclusion, and, where you decline a specification, the reason and the alternative measure. 45 CFR 164.316(b)(1) requires written policies and a written record of required assessments, and those records must be kept for six years. Drivers include:
- Size and number of ePHI systems and data flows
- How many addressable specifications apply to each system
- How often the risk analysis changes after new systems or incidents
- Whether decisions are reused across similar systems or re-argued each time
Ask any quote to separate one-time analysis from recurring review.
Does a vendor's HIPAA certificate cover our addressable decisions?
No. HHS states that no Security Rule standard requires certification, and it does not endorse or recognize private certifications. A vendor certificate, seal or report can describe the vendor's own controls, but it cannot make your addressable choices for you. The decision about whether a specification is reasonable and appropriate depends on your risk analysis, your data flows and your environment. Ask the vendor for its documented decisions on the specifications that affect data you send them, such as encryption and audit logging, and for the evidence behind them.
How would the 2025 proposal change our existing addressable decisions?
The January 2025 proposal would remove the distinction between required and addressable implementation specifications and make all of them required, with specific, limited exceptions. If finalized, decisions that currently rest on an addressable designation would need to be revisited against the new requirements. The proposal is not final. The latest Unified Agenda entry lists it under Long-Term Actions, so current decisions still follow today's rule. Keep your existing records current, because they show your reasoning and will help you measure the gap if the rule changes. Confirm the current status on the Federal Register and reginfo.gov before you plan changes.
Can we make addressable decisions in-house?
Yes, many organizations do, provided they have people who understand the risk analysis, the technical controls and the documentation expectations. The organization must have a named security official who owns the decisions. In-house teams often need help with three areas: confirming the technical facts behind a decision, testing whether an alternative measure actually achieves the standard's purpose, and keeping records consistent over time. Consider the cost of staff time, the depth of technical review, and whether an independent check is worth having before an OCR audit or a customer assessment. Ask any partner for a written scope that lists each decision and each deliverable.
How DeployOpen prepares systems and evidence for your addressable decisions
DeployOpen works with your team to turn each addressable decision into a documented choice tied to your own risk analysis. We prepare the systems, configurations and records that show what you adopted, what you rejected and which equivalent measure you put in place, while your organization keeps ownership of every decision.
How we scope
- Written scope lists which implementation specifications and self-hosted platforms are in the engagement before work starts.
- We confirm with your security official which addressable specifications need a decision record and which systems hold the ePHI involved.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before any configuration begins.
How we build
- We configure encryption, access control, audit logging and backup settings on open-source platforms inside your own infrastructure.
- Where a specification is not adopted, we prepare the equivalent alternative measure you select and test that it operates as documented.
- We test each configuration against the decision recorded in your risk analysis and note any gaps for your team to resolve.
How we hand over
- You receive decision records that state the specification, the risk analysis finding, the choice made and the reason for it.
- Configuration baselines, test results and policy text are delivered in editable form for your own retention under the six-year documentation rule.
- Handover includes a walkthrough so your staff can explain each decision to an auditor, OCR investigator or customer.
How we support
- Ongoing support is available as a retainer for upgrades, configuration changes and periodic review of addressable decisions.
- We can re-check decision records when your risk analysis changes, a platform is upgraded or a new system holds ePHI.
- Independent auditors and assessors make any formal assessment conclusions, and DeployOpen prepares the systems and evidence they review.
