[vivegi]

In the healthcare industry in USA, Personal Identification Information (PII)/Personal Health Information (PHI) needs to be encrypted at rest and in transit and is mandated by law. So, they are required to encrypt PII/PHI data fields.

Some of those practices may be generally applied for non-healthcare settings as well.

[racingmars]

To get nitpicky... (usual disclaimer, IANAL but I worked in health IT including heavy involvement in HIPAA topics earlier in my career) I don't think there's a requirement under HIPAA or HITECH to use encryption.

The relevant parts of HIPAA are the duty to not disclose PHI to unauthorized recipients and breach notification requirements if you do incorrectly disclose PHI (the HIPAA breach notification rule).

The magic of encryption is that HIPAA provides safe harbor if the data stolen/lost/intercepted was encrypted to certain standards. So if you lose an encrypted hard drive full of PHI, or someone breaks into your servers and steals encrypted data but not the decryption capability, then it's not considered a breach under HIPAA and you do not need to notify anyone.

Tons of PHI isn't stored encrypted at rest. Physical theft of the hard drive from the practice's back-end EHR database server hasn't generally been high priority on the HIPAA breach potential risk assessment list. But nearly all data in transit, on employee laptops, etc. will be encrypted, because that's where you want the safety net of the safe harbor provision.

[vivegi]

You are right. The law mandates reasonable safeguards and one of them is encryption at rest/motion when deemed necessary by the covered entity (which is quite common in Healthcare).

From the HHS site: https://www.hhs.gov/hipaa/for-professionals/faq/2001/is-the-...

> Is the use of encryption mandatory in the Security Rule?

> Answer:

> No. The final Security Rule made the use of encryption an addressable implementation specification. See 45 CFR § 164.312(a)(2)(iv) and (e)(2)(ii). The encryption implementation specification is addressable, and must therefore be implemented if, after a risk assessment, the entity has determined that the specification is a reasonable and appropriate safeguard in its risk management of the confidentiality, integrity and availability of e-PHI. If the entity decides that the addressable implementation specification is not reasonable and appropriate, it must document that determination and implement an equivalent alternative measure, presuming that the alternative is reasonable and appropriate. If the standard can otherwise be met, the covered entity may choose to not implement the implementation specification or any equivalent alternative measure and document the rationale for this decision.

[KingOfCoders]

Does at-rest mean: encrypted on storage so noone can physically steal a drive or encrypted in the database so noone can get the information with SQL without the key (e.g. Postgres column encryption)?

[vivegi]

Conceptually, yes. You can encrypt at the database/filesystem level (where the OS/DB engine manages the encryption keys and enforces access control), at a table level/column level (where the db engine enforces access control) or at the application level (where the application manages the encryption keys and they are separate from the database engine).

They serve different purposes. For eg: When a disk drive is faulty and thrown away, you may not want data to be recoverable from it. So, the filesystem level encryption helps there. A db/table/column level encryption helps when there are different applications (eg: transaction processing and analytics) accessing a shared database. Reporting queries may not need access to the sensitive fields whereas certain transaction processes may need it. In this case, db/table/column level encryption helps. When you want separation of concerns, you can add application level encryption (on top of the other two). Example: Your data is stored on the cloud and you don't want the cloud service provider to know the data or if they replace a disk drive as part of normal servicing, you don't want your data to leak.

This depends on the threat model.