HIPAA policy templates
Updated
22 free, editable security policies mapped to all 65 standards and implementation specifications of the HIPAA Security Rule (45 CFR 164.308 to 164.316). 44 are addressed by the policies, 17 partly, and 4 not at all, each with the reason and the policy sections that matter.
This is Policyseed's own mapping. It is not legal advice and not a determination by HHS or OCR, and adopting these policies does not by itself meet HIPAA. Citations, names and Required or Addressable markings follow the regulation; the plain-English summaries are ours, not the regulation text.
Who this is for
Small health-tech SaaS companies that sell to providers and hold their patients' data. If your product creates, receives, maintains or transmits protected health information for a covered entity, you are a business associate, and the Security Rule applies to you directly. The same customers usually ask about SOC 2 as well, so one set of policies that answers both saves writing two.
The policies were written against the SOC 2 Trust Services Criteria. When you tell the generator that you handle health data, several statements change: the vendor policy requires a business associate agreement before any vendor receives PHI, the retention policy keeps Security Rule documentation for six years, the incident policy commits to notifying the covered entity, and the classification, encryption, acceptable use, people and privacy policies add PHI rules. The section numbers below are read from that PHI version.
How to read the mapping
- Standards are always mandatory. Each one may have implementation specifications, which the regulation marks Required or Addressable.
- Addressable does not mean optional. You assess each one, then implement it, implement an equivalent alternative, or write down why neither is reasonable and appropriate for you.
- Addressed by policies: the policy text requires what the standard or specification asks for. You still have to follow it.
- Partly addressed: the policies cover some of it, or it asks for an activity, a record or a contract (an analysis performed, an evaluation run, an agreement signed) that a policy can require but cannot be.
- Not addressed by policies: nothing in the policies speaks to it. Here that is limited to requirements for clearinghouses, group health plans and government agencies, which a SaaS vendor records as not applicable.
Coverage at a glance
| Section | Items | Addressed | Partly | Not addressed |
|---|---|---|---|---|
| 164.308 Administrative safeguards | 30 | 23 | 6 | 1 |
| 164.310 Physical safeguards | 12 | 8 | 4 | 0 |
| 164.312 Technical safeguards | 12 | 10 | 2 | 0 |
| 164.314 Organizational requirements | 6 | 0 | 3 | 3 |
| 164.316 Policies and procedures and documentation requirements | 5 | 3 | 2 | 0 |
| Security Rule | 65 | 44 | 17 | 4 |
The 65 items are 22 standards and 43 implementation specifications (21 Required, 22 Addressable).
65 standards and specifications, built in your browser; nothing is uploaded. Opens in Excel, Numbers or Google Sheets.
The Audit Kit adds the same mapping as a HIPAA Security Rule sheet in its crosswalk.xlsx when your answers include health data, next to the SOC 2 crosswalk and the ISO 27001 Annex A sheet.
The Security Rule, standard by standard
164.308 Administrative safeguards (30)
Risk analysis and management, the security official, workforce access, training, incidents, contingency planning, evaluation and business associate agreements. Most of the Security Rule sits here.
| Citation | Name | In plain English | Policyseed policies and sections | Coverage |
|---|---|---|---|---|
| 164.308(a)(1)(i) | Security management processRequired (standard) | Have policies and procedures that prevent, detect, contain and correct security violations. | Information Security Policy 4.1, 4.4 Risk Assessment and Management Policy 4.1, 4.3 Logging and Monitoring Policy 4.7, 4.8 Incident Response Policy 4.6, 4.11 | Addressed by policiesP01 sets up a written, risk-based security program; the risk, logging and incident policies cover prevention, detection, containment and correction. The four specifications below carry the detail, and one of them (risk analysis) still has to be performed. |
| 164.308(a)(1)(ii)(A) | Risk analysisRequired | Carry out an accurate and thorough assessment of the risks and vulnerabilities to the confidentiality, integrity and availability of the ePHI you hold. | Risk Assessment and Management Policy 4.1, 4.2, 5.1, 5.2, 5.3 Data Classification and Handling Policy 5.1 | Partly addressedP17 requires an annual and triggered risk assessment of threats, vulnerabilities, likelihood and impact, and the P06 data inventory records which stores hold PHI. The policy is not the analysis: the assessment has to be performed, cover every system and flow that creates, receives, maintains or transmits ePHI, and be written down. |
| 164.308(a)(1)(ii)(B) | Risk managementRequired | Put security measures in place that bring the risks found in the analysis down to a reasonable and appropriate level. | Risk Assessment and Management Policy 4.4, 4.5, 4.6, 4.7, 5.4 Information Security Policy 4.4 Secure Software Development Policy 4.2, 5.1 | Addressed by policiesP17 requires a treatment decision for every risk, treatment plans with owners and due dates, written acceptance by a named authority, and a risk appetite that never accepts a High or Critical risk of exposing PHI. P10 adds a threat model for every feature that processes PHI. The treatment plan records come from carrying this out. |
| 164.308(a)(1)(ii)(C) | Sanction policyRequired | Apply appropriate sanctions to workforce members who do not follow the security policies and procedures. | Human Resources Security Policy 4.11, 5.8 Information Security Policy section 7 Acceptable Use Policy section 7 | Addressed by policiesP18 sets a documented, proportionate disciplinary process from retraining to termination, and every policy has an enforcement section. Keep a record of each sanction applied. |
| 164.308(a)(1)(ii)(D) | Information system activity reviewRequired | Regularly review records of system activity, such as audit logs, access reports and security incident reports. | Logging and Monitoring Policy 4.10, 5.5 Data Classification and Handling Policy 4.9, 5.5 Privacy and Data Protection Policy 4.8 Access Control Policy 5.8 | Addressed by policiesP12 requires a weekly review of alerts and privileged actions, P06 requires every access to PHI to be logged and the access logs to be sampled monthly against tickets, and P03 requires weekly review of access-change alerts. The dated review records are what show it happens. |
| 164.308(a)(2) | Assigned security responsibilityRequired (standard, Appendix A) | Name the one security official responsible for developing and implementing the security policies and procedures. | Information Security Policy section 3, 4.3 | Addressed by policiesP01 has Executive Management appoint a named Security Owner who owns the program and this policy set. Record that this person is your HIPAA security official. |
| 164.308(a)(3)(i) | Workforce securityRequired (standard) | Make sure workforce members who need ePHI have appropriate access, and keep everyone else out. | Access Control Policy 4.1, 4.7 Human Resources Security Policy 4.3, 4.5, 4.6 | Addressed by policiesLeast privilege and need-to-know (P03 4.1), named engineers only for direct access to customer data (P03 4.7), and role-based provisioning, role-change review and offboarding in P18. |
| 164.308(a)(3)(ii)(A) | Authorization and/or supervisionAddressable | Have procedures for authorizing or supervising workforce members who work with ePHI or where it can be accessed. | Access Control Policy 4.5, 4.7, 5.1, 5.2 Human Resources Security Policy 4.3 | Addressed by policiesAccess is requested by ticket and approved by the manager and system owner before it is granted, and direct queries against customer data are tied to a ticket or incident reference. |
| 164.308(a)(3)(ii)(B) | Workforce clearance procedureAddressable | Have a procedure to decide whether a workforce member's access to ePHI is appropriate. | Human Resources Security Policy 4.1, 4.4, 5.1 Access Control Policy 4.1 | Addressed by policiesPre-start screening (P18 4.1 and 5.1), PHI handling training before access is granted (P18 4.4) and the role-to-access matrix (P03 4.1). |
| 164.308(a)(3)(ii)(C) | Termination proceduresAddressable | Have procedures to end access to ePHI when someone leaves or their access is no longer appropriate. | Access Control Policy 4.11, 5.4 Human Resources Security Policy 4.6, 4.7, 5.6 | Addressed by policiesIdentity disabled by the end of the last working day, all other access removed within one business day, devices returned and wiped, with a timestamped checklist. |
| 164.308(a)(4)(i) | Information access managementRequired (standard) | Have policies and procedures for authorizing access to ePHI that fit the Privacy Rule's limits on use and disclosure. | Access Control Policy 4.1, 4.5 Privacy and Data Protection Policy 4.8 Data Classification and Handling Policy 4.9 | Addressed by policiesLeast-privilege access by approved request (P03), and PHI limited to the minimum necessary under a business associate agreement (P22 4.8, P06 4.9). |
| 164.308(a)(4)(ii)(A) | Isolating health care clearinghouse functionsRequired | A health care clearinghouse that is part of a larger organization must keep its ePHI protected from the rest of that organization. | None | Not addressed by policiesApplies only where a health care clearinghouse is part of a larger organization. A SaaS vendor that is not a clearinghouse records this specification as not applicable; if you do operate a clearinghouse, you need your own separation policy. |
| 164.308(a)(4)(ii)(B) | Access authorizationAddressable | Have policies and procedures for granting access to ePHI, for example through a workstation, program or process. | Access Control Policy 4.5, 4.6, 5.1, 5.2 Data Classification and Handling Policy 4.5 | Addressed by policiesTicketed requests approved by the manager and system owner, production roles through identity federation with session limits, and Restricted data access only on documented need. |
| 164.308(a)(4)(ii)(C) | Access establishment and modificationAddressable | Set up, document, review and change each user's access rights based on the access authorization rules. | Access Control Policy 4.10, 5.3, 5.4 Human Resources Security Policy 4.5, 5.5 | Addressed by policiesQuarterly access reviews for systems holding Restricted data, removals within five business days, and access re-checked on every role change. |
| 164.308(a)(5)(i) | Security awareness and trainingRequired (standard) | Run a security awareness and training program for the whole workforce, management included. | Information Security Policy 4.7, 5.3 Human Resources Security Policy 4.4, 5.4 Privacy and Data Protection Policy 5.8 | Addressed by policiesAwareness training within 30 days of starting and annually for all personnel, PHI-specific training before access to PHI, and phishing simulations twice a year. Completion records are the evidence. |
| 164.308(a)(5)(ii)(A) | Security remindersAddressable | Send the workforce periodic security updates and reminders. | Human Resources Security Policy 5.4 Acceptable Use Policy 5.5 Information Security Policy 5.2 | Partly addressedAnnual training, phishing simulations twice a year, team warnings about targeted phishing, and notice of policy revisions. No policy sets a standing cadence of security reminders between trainings; add one (a monthly note is common) or record why the existing touchpoints are enough. |
| 164.308(a)(5)(ii)(B) | Protection from malicious softwareAddressable | Have procedures to guard against, detect and report malicious software. | Endpoint and Workstation Security Policy 4.7, 4.8, 5.3 Acceptable Use Policy 4.8, 4.13, 5.5 Vulnerability and Patch Management Policy 4.1 | Addressed by policiesEndpoint protection with real-time scanning, malicious-site blocking, software only from official sources, container image scanning, and reporting of suspected malware within one hour. |
| 164.308(a)(5)(ii)(C) | Log-in monitoringAddressable | Have procedures to monitor log-in attempts and report discrepancies. | Authentication and Password Policy 4.9 Logging and Monitoring Policy 4.1, 4.7, 4.8 | Addressed by policiesEvery failed authentication is logged, alerts fire on brute force and credential stuffing, and alerts are triaged on set timelines and escalated as incidents. |
| 164.308(a)(5)(ii)(D) | Password managementAddressable | Have procedures for creating, changing and protecting passwords. | Authentication and Password Policy 4.4, 4.5, 4.6, 5.3, 5.4 Acceptable Use Policy 4.2 | Addressed by policiesLength and breached-password rules, change on suspected compromise, a password manager for every work credential, no sharing or reuse, and verified account recovery. |
| 164.308(a)(6)(i) | Security incident proceduresRequired (standard) | Have policies and procedures for dealing with security incidents. | Incident Response Policy 4.1, 4.2, 4.3, 5.1, 5.2 | Addressed by policiesP13 is a complete incident response policy: reporting within one hour, severity triage, a named Incident Commander, and a procedure from detection to post-incident review. |
| 164.308(a)(6)(ii) | Response and reportingRequired | Identify and respond to suspected or known incidents, limit their harm where practical, and document what happened and the outcome. | Incident Response Policy 4.4, 4.6, 4.9, 5.4, 5.6, 5.8 | Addressed by policiesContainment first, an incident record with timeline, decisions and evidence kept for seven years, eradication and recovery, and a post-incident review. P13 4.9 also covers notifying the covered entity when PHI is involved. |
| 164.308(a)(7)(i) | Contingency planRequired (standard) | Have policies and procedures for responding to an emergency or other event that damages systems holding ePHI. | Business Continuity and Disaster Recovery Policy 4.1, 4.2, 4.5 Backup and Recovery Policy 4.1 | Addressed by policiesP14 requires a business impact analysis, written recovery procedures for Tier 1 and Tier 2 systems and declaration criteria; P15 requires a documented backup approach for every system. |
| 164.308(a)(7)(ii)(A) | Data backup planRequired | Have procedures to create and keep retrievable exact copies of ePHI. | Backup and Recovery Policy 4.2, 4.3, 4.4, 4.10, 5.1 | Addressed by policiesScheduled backups with point-in-time recovery, a copy in a separate account or region, deletion protection, and backups holding PHI handled at the highest classification. |
| 164.308(a)(7)(ii)(B) | Disaster recovery planRequired | Have procedures to restore any lost data. | Business Continuity and Disaster Recovery Policy 4.2, 5.4 Backup and Recovery Policy 5.5 | Addressed by policiesWritten recovery procedures a competent engineer can follow, an offline copy, a recovery order, and a restore-request procedure. |
| 164.308(a)(7)(ii)(C) | Emergency mode operation planRequired | Have procedures that keep critical business processes running, and ePHI protected, while operating in an emergency. | Business Continuity and Disaster Recovery Policy 4.6, 4.7, 5.3, 5.5 | Addressed by policiesDuring a declared disaster, access control, encryption and logging stay in force, emergency access is time-limited and logged, and security is confirmed before a recovered system returns to service. |
| 164.308(a)(7)(ii)(D) | Testing and revision proceduresAddressable | Have procedures to test contingency plans periodically and revise them. | Business Continuity and Disaster Recovery Policy 4.10, 4.13, 5.2, 5.8, 5.9 Backup and Recovery Policy 4.8, 5.3 | Addressed by policiesAn annual technical restore of a Tier 1 environment, an annual tabletop, quarterly restore tests and a review with corrective actions after every test. The test records are the evidence. |
| 164.308(a)(7)(ii)(E) | Applications and data criticality analysisAddressable | Assess how critical each application and data set is, to support the rest of the contingency plan. | Business Continuity and Disaster Recovery Policy 4.1, 5.1 | Partly addressedP14 requires an annual business impact analysis that tiers every system. The analysis itself has to be performed and approved, and it should say which systems hold ePHI. |
| 164.308(a)(8) | EvaluationRequired (standard, Appendix A) | Periodically evaluate, technically and non-technically, how well your security policies and procedures meet the Security Rule, and again after environmental or operational changes. | Risk Assessment and Management Policy 4.13, 5.10 Information Security Policy 4.13, 5.8 Vulnerability and Patch Management Policy 4.12 | Partly addressedThe policies require an annual independent evaluation of the risk process, the SOC 2 examination and an annual penetration test. None of these is an evaluation against the Security Rule's own standards, which still has to be performed and documented (this mapping is a starting point for it). |
| 164.308(b)(1) | Business associate contracts and other arrangementsRequired (standard) | Let a business associate, or a subcontractor of a business associate, handle ePHI for you only after getting satisfactory written assurances that it will safeguard it. Paragraph (b)(2) applies the same rule between a business associate and its subcontractors. | Vendor and Third-Party Risk Management Policy 4.5, 5.3 Privacy and Data Protection Policy 4.8 | Partly addressedP16 4.5 requires a business associate agreement before any vendor receives PHI, and P22 4.8 processes PHI only under one. The agreements are contracts the policies cannot provide: each must be negotiated and signed. |
| 164.308(b)(3) | Written contract or other arrangementRequired | Document those assurances in a written contract or other arrangement that meets 164.314(a). | Vendor and Third-Party Risk Management Policy 4.5, 5.3 Information Security Policy 4.15, 5.9 | Partly addressedThe policies require the agreements and a register of contractual obligations; the written contracts themselves have to be signed, and no policy can stand in for them. |
164.310 Physical safeguards (12)
Facilities, workstations, devices and media. For a company whose systems run with a cloud provider, the data center part sits with the provider under its business associate agreement.
| Citation | Name | In plain English | Policyseed policies and sections | Coverage |
|---|---|---|---|---|
| 164.310(a)(1) | Facility access controlsRequired (standard) | Limit physical access to systems holding ePHI and the buildings they are in, while letting authorized people in. | Physical and Remote Work Security Policy 4.1, 4.2, 5.1, 5.2 | Partly addressedData centers are the hosting provider's: P21 relies on the provider's physical controls and requires a yearly review of its assurance report, and no production system may sit in an office or home. The provider's own business associate agreement has to cover this. Office entry rules apply only where an office exists. |
| 164.310(a)(2)(i) | Contingency operationsAddressable | Have procedures that allow facility access during an emergency to support data restoration and emergency operations. | Business Continuity and Disaster Recovery Policy 4.9 Physical and Remote Work Security Policy 4.1 | Partly addressedRecovery never depends on physical access to an office (P14 4.9), and data center access is the hosting provider's. There is no facility-access procedure because none is needed for a cloud-hosted company; record that reasoning as your decision on this addressable specification. |
| 164.310(a)(2)(ii) | Facility security planAddressable | Protect the facility and its equipment from unauthorized physical access, tampering and theft. | Physical and Remote Work Security Policy 4.1, 4.2, 4.3, 4.5 | Partly addressedOffice entry, locking and visitor rules exist where an office exists, and devices are protected away from the office. There is no standalone facility security plan; data center plans are the provider's. |
| 164.310(a)(2)(iii) | Access control and validation proceduresAddressable | Control and validate each person's access to facilities by role, including visitors, and control access to software for testing and revision. | Physical and Remote Work Security Policy 4.3, 5.2, 5.3, 5.4 Change Management Policy 4.6, 4.11 Secure Software Development Policy 4.7 | Addressed by policiesPhysical access issued and revoked by People Operations, a quarterly physical access review, a visitor log with escorts, and software changes tested in separated environments and deployed only by the pipeline. |
| 164.310(a)(2)(iv) | Maintenance recordsAddressable | Document repairs and changes to security-related physical parts of a facility, such as doors, locks and hardware. | Endpoint and Workstation Security Policy 5.10 | Partly addressedLaptop repairs are recorded in the device inventory (P19 5.10). Nothing requires a record of repairs or changes to office doors, locks or walls; data center maintenance is the provider's. |
| 164.310(b) | Workstation useRequired (standard, Appendix A) | Specify what workstations may be used for, how, and in what physical surroundings. | Acceptable Use Policy 4.1, 4.4, 4.11 Physical and Remote Work Security Policy 4.4, 4.6, 4.8 Endpoint and Workstation Security Policy 4.10 | Addressed by policiesAcceptable use of company devices, managed devices only for customer data, clear screens and private workspaces at home and in public, and no customer data stored on endpoints. |
| 164.310(c) | Workstation securityRequired (standard, Appendix A) | Physically safeguard every workstation that can reach ePHI so only authorized users can use it. | Endpoint and Workstation Security Policy 4.3, 4.4, 4.5 Physical and Remote Work Security Policy 4.5, 4.6 | Addressed by policiesManaged enrollment, full-disk encryption, automatic screen lock, devices never left unattended in public, and devices used only by the person they are assigned to. |
| 164.310(d)(1) | Device and media controlsRequired (standard) | Govern how hardware and electronic media holding ePHI come into, leave and move within the organization. | Asset Management Policy 4.1, 4.9 Endpoint and Workstation Security Policy 4.11 Physical and Remote Work Security Policy 4.13 | Addressed by policiesAn asset register for hardware and cloud resources, removable media blocked or approved and recorded, and tracked shipping of company equipment. |
| 164.310(d)(2)(i) | DisposalRequired | Have policies and procedures for the final disposal of ePHI and of the hardware or media it was stored on. | Data Retention and Disposal Policy 4.7, 4.8, 4.12, 5.5, 5.6 Asset Management Policy 4.8 Endpoint and Workstation Security Policy 4.13, 5.8 | Addressed by policiesCryptographic erasure or NIST SP 800-88 purge or destruction, remote erase of devices, certificates of destruction, a cloud decommissioning checklist, and a disposal log. |
| 164.310(d)(2)(ii) | Media re-useRequired | Remove ePHI from electronic media before the media is re-used. | Asset Management Policy 4.8 Data Retention and Disposal Policy 4.8 Endpoint and Workstation Security Policy 4.13, 5.7 | Addressed by policiesMedia and devices are sanitized before reuse, and devices are not reassigned until the wipe is recorded. |
| 164.310(d)(2)(iii) | AccountabilityAddressable | Keep a record of the movements of hardware and electronic media and who is responsible for them. | Asset Management Policy 4.1, 4.2, 5.2 Endpoint and Workstation Security Policy 4.2 Physical and Remote Work Security Policy 5.9 | Addressed by policiesThe asset register records owner, assigned user and location, changes are recorded within two business days, and shipments are tracked with the tracking number in the inventory. |
| 164.310(d)(2)(iv) | Data backup and storageAddressable | Make a retrievable, exact copy of ePHI, when needed, before equipment is moved. | Data Classification and Handling Policy 4.3 Endpoint and Workstation Security Policy 4.10 Backup and Recovery Policy 4.2 | Addressed by policiesCustomer data, including PHI, is never stored on endpoints and lives only in production and its managed backups, so moving a laptop never moves the only copy. Production hardware is the hosting provider's. |
164.312 Technical safeguards (12)
Access control, unique IDs, emergency access, automatic logoff, encryption, audit controls, integrity, authentication and transmission security.
| Citation | Name | In plain English | Policyseed policies and sections | Coverage |
|---|---|---|---|---|
| 164.312(a)(1) | Access controlRequired (standard) | Use technical controls so only people and software that have been granted access rights can reach systems holding ePHI. | Access Control Policy 4.1, 4.6, 4.7 Data Classification and Handling Policy 4.5 | Addressed by policiesLeast privilege, federated identity with short-lived credentials for production, and audited, ticketed direct access to customer data. |
| 164.312(a)(2)(i) | Unique user identificationRequired | Give every user a unique name or number so their activity can be tracked. | Access Control Policy 4.2, 4.9 Authentication and Password Policy 4.1 | Addressed by policiesEvery person has an individually attributable account; shared accounts are prohibited except documented break-glass credentials, and non-human identities each have a named owner. |
| 164.312(a)(2)(ii) | Emergency access procedureRequired | Have procedures for getting at necessary ePHI during an emergency. | Access Control Policy 4.2, 5.6 Business Continuity and Disaster Recovery Policy 4.7 | Addressed by policiesBreak-glass credentials, restricted to named people, for when normal access paths fail during an incident, with each use recorded, reviewed and followed by rotation; emergency access during recovery is time-limited and logged. |
| 164.312(a)(2)(iii) | Automatic logoffAddressable | End electronic sessions automatically after a set period of inactivity. | Authentication and Password Policy 4.7 Endpoint and Workstation Security Policy 4.5 | Partly addressedDevices lock after 10 minutes of inactivity and workforce and privileged sessions have maximum lifetimes. No policy sets an inactivity timeout for sessions in your own product, which is where covered entity users see ePHI; add one or record your decision. |
| 164.312(a)(2)(iv) | Encryption and decryptionAddressable | Have a way to encrypt and decrypt ePHI. | Encryption and Key Management Policy 4.2, 4.4, 4.9, 4.11 Data Classification and Handling Policy 4.4 | Addressed by policiesAll production data at rest is encrypted with keys in the provider's key management service, laptops use full-disk encryption, and PHI is encrypted in line with HHS guidance on unsecured PHI. |
| 164.312(b) | Audit controlsRequired (standard, Appendix A) | Use hardware, software or procedures that record and examine activity in systems that hold or use ePHI. | Logging and Monitoring Policy 4.1, 4.2, 4.3, 4.5 Data Classification and Handling Policy 4.9, 5.5 Access Control Policy 4.7 | Addressed by policiesAudit logging across cloud, identity, source control and the product, forwarded to a central platform, tamper-resistant, and every access to PHI logged. |
| 164.312(c)(1) | IntegrityRequired (standard) | Protect ePHI from improper change or destruction. | Access Control Policy 4.1, 4.7 Backup and Recovery Policy 4.4 Change Management Policy 4.2, 4.8 | Addressed by policiesLeast-privilege write access, reviewed changes, a verified backup before destructive migrations, and deletion-protected backups. |
| 164.312(c)(2) | Mechanism to authenticate electronic protected health informationAddressable | Use electronic means to confirm ePHI has not been altered or destroyed without authorization. | Backup and Recovery Policy 5.3 Business Continuity and Disaster Recovery Policy 5.5 Encryption and Key Management Policy 4.3 | Partly addressedChecksums or record counts verify restored data, and approved ciphers are authenticated modes that detect tampering. No policy requires a mechanism to detect unauthorized changes to stored ePHI in normal operation; add one or record your decision. |
| 164.312(d) | Person or entity authenticationRequired (standard, Appendix A) | Verify that a person or system seeking access to ePHI is who or what it claims to be. | Authentication and Password Policy 4.2, 4.3, 4.8, 4.10, 4.11 Access Control Policy 4.4 | Addressed by policiesMandatory multi-factor authentication (phishing-resistant for administrators), single sign-on, managed service credentials, verified account recovery, and protected customer authentication. |
| 164.312(e)(1) | Transmission securityRequired (standard) | Guard ePHI against unauthorized access while it travels over an electronic network. | Encryption and Key Management Policy 4.1, 4.11 Network and Infrastructure Security Policy 4.4 Data Classification and Handling Policy 4.9 | Addressed by policiesTLS 1.2 or higher on every network boundary, no plaintext protocols, and PHI never sent by email or chat. |
| 164.312(e)(2)(i) | Integrity controlsAddressable | Make sure ePHI sent electronically cannot be changed without detection. | Encryption and Key Management Policy 4.1, 4.3 | Addressed by policiesTLS 1.2 or higher with authenticated cipher modes (GCM, ChaCha20-Poly1305), which detect modification in transit. |
| 164.312(e)(2)(ii) | EncryptionAddressable | Encrypt ePHI in transit whenever appropriate. | Encryption and Key Management Policy 4.1, 4.11 Network and Infrastructure Security Policy 4.4 Acceptable Use Policy 4.5 | Addressed by policiesEncryption in transit everywhere, including exports and transfers to vendors, and PHI kept out of email and chat unless the Security Owner approves the channel. |
164.314 Organizational requirements (6)
What a business associate agreement must contain, plus requirements for group health plans that do not apply to a SaaS vendor.
| Citation | Name | In plain English | Policyseed policies and sections | Coverage |
|---|---|---|---|---|
| 164.314(a)(1) | Business associate contracts or other arrangementsRequired (standard) | The business associate agreement required by 164.308(b) must meet the contract terms in this section. | Vendor and Third-Party Risk Management Policy 4.4, 4.5, 5.3 | Partly addressedP16 requires a business associate agreement and lists security terms vendor contracts must contain. The agreements themselves must be signed, and their terms checked against this section. |
| 164.314(a)(2)(i) | Business associate contractsRequired | The agreement must commit the business associate to follow the Security Rule, to bind its subcontractors to the same, and to report security incidents, including breaches of unsecured PHI. | Vendor and Third-Party Risk Management Policy 4.4, 4.5 Incident Response Policy 4.9 | Partly addressedP16 4.4 requires vendors to report incidents within 72 hours and restricts sub-processors, and P13 4.9 commits you to notify the covered entity. The policies do not list the three clauses this specification requires; check each agreement you sign or issue for them. |
| 164.314(a)(2)(ii) | Other arrangementsRequired | A covered entity can rely on another arrangement that meets 164.504(e)(3), such as a memorandum of understanding between government entities, instead of a contract. | None | Not addressed by policiesThese arrangements are for government entities and situations where law already imposes the obligations. A private SaaS company uses a written business associate agreement; record this as not applicable. |
| 164.314(a)(2)(iii) | Business associate contracts with subcontractorsRequired | The same contract terms apply between a business associate and each subcontractor that handles ePHI. | Vendor and Third-Party Risk Management Policy 4.5, 5.3 Privacy and Data Protection Policy 4.6 | Partly addressedVendors that handle PHI sign a business associate agreement before receiving any, and obligations flow down to each sub-processor. The subcontractor agreements must actually be signed. |
| 164.314(b)(1) | Requirements for group health plansRequired (standard) | A group health plan's documents must require the plan sponsor to safeguard ePHI it handles for the plan, with limited exceptions. | None | Not addressed by policiesApplies to group health plans and their sponsors, not to a SaaS vendor serving providers. Record as not applicable. (Your own employee health plan, if you sponsor one, is a separate matter for your benefits counsel.) |
| 164.314(b)(2) | Implementation specifications (plan documents)Required | The plan documents must require the sponsor to apply safeguards, support separation from the plan, bind its agents and report security incidents to the plan. | None | Not addressed by policiesSame as 164.314(b)(1): a group health plan requirement, not applicable to a SaaS vendor. |
164.316 Policies and procedures and documentation requirements (5)
Written policies and procedures, records of required activities, six-year retention, availability to the people who use them, and periodic updates.
| Citation | Name | In plain English | Policyseed policies and sections | Coverage |
|---|---|---|---|---|
| 164.316(a) | Policies and proceduresRequired (standard) | Have reasonable and appropriate written policies and procedures for the Security Rule, sized to your organization, and document any changes to them. | Information Security Policy 4.1, 4.5, 5.2 Risk Assessment and Management Policy 4.8 | Partly addressedThis set is the policies and procedures, with versioned changes. It was written for SOC 2: the partly and not-addressed items on this page need a policy line or a documented decision, and the policies must be adopted by management and reflect your risk analysis. |
| 164.316(b)(1) | DocumentationRequired (standard) | Keep the policies and procedures in written or electronic form, and keep a written record of every action, activity or assessment the Security Rule requires to be documented. | Information Security Policy 4.5, 5.2, 5.5 Data Retention and Disposal Policy 4.6 | Partly addressedThe policies are written and versioned, and each procedure names its record. The records themselves (risk analysis, reviews, tests, training, incidents, decisions on addressable specifications) come from doing the work. |
| 164.316(b)(2)(i) | Time limitRequired | Keep the required documentation for six years from when it was created or last in effect, whichever is later. | Data Retention and Disposal Policy 4.6, 5.1 | Addressed by policiesWith PHI selected, P07 4.6 retains Security Rule documentation for at least six years from creation or last effective date, and the schedule keeps most security records for seven. Check that log review records are kept as documentation, not only under the 12-month log retention. |
| 164.316(b)(2)(ii) | AvailabilityRequired | Make the documentation available to the people responsible for carrying out the procedures it covers. | Information Security Policy 4.6, 5.2 Human Resources Security Policy 5.3 | Addressed by policiesPolicies are acknowledged at hire and on every revision, and revisions are communicated to affected personnel within ten business days. |
| 164.316(b)(2)(iii) | UpdatesRequired | Review the documentation periodically and update it when changes affect the security of ePHI. | Information Security Policy 4.5, section 8 | Addressed by policiesEvery policy is reviewed on the annual cycle and after significant changes to the business, technology or threats, and each review is recorded in its revision history. |
What HIPAA needs beyond the policies
A policy says what will happen. For HIPAA, as for SOC 2, the evidence is that it did. These are the pieces no template can supply:
- A risk analysis that has been performed. 164.308(a)(1)(ii)(A) asks for an accurate and thorough assessment of the risks to all the ePHI you hold, written down and kept current. The Risk Assessment and Management Policy requires one; doing it is separate work. OCR enforcement actions frequently cite a missing or incomplete risk analysis. The risk register template is a starting point.
- Signed business associate agreements. Upstream with each covered entity customer, and downstream with every subcontractor that can see PHI (hosting, database, logging, email, support tools). The agreements must contain the terms in 164.314(a). The vendor review template records each vendor's contract terms, including the business associate agreement where one applies.
- Training records. Completion records for awareness training and the PHI handling training the policies require before access, for every workforce member, management included. See the security awareness training materials.
- The audit log review that actually happens. The policies require a weekly log review and monthly sampling of PHI access; the dated review notes and follow-ups are what show it.
- Contingency testing. Restore tests, the annual recovery test and a tabletop, with the results and the plan changes they led to. See the business continuity plan template and the tabletop exercise.
- Written decisions on every Addressable specification, and a periodic evaluation against the Security Rule itself (164.308(a)(8)). The mapping on this page is a reasonable first draft of that evaluation.
Every item whose status depends on work outside the policies:
- 164.308(a)(1)(ii)(A) Risk analysis: A documented risk analysis covering all ePHI, repeated at least annually and after major changes.
- 164.308(a)(1)(ii)(D) Information system activity review: Dated records of the weekly log reviews and monthly PHI access sampling, with follow-up actions.
- 164.308(a)(5)(i) Security awareness and training: Training completion records for every workforce member, including the PHI training taken before access.
- 164.308(a)(7)(ii)(D) Testing and revision procedures: Records of the annual recovery test, the tabletop and the quarterly restore tests, with what changed in the plan as a result.
- 164.308(a)(7)(ii)(E) Applications and data criticality analysis: The business impact analysis and approved tier list, marking the systems that hold ePHI.
- 164.308(a)(8) Evaluation: A periodic written evaluation against each Security Rule standard and specification, repeated after significant changes.
- 164.308(b)(1) Business associate contracts and other arrangements: Signed business associate agreements with each covered entity customer and with every subcontractor that handles ePHI (hosting, database, logging, support tools).
- 164.308(b)(3) Written contract or other arrangement: The signed agreements, kept with the vendor record and the register of obligations.
- 164.314(a)(1) Business associate contracts or other arrangements: Business associate agreements whose terms meet 164.314(a), upstream with customers and downstream with subcontractors.
- 164.316(a) Policies and procedures: Management adoption of the policies, plus a written decision for every addressable specification: implemented, implemented through an alternative, or not reasonable and appropriate, and why.
- 164.316(b)(1) Documentation: The records each procedure produces, kept where the people who need them can find them.
What this mapping does not cover
- The Privacy Rule (45 CFR Part 164, Subpart E): permitted uses and disclosures, minimum necessary as a Privacy Rule standard, and individuals' rights. A business associate's Privacy Rule obligations come mostly through its business associate agreements.
- The Breach Notification Rule (45 CFR 164.400 to 164.414), except where the Incident Response Policy commits to notifying the covered entity under the business associate agreement (P13 4.9).
- State health privacy and breach laws, the FTC Health Breach Notification Rule, and 42 CFR Part 2 for substance use disorder records.
The proposed Security Rule update
On January 6, 2025, HHS published a proposed rule to update the Security Rule ("HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information", 90 FR 898). It is a proposal, not the law in force: when this mapping was checked, the eCFR text of Subpart C had not been amended. Among other changes it would remove the distinction between required and addressable specifications and add specific requirements such as a technology asset inventory and network map, encryption of ePHI, and multi-factor authentication. Check its current status with HHS before relying on either version.
How this relates to SOC 2
The same 22 policies are mapped to the SOC 2 Trust Services Criteria, and most HIPAA technical and administrative safeguards land on the same statements: access control, multi-factor authentication, logging, encryption, incident response, backups and vendor management. The evidence you collect for a SOC 2 examination (access reviews, change records, incident logs, restore tests, vendor reviews) is largely the evidence a covered entity or OCR would ask for.
The differences are in what HIPAA asks for by name: a risk analysis scoped to ePHI, business associate agreements, a named security official, a sanction policy, six-year retention of documentation, and written decisions on Addressable specifications. A SOC 2 report is an independent CPA opinion on your controls against the criteria; HIPAA has no equivalent report, and nobody issues one on HHS's behalf. To compare the other framework mapping, see the ISO 27001 policy templates, the SOC 2 to ISO 27001 mapping and the full security policy templates index.
Frequently asked questions
- Does a SaaS company have to follow HIPAA?
- If you create, receive, maintain or transmit protected health information on behalf of a covered entity (a health care provider, health plan or clearinghouse), you are a business associate. Since the 2013 Omnibus Rule, business associates are directly subject to the Security Rule and to parts of the Privacy and Breach Notification Rules, on top of whatever the business associate agreement says. A SaaS company that never handles PHI for a covered entity is not a business associate on that account, and keeping health data out of your product is often the simplest answer.
- What is the difference between Required and Addressable?
- A Required implementation specification must be implemented. An Addressable one is not optional: you assess whether it is reasonable and appropriate for you, then either implement it, implement an equivalent alternative, or document why neither is reasonable and appropriate. The written decision is part of your documentation. Standards themselves are always mandatory.
- Is adopting these policies enough for HIPAA?
- No. Policies are one requirement of the Security Rule (164.316) and the place where most others are written down, but the rule also asks for a performed risk analysis, signed business associate agreements, training that actually happens, log reviews that actually happen, tested contingency plans and a periodic evaluation. The mapping on this page marks each of those as partly addressed so you can see the remaining work.
- Do we need a business associate agreement with our cloud provider?
- If ePHI is stored or processed on it, yes. HHS guidance on cloud computing treats a cloud provider that maintains ePHI as a business associate even when the data is encrypted and the provider holds no key. The major cloud providers offer a business associate agreement, usually covering a published list of eligible services, so check that every service you put ePHI in is on that list. The same applies to your database host, logging tool, support desk and any other subcontractor that can see PHI.
- Is there an official HIPAA seal or approval for vendors?
- No. HHS does not endorse or recognize any private seal, badge or attestation as showing that an organization meets HIPAA. OCR enforces the rules through complaint investigations, breach reviews and audits of covered entities and business associates. What customers can check is your evidence: the risk analysis, policies, agreements and records.
- Will our SOC 2 report answer a hospital's HIPAA questions?
- Partly. The controls overlap heavily, so a SOC 2 report covers much of the same ground, and many health systems accept one alongside a HIPAA mapping like this one and a signed business associate agreement. A SOC 2 report does not test against the Security Rule itself. Some CPA firms offer a SOC 2 report that also covers HIPAA Security Rule requirements as additional subject matter; ask your firm if your customers want that.
- What about the proposed changes to the Security Rule?
- HHS published a proposed update in January 2025. It is a proposal: the mapping on this page follows the rule as it stands in the Code of Federal Regulations. If the update is finalized, the Required and Addressable column and several statuses here would change. Check its current status with HHS.
- Is anything uploaded?
- No. This page is static, and the CSV is built in your browser when you click the button. The policy generator also runs in your browser and keeps your answers in local storage.
HIPAA is the Health Insurance Portability and Accountability Act of 1996; the Security Rule is at 45 CFR Part 164, Subpart C, administered by the HHS Office for Civil Rights. Policyseed is not affiliated with HHS or OCR. Citations and names are given for reference from the eCFR; the summaries are our own.
Policyseed provides governance policy templates and AI tailoring. It is not legal advice and not a compliance guarantee. Management adopts the policies; the CPA firm performs the SOC 2 examination.