Category: Regulatory Framework

Required Specifications

Also known as: Required Implementation Specifications

Simply put

In the HIPAA Security Rule, 'required' implementation specifications are the specific steps a covered entity or business associate must put in place to satisfy a security standard, with no discretion to skip them. This is different from 'addressable' specifications, which allow some flexibility but are not optional. The evidence packet provided does not contain HIPAA-specific source material for this term, so the details below should be verified against the current text of the Security Rule.

Formal definition

Under the HIPAA Security Rule, each security standard is supported by implementation specifications that are classified as either 'required' or 'addressable.' A 'required' implementation specification must be implemented as stated by a regulated entity (covered entity or business associate) in order to comply with the associated administrative, physical, or technical safeguard standard; unlike 'addressable' specifications, it does not permit the entity to assess reasonableness and adopt an alternative or documented rationale for not implementing it. Note that 'addressable' does not mean optional. The Security Rule applies only to electronic protected health information (ePHI) and does not govern PHI in oral or paper form, which falls under the Privacy Rule. The evidence supplied for this entry addresses software requirements specifications in software engineering, a distinct concept unrelated to the HIPAA regulatory meaning; practitioners should confirm the precise classification and text of each implementation specification against the current Security Rule regulatory language, and be aware that HITECH, state law, or frameworks such as the HITRUST CSF may impose additional requirements.

Why it matters

In the HIPAA Security Rule, the classification of an implementation specification as 'required' removes any discretion: a covered entity or business associate must implement it as stated to satisfy the associated safeguard standard. Understanding which specifications are 'required' versus 'addressable' is central to building a defensible compliance program, because failing to implement a required specification is generally a straightforward gap, whereas mishandling an addressable one is a common and often misunderstood source of risk.

A frequent misconception is that 'addressable' means 'optional.' It does not. Addressable specifications still must be evaluated, and either implemented, satisfied through a reasonable and documented alternative, or documented as not reasonable and appropriate given the entity's circumstances. Confusing these categories can lead organizations to skip controls they were obligated to address. Required specifications, by contrast, leave no room for that analysis, they must be put in place.

Because the evidence packet supplied for this entry does not contain HIPAA-specific source material, it addresses software requirements specifications in software engineering, which is an entirely different concept, practitioners should not rely on this entry alone. The precise classification and wording of each implementation specification should be confirmed against the current text of the Security Rule, and organizations should remain aware that HITECH, state law, or frameworks such as the HITRUST CSF may impose additional requirements.

Who it's relevant to

Security Officers and Compliance Teams

Those responsible for a covered entity's or business associate's Security Rule program need to distinguish required from addressable specifications so they can correctly scope mandatory controls. Required specifications must be implemented as stated, with no discretion to skip them, making them a priority in any risk analysis and safeguard implementation effort.

Business Associates and Their Subcontractors

Because the Security Rule applies to regulated entities including business associates, organizations handling ePHI on behalf of covered entities are also subject to required implementation specifications. They should confirm which obligations flow to them through business associate agreements and against the current regulatory text.

Auditors and Assessors

Professionals evaluating a program's Security Rule posture must verify that required specifications are actually implemented, since these leave no room for a reasonableness assessment. They should also be careful not to treat addressable specifications as optional, and should confirm classifications against the current Security Rule and note where HITRUST CSF or state law may add requirements.

Inside Required Specifications

Required Implementation Specifications

Under the HIPAA Security Rule, these are implementation specifications that a covered entity or business associate must implement as stated, without discretion to omit them. They contrast with addressable specifications, which allow flexibility in how, but not whether, the underlying standard is met.

Relationship to Security Rule Standards

Required specifications sit beneath broader Security Rule standards and describe the specific actions needed to satisfy those standards. Each standard may contain required specifications, addressable specifications, or both.

Safeguard Categories

Required specifications appear across the three Security Rule safeguard categories: administrative, physical, and technical. The requirement applies only to electronic protected health information (ePHI), as the Security Rule governs ePHI rather than PHI in all forms.

Distinction from Addressable Specifications

For a required specification, the entity must implement it. For an addressable specification, the entity must assess whether it is reasonable and appropriate and, if not, document why and implement an equivalent alternative where reasonable. Addressable does not mean optional; the distinction concerns flexibility of implementation, not whether the safeguard can be skipped.

Common questions

Answers to the questions practitioners most commonly ask about Required Specifications.

Are required implementation specifications more mandatory than addressable ones?

Both required and addressable implementation specifications are obligations under the Security Rule; the distinction is not one of mandatory versus optional. For a required specification, a covered entity or business associate must implement it as stated. For an addressable specification, the entity must assess whether it is a reasonable and appropriate safeguard in its environment and then either implement it, implement an equivalent alternative measure, or document why it is not reasonable and appropriate. Addressable does not mean the safeguard can simply be ignored. Readers should confirm the current regulatory text, as the Security Rule governs only ePHI.

If we satisfy every required specification, does that mean we are compliant with the Security Rule?

No. Implementing the required specifications is only part of compliance. An entity must also appropriately address every addressable specification and meet the broader general requirements of the Security Rule, including conducting a risk analysis and applying administrative, physical, and technical safeguards. Beyond the Security Rule, the Privacy Rule, Breach Notification Rule, and potentially the HITECH Act and state law may impose additional obligations. Satisfying required specifications alone does not by itself establish overall HIPAA compliance, and readers should verify against current guidance.

How should we document that we have met a required specification?

Generally, entities maintain written policies, procedures, and evidence showing how each required specification is implemented in practice. Because the Security Rule imposes documentation and retention obligations, keeping records that demonstrate implementation is typically advisable for both internal governance and any HHS OCR inquiry. Specific retention periods and documentation expectations should be confirmed against the current regulatory text.

Do required specifications apply to business associates as well as covered entities?

In most cases, yes. Business associates are directly subject to the Security Rule's requirements with respect to ePHI they create, receive, maintain, or transmit, and these obligations are also reflected in business associate agreements. Subcontractors that handle ePHI on behalf of a business associate are likewise subject to comparable obligations through the applicable agreements. Entities should confirm the precise scope of their obligations based on their defined relationships and current guidance.

Does implementing a required specification differ based on the size or complexity of our organization?

The Security Rule generally allows entities to take a flexible, scalable approach that considers factors such as size, complexity, technical infrastructure, and the costs of security measures. However, this flexibility applies to how a required specification is implemented, not to whether it is implemented. A required specification must still be put in place; the manner may reasonably reflect the entity's circumstances. Readers should review the current regulatory text for the flexibility factors.

How does achieving HITRUST CSF certification relate to meeting required specifications?

The HITRUST CSF is a private, certifiable control framework that can help an organization structure and demonstrate its security controls, and it may map to Security Rule requirements. However, HITRUST is a private organization and its certification is not a legal requirement, nor does certification by itself establish HIPAA compliance or prove that required specifications have been satisfied under the law. HIPAA compliance is enforced by HHS OCR against the regulatory text. Any mapping should be verified against the current HITRUST CSF version and current HIPAA guidance.

Common misconceptions

Required and addressable specifications differ in that addressable ones can simply be ignored.

Addressable specifications are not optional. They require the entity to evaluate whether the specification is reasonable and appropriate for its environment and, where it is not, to document that determination and adopt an equivalent alternative measure where reasonable. Required specifications, by contrast, must be implemented as written with no discretion to omit them.

Meeting all required specifications guarantees HIPAA compliance or prevents breaches.

Implementing required specifications is a necessary part of Security Rule compliance but does not by itself guarantee overall compliance and cannot be said to prevent all breaches. The Privacy Rule, Breach Notification Rule, and applicable state law or the HITECH Act may impose additional obligations, and no single measure guarantees compliance.

Required specifications apply to protected health information in every form.

Required specifications are part of the Security Rule, which governs only electronic protected health information (ePHI). PHI in oral or paper form falls under the Privacy Rule, which uses a different structure and does not use the required/addressable distinction.

Best practices

Inventory each Security Rule standard and identify which of its implementation specifications are required versus addressable, so that no required specification is inadvertently treated as discretionary.

Implement every required specification as stated, and maintain documentation demonstrating how each has been satisfied for ePHI across administrative, physical, and technical safeguards.

For addressable specifications, document the reasonableness assessment and any equivalent alternative measures adopted, since addressable does not mean optional and regulators generally expect a documented rationale.

Verify the current regulatory text of the Security Rule rather than relying on memory, as specific citations and specification wording should be confirmed against current guidance.

Assess whether state law or the HITECH Act imposes obligations beyond the required specifications, and address those separately from the HIPAA Security Rule analysis.

Avoid treating implementation of required specifications as a guarantee of compliance; pair it with ongoing risk analysis and coordinate with Privacy Rule and Breach Notification Rule obligations.