HITECH Act Guide: Breach Rules, Penalty Tiers and Recognised Security Practices

Most of what US healthcare security teams call "HIPAA enforcement" today, from breach notification clocks to business associate liability and the four penalty tiers, was written into law by the HITECH Act, not by the original 1996 statute. The Health Information Technology for Economic and Clinical Health Act was enacted as part of the American Recovery and Reinvestment Act of 2009 and signed on 17 February 2009. Its Subtitle D is the privacy and security part, and a 2021 amendment (Public Law 116-321) added the "recognised security practices" provision that lets HHS weigh a mature security programme when it sets fines and settles investigations. This guide explains what HITECH added on top of HIPAA, how the penalty tiers and annual caps work in practice, what counts as a recognised security practice and how to evidence it, and what the statute means for service accounts, API keys and AI agents that touch protected health information (PHI). It is for security, privacy and compliance leads at covered entities and business associates. The safeguards themselves are covered in the HIPAA Security Rule Guide and the notification process in the HIPAA Breach Notification Rule Guide; this page does not repeat them.

Status, checked 14 November 2026: HITECH Subtitle D is in force and is implemented mainly through the 2013 Omnibus Rule (effective 26 March 2013, compliance date 23 September 2013). Public Law 116-321 was approved on 5 January 2021. HHS's 2019 notice of enforcement discretion on annual penalty caps remains in effect until HHS issues further notice or completes rulemaking, and the dollar amounts are adjusted for inflation each year in 45 CFR part 102. The HHS Office for Civil Rights (OCR) asked for public input on recognised security practices in April 2022; check OCR's pages for any later guidance before relying on this summary.

Key takeaways

• HITECH is the enforcement layer of HIPAA: it created the federal breach notification duty, made business associates directly liable for the Security Rule, introduced the four culpability tiers and let state attorneys general sue.
• The real annual caps are lower than the regulation suggests: 45 CFR 160.404 sets a $1.5 million calendar-year cap for every tier, but since 2019 HHS applies caps of $25,000, $100,000, $250,000 and $1.5 million by tier, before inflation adjustment.
• Recognised security practices reduce outcomes, they do not create a safe harbour: HHS must consider whether NIST-based or 405(d) practices were in place for at least the previous 12 months, and may then mitigate fines, end an audit early or soften a resolution agreement.
• "In place" means fully implemented: OCR reads the 12-month test as practices actively and consistently used across the enterprise, so adoption dates and operating evidence matter more than policy documents.
• Machine identities sit inside the statute: a leaked API key or an over-privileged integration account that exposes unsecured PHI triggers the same 60-day clock as a lost laptop, and the burden of proof sits with the organisation.

What HITECH added to HIPAA

HIPAA (1996) authorised the Privacy and Security Rules. HITECH Subtitle D changed who is liable, what happens after a breach and how hard the regulator can hit. The table lists the provisions that matter most for security teams, with the US Code section where each now sits.

HITECH also funded the Medicare and Medicaid EHR Incentive Programs, established in 2011 and now the Promoting Interoperability Programs run by CMS. That is the reason so much clinical data became electronic in the first place, and it is the context for the statute's focus on electronic records.

Breach notification: what the statute itself requires

The regulation fills in the detail, but several points that drive incident response come straight from section 13402 and are worth knowing at statute level because they cannot be changed by guidance.

• Discovery: a breach is treated as discovered on the first day it is known, or by exercising reasonable diligence would have been known, to any employee or agent other than the person who committed it. Alerts that sat unread in a SIEM queue can start the clock.
• Deadline: notices go out "without unreasonable delay and in no case later than 60 calendar days after the discovery of a breach". Sixty days is a ceiling, not a target, and the organisation carries the burden of showing that any delay was reasonable.
• Business associates: must notify the covered entity and identify each affected individual. Contracts usually shorten this window; see the HIPAA Business Associate Agreements Guide.
• Thresholds: media notice when more than 500 residents of a state or jurisdiction are affected. HHS must be told of breaches affecting 500 or more individuals without unreasonable delay and within 60 calendar days of discovery; smaller breaches can be logged and reported within 60 days after the end of the calendar year.
• Public list: HHS publishes the covered entities involved in breaches of more than 500 individuals on its breach portal.
• Law enforcement delay: notification can be delayed where a law enforcement official states that it would impede a criminal investigation or damage national security.

Unsecured PHI and the encryption exit

The duty applies only to unsecured PHI, meaning PHI not rendered unusable, unreadable or indecipherable by a method HHS specifies. HHS guidance names two: encryption, where the key or decryption process has not also been compromised, and destruction. The guidance points to NIST SP 800-111 for data at rest, NIST SP 800-52 (TLS), SP 800-77 (IPsec VPNs) or SP 800-113 (SSL VPNs) for data in motion, and NIST SP 800-88 for media sanitisation. HHS also advises that decryption tools be kept apart from the data they protect.

The practical consequence for identity teams is direct. If an attacker uses a valid service account or a stolen storage access key, the data is decrypted for them by the platform and the encryption exit no longer applies. Encryption at rest protects against lost media, not against compromised credentials.

Penalty tiers and annual caps

HITECH replaced a flat $100 per violation regime with four tiers based on culpability, effective for violations on or after 18 February 2009. It also removed the old bar on penalties where the entity did not know of a violation (such cases now fall in the lowest tier) and kept a 30-day correction window that blocks penalties for anything except willful neglect.

The caps apply per identical provision per calendar year, so a single incident that breaches several Security Rule standards (risk analysis, access control, audit controls) can produce several capped amounts. All figures are adjusted for inflation each year; use the current table in 45 CFR 102.3 for any live calculation. Section 1176(c) as amended by HITECH also requires HHS to formally investigate where a preliminary review indicates possible willful neglect, and to impose a penalty where willful neglect is found.

State attorney general actions

State attorneys general can sue in federal district court on behalf of residents, for an injunction or damages. Statutory damages are up to $100 per violation, capped at $25,000 for all violations of an identical requirement in a calendar year, plus discretionary costs and attorney fees. The state must notify HHS first (or immediately after filing where prior notice is not feasible), and cannot sue over a violation while a federal action on it is pending. These HIPAA-based claims sit alongside state consumer protection and breach laws, which often carry larger remedies; see the Healthcare Cyber Regulation Map.

Recognised security practices (Public Law 116-321)

Section 13412 is the only part of HITECH that rewards security investment rather than punishing failure. When HHS decides fines, audit outcomes or the remedies in a resolution agreement for potential Security Rule violations, it "shall consider whether the covered entity or business associate has adequately demonstrated that it had, for not less than the previous 12 months, recognized security practices in place". Those practices may mitigate fines under section 1176, lead to the early, favourable termination of an audit under section 13411, and mitigate remedies in a resolution agreement.

What evidence to keep

OCR's April 2022 request for information asked how entities expect to show that practices are in place and used enterprise-wide over the 12 months. Until OCR publishes more, build evidence that answers those questions:

1. Adoption record: a board or executive decision naming the framework (for example NIST CSF 2.0 or the HICP practices for your organisation size) and the date it was adopted.
2. Scope statement: which entities, systems and business associates are in scope, so "enterprise-wide" can be shown rather than asserted.
3. Control operating evidence over time: monthly or quarterly records such as access review completions, MFA coverage reports, vulnerability remediation figures and log review tickets, retained for at least the last 12 months.
4. Assessments: internal or third-party assessments against the chosen framework with dated findings and remediation tracking.
5. Mapping: a crosswalk from the framework to Security Rule standards, so the investigator can see coverage of each one.

Where machine identities and AI agents fit

HITECH does not mention service accounts or AI agents, but the statute applies to them without modification because it is written around access to PHI, not around people.

• Business associate reach: SaaS platforms, analytics vendors and AI service providers that create, receive, maintain or transmit PHI are business associates, directly liable under section 13401. Their API keys, OAuth grants and integration accounts into your EHR are part of your attack surface and theirs.
• Discovery by any agent: the discovery rule counts knowledge held by any employee or agent. Secret scanning alerts, cloud audit findings and anomaly detections on non-human accounts are knowledge; triage them on a clock.
• Credential misuse defeats encryption: as above, a working key or token exposes decrypted PHI, so the encryption exit rarely helps in machine identity incidents. The Change Healthcare breach began with a stolen credential on a remote-access portal without MFA, and became the largest healthcare data breach reported in the US; see the Change Healthcare Breach 2024 analysis.
• Minimum necessary for agents: section 13405(b) ties disclosures to the minimum necessary. An AI agent with read access to whole patient tables when it needs one field is a minimum necessary problem as well as a security one. See the HIPAA Privacy Rule Guide.
• Recognised security practices cover NHI controls: NIST CSF 2.0 PR.AA-05 (access permissions managed and reviewed) and SP 800-53 AC-2 apply to service accounts and agent identities. Include them in the 12-month evidence, or the investigator will find the gap.

Framework mapping

Implementation steps

1. Confirm your status: record whether each legal entity is a covered entity, a business associate or both, and list every business associate and sub-business associate that touches PHI, including AI and analytics services.
2. Choose and date a recognised framework: adopt NIST CSF 2.0 or the 405(d) HICP practices formally now, because the 12-month clock only starts at real implementation.
3. Close the encryption and key separation gaps: inventory PHI stores, confirm encryption that meets the HHS guidance, and confirm keys are held separately from the data (a key management service with its own access policy, not keys in application configuration).
4. Bring non-human accounts into scope: inventory service accounts, API keys and agent identities with PHI access, assign owners, rotate long-lived secrets and apply least privilege.
5. Wire discovery to the clock: define which alerts count as potential breach discovery and route them to the privacy officer with a timestamp, so the 60-day calculation is defensible.
6. Rehearse notification: run a tabletop that includes a business associate breach and a leaked credential scenario, and check that the under-500 annual log process works.
7. Review and roll forward: each year refresh the penalty figures from 45 CFR 102.3, review OCR guidance on recognised security practices and update the evidence pack.

Detection and measurement

• Discovery-to-decision time: days from first alert to the breach risk assessment decision; aim well under 60.
• Encryption coverage: percentage of PHI stores and transfers meeting the HHS guidance, with key separation confirmed.
• NHI coverage: percentage of service accounts and API keys with PHI access that have a named owner and a rotation date in the last 12 months.
• Business associate assurance: percentage of business associates with a current agreement and a security attestation reviewed in the last year.
• Evidence continuity: number of months in the last 12 with complete control operating evidence for the chosen framework (target: 12).

Common failure patterns

• Treating 60 days as the deadline: the statute requires notice without unreasonable delay; waiting until day 59 with a finished investigation on day 20 is hard to defend.
• Adopting a framework after the incident: recognised security practices only count if in place for the previous 12 months, so a post-breach NIST CSF project mitigates nothing for that case.
• Policy without operation: OCR reads "in place" as fully implemented; a framework adoption memo with no operating evidence will not carry weight.
• Relying on encryption against credential theft: encryption at rest does not make PHI secured when the attacker holds a valid key, token or session.
• Forgetting business associates' machine access: vendor integration accounts and API keys that never expire are a common route into PHI, and the covered entity still has to notify.
• Quoting the $1.5 million cap for every tier: budgeting and board reporting should use the tiered caps HHS applies, adjusted for inflation.

Practitioner checklist

• Map each entity to covered entity or business associate status and list all business associates, including AI services.
• Adopt and date a recognised security framework (NIST CSF 2.0 or 405(d) HICP), signed by leadership.
• Keep 12 months of monthly control operating evidence and a framework to Security Rule crosswalk.
• Confirm PHI encryption against the HHS guidance and keep keys separate from the data.
• Inventory and own every service account, API key and agent identity with PHI access.
• Define breach discovery triggers and timestamp them for the 60-day calculation.
• Test the over-500 and under-500 notification paths, including state media notice.
• Refresh penalty figures from 45 CFR 102.3 each year for risk reporting.

Standards and references

• US Government Publishing Office: Public Law 116-321 (recognised security practices)
• HHS: HITECH Act Enforcement Interim Final Rule
• Cornell LII: 42 USC 17932, Notification in the case of breach
• Cornell LII: 42 USC 1320d-5, General penalty for failure to comply
• Cornell LII: 45 CFR 160.404, Amount of a civil money penalty
• Federal Register: Notification of Enforcement Discretion Regarding HIPAA Civil Money Penalties (2019)
• Federal Register: Considerations for Implementing the HITECH Act, as Amended (2022 RFI)
• HHS: Guidance to Render Unsecured PHI Unusable, Unreadable or Indecipherable

Related NHI Mgmt Group resources: HIPAA Security Rule Guide, HIPAA Breach Notification Rule Guide, Healthcare Cyber Regulation Map, HHS 405(d) HICP, HHS HIPAA Security Rule Update (2025 NPRM). This guide summarises the HITECH Act and related HHS rules and is not legal advice.