Does recognized security practices status reduce HIPAA penalties?
Recognized security practices status can lower the outcome of an OCR matter, but it does not lower the bar the Security Rule sets. Under Public Law 116-321, OCR must consider whether your organization can show that recognized security practices were in place for at least the previous 12 months when it decides fines, the length and extent of an audit, or remedies in a Security Rule resolution. The amendment does not reduce the Security Rule obligations themselves, and it does not let HHS increase penalties or audit scope because an entity lacked these practices. If your budget owner expects a fixed discount, that expectation is wrong. The effect is a weighing factor, and its weight depends on the facts of each case.
The weight depends on three things you control or can document: the written program, its size and history, and the evidence behind it. Start by confirming which recognized practices your program follows, such as the NIST Cybersecurity Framework or the HHS 405(d) practices, and record how you chose them and why they fit your organization. Then assemble dated proof that they operated for the full 12-month window, including risk management decisions, access reviews, training records, patch and backup logs, and incident exercises. Ask your compliance lead to confirm that the 12-month period is continuous. Gaps in the record often matter more than the framework name.
Organizations own this evidence, and only an independent assessor or auditor can give a third-party view of it. HHS does not certify or endorse private certifications, so no seal from any vendor or consultant establishes that you qualify. Any outside review, such as a third-party HIPAA assessment, should be scoped in writing to test the specific practices you claim, and its findings should be kept with your documentation. Before a planned OCR inquiry, ask your outside advisors to confirm which of your records would satisfy a request for evidence, and assign an internal owner to keep them current.
Which frameworks count as recognized security practices
Public Law 116-321 does not hand OCR a fixed list. It names three categories of practices, and the covered entity or business associate chooses which ones it has in place, consistent with the Security Rule. The cards below map each category to the decisions and checks that matter when you build that record.
NIST standards and the Cybersecurity Framework
The first category covers standards and practices developed under section 2(c)(15) of the NIST Act, which explicitly includes the NIST Cybersecurity Framework. In practice, map your existing controls to CSF categories so an assessor can trace each Security Rule safeguard to a documented CSF outcome. Confirm which CSF version your program references, since the statute does not name one.
Section 405(d) approaches
The second category covers approaches promulgated under section 405(d) of the Cybersecurity Act of 2015, which is the basis for HHS's Health Industry Cybersecurity Practices publication. Decide which practices your organization adopts from that publication, then record the reason each practice fits your size and risk profile. Ask OCR's current guidance whether a given volume or practice set is treated as recognized, because the list of qualifying approaches is determined by HHS, not by the entity.
Other programs recognized by statute or regulation
The third category covers other cybersecurity programs recognized by statute or regulation. This is the open-ended part of the definition, so the risk is assuming a private certification counts. HHS states it does not endorse or recognize private organizations' certifications, so treat any third-party seal as supporting evidence only until you confirm its status in writing with HHS.
Entity-determined selection
The statute leaves the choice of practices to the entity, consistent with the Security Rule. Your written decision record should name each practice adopted, the scope it covers (for example, specific ePHI systems or business units), and the owner accountable for it. An assessor will test whether the selection is coherent with your risk analysis, so link each practice to a documented risk rather than listing frameworks for their own sake.
Twelve-month demonstration window
Recognition only helps when you can show the practices were in place for at least the previous 12 months. Keep dated evidence of configuration, training, review and testing from the start of the period, not a snapshot assembled when OCR writes. Build the evidence trail as part of normal operations, and keep a continuous log of when each practice was active and who approved changes to it.
Confirm current recognition status
Recognition status is a fact you verify, not one you assume from a framework's reputation. Before relying on a source in an OCR response, check HHS's Security Rule guidance and confirm with HHS or your counsel how the source is treated today. Record the date of your check and the version of the source you relied on, because the statute does not fix a single version for every framework.
How to show practices were in place for 12 months
This sequence turns recognized security practices into a dated record that shows the chosen practices were adopted, operated and reviewed across the look-back period. The output is a file set an examiner can read without needing your staff to explain it.
Choose and scope the recognized practices
Select the recognized security practices your program will rely on, such as the NIST Cybersecurity Framework, HHS's 405(d) practices or another source the entity determines is consistent with the Security Rule. Record the systems and ePHI environments in scope, and name the owner for each practice. The artifact is a signed practice register that states the source, version and scope of each practice. Confirm the selection with counsel or your compliance lead before work starts, because the rule leaves the choice to the entity.
Adopt and document each practice
Translate every selected practice into written procedures, configurations and assigned responsibilities that fit your environment. Link each procedure to the Security Rule standards it touches so reviewers can follow the logic. Approve the documents through your governance process and record the approval date and version. The output is a controlled document set with version history, which is the baseline your dated evidence will be measured against.
Operate the practices continuously
Run each practice as routine work rather than a one-off project, so the activity repeats on its scheduled cadence. Staff perform the tasks, system owners approve exceptions and tooling produces logs where it can. Keep a running calendar of recurring activities so gaps in operation are visible early. The output is a set of completed tasks with timestamps and named operators, which shows the practice was in place rather than only written down.
Collect dated evidence for each practice
Gather artifacts that prove operation, including risk analysis records, training attendance logs, access review sign-offs, vulnerability scan reports, backup restore tests and incident response exercise reports. Store each item in a repository with a fixed naming convention, the date it was produced and the practice it supports. Retention rules should keep items available for the whole look-back window. The output is an indexed evidence library that can be retrieved within a short time when OCR asks for it.
Keep a gap log and close findings
Record every missed task, failed control test or unresolved finding in a gap log with a date, owner, root cause and corrective action. Track each entry until the closure evidence is filed and the reviewer signs off. Gaps are not a failure to hide, because an examiner will look for how the organization detected and fixed them. The output is a dated log showing that problems were found, assigned and resolved, which supports the claim of continuous practice.
Review the program on a set schedule
Have someone independent of the operators review the evidence library and gap log at regular intervals, and record the outcome of each review. Reviews should test whether artifacts exist for every practice in the register and whether the practices still match the environment. Update the practice register when systems or threats change, with the change dated and approved. The output is a set of signed review records that demonstrates oversight across the period.
Prepare the practice-to-standard summary
Build a summary table that maps each recognized practice to the Security Rule standards and implementation specifications it supports, with a pointer to the evidence for each row. Include the open gaps and their status so the summary is candid rather than promotional. Confirm the mapping with your security official and, where you rely on an outside assessor, with that assessor. The output is a single document that lets an OCR investigator navigate from a Security Rule requirement to the dated proof, which is what an evidence request typically needs.
What the amendment does not do
The amendment gives HHS a reason to consider good practices when it decides penalties, audit scope and remedies. It does not reduce the baseline exposure created by the Security Rule itself, and it does not protect an organization from findings that the rule already requires it to meet. Executives should read it as a factor that can help in a resolution, not as a guarantee that will reduce the outcome of an investigation.
- No increase for absence: Section 13412 does not let HHS raise fines or extend audits because an entity lacks recognized security practices. The absence of a practice is not itself a violation.
- No liability for choice: An organization that decides not to adopt a recognized practice carries no liability under the amendment for that decision.
- Enforcement still applies: Violations of the Security Rule are assessed on their merits, and the civil money penalty table in 45 CFR 102.3 continues to apply.
- Board reporting: Ask whether the risk register records the Security Rule gaps that remain open, not only the practices the organization has adopted.
Before approving any budget framed around the amendment, confirm with counsel how the 12-month demonstration would be documented and what would be expected from the board.
Compliance leads own the Security Rule program, so the central risk is treating recognized practices as a substitute for the rule's own requirements. The amendment does not limit enforcement of the Security Rule and does not replace an entity's obligations under it. Every standard and required implementation specification still has to be met, and addressable specifications still need a documented assessment under 45 CFR 164.306(d).
- Obligations remain whole: Risk analysis under 164.308, access controls under 164.312 and documentation under 164.316 remain required regardless of which frameworks an entity adopts.
- Addressable choices stay documented: If an addressable specification is not reasonable and appropriate, the entity must document why and implement an equivalent measure where appropriate.
- Mapping is not compliance: A control mapped to a framework does not close a Security Rule gap unless the evidence shows the rule's requirement is met.
- Evidence still needed: Expect OCR to ask for the Security Rule documents themselves, not only for a list of frameworks.
Check whether your program can show the Security Rule requirement, the implementing control and the evidence for each, independent of any framework label.
Procurement teams often receive vendor statements that a product or service is HIPAA certified or that it follows a recognized practice. These statements need careful reading. HHS does not certify organizations, does not endorse private certifications, and does not recognize third-party certificates for Security Rule purposes. No third party issues a recognized-practice certificate under the amendment, so a vendor claiming one should be asked to explain the basis of the claim.
- No HIPAA certificate: HHS states that no Security Rule standard requires certification, so a certificate labeled HIPAA compliant is not a regulatory finding.
- No recognized-practice certificate: The amendment provides no certificate. Ask which practices the vendor adopted, how it documented them and for what period.
- Ask for the evidence: Request the vendor's risk analysis summary, policies, business associate terms and recent assessment results, with their scope and dates.
- Contract for accountability: Business associate agreements should state responsibilities that the vendor can be held to, whatever frameworks it references.
Ask vendors to show evidence for each claim and to name the assessor, if any, who tested it.
What OCR asks for when it requests evidence
OCR asks for documentation that shows the practices were in place, not just that they were written down. When the Office for Civil Rights opens a complaint investigation, compliance review or audit, it requests records that show how a covered entity or business associate meets the Security Rule, and for recognized security practices it also asks the entity to show those practices were in place for at least the previous 12 months. HHS's Security Rule guidance includes a video on recognized security practices that explains how entities can demonstrate them and how OCR requests that evidence. Before any request arrives, confirm the current request format, file naming and submission method against that guidance and the OCR audit program page, because the request letters and document lists change between audit cycles.
The baseline evidence is the documentation the Security Rule already requires. Section 164.316 requires written policies and procedures for every Security Rule requirement, and documentation of the actions, activities and assessments those policies call for, kept for six years and made available to the people who implement them. In practice this means dated policy versions, approval records, training logs, access review records, incident logs and change records. Recognized-practice evidence does not replace any of this. It sits alongside the risk analysis, which OCR treats as the starting point, so the risk analysis should show which threats were identified and how a recognized practice, such as a control from the NIST Cybersecurity Framework or the HICP practices, addresses each one.
Start by building an evidence index that maps each claimed practice to its 12-month record and to the risk analysis entry it supports. Ask whether your security official can produce dated artifacts for every month in the look-back window, such as configuration exports, patch reports, vulnerability scan results and access reviews, and who owns each one. Gaps in the record are more damaging than missing paperwork, so identify them before an audit does. Expect that an implementation partner can prepare these systems and records for you, but the covered entity or business associate owns the policies, the decisions and the evidence, and only OCR itself determines whether the evidence is sufficient.
What changes how much this helps your organization
Recognized security practices only help when OCR can see a steady, documented record that fits the entity's own risk. The factors below decide whether that record exists, how credible it is, and how far it reaches across the organization and its business associates.
Length and consistency of the record
The 2021 amendment asks whether practices were in place for the previous 12 months, so a practice adopted last month carries little weight. Gaps matter as much as the start date: a control that ran for eleven months and lapsed will be read as a gap. Check that each practice has dated evidence (change tickets, review sign-offs, scan reports) for every month of the look-back. Keep the record in one place so it can be produced quickly if OCR asks.
Quality of the risk analysis
A recognized practice that is not tied to your own risk analysis is hard to defend, because OCR looks for practices chosen to address the ePHI you hold and the threats you face. Confirm the risk analysis lists where ePHI lives, the threats and vulnerabilities considered, and a risk management plan with owners and dates. Shallow or outdated analyses weaken every practice that depends on them.
Incident history and open findings
Recent incidents, especially ransomware or phishing events, change how OCR reads your practices. Expect questions about what failed, what changed afterward and whether the same weakness recurred. Open audit findings or unresolved vulnerabilities from earlier reviews can undercut a strong narrative. Review incident post-mortems and corrective action logs against the practices you plan to cite.
Organization size and resources
The Security Rule scales safeguards to the size and capabilities of the entity, and recognized practices are read the same way. A small practice with a documented, proportionate program may demonstrate more than a large system with a thick binder and no operating evidence. Ask which practices your staff can run and evidence without outside help, and which depend on a vendor. Be honest about capacity in the record, because OCR compares claims to what is actually operating.
Business associate coverage
Your record covers only the systems and processes you control. Hosting providers, billing firms, managed IT providers and other business associates that handle ePHI for you need their own evidence, or the gap will surface during an audit or investigation. Confirm each business associate's practices, obtain their evidence on a set schedule, and check that business associate agreements describe the safeguards they must maintain.
Mapping to Security Rule requirements
Recognized practices help only where they show how a Security Rule standard or implementation specification is met. A practice that is not mapped to a specific requirement forces OCR to infer the connection, and inference is where arguments fail. Build a crosswalk that names each practice, the standard it supports, the evidence it produces and the owner. Review the mapping whenever the framework or the Security Rule changes, and remember that addressable specifications still require a documented decision.
How resolution settlements show what OCR expects
Resolution settlements are the clearest public record of what the HHS Office for Civil Rights expects after an incident, but they describe outcomes, not a checklist. Two 2026 announcements show the pattern. The Ambry Genetics press release, dated September 17, 2026, covers a settlement of an investigation into a phishing attack affecting 225,000 individuals. The MMG Fusion announcement, dated March 5, 2026, covers a settlement of an investigation into a breach. Treat both as illustrative of enforcement outcomes. Facts vary from case to case, and the public announcements do not establish that recognized security practices shaped either result, so do not cite them that way unless the agreement says so.
Read the full agreement before drawing lessons from the summary. A resolution agreement generally binds the entity to obligations and reports to HHS for three years, during which HHS monitors compliance, so the operative terms are in the agreement text, not the press release. Check the scope of the corrective obligations, the risk analysis and risk management terms, the reporting schedule and the controls named for email-borne threats, such as multi-factor authentication, email filtering and workforce phishing training. Then compare each named control with your own program. Could you show that it was in place, documented and operating for the prior 12 months? That is the question section 13412 asks, and a settlement does not answer it for you.
Turn each obligation into a working item. Assign an owner to every control the agreement names, record where the evidence lives and note the date it was produced. Where you have no evidence for a control, treat that as a gap to close before an OCR request arrives. Confirm the current expectations against OCR's own Security Rule guidance, including its material on recognized security practices and how OCR requests evidence of them. If your organization lacks in-house expertise, decide whether an outside party will prepare the evidence or only review it, and confirm in writing which of those tasks the outside party performs and which the organization keeps.
What to have in place before OCR or an assessor asks
OCR and independent assessors start from the same question: can the organization show its safeguards were designed, documented and operating before the request arrived. The items below are the artifacts and records that make a recognized security practices claim checkable, and each one can be verified without waiting for an audit.
Current HHS-aligned risk analysis
The risk analysis is the document OCR asks for first, and it anchors every other item. Check that it covers every system, location, device and vendor that creates, receives, maintains or transmits electronic PHI, that it is dated, and that it was updated after major changes such as a new cloud platform or a merger. Ask whether the threat and vulnerability sections reflect ransomware and phishing, since those dominate recent OCR cases. Confirm the method against the HHS risk assessment guidance.
Documented risk management plan
A risk analysis lists risks but does not show what was done about them. The risk management plan assigns each risk a treatment decision, an owner, a target date and a residual risk level, and it records which risks the organization accepted and why. Check that every high-rated item links to a named control change or a documented acceptance. Without this link, a reviewer can read the analysis as a list of known problems left open.
Written policies under 164.316
Section 164.316 requires written policies and procedures for each Security Rule requirement, and the documentation must be kept current. Check that each policy names an owner, an approval date and a review cycle, and that each safeguard in the risk management plan points to a procedure someone can follow. Confirm the documentation retention practice matches the six-year requirement in the same section, since that is one of the first items reviewers request.
Chosen recognized framework with a mapping
Recognized security practices are whatever the entity determines consistent with the Security Rule, drawn from sources such as the NIST Cybersecurity Framework or the HHS 405(d) practices. Pick one primary source, record the version used, and maintain a mapping from its requirements to your HIPAA safeguards and to the systems that implement them. Verify the mapping is your own work product, because a framework named in a policy without a traceable mapping does not show anything was implemented.
Evidence of operation over the look-back
The 2021 amendment asks whether practices were in place for the previous 12 months, so a policy adopted last month does not carry much weight on its own. Gather dated evidence that controls ran throughout that window: access review records, patch reports, backup restore tests, training completion logs and audit log reviews. Check for gaps, because a single quarter with no evidence can undercut an otherwise complete program. Ask your team to confirm the log sources are retained and that exports can be produced quickly.
Named security official
The Security Rule requires a single individual to be identified as responsible for developing and implementing security policies and procedures. The named official should have written authority, access to leadership, and enough time to run the program, whether employed or contracted. Check that the appointment is documented, that the official can state the status of open risk items from memory, and that a backup contact exists. If the role is outsourced, confirm the contract states exactly which decisions remain with the organization.
Who owns the program, who prepares evidence, and who assesses it
The covered entity or business associate owns the Security Rule program. Under 45 CFR 164.308, the organization must designate a security official and make the decisions that define its safeguards, including how it performs risk analysis, which addressable specifications it adopts, and which alternative measures it accepts. Recognized security practices only help if the organization has actually adopted them and can show they were in place for the prior 12 months, so that record starts with internal decisions.
- Control ownership: Named owners for each safeguard, with authority to fund and change it.
- Risk acceptance: Written sign-off on residual risk, including any addressable specification the organization decides not to implement and why.
- Policies and procedures: Documents approved by leadership and reviewed on a schedule, as 45 CFR 164.316 requires.
- Workforce accountability: Training, access reviews and incident response roles that staff actually follow.
- Continuity of records: Evidence retained so that a 12-month history can be produced when OCR asks.
Confirm internally who signs the risk acceptance and who holds the evidence archive before any outside party begins work.
An implementation partner such as DeployOpen helps the organization build and document the controls it owns. For self-hosted open-source platforms in the client's own cloud accounts, data centers or air-gapped networks, that work can include hardening, logging configuration, backup setup, access design, and writing procedures and evidence collection routines. Where scoped in writing, the partner may also run security testing. The partner prepares systems and evidence; it does not decide what risk the organization accepts and does not issue any report or certificate.
- System preparation: Configuration, hardening and integration of the platforms that hold ePHI.
- Documentation: Drafts of procedures and technical records that the organization reviews, approves and maintains.
- Evidence production: Logs, configuration baselines, test results and change records set up to be retrievable.
- Security testing: Application, infrastructure or risk testing only where the written scope includes it.
- Handover: Runbooks and training so the organization can operate the controls without the partner.
Ask for the written scope, the deliverables list and who holds the final documents before work starts. Scope and fees follow from that written scope, so confirm them in a quote, not from a general claim.
An independent assessor tests whether the controls work and states its conclusions. HHS does not endorse or recognize private certifications, and no Security Rule standard requires certification, so an assessor's output is an opinion about specific controls on specific dates, not a HIPAA certificate. OCR, not an assessor, decides whether an entity met the Security Rule and whether recognized security practices are weighed in a particular case. Assessors are useful to test the evidence before OCR asks for it, but their report does not bind OCR.
- Independence: The assessor should not design or operate the controls it tests.
- Test method: Confirm whether the work is a sample-based examination, a review of documents or an interview-based readiness check.
- Deliverable: Ask whether the output is a written findings report, a gap list or an attestation, and who may rely on it.
- Limits: Get the assessor's statement of what it did not cover, such as cloud provider controls or business associate systems.
- Qualifications: Verify the assessor's experience with healthcare and the Security Rule, and confirm its engagement terms in writing.
Before engaging any assessor, confirm that its deliverable matches what OCR would ask for and that no one describes it as a HIPAA certification.
Common questions about recognized security practices and HIPAA
Does adopting a framework make us HIPAA compliant?
No. Adopting a framework does not by itself make an entity compliant with the Security Rule. The Security Rule, codified at 45 CFR Part 164 Subpart C, sets the obligations, and recognized security practices are one factor OCR must weigh when it decides fines, audit length and extent, or remedies. Under Public Law 116-321, section 13412 does not replace an entity's obligations under the Security Rule and does not limit enforcement of it. Your organization still has to run the risk analysis, implement the required specifications and address each addressable specification with a documented decision. Frameworks help you build and evidence that work, but they do not substitute for it.
Is there a HIPAA certification we can earn?
No. HHS states that no Security Rule standard requires an entity to certify compliance, that HHS does not endorse or recognize private organizations' certifications, and that such certifications do not prevent HHS from later finding a violation. Any vendor offering a HIPAA certificate is selling a private assessment, not a government credential. When a customer asks for proof, the useful documents are your risk analysis, risk management plan, written policies, and evidence that controls operate. If you want an outside view, a third-party assessment can test those artifacts, but it does not turn into an official HIPAA certification. Ask any provider exactly what their report does and does not cover.
How far back does the 12-month look-back reach?
The look-back covers the 12 months before the event OCR is considering. Public Law 116-321 requires HHS, when deciding fines, audit length and extent, or remedies in Security Rule matters, to consider whether an entity adequately demonstrated that recognized security practices were in place for at least the previous 12 months. The provision asks about a sustained period, not a single point in time. A control introduced last week gives you little look-back credit, so you should document when each practice started, who owned it, and how it was reviewed across the year. Confirm the exact evidence expectations with OCR's guidance, since the statute sets the period but not the form of proof.
Can we do this ourselves without outside help?
Often yes, if you have the internal skills and time. The Security Rule does not require outside consultants, and the work is largely documentation, decision-making and operating controls that your workforce can own. Outside help is a choice made for capacity, expertise or independent testing. Each option has a different owner: your organization owns its controls and the decisions behind them, an implementation partner can prepare systems and evidence, and only an independent assessor issues a report. Before deciding, list the standards you cannot staff, the systems you cannot configure, and the evidence you cannot produce on schedule, then compare that list against what in-house staff can cover.
What does the work need from our staff?
It needs named owners, time from people who know your systems, and a steady rhythm of review. At minimum, you will need a security official accountable for the program, system owners who can describe where ePHI lives and how it moves, and workforce members who follow the written policies. The effort is recurring: the risk analysis must be kept current, access reviews and audit log reviews must run, and training and incident procedures must be exercised. Cost drivers include the size of your environment, the number of business associates, how many systems hold ePHI, and how much documentation exists already. Ask any quote to break out one-time setup from recurring operations.
Does adopting recognized security practices lower fines automatically?
No. Public Law 116-321 does not guarantee a reduction. It requires OCR to consider whether recognized security practices were in place, and that consideration is one factor among many in fines, audit scope and remedies. The statute also states that HHS cannot increase fines or audits because an entity lacks these practices, and that choosing not to adopt them creates no liability. Civil money penalties are set under 45 CFR 102.3, which sets a per-violation range and an annual cap. Treat recognized security practices as evidence of good faith and diligence, and focus on documenting how they worked in practice over the prior year.
How DeployOpen works on this
DeployOpen helps organizations prepare their self-hosted open-source systems and the evidence that shows recognized security practices were in place for the prior 12 months. DeployOpen prepares systems and evidence only; the organization owns its controls, and OCR and independent assessors decide what the evidence shows.
How we scope
- Engagements are fixed-scope, with scope and deliverables agreed in writing before work starts.
- The written scope names which recognized security practices the organization has adopted and which systems they cover.
- We agree the look-back period to document, so evidence covers a continuous 12-month window rather than isolated snapshots.
How we build
- We plan, implement and harden self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks.
- We configure logging, access control, backup and patching so the practices you adopt leave records a reviewer can inspect.
- We run security testing against the systems in scope and track findings to closure with named owners.
How we hand over
- We document configurations, procedures and test results in a form your security team can maintain after handover.
- We map each adopted practice to the evidence that demonstrates it, so you can answer an OCR evidence request directly.
- We train your staff on operating the systems and producing the evidence, and confirm the organization owns the final documentation.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work ends.
- We can refresh evidence periodically so the 12-month record stays current as systems change.
- Independent assessors and auditors remain responsible for any assessment or report; confirm their role with your counsel before work begins.
