HealthcarePrivacyUSA

HIPAA Security

Keep ePHI safeguards connected to accountable work

Organise security risk reviews, policy tasks and evidence for the systems that handle electronic protected health information.

Full title
Security Standards for the Protection of Electronic Protected Health Information, 45 CFR Part 160 and Part 164, Subparts A and C
Issued by
US Department of Health and Human Services. Enforced by the HHS Office for Civil Rights (OCR).
Current version
Final rule of February 2003, as amended by the 2013 Omnibus Rule. A January 2025 proposal to update it had not been finalised as of October 2026.
Applies to
Health plans, health care clearinghouses, health care providers that conduct standard electronic transactions, and their business associates
Nature
Binding US federal regulation. There is no official HIPAA certification.
Structure
General rules, then administrative, physical and technical safeguards, organisational requirements, and policies and documentation

Overview

What the Security Rule requires

The HIPAA Security Rule sets national standards for protecting electronic protected health information, or ePHI. A regulated entity must ensure the confidentiality, integrity and availability of all ePHI it creates, receives, maintains or transmits, protect against reasonably anticipated threats and impermissible uses or disclosures, and ensure that its workforce complies. The rule covers electronic information only. Paper and oral information falls under the Privacy Rule.

The rule is deliberately flexible and technology neutral. Each entity chooses measures that reasonably and appropriately implement the standards, taking into account its size, complexity and capabilities, its technical infrastructure, the cost of security measures, and the probability and criticality of potential risks to ePHI. That is why the risk analysis sits at the centre of the rule: it is how an entity shows that its choices are reasonable.

Every standard must be met. Some implementation specifications are required. Others are addressable, which does not mean optional: the entity must implement an addressable specification if it is reasonable and appropriate, or document why it is not and implement an equivalent alternative measure where that is reasonable and appropriate. Policies, procedures and records of required actions and assessments must be kept in writing for six years.

In January 2025 HHS published a notice of proposed rulemaking to update the Security Rule. Among other things it proposes removing the distinction between required and addressable specifications and making specific measures, such as encryption and multi-factor authentication, generally mandatory with limited exceptions. As of October 2026 it remained a proposal, and HHS’s regulatory agenda had moved its target date for a final rule more than once. The rule described on this page is the one in force.

Who it applies to

The Security Rule applies to covered entities and business associates that handle ePHI:

  • Health plans, including health insurers, HMOs and many employer group health plans
  • Health care clearinghouses
  • Health care providers that transmit health information electronically in connection with a HIPAA standard transaction
  • Business associates that create, receive, maintain or transmit ePHI on behalf of a covered entity, such as cloud, IT, billing and analytics providers
  • Subcontractors of business associates that handle ePHI
  • Indian technology, BPO and IT services firms that handle ePHI for US healthcare clients as business associates or subcontractors

The HITECH Act made business associates directly liable for Security Rule compliance. The Security Rule is one part of HIPAA. The Privacy Rule and the Breach Notification Rule set further obligations. For a broader assurance programme many healthcare organisations also use HITRUST or NIST CSF 2.0.

Structure

How the rule is organised

Subpart C of Part 164 runs from general rules to documentation. (R) marks a required implementation specification and (A) an addressable one. Standards without listed specifications must be met as written.

164.302 to 164.306

Applicability, definitions and general rules

Applicability (164.302)
Covered entities and business associates must comply with the Subpart C standards for ePHI.
Definitions (164.304)
Terms such as administrative, physical and technical safeguards, security incident, access, availability, confidentiality and integrity.
General requirements and flexibility (164.306)
Protect the confidentiality, integrity and availability of ePHI. Choose measures based on size, complexity, infrastructure, cost and risk. Meet every standard, handle addressable specifications as the rule sets out, and review and modify measures as needed.
164.308

Administrative safeguards: managing security

Security management process
Risk analysis (R), risk management (R), sanction policy (R) and information system activity review (R).
Assigned security responsibility
Identify the security official responsible for developing and implementing the security policies and procedures.
Workforce security
Authorisation and/or supervision (A), workforce clearance procedure (A) and termination procedures (A).
Information access management
Isolating health care clearinghouse functions (R), access authorisation (A), and access establishment and modification (A).
Security awareness and training
Security reminders (A), protection from malicious software (A), log-in monitoring (A) and password management (A).
164.308

Administrative safeguards: incidents, continuity and evaluation

Security incident procedures
Response and reporting (R): identify and respond to suspected or known incidents, mitigate harmful effects where practicable, and document incidents and outcomes.
Contingency plan
Data backup plan (R), disaster recovery plan (R), emergency mode operation plan (R), testing and revision procedures (A), and applications and data criticality analysis (A).
Evaluation
Periodic technical and non-technical evaluation of how well security policies and procedures meet the rule, including in response to environmental or operational changes.
Business associate contracts and other arrangements
Written contract or other arrangement (R) giving satisfactory assurances before a business associate handles ePHI.
164.310

Physical safeguards

Facility access controls
Contingency operations (A), facility security plan (A), access control and validation procedures (A), and maintenance records (A).
Workstation use
Policies on the functions performed on workstations and the physical attributes of their surroundings.
Workstation security
Physical safeguards that restrict access to workstations that access ePHI to authorised users.
Device and media controls
Disposal (R), media re-use (R), accountability (A), and data backup and storage (A).
164.312

Technical safeguards

Access control
Unique user identification (R), emergency access procedure (R), automatic logoff (A), and encryption and decryption (A).
Audit controls
Hardware, software or procedural mechanisms that record and examine activity in systems containing ePHI.
Integrity
Protect ePHI from improper alteration or destruction, including a mechanism to authenticate ePHI (A).
Person or entity authentication
Verify that a person or entity seeking access to ePHI is the one claimed.
Transmission security
Guard against unauthorised access to ePHI sent over electronic networks, through integrity controls (A) and encryption (A).
164.314

Organisational requirements

Business associate contracts
Contracts require the business associate to comply with Subpart C, to make its subcontractors agree to the same, and to report security incidents, including breaches of unsecured PHI, to the covered entity.
Subcontractors
The same requirements apply between a business associate and its subcontractors.
Group health plans
Plan documents require the plan sponsor to safeguard ePHI, support adequate separation, ensure its agents protect the information and report security incidents.
164.316

Policies, procedures and documentation

Policies and procedures
Reasonable and appropriate policies and procedures to comply with the standards. They may be changed at any time, provided changes are documented and implemented.
Documentation
Policies kept in written form, which may be electronic, and a written record of any action, activity or assessment the rule requires.
Retention, availability and updates
Keep documentation for six years from creation or the date it was last in effect, whichever is later. Make it available to those responsible for implementing it, and review and update it periodically.
Related rules

Breach notification and enforcement

Breach Notification Rule (164.400 to 164.414)
After a breach of unsecured PHI, notify affected individuals without unreasonable delay and no later than 60 days after discovery. Breaches affecting more than 500 residents of a state or jurisdiction also require media notice. Breaches affecting 500 or more individuals are reported to HHS within the same 60 days, smaller ones in an annual log.
Business associate notice
A business associate notifies the covered entity of a breach without unreasonable delay and no later than 60 days after discovery.
Civil money penalties (Part 160)
OCR can impose penalties in four tiers of culpability, from violations the entity did not know about to willful neglect not corrected within 30 days. The amounts are adjusted for inflation each year.

Implementation roadmap

How to implement it, step by step

A practical sequence for building and keeping a Security Rule programme.

  1. 1

    Confirm your role and find the ePHI

    Establish whether you are a covered entity, a business associate or a subcontractor. Identify every system, location, device and vendor that creates, receives, maintains or transmits ePHI.

    OutputsRole determinationePHI inventory and data flows
  2. 2

    Appoint the security official

    Name the person responsible for security policies and procedures, and set how they report to leadership.

    OutputsSecurity official appointment
  3. 3

    Carry out the risk analysis

    Assess threats and vulnerabilities to ePHI across the whole environment, rate likelihood and impact, and record current safeguards. This is the foundation OCR looks for first.

    OutputsRisk analysisRisk ratings
  4. 4

    Decide and document each specification

    Implement every required specification. For each addressable one, record whether it is reasonable and appropriate, and if not, why, and what equivalent measure is used instead.

    OutputsSpecification decisionsRisk management plan
  5. 5

    Write policies and train the workforce

    Approve policies and procedures across the administrative, physical and technical safeguards, apply a sanction policy, and run security awareness training with reminders.

    OutputsApproved policiesTraining records
  6. 6

    Put business associate agreements in place

    Sign agreements that include the Security Rule terms with every business associate, and make sure business associates flow them down to subcontractors.

    OutputsBAA registerSigned agreements
  7. 7

    Prepare for incidents and contingencies

    Set up incident procedures, backup, disaster recovery and emergency mode plans, and a breach assessment and notification process that meets the 60-day limits.

    OutputsIncident proceduresContingency plansBreach procedure
  8. 8

    Review, evaluate and keep records

    Review system activity, repeat the risk analysis and the evaluation when operations or technology change, and keep every record for six years.

    OutputsEvaluation reportsSix-year document archive

Audit and evidence guide

What auditors look for, and the evidence to keep

There is no HIPAA certification. Compliance is tested when OCR investigates a complaint or a reported breach, or carries out a compliance review or audit. OCR asks for documented evidence, starting with the risk analysis and risk management.

What reviewers look for

  • An accurate and thorough risk analysis covering all ePHI, kept current
  • Risk management showing how identified risks were reduced to a reasonable and appropriate level
  • Documented decisions for every addressable specification
  • Information system activity reviews of logs and access reports
  • Access controls, unique user IDs, and timely removal of access when staff leave
  • Encryption decisions for ePHI at rest and in transmission
  • Business associate agreements in place before ePHI was shared
  • Contingency plans, backups and tests of restoration
  • Security incident records and breach risk assessments
  • Written policies, training records and six-year retention of documentation

Key timelines

Documentation retention6 years
Notice to affected individuals after a breachWithin 60 days of discovery
Notice to HHS, 500 or more individualsWithin 60 days of discovery
Notice to HHS, fewer than 500 individuals60 days after year end
Business associate notice to covered entityWithin 60 days of discovery
Risk analysis and evaluationPeriodically and on change

Evidence to keep, by area

Examples to guide your evidence library. Your auditor or regulator decides what is sufficient.

Risk

  • Risk analysis
  • Risk management plan
  • Addressable specification decisions

Governance

  • Security official appointment
  • Approved policies and procedures
  • Sanction policy and records

Workforce

  • Security awareness training
  • Joiner and leaver access records
  • Workforce clearance records

Technical

  • Access control and unique IDs
  • Audit logs and activity reviews
  • Encryption configuration
  • Authentication settings

Physical

  • Facility security plan
  • Workstation policies
  • Media disposal and re-use records

Continuity and incidents

  • Backup and restore tests
  • Disaster recovery and emergency mode plans
  • Incident log
  • Breach risk assessments and notices

Business associates

  • BAA register
  • Signed agreements
  • Subcontractor flow-down

Areas that often need attention

  • No risk analysis, or one that covers only part of the environment
  • Risk analysis done once and never updated
  • Addressable specifications treated as optional, with no documented decision
  • Logs collected but never reviewed
  • Missing business associate agreements
  • Backups not tested for restoration
  • Policies not reviewed or not retained for six years
  • Breach decisions made without a documented risk assessment

How Netra helps

Where each part of the work lives in Netra

Netra loads the Security Rule as requirements, tasks and policies, so every standard and specification has an owner, a due date and evidence behind it.

Every standard and specification owned

Task Engine

Requirements arrive as tasks with owners and due dates. Recurring tasks cover activity reviews, access reviews, training and contingency tests so evidence stays current.

Status for each safeguard

Compliance Centre

Status is derived from completed tasks and evidence, never typed in. Work done for HIPAA also counts towards other frameworks where the same control applies.

Risk analysis and risk management

Risk Manager

A risk register with inherent and residual heatmaps. Risks come down as the linked tasks are completed.

Written policies and six-year records

Policy Hub

A policy library generated at onboarding, with a policy score that rises as the work behind each policy is done.

Business associates and vendors

Third-Party Risk

Find vendors from what Accounts and Purchase pay, assess them through a vendor portal and record each decision with a rating.

Knowing where ePHI lives

Asset Management

Assets linked to tasks, so teams know which systems a safeguard covers and which evidence applies.

Evaluations and OCR requests

Audit Centre

Run internal and regulatory audits end to end, with findings and corrective actions, using evidence already in a tamper-evident vault.

Missing evidence and procedures

Netra AI

Works from the organisation’s own records, suggests missing evidence and drafts SOPs. It never changes status on its own.

Netra organises work, evidence and reviews. It does not by itself establish HIPAA compliance, there is no HIPAA certification it can confer, and it is not a legal adviser or a breach reporting channel to HHS. Use synthetic or redacted data, never patient records, when evaluating Netra.

Common questions

More questions about Netra

Related frameworks

View all frameworks
Healthcare

HITRUST

Coordinate the work behind HITRUST readiness

Security

ISO 27001:2022 (Security Controls)

Make security controls visible through completed work

Privacy

GDPR

Make privacy accountability easier to demonstrate

See HIPAA Security in Netra

See how Netra connects your framework requirements with tasks, evidence and audit follow-up.