What HIPAA security reminders require and why an addressable specification still needs a decision
164.308(a)(5)(ii)(A) asks covered entities and business associates to send periodic security updates to the workforce as part of the security awareness and training program. The updates are the short, recurring messages that sit between formal training sessions, such as a notice about a new phishing campaign, a reminder about a changed remote access procedure, or a warning about a password reset scam. The specification is addressable, not required. Under 45 CFR 164.306(d)(3), the organization must first assess whether periodic reminders are reasonable and appropriate for its environment. If they are, it implements them. If they are not, it must document why and adopt an equivalent alternative measure where that is reasonable and appropriate. In either case, the decision and its reasoning belong in writing, because an assessor will ask for both.
The risk this addresses is predictable. Staff complete annual training, then forget most of it by the next quarter, while attackers change lures faster than a yearly course can. A clinician who was taught to report suspicious email in January may not recognize a credential harvesting message in August. Reminders close that gap by repeating key behaviors and by telling staff about threats that appeared after the last session. The risk analysis under 164.308(a)(1)(ii)(A) should show which threats are current for your organization, and that finding should set how often reminders go out and which topics they cover. Reminders that are not tied to identified risks are easy to defend as noise, and easy to dismiss as noise.
Two things usually make this specification hard to run well. The first is ownership: awareness content often sits with no one, so messages go out irregularly or stop after a staff change, and nobody notices. Name one role, usually the security official or a delegate, and define how content is approved. The second is the record: few organizations keep a log of what was sent, to whom, and when, so they cannot show an assessor that the program ran. Keep the sent messages, the distribution list or delivery tool report, and a short note linking each reminder to the risk or incident that prompted it. Confirm with your own counsel and compliance lead how long these records are kept under your documentation practices, since the Security Rule's documentation standard in 164.316 governs documentation generally.
Which workforce, channels and policy changes fall inside security reminders
Security reminders only satisfy 164.308(a)(5)(ii)(A) if the right people receive them through channels they actually read, at a cadence the entity can justify. The cards below cover the scoping decisions an entity must document, and the risk analysis is the record that should drive each one.
Workforce groups that receive reminders
The standard applies to the whole workforce, so reminders should reach management, clinical and administrative staff, IT administrators and temporary personnel. Contractors and other non-employees who can reach ePHI, such as billing vendors' staff working in your systems, belong in scope when your risk analysis shows they can affect ePHI. Check that your list comes from the access records, not the org chart, because access often outruns job titles.
Channels that count as delivery
Email, the intranet, posters in staff areas and chat messages can all deliver a reminder, but a channel only counts if you can show who received it. Email and intranet postings leave timestamped records, while posters and chat posts usually do not. Pair any untraceable channel with a channel that does leave a record, and keep the message text and distribution list for each reminder cycle.
Triggers for an extra reminder
A scheduled cadence should be supplemented when a new threat appears, such as a phishing campaign targeting clinics, or when a policy, system or vendor changes how staff handle ePHI. Incidents that the incident response process records also justify a targeted notice. Document each trigger you define, so auditors can see that reminders respond to real changes rather than only to the calendar.
Risk analysis sets frequency and audience
The rule does not fix how often reminders go out, so the risk analysis must justify the cadence and the audience. Groups with broad ePHI access, or with a history of phishing failures, may need more frequent or more targeted reminders than low-access roles. Revisit the cadence when the risk analysis changes, and record the reasoning in the policy so that the frequency has a documented basis.
Documenting an alternative measure
Because the specification is addressable, an entity that decides reminders are not reasonable and appropriate must document that decision and implement an equivalent alternative measure. Reminders delivered through a learning platform need a completion record, such as a view or acknowledgment, to serve as that evidence. Confirm with your learning platform which completion conditions it records before you rely on it.
How an assessor tests security reminders
This table sets out each step an assessor takes when testing 164.308(a)(5)(ii)(A), the evidence requested at each step, and the findings that most often lead to a gap. Read it as a checklist for preparing your own reminder program before an OCR request or an independent review.
| Test step | What the assessor checks | Common finding |
|---|---|---|
| Confirm the addressable decision | A written assessment showing whether periodic security updates are reasonable and appropriate, dated and approved by the security official | No record that the entity considered reminders at all, or the decision was made informally and never written down |
| Reject without an alternative | If reminders were declined, documentation of why and an equivalent alternative measure that is reasonable and appropriate | Reminders were skipped with no reason recorded, or the claimed alternative was never actually run |
| Sample reminders | A set of reminders selected across the review period, with send dates, subject matter and version of the source policy | Reminders exist as a plan or template but few or none were actually sent in the period tested |
| Check the audience | Distribution lists or LMS assignment records showing that the full workforce in scope received each reminder, including management | Reminders went only to IT or to staff who joined a particular channel, leaving parts of the workforce out |
| Test recall with staff | Short staff interviews asking what recent reminders covered and what to do when they see a suspicious message | Staff cannot name a recent reminder or repeat the reporting step, which suggests the content did not land |
| Match updates to policy changes | Dated policy revisions, threat notices or incident lessons compared with the reminder that followed each one | Policies changed or an incident occurred, but no reminder followed within the entity's own stated timeframe |
| Review the evidence trail | Delivery logs, completion or acknowledgment records and retained copies of each reminder for the retention period | Only a policy statement says reminders happen; no copies, logs or acknowledgments can be produced on request |
How to set up a reminder program that produces evidence
This sequence turns the addressable security reminders specification into a documented, recurring program. Each step leaves a record that shows the organization decided on reminders, delivered them to the workforce and checked whether they worked.
Assess and document whether reminders are reasonable
The security official, with HR and the people who own the training program, decides whether periodic security updates are reasonable and appropriate for each workforce group. Under the addressable rules, the organization must assess the specification and, if it does not implement it, document why and adopt an equivalent alternative measure. The output is a short signed decision record that names the reasoning, the workforce groups covered and the risks it addresses. Most organizations will find reminders reasonable, so the record should explain why, not only that the decision was made.
Define the reminder calendar and triggers
Set a regular cadence for routine reminders and a list of event triggers, such as a new threat pattern in the risk analysis, a policy change, a phishing campaign, or a security incident affecting staff behavior. Tie each reminder topic to a risk identified in the risk analysis so the calendar can be traced back to the assessment. The output is a reminder calendar with owners, topics and trigger conditions. Confirm the cadence with your own risk analysis, since the Security Rule does not set a frequency for reminders.
Draft and approve reminder content
The security team drafts each reminder in plain language, with a clear action for the reader, and routes it to the security official and, where policy is affected, to the policy owner for approval. Approval should be recorded with the version number, date and approver. The output is an approved content library with version history, so an assessor can see what staff were told and when a policy change was communicated.
Deliver reminders through a recorded channel
Send each approved reminder through a channel that logs who received it, such as the learning management system, the corporate email platform or an intranet with read tracking. Open-source options such as Moodle can record activity completion, but the organization must confirm that a given setting records receipt in the way it needs. The output is a delivery log listing the reminder version, the date and the recipient groups, which becomes the primary evidence that the specification was carried out.
Track acknowledgement and follow up on gaps
Measure which workforce members acknowledged each reminder, and define what follow-up applies to those who did not, such as a manager reminder or a short refresher. Review the acknowledgement rates and record exceptions, including leave, contractors not yet onboarded or shared accounts that cannot be tied to one person. The output is an acknowledgement report with documented follow-up actions for the gaps, which shows the program is operating and not only scheduled.
Review the program against the risk analysis
On a schedule the organization sets, the security official compares the reminder topics and delivery results with the current risk analysis and any changes in systems, threats or incidents. Reminder topics are added, retired or reprioritized, and the decision record from the first step is updated if the reasoning has changed. The output is a dated review memo with any calendar changes listed, which keeps the program aligned with the evaluation standard and the risk management process.
Evidence that shows reminders were sent and reviewed
Security reminders are an addressable specification, so the evidence has two jobs: show that the entity decided deliberately whether reminders were reasonable and appropriate, and show that the reminders actually reached the workforce on a schedule. The cards below cover the decision record, the schedule, the reminders themselves, the delivery trail, the acknowledgement trail and the event-driven notices. Each one should be dated and traceable to the others.
Addressable decision memo
This is the record that shows the entity assessed the specification under 45 CFR 164.306(d)(3) rather than skipping it. It should state whether periodic reminders are reasonable and appropriate, the risk analysis findings that support that answer, and, if any part was not adopted, why and what equivalent measure replaced it. Check that the memo is signed, dated, tied to the current risk analysis, and reviewed when the risk analysis changes.
Reminder calendar
The calendar shows the planned cadence of reminders, the owner of each topic and the date each notice is due. An assessor compares it with the sent items to see whether the program ran as designed. Keep it in a system of record the security official controls, and record reschedules with the reason, so a gap can be explained rather than discovered.
Copies of each reminder
Keep the exact text, images and attachments of every reminder as sent, with its send date and channel, such as email, intranet post or posters. Versions matter: a reminder that changed after sending should be retained in its original form. Store copies in a write-protected archive so the record cannot be edited after the fact.
Distribution lists and delivery logs
Distribution lists show who was in scope on each send, including management, contractors and staff who joined later. Delivery logs from the mail or messaging system show what was sent and when, and bounce reports show what did not arrive. Reconcile these against the current workforce roster, since a list that was correct in January may miss staff hired in March.
Acknowledgement and completion records
Where the entity requires staff to acknowledge a reminder, record who opened or confirmed it and when. Learning platforms can record completion when a learner views an activity, receives a grade or ticks it manually, depending on how the activity is configured. Confirm which trigger is used, because a view is weaker evidence than an acknowledgement, and document which one the entity accepts.
Event-driven reminder records
When a threat bulletin, phishing wave or policy change prompts an extra notice, keep the trigger, such as the vendor advisory or incident ticket, next to the notice it produced. This shows the program responds to the environment as well as to the calendar. Reviewing these records each quarter helps the security official confirm that the cadence still matches the risks in the current risk analysis.
How security reminders differ from formal training and malware protection
Security reminders are the periodic updates that fill the gaps between formal training sessions, and they sit under the same standard as that training. Under 164.308(a)(5), the security awareness and training program covers the whole workforce, and reminders are one of its four addressable specifications. A formal session teaches a course of material, usually at onboarding and on a set cycle. A reminder is shorter and more frequent: a notice about a new phishing campaign, a changed password rule, or an updated instruction on reporting a lost device. The practical test is what the item is for. If it is delivered to staff as a message about current threats or policy changes, it is a reminder. If it is a structured course with a completion record, it belongs to training, even though both serve the same standard.
Do not count malware protection or log-in monitoring as reminders, even when staff are told about them. Protection from malicious software (164.308(a)(5)(ii)(B)) and log-in monitoring (164.308(a)(5)(ii)(C)) are separate addressable specifications with their own evidence. Malware protection evidence is the technical configuration and scan or detection records, with reporting procedures. Log-in monitoring evidence is the record of how failed or unusual log-in attempts were reviewed and escalated. A notice telling staff to report suspicious attachments supports the malware specification, but it does not prove the malware specification is met. Build one evidence register that lists each specification separately, and map each reminder to the specification it supports. This prevents the same newsletter from being claimed three times.
NIST SP 800-66 Rev. 2 lists implementing security reminders as a key activity of the awareness and training standard (section 5.1.5), and the guidance is informational, not legally binding. Use it as a checklist for what a reasonable reminder program contains, not as a source of required frequency. Confirm with your security official and risk analysis how often reminders go out, which audiences receive which messages, and how delivery is recorded. The NIST SP 800-66 Rev. 2 publication sets out the key activities in full, and your documented decisions on reminders should cite the risk analysis that justifies them.
What security reminders cost in staff time, tooling and review
This table breaks down what periodic security reminders cost to produce, deliver and evidence, showing who is paid for each component and whether it is one-time or recurring. Use it to shape the questions you put to an internal team or a vendor before agreeing on scope, since no dollar figures are supplied here and the real amounts depend on your workforce and tools.
| Cost component | Who is paid or who spends time | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Reminder content development | Internal privacy or security staff, or an outside writer | Recurring, with a one-time setup for templates | Number of topics per year, how often threats or policies change, and how much review each item needs |
| Content review and approval | Security official, legal or compliance reviewer | Recurring | Number of approval layers and whether reminders reference policy text that changes often |
| Delivery tooling (email or intranet) | Existing IT staff or the email and intranet vendor you already pay | Mostly one-time setup, small recurring effort | Whether distribution lists and existing channels can be reused instead of new tools |
| Learning management system (for example Moodle) | Platform or LMS administrator, plus hosting team if self-hosted | One-time build, recurring hosting and upgrades | Number of learners, whether activity completion tracking is configured, and whether the platform is already in use for training |
| Completion and evidence upkeep | Compliance lead or training coordinator | Recurring | Whether completion records are exported on a schedule and how many reminder campaigns must be traced to staff |
| External content or specialist review | Outside consultant or content provider, billed per engagement | Usually one-time or periodic | Whether internal staff can write to the risk analysis findings or must buy generic material |
| Staff time to read and act on reminders | Workforce time, paid through existing salaries | Recurring | Length and relevance of each reminder, and whether reminders tie to real incidents your organization has seen |
| Assessor walkthrough and sample preparation | Internal team during assessment, auditor or OCR inquiry | Recurring, tied to review cycles | How well records are organized before an assessment and whether the risk analysis justifies the chosen frequency |
Who writes, sends and evidences reminders, and what to outsource
The covered entity or business associate owns the security awareness program, including the reminders. Under 164.308(a)(5)(ii)(A), the obligation sits with the organization, and an addressable specification still requires a documented decision: whether periodic reminders are reasonable and appropriate, and if not, why not and what equivalent measure replaces them. That decision should come from the risk analysis, not from a vendor's default settings. The organization also owns the calendar, the audience definitions and the records that prove each reminder reached its audience.
- The decision record: A written determination that reminders are reasonable and appropriate, or a documented alternative, tied to the risk analysis.
- The calendar: Dates or triggers for reminders, such as after a policy change, a new phishing campaign or a notable incident.
- The audience definition: Who receives each reminder, including management and staff who access ePHI.
- The records: Retained copies of each reminder and evidence of delivery or acknowledgment.
Confirm internally who holds each of these items and where the records are stored before any partner is engaged.
An implementation partner can prepare the systems that deliver and record reminders, as long as the organization keeps the content and approval decisions. DeployOpen plans and configures self-hosted open-source platforms inside the client's own infrastructure, so a partner can set up the delivery and tracking environment and build evidence templates. The partner prepares the systems and evidence; it does not decide what the workforce must be told, and it does not attest that the program meets the Security Rule.
- Delivery tooling: Configuration of a learning platform or messaging channel that the organization has approved.
- Tracking setup: Activity completion or acknowledgment settings so that views or confirmations are recorded per learner.
- Evidence templates: Standard formats for reminder logs, distribution lists and acknowledgment exports.
- Access controls: Restricting who can publish, edit or delete reminders and who can view completion data.
- Documentation: Runbooks that describe how the reminder process works and how to pull records for review.
Request a written scope that names each item above and states which items remain with the organization.
Drafting reminder content is one of the parts organizations commonly outsource, often to a training vendor or a consultant. External writers can produce readable notices on phishing, password hygiene or new threat patterns. The work still needs internal review, because the reminders must match the organization's actual policies, systems and incident history. Inaccurate or generic guidance can contradict the written security policies required under 164.316, which an assessor will compare against what staff were told.
- Outsourcing scope: Draft notices, templates and short explanations of threats or policy changes.
- Internal inputs: Current policies, recent incident lessons, and the risk analysis findings that motivate each topic.
- Consistency checks: Ensuring reminders use the same terms and procedures as the written policies.
- Version control: Keeping each published reminder with its date and author.
- Localization or accessibility: Adjusting content for workforce members who need it in another language or format.
Ask the drafting provider how they will receive policy updates and whether they will retain drafts or only final versions.
An independent assessor tests whether the reminder program operates as documented. The assessor selects samples of reminders, checks delivery and acknowledgment records, and compares the content against policy and the risk analysis. The assessor cannot write the reminders for the organization and remain independent, and a preparation partner should not sign off on the results. HHS states that no Security Rule standard requires certification and that private certifications do not bind HHS, so any third-party report is evidence to review, not a compliance stamp.
- Sample testing: The assessor picks specific reminders and traces them to distribution and acknowledgment records.
- Policy comparison: The assessor checks that reminder content aligns with written procedures.
- Independence: The team that drafted or configured the program should not also evaluate it.
- Gap identification: Missing decision records or unexplained gaps in the calendar are typical findings.
- Limits of the report: An assessment shows the state of the program at the time tested, not ongoing compliance.
Confirm with any assessor how they handle conflicts when a partner built the tooling they are testing.
Two decisions should stay with the organization: policy approval and the security official's review. Under 164.308(a)(2), the organization names one security official responsible for the Security Rule policies and procedures. That person should approve the reminder program's scope, sign off on significant reminder content and review completion results. Delegating these steps to a vendor removes the accountability that an assessor will ask about first.
- Policy approval: Formal sign-off on the reminder policy and the decision on addressable treatment.
- Security official review: Periodic review of reminder topics, completion rates and follow-up for non-responders.
- Escalation decisions: Choosing how to address staff who do not acknowledge reminders, through the sanction policy where relevant.
- Risk-driven topics: Deciding which threats warrant an immediate reminder after an incident or a new campaign.
- Final records: Owning the retained evidence and its retention period.
Document who holds each of these roles and confirm that the named security official has the time and authority to perform the review.
Where organizations fall short on security reminders
Security reminders are addressable, which means the entity must decide whether they are reasonable and appropriate and record that decision. Most shortfalls come from skipping that decision, sending reminders that leave no trace, or never tying them to the risk analysis, contractors or policy changes.
No documented addressable decision
Under 45 CFR 164.306(d)(3), an addressable specification requires the entity to assess whether it is reasonable and appropriate. Many organizations never write that assessment down, so an assessor sees a gap rather than a reasoned choice. Check that the decision names the specification, the reasoning, and either the implementation or the documented equivalent alternative measure. Record the decision before the first reminder goes out.
Reminders sent but not recorded
A reminder that cannot be shown to have reached the workforce is hard to defend. Email blasts, intranet posts and chat messages often leave no record of who received them or when. Keep a dated copy of each reminder, the distribution list used, and an acknowledgment or completion record where the channel allows it. An illustrative check: pull one reminder from last quarter and trace it to named recipients.
No link to the risk analysis
Reminder topics should follow the risk analysis, not a generic calendar. If phishing, credential misuse or a new ePHI system appears in the risk analysis and the reminders never mention it, the program is disconnected from the entity's own risks. Map each reminder topic to a finding or risk entry, and review the mapping whenever the risk analysis is updated.
Reminders that never reach contractors
Workforce members under the rule are not limited to employees. Contractors, temporary staff, trainees and some vendor personnel with access to ePHI systems also need reminders where they touch that information. Many organizations send reminders only through the employee directory. Confirm which non-employees hold accounts, and whether their contracts or business associate arrangements give you a way to reach them.
No update after a policy change
Security reminders are meant to carry new threats and policy changes between formal training sessions. When a password standard, remote access rule or data handling policy changes and no reminder follows, staff keep working from the old instructions. Set a trigger in change management so that each approved policy change produces a reminder, and record the link between the change ticket and the reminder.
Reminders with no owner or review
Reminders often drift from the program when no named person owns them. Without a review step, content goes stale and no one notices when a referenced policy has been retired. Assign an owner, set a review point tied to the annual evaluation under 164.308(a)(8), and keep a version history of the reminder library so an assessor can see what was sent and why.
Questions buyers ask about security reminders
Are security reminders mandatory under the HIPAA Security Rule?
No, security reminders are an addressable implementation specification, so you must make a documented decision about them rather than skip them silently. Under 45 CFR 164.306(d)(3), you assess whether periodic security updates are reasonable and appropriate for your organization. If they are, you implement them. If they are not, you document why and put an equivalent alternative measure in place if that is reasonable and appropriate. Auditors will look for that written decision and the reasoning behind it, so the record matters as much as the choice.
How often should HIPAA security reminders be sent?
The rule does not set a fixed interval. The frequency should come from your risk analysis and from how quickly your threat environment and policies change. A practice that sees frequent phishing campaigns may need short, targeted notices more often than a stable organization with few changes. Whatever cadence you choose, document it in your security awareness and training program, deliver updates between formal training sessions, and keep records showing each reminder reached the workforce. Revisit the cadence when the risk analysis changes or a new threat pattern emerges.
Do we need a learning management system to send security reminders?
No. The rule requires that the reminders happen and that you can show they happened, not that a particular tool delivers them. Email, an intranet post, a staff meeting agenda or a printed notice can all work if you keep dated records of distribution and, where practical, acknowledgment. A learning management system helps when you need tracking at scale, such as completion reports across many sites. Moodle, for example, can mark an activity complete when a learner views it, receives a grade, or ticks it manually, which gives you a dated record. Confirm that any tool you choose can export the evidence an assessor will ask for.
How much effort do security reminders take to run?
The recurring effort is mainly content preparation, distribution and recordkeeping, and it scales with the size of the workforce and the number of threat changes you need to cover. The one-time effort is writing the reminder template, agreeing who approves content, and setting up the distribution channel and evidence store. Costs rise when reminders must be tailored by role, language or site, and fall when a single standard template covers most updates. No public figure for this effort is available in the sources for this page, so ask your team or a provider to estimate hours based on your workforce size, distribution method and update frequency.
Can we run HIPAA security reminders ourselves?
Yes, most covered entities and business associates can run reminders in-house, provided someone owns the program and keeps the records. The security official, or a designated delegate, usually approves content, while a compliance or training lead handles distribution and evidence. Outside help is commonly used to draft threat-specific content, review the documented decision on whether reminders are reasonable and appropriate, or set up a tracking system. Whatever the split, the organization owns the decision and the evidence. An implementation partner can prepare systems and records, but only an independent assessor can issue an audit opinion.
Is there an HHS certification proving we sent security reminders?
No. There is no HIPAA certification. 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. What you need instead is evidence: your documented decision on the addressable specification, your reminder content, distribution records and any acknowledgments. Be cautious with vendors who sell a HIPAA certificate for training. Ask what the document actually proves and whether any regulator recognizes it.
What evidence will an OCR auditor expect for security reminders?
Auditors typically look for a documented assessment of whether periodic updates are reasonable and appropriate, the reminders themselves with dates, proof of delivery to the workforce, and a link between reminder topics and the risk analysis. If you chose an alternative measure, expect questions about why it is equivalent. Keep reminders under version control, retain distribution records under your documentation policy, and note which threats or policy changes each reminder addressed. You can confirm the current audit focus on OCR's HIPAA Audit Program page before preparing your files.
How DeployOpen prepares reminder programs and evidence
DeployOpen starts with a written scope that names the reminder program the organization will run for 164.308(a)(5)(ii)(A). The scope records who receives reminders (workforce members, contractors and any others with ePHI access), which topics the reminders cover, who approves each notice before it goes out, and how the organization will decide that reminders are reasonable and appropriate. Because the specification is addressable, the scope also records the reasoning if the organization chooses a different alternative measure. The organization owns these decisions and the policy behind them. DeployOpen prepares the configuration and records so the organization can show what it decided and why.
On the technical side, DeployOpen configures self-hosted open-source learning or messaging tools inside the client's own cloud account, data center or air-gapped network, so reminder content and workforce data stay under the organization's control. Where a learning platform is used, the configuration typically covers course or notice structure, delivery schedules, and completion tracking. For example, Moodle's activity completion can mark a reminder complete when a learner views it, when it is graded, or when they tick it manually, so the organization must choose which condition counts as acknowledgment. Confirm the exact settings and any retention limits against the platform's own documentation and the organization's data policies before rollout.
DeployOpen then sets up evidence templates and a records structure for the assessor. These usually include a reminder calendar, the approved content for each notice, delivery logs, acknowledgment records, exception and follow-up notes, and the risk analysis entries that justified the reminder frequency. Evidence is only as useful as its timing and integrity, so the organization should confirm who maintains each record and how long it is retained under its own documentation policy. Independent assessors review this evidence and issue any reports or conclusions. DeployOpen does not issue audit reports, attestations or certifications, and HHS does not recognize any private certification of Security Rule compliance.
