Encryption protects information. Website language explains expectations. Both must reflect the organization’s real practices.
A healthcare website can look polished and secure while leaving two questions unanswered. What happens to information after a visitor enters it? And do the words on the page describe that path honestly?
Encryption protects data from unauthorized reading. Website disclaimers and notices explain limits, responsibilities, and privacy practices. One works on the information itself. The other guides people before they click, submit, or rely on what they read. Both must match what actually happens.
Encryption Protects the Data Not Every Decision Around It
Encryption changes readable information, called plaintext, into an unreadable form called ciphertext. An authorized person or system uses a cryptographic key to convert it back. When properly implemented, encryption can make stolen or intercepted data useless to someone who does not have the key.
The National Institute of Standards and Technology describes encryption as a tool for protecting information while it is stored and while it moves between systems. These settings are often called data at rest and data in transit.[1]
Data at rest may sit on servers, laptops, mobile devices, databases, or backups. Data in transit may move through email, a patient portal, a web form, or a link between systems. A sound program considers both. Protecting a laptop while leaving its backups exposed solves only part of the problem.
What the Current HIPAA Rule Requires
The Health Insurance Portability and Accountability Act of 1996 (HIPAA) Security Rule treats encryption and decryption as an addressable implementation specification under access control. It also treats encryption as addressable when electronic protected health information (ePHI) is transmitted over an electronic communications network.[2]
Addressable does not mean optional. The organization must assess whether encryption is reasonable and appropriate. If it is, the organization must use it. If it is not, the organization must document why and use an equivalent alternative when one is reasonable and appropriate.[3]
That decision should reflect current risks and workflows. An old conclusion may no longer fit after the organization adds cloud services, remote work, mobile access, or online scheduling.
The Key Is Part of the Safeguard
Encryption is only as dependable as its keys. If encrypted data and its key are kept together without adequate protection, an intruder may obtain both. If too many people or systems can reach the key, protection is weaker than leaders may assume.
The U.S. Department of Health and Human Services (HHS) points to federal guidance for valid methods and says decryption tools should be stored separately from the data they unlock.[4] Organizations should know who controls keys, how access is approved, and what happens when a key is lost or compromised.
Coverage also matters. A database may be encrypted while downloads, test files, email attachments, or older backups are not. Those copies can become the easier route to the same information.
| Information path | Question leaders should be able to answer |
|---|---|
| Laptops and mobile devices | Is ePHI encrypted when a device is lost, stolen, or left unattended? |
| Email and file transfer | Is sensitive information protected during transmission, and are approved secure methods easy for staff to use? |
| Backups and archives | Are copies encrypted, tested, and protected separately from the systems that created them? |
| Patient portals and web forms | Is information encrypted throughout collection, transmission, storage, and delivery to the intended team? |
| Vendors and cloud services | Do agreements and technical reviews confirm how the vendor encrypts data and manages keys? |
| Exports and removable media | Can users create unprotected copies outside the organization’s normal controls? |
What Encryption Cannot Do
Encryption does not decide whether a person should have access. If an attacker steals a valid password, the system may decrypt information for that session. The data is encrypted, but the account is compromised.
It also does not replace multifactor authentication, access limits, updates, audit logs, training, backups, or incident response. These controls address different risks and should work together.
Proper encryption can matter after an incident. Under HHS guidance, protected health information encrypted to specified standards may be considered secured for the HIPAA Breach Notification Rule, as long as the information needed to decrypt it was not also compromised.[4][5] The method and facts matter. A label that says “encrypted” is not enough.
A Clear Policy Watch
In December 2024, HHS proposed changes to the HIPAA Security Rule that would generally require encryption of ePHI at rest and in transit, with limited exceptions. As of September 24, 2026, HHS continues to identify those changes as a proposed rule. They are not part of the current HIPAA Security Rule, and the current rule remains in effect.[6]
Organizations may consider the proposal in future planning, but policies and training should separate proposed requirements from current law.
Website Disclaimers Explain Boundaries but They Do Not Create Security
Healthcare websites speak even when no employee is present. A headline may sound like medical advice. A contact form may appear private. A cookie banner may suggest that one click settles every privacy question.
Website language tells visitors what a page is for, how information may be handled, and when another channel is safer. It should guide people who are moving quickly or worried about a health issue.
“Disclaimer” is often used as a catchall, but several website documents serve different purposes.
| Website document | Main purpose | Important limitation |
|---|---|---|
| General disclaimer | Explains limits on educational content, professional advice, emergencies, accuracy, or external links | It cannot excuse misleading statements, weak security, or unlawful data practices. |
| Terms of Service | Sets rules for using the website or service | Acceptance of terms does not automatically authorize every use or disclosure of health information. |
| Privacy Policy | Describes online collection, use, sharing, and protection of personal information | It must match actual website and vendor practices. A statement alone does not make a disclosure permissible. |
| HIPAA Notice of Privacy Practices | Explains how a covered entity may use and disclose protected health information and describes individual rights and the entity’s legal duties | It is a specific HIPAA notice, not a substitute for a general website privacy policy or terms. |
The HIPAA Notice Has Its Own Role
Most HIPAA covered entities must provide a plain-language Notice of Privacy Practices. If a covered entity’s website describes customer services or benefits, the notice must be posted prominently and made available electronically. A material change calls for a prompt website update.[7]
The notice does not answer every website question. A privacy policy may explain cookies, analytics, or account registration. Terms may govern use of the site. A focused disclaimer may state that educational content is not individual medical advice or that a contact form is not for emergencies. These documents should support, not contradict, one another.
A Disclaimer Cannot Repair an Undisclosed Data Flow
The most important privacy questions often sit behind the page. Forms, appointment tools, chat features, analytics services, advertising pixels, and plug-ins may send data to third parties.
HHS is direct on this point: a privacy policy, notice, or website terms alone does not permit a regulated entity to disclose protected health information to a tracking vendor. A cookie banner is also not, by itself, a valid HIPAA authorization. When a vendor receives protected health information for a regulated function, the organization may need a business associate agreement and an appropriate HIPAA permission or authorization.[8]
The team writing the policy therefore needs to know what the site collects, where the data goes, why a vendor receives it, and how long it is kept. Security, compliance, marketing, and web teams need a shared process before anyone adds a new plug-in or campaign tool. Otherwise, a disclaimer can describe a website that no longer exists.
Put the Message Where the Decision Happens
A footer link is useful, but key guidance should appear close to the visitor’s choice. A contact form can say what not to enter and offer a safer channel. A health page can explain that its content is educational and identify what to do in an emergency. An external link can tell visitors that they are leaving the site. A notice shown only after information is submitted arrives too late.
Review the Website as a System Not a Stack of Pages
A useful review begins with the real data path. The organization should inventory its pages, forms, portals, scheduling tools, tracking technologies, plug-ins, and vendors. It should then compare those practices with the privacy policy, terms, disclaimers, and Notice of Privacy Practices.
The review should answer a short set of practical questions:
- What information can a visitor enter, upload, or reveal through the site?
- Which organization and vendor systems receive that information?
- Is the information encrypted during transmission and storage?
- Does each collection and disclosure have an appropriate purpose and legal basis?
- Do notices and disclaimers describe the current practice in language a typical visitor can understand?
- Who must approve and document a change to a form, vendor, tracker, or public statement?
This is not a once-a-year reading exercise. The review belongs in the change process whenever the organization adds a page, tool, vendor, or new use of information.
When the Safeguard and the Statement Agree
Encryption and website disclaimers solve different problems, but both must reflect reality. Encryption should protect ePHI where it is stored and while it travels. Website language should explain what the organization provides, how online information is handled, and when another channel is safer.
A trustworthy healthcare website does more than display the right words or show a lock icon. Its safeguards and statements tell the same accurate story.
EPICompliance and Taino Consultants Support
EPICompliance helps organizations connect workforce education, policy resources, recurring compliance tasks, and documentation. Taino Consultants can support risk assessment, privacy, security, and implementation work so that technical practices and public communications remain aligned with actual operations.
Current Users: Review your policies, training, risk-management tasks, website documentation, and vendor records to confirm that encryption decisions and online privacy statements remain current.
New to Us: Learn how coordinated compliance tools and experienced guidance can help your organization build a clearer and more sustainable privacy and security program.
References
- Stine, K., & Dang, Q. National Institute of Standards and Technology. Encryption Basics.
- Electronic Code of Federal Regulations. 45 C.F.R. § 164.312 Technical Safeguards.
- U.S. Department of Health and Human Services, Office for Civil Rights. Summary of the HIPAA Security Rule.
- U.S. Department of Health and Human Services. Guidance to Render Unsecured Protected Health Information Unusable, Unreadable, or Indecipherable to Unauthorized Individuals.
- U.S. Department of Health and Human Services, Office for Civil Rights. Breach Notification Rule.
- U.S. Department of Health and Human Services, Office for Civil Rights. HIPAA Security Rule Notice of Proposed Rulemaking Fact Sheet. December 27, 2024.
- U.S. Department of Health and Human Services, Office for Civil Rights. Notice of Privacy Practices for Protected Health Information.
- U.S. Department of Health and Human Services, Office for Civil Rights. Use of Online Tracking Technologies by HIPAA Covered Entities and Business Associates.