164.312(c)(1)
Technical Safeguards
Integrity
High Risk
Moderate
Medium
Implement policies and procedures to protect ePHI from improper alteration or destruction.
Implementation Guidance
Implement policies and procedures to protect ePHI from improper alteration or destruction. The standard at 164.312(c)(1) is supported by one addressable specification, the mechanism to authenticate ePHI at 164.312(c)(2), which asks for electronic means to corroborate that data has not been altered or destroyed without authorisation.
Integrity failures are less visible than confidentiality failures and often more dangerous clinically: a silently altered allergy record or medication dose can cause direct patient harm, and ransomware that encrypts or corrupts records is an integrity and availability event as much as a confidentiality one.
Implementation approach:
• Restrict who can modify ePHI, and separate the ability to change data from the ability to change the audit trail
• Enforce validation at entry — type, range, format and clinical plausibility checks — so bad data is rejected rather than stored
• Maintain record versioning or an amendment history so prior values remain recoverable and visible
• Apply cryptographic corroboration where it is reasonable and appropriate: hashes or checksums on stored records, archives and exports, and digital signatures where authorship matters
• Verify integrity on transfer, backup and restore, and compare hashes rather than assuming success
• Protect against malware and ransomware, which are the most common cause of large-scale integrity loss
• Test restores regularly; an untested backup is an assumption, not a control
• Log and alert on unexpected bulk modification or deletion
Where you decide not to implement the addressable authentication mechanism, document the reasoning and the alternative safeguard under 164.306(d).
Integrity failures are less visible than confidentiality failures and often more dangerous clinically: a silently altered allergy record or medication dose can cause direct patient harm, and ransomware that encrypts or corrupts records is an integrity and availability event as much as a confidentiality one.
Implementation approach:
• Restrict who can modify ePHI, and separate the ability to change data from the ability to change the audit trail
• Enforce validation at entry — type, range, format and clinical plausibility checks — so bad data is rejected rather than stored
• Maintain record versioning or an amendment history so prior values remain recoverable and visible
• Apply cryptographic corroboration where it is reasonable and appropriate: hashes or checksums on stored records, archives and exports, and digital signatures where authorship matters
• Verify integrity on transfer, backup and restore, and compare hashes rather than assuming success
• Protect against malware and ransomware, which are the most common cause of large-scale integrity loss
• Test restores regularly; an untested backup is an assumption, not a control
• Log and alert on unexpected bulk modification or deletion
Where you decide not to implement the addressable authentication mechanism, document the reasoning and the alternative safeguard under 164.306(d).
Required Documentation
• Data integrity policy and supporting procedures
• Data validation rules and where they are enforced
• Record versioning or amendment history design, and retention of prior values
• Integrity mechanism decision record for 164.312(c)(2), including equivalent alternatives where not implemented
• Checksum, hash or digital signature standard and the systems it covers
• Backup and restore procedures, with completed restore test records
• Malware and ransomware protection configuration and coverage evidence
• Change control records for systems processing ePHI
• Integrity incident records, including detection, investigation and correction
• Alert definitions for unexpected bulk modification or deletion
• Data validation rules and where they are enforced
• Record versioning or amendment history design, and retention of prior values
• Integrity mechanism decision record for 164.312(c)(2), including equivalent alternatives where not implemented
• Checksum, hash or digital signature standard and the systems it covers
• Backup and restore procedures, with completed restore test records
• Malware and ransomware protection configuration and coverage evidence
• Change control records for systems processing ePHI
• Integrity incident records, including detection, investigation and correction
• Alert definitions for unexpected bulk modification or deletion
Best Practices
• Keep immutable or append-only audit trails so alteration of the record is always detectable
• Retain version history for clinical data rather than overwriting in place
• Hash records and archives at rest, and verify on access, transfer and restore
• Use digital signatures where authorship or non-repudiation matters, such as orders and consent
• Hold at least one backup copy offline or immutable so ransomware cannot reach it
• Test restores on a schedule and record the outcome, including time taken
• Alert on anomalous bulk change or deletion patterns rather than relying on discovery
• Apply strict change control to systems processing ePHI, including database schema changes
• Validate data at the point of entry, where correction is cheapest and safest
• Retain version history for clinical data rather than overwriting in place
• Hash records and archives at rest, and verify on access, transfer and restore
• Use digital signatures where authorship or non-repudiation matters, such as orders and consent
• Hold at least one backup copy offline or immutable so ransomware cannot reach it
• Test restores on a schedule and record the outcome, including time taken
• Alert on anomalous bulk change or deletion patterns rather than relying on discovery
• Apply strict change control to systems processing ePHI, including database schema changes
• Validate data at the point of entry, where correction is cheapest and safest
Common Violations
• No mechanism at all to detect that ePHI has been altered
• Backups configured but never restore-tested, so integrity is assumed rather than known
• All backup copies reachable from the production network, leaving nothing safe from ransomware
• Records overwritten in place with no version history, making improper alteration undetectable
• Weak or absent input validation allowing implausible clinical values to be stored
• Privileged users able to change both the data and the audit trail that would reveal it
• The addressable authentication mechanism dismissed with no documented decision
• Malware protection missing from servers, medical devices or cloud workloads
• Integrity treated purely as a backup question, with no detection component
• Backups configured but never restore-tested, so integrity is assumed rather than known
• All backup copies reachable from the production network, leaving nothing safe from ransomware
• Records overwritten in place with no version history, making improper alteration undetectable
• Weak or absent input validation allowing implausible clinical values to be stored
• Privileged users able to change both the data and the audit trail that would reveal it
• The addressable authentication mechanism dismissed with no documented decision
• Malware protection missing from servers, medical devices or cloud workloads
• Integrity treated purely as a backup question, with no detection component
Testing Procedures
• Attempt to write invalid data and confirm validation rejects it rather than storing it
• Modify a test record and confirm the prior value remains recoverable through version or amendment history
• Verify hash or checksum generation and validation on stored records, archives and exports
• Perform a full restore from backup into an isolated environment and compare against expected content
• Confirm integrity verification occurs on transfer and after restore, with recorded results
• Attempt an unauthorised modification and confirm it is prevented, logged and alerted
• Confirm malware protection is deployed, current and covering every system holding ePHI
• Review change control records for a sample of recent changes to ePHI systems
• Test the alert path for bulk deletion or modification end to end
• Confirm the ability to modify data is separated from the ability to modify audit records
• Modify a test record and confirm the prior value remains recoverable through version or amendment history
• Verify hash or checksum generation and validation on stored records, archives and exports
• Perform a full restore from backup into an isolated environment and compare against expected content
• Confirm integrity verification occurs on transfer and after restore, with recorded results
• Attempt an unauthorised modification and confirm it is prevented, logged and alerted
• Confirm malware protection is deployed, current and covering every system holding ePHI
• Review change control records for a sample of recent changes to ePHI systems
• Test the alert path for bulk deletion or modification end to end
• Confirm the ability to modify data is separated from the ability to modify audit records
Implementation Resources
Download expert-developed templates and checklists to implement this control:
Quick Facts
Control ID
164.312(c)(1)
Category
Technical Safeguards
Risk Level
High
Difficulty
Moderate
Est. Cost
Medium
Timeframe
2-4 months
Last Updated
Sep 3, 2026
Related Controls
Explore other controls in the Technical Safeguards category.
164.312(d)
Critical
Person or Entity Authentication
Implement procedures to verify that a person or entity seeking access to ePHI is the one claimed.
164.312(e)
Critical
Transmission Security
Implement technical security measures to guard against unauthorized access to ePHI that is being transmitted over an electronic communications…
164.312(a)(1)
Critical
Access Control
Implement technical policies and procedures for electronic information systems that maintain ePHI to allow access only to those persons or software…
Need Help Implementing This Control?
Our certified HIPAA experts can help you implement this control correctly and efficiently.