The short answer: written policies are a legal requirement on their own
If you arrived here from a training course or a compliance quiz, the question probably read something like this: the Security Rule legally requires organizations to keep and maintain written policies and procedures, true or false. The answer is true, and the citation is 45 CFR 164.316(b)(1), which requires covered entities and business associates to maintain the policies and procedures they implement under the Security Rule in written form, which may be electronic. The Privacy Rule imposes its own version of the same duty at 45 CFR 164.530(i), which requires covered entities to implement policies and procedures designed to comply with every privacy standard that applies to them. Between those two provisions, HIPAA policies and procedures are not a best practice or a sign of maturity. They are a standalone legal requirement, and failing to write them down is itself a violation even if nobody ever mishandles a single record. That surprises a lot of practice managers, because the day-to-day work of protecting patient information feels like the real obligation and the paperwork feels like an afterthought. Regulators see it the other way around. An investigator cannot watch how your front desk actually behaves, but they can read what you told your workforce to do, check when leadership approved it, and compare it against what the regulation demands. This guide walks through where the policy requirements live, which specific policies the Privacy Rule, Security Rule, and Breach Notification Rule each expect, and how to write and maintain a set that holds up.
The fastest way to understand why written policies matter is to look at how an Office for Civil Rights investigation starts. After a breach report or a complaint, OCR sends a data request, and the first items on that list are almost always the organization's policies and procedures relevant to the incident, along with proof of when they were adopted and how the workforce was trained on them. If you cannot produce them, the investigation widens, because a missing policy suggests the compliance program underneath it is missing too. The enforcement record shows how expensive that inference gets. In 2017, CardioNet, a remote mobile cardiac monitoring provider, paid 2.5 million dollars to settle after a laptop containing the health information of 1,391 patients was stolen from an employee's parked car. What turned a single stolen laptop into a seven-figure settlement was not the theft itself but what OCR found when it asked for documentation: the company's Security Rule policies were still in draft form and had never been implemented, and it had no final policies governing the movement of devices containing electronic protected health information outside its facilities. A draft policy is legally equivalent to no policy. The same logic runs through dozens of other resolution agreements, where the cited failure is not the incident but the absence of implemented policies and procedures behind it. Under the penalty structure at 45 CFR 160.404, that absence can push conduct into the willful neglect tiers, where minimum penalties jump sharply and the annual cap per violation type reaches 2,190,294 dollars.
Where the requirement lives: 164.530(i), 164.316, and the six-year rule
The Privacy Rule's policy requirement sits in the administrative requirements section at 45 CFR 164.530(i)(1). It obligates a covered entity to implement policies and procedures with respect to protected health information that are designed to comply with the standards, implementation specifications, and other requirements of the Privacy Rule. The word designed matters: the policies must map to the actual regulatory text, not to a generic notion of confidentiality. The provision continues at 164.530(i)(2) through (i)(5) with a change-management duty that most organizations overlook. When the law changes, or when the covered entity materially changes its own practices, it must revise the affected policies promptly, update its Notice of Privacy Practices if the change affects what the notice says, and document the revision. The documentation rule at 164.530(j) then requires the entity to maintain the policies and procedures in written or electronic form, and to retain each version for six years from the date it was created or the date it was last in effect, whichever is later. That six-year clock on superseded versions is the detail auditors use to test whether a compliance program is real. If a policy was revised in 2024, OCR can still demand the 2022 version, because a complaint about conduct in 2022 is judged against the policy that governed at the time. Organizations that overwrite old policy files with each revision, keeping no version history, are quietly destroying the evidence they will need.
The Security Rule's version of the requirement lives at 45 CFR 164.316 and is broader in an important way: it binds business associates directly, not just covered entities. Section 164.316(a) requires reasonable and appropriate policies and procedures to comply with the standards, implementation specifications, and other requirements of the Security Rule, taking into account the flexibility factors at 164.306(b)(2), which are the organization's size, complexity, and capabilities, its technical infrastructure, the cost of security measures, and the probability and criticality of the risks to electronic protected health information. A two-dentist practice and a hospital system are not expected to produce identical manuals, but both are expected to produce manuals. Section 164.316(b) then adds three maintenance duties. The policies must be written, which may be electronic, under (b)(1). They must be retained for six years from creation or last effective date under (b)(2)(i), mirroring the Privacy Rule clock. They must be made available to the people responsible for implementing them under (b)(2)(ii), which means a policy locked in a compliance officer's drawer fails even if it is well written. And under (b)(2)(iii) they must be reviewed periodically and updated in response to environmental or operational changes, so a manual written in 2019 that predates your move to a cloud EHR is out of compliance on its face. The Breach Notification Rule closes the loop at 45 CFR 164.414(a), which applies the administrative requirements of 164.530, including the policy and documentation duties, to breach notification obligations. All three rules, in other words, expect their own policies.
Related implementation paths
The privacy policies and procedures every covered entity needs
Start the privacy policy set with the rules that govern using and disclosing protected health information, because that is where daily decisions happen. You need a policy stating when PHI may be used or disclosed without authorization for treatment, payment, and health care operations under 45 CFR 164.506, and a procedure for obtaining a valid written authorization under 164.508 for everything outside those categories, including the special authorization rules for psychotherapy notes, marketing, and any sale of PHI. You need a policy covering the informal permissions at 164.510, which govern facility directories and disclosures to family members and friends involved in care, including what staff should do when the patient is unconscious or unavailable. You need a policy addressing the twelve public-interest permissions at 164.512, at minimum the ones your organization actually encounters: disclosures required by law, to public health authorities, and for law enforcement purposes, each with its own conditions. Layered over all of these sits the minimum necessary standard at 164.502(b), implemented through 164.514(d), which requires written role-based rules about who in your workforce needs access to which categories of PHI, and 164.514(h), which requires procedures for verifying the identity and authority of anyone requesting PHI before you release it. Finally, the patient rights procedures need policies of their own: access to records within the 164.524 deadlines, amendment requests under 164.526, an accounting of disclosures under 164.528, and restriction requests and confidential communications under 164.522, including the mandatory restriction for services paid fully out of pocket.
The second half of the privacy set is administrative, and it comes almost entirely from 45 CFR 164.530. You must designate a privacy official responsible for the policies and a contact person for complaints under 164.530(a), and the designation itself must be documented. You need a training policy under 164.530(b) that commits to training every workforce member on the policies relevant to their role, within a reasonable period after hire and after any material policy change, with documented completion. You need a safeguards policy under 164.530(c) covering administrative, technical, and physical protections for PHI in all forms, which is where paper charts, printed schedules, and conversations in hallways get addressed, since the Security Rule only reaches electronic PHI. You need a complaint procedure under 164.530(d) that tells patients and workforce members where to raise concerns, a sanctions policy under 164.530(e) that commits to consistent discipline for violations, a mitigation policy under 164.530(f) that obligates the organization to lessen harm from any improper use or disclosure it learns about, and a non-retaliation policy under 164.530(g) protecting anyone who files a complaint or cooperates with an investigation. The Notice of Privacy Practices under 164.520 is technically a patient-facing document rather than an internal policy, but it must accurately reflect your policies, and a procedure for distributing it, posting it, and collecting acknowledgments belongs in the manual. When any policy in this set changes materially, remember that the notice, the training, and the documentation all have to move together.
The security policies and procedures the Security Rule expects
The security policy set begins with the administrative safeguards at 45 CFR 164.308, and the first standard is the one OCR cites most often: the security management process at 164.308(a)(1), which requires a documented risk analysis procedure, a risk management procedure for reducing identified risks to reasonable levels, a sanction policy for security violations, and a procedure for regularly reviewing information system activity such as audit logs and access reports. Your risk analysis policy should state who runs it, how often, what triggers an off-cycle rerun, and where findings are tracked, because an undocumented risk analysis is treated as not having happened. From there, 164.308(a)(2) requires a documented designation of a security official. Workforce security at 164.308(a)(3) needs procedures for authorizing access to electronic PHI, screening workforce members, and terminating access when someone leaves, with the termination procedure deserving special care since unrevoked credentials are a recurring settlement theme. Information access management at 164.308(a)(4) requires written rules for granting and modifying access rights. Security awareness and training at 164.308(a)(5) expects a program covering security reminders, malicious software protection, log-in monitoring, and password management. Security incident procedures at 164.308(a)(6) must define what counts as an incident, who responds, and how outcomes are documented. The contingency plan standard at 164.308(a)(7) requires a data backup plan, a disaster recovery plan, and an emergency mode operation plan, with testing and criticality analysis as addressable specifications. Evaluation at 164.308(a)(8) commits you to periodic technical and nontechnical reviews of whether the policies still match reality.
The physical and technical safeguards fill out the rest of the security manual. Under 45 CFR 164.310 you need facility access control procedures covering contingency access, a facility security plan, visitor and access validation procedures, and maintenance records for physical security changes. You need a workstation use policy under 164.310(b) describing what may be done on machines that touch electronic PHI, and a workstation security policy under 164.310(c) covering screen placement, locking, and physical protection. Device and media controls under 164.310(d) require documented procedures for the final disposal of hardware containing ePHI, for wiping media before re-use, and, as addressable specifications, for tracking device movement and backing up data before equipment moves, which is exactly the policy family CardioNet was missing and which covers laptops, USB drives, and the hard drives inside copiers and printers. On the technical side, 164.312 expects an access control policy implementing unique user identification and emergency access procedures, with automatic logoff and encryption as addressable specifications, an audit controls policy under 164.312(b) stating what activity your systems record and who reviews it, an integrity policy under 164.312(c), an authentication policy under 164.312(d) covering how users prove identity, including your password and multi-factor rules, and a transmission security policy under 164.312(e) governing encryption of ePHI in motion. Remember that addressable never means optional: under 164.306(d), if you decide not to implement an addressable specification like encryption, the policy file must contain your written assessment of why it was not reasonable and appropriate and what you did instead.
Breach notification, business associates, and the policies people forget
The Breach Notification Rule needs its own procedure set, and it is the one most likely to be tested under time pressure. Your incident response policy should hand off into a breach assessment procedure that walks the four-factor risk assessment at 45 CFR 164.402: the nature and extent of the information involved, the unauthorized person who received it, whether the information was actually acquired or viewed, and the extent of mitigation. The policy should then map the notification deadlines: individual notice without unreasonable delay and no later than 60 days after discovery under 164.404, media notice for breaches affecting more than 500 residents of a state under 164.406, and notice to the Secretary under 164.408, immediately for large breaches and within 60 days after year end for smaller ones. Business associates need a parallel policy implementing their duty under 164.410 to notify the covered entity without unreasonable delay and no later than 60 days after discovery, and covered entities should have a contractual expectation of much faster reporting written into their agreements. That points to the last mandatory policy family: business associate management. Under 164.308(b) and 164.502(e), you need a procedure for identifying which vendors are business associates, executing agreements that contain the required provisions of 164.504(e) before PHI flows, and tracking renewal and termination. Keep an inventory of signed agreements with the policy manual, because OCR routinely asks for the specific agreement covering the vendor involved in an incident, and a missing agreement is a violation independent of the breach.
Beyond the mandatory core, several policies earn their place in the manual because they answer questions the regulations only address indirectly, and their absence shows up in enforcement narratives again and again. A mobile device and BYOD policy translates the access control, encryption, and media control requirements into rules for phones and tablets that leave the building. A remote work policy does the same for home offices, covering household member access, screen privacy, home network expectations, and paper handling. A social media policy addresses the recurring disaster of staff posting about patients, which OCR has treated as an impermissible disclosure even when no name appears, since the eighteen identifiers reach photos, dates, and any detail that could identify someone. A disposal policy should cover paper via shredding under the 164.530(c) safeguards duty as well as electronic media sanitization consistent with NIST guidance. A fax and copier policy covers misdirected transmissions and the stored images on multifunction device hard drives. If you operate in a state with stricter rules, such as Texas with its HB 300 training and breach requirements or California with its medical information statutes, a preemption policy should state which rules control on each point, since HIPAA sets a federal floor rather than a ceiling. None of these documents needs to be long. A page that names an owner, states the rule, and describes the procedure beats twenty pages nobody reads, and shorter policies are easier to keep current through the required periodic review.
Writing, maintaining, and proving the policy manual
Writing the manual goes fastest when you let your risk analysis drive the order instead of drafting alphabetically. Run a Security Rule risk assessment first, list the gaps it surfaces, and write or fix the policies tied to the highest-rated risks before polishing anything cosmetic, because that sequence mirrors how 164.308(a)(1) expects risk management to work and produces a defensible narrative if you are ever asked why a given policy came last. For each policy, capture the same skeleton: the regulatory citation it implements, the plain-language rule, the procedure that carries it out, the named role that owns it, the effective date, and the approval signature or electronic equivalent. Template policies are a legitimate starting point, and our policy and procedure manual guide walks through assembling one, but every template must be tailored until it describes what your organization actually does, because a policy promising daily log review that nobody performs is worse than a policy promising weekly review that happens. Version control is not optional given the six-year retention rules, so keep superseded versions with their effective date ranges rather than overwriting files. Set a standing annual review cadence plus defined triggers for off-cycle review, such as a new system, a new location, an incident, or a regulatory change. On that last point, the Security Rule update proposed in January 2025 would, if finalized, make many currently addressable specifications mandatory and tighten documentation expectations, and while no final rule has been issued as of July 2026, drafting new policies to that stricter standard now is cheap insurance.
The last requirement is the one that makes every other policy real: your workforce has to know what the policies say, and you have to be able to prove it. The Privacy Rule ties the two together explicitly at 164.530(b), which requires training on policies and procedures, not on HIPAA in the abstract, and requires retraining within a reasonable period whenever a material policy change affects someone's job. The Security Rule matches it at 164.308(a)(5) with the security awareness and training standard. In practice that means every policy rollout needs three artifacts filed together: the approved policy, the training that communicated it, and the completion records showing who took the training and when, all retained on the same six-year schedule as the policy itself. The sanctions policy is what closes the loop, because applying documented, consistent discipline when someone violates a policy is the strongest evidence an organization can offer that its manual governs real behavior rather than decorating a shelf. If you are building this program now, sequence it the way an investigator would test it: assess your risks, write the policies the assessment demands, train every workforce member on the policies relevant to their role with verifiable completion certificates, and review the whole set on a schedule you actually keep. Our team training plans exist for exactly that middle step, pairing role-appropriate HIPAA certification with the per-person completion records your training policy promises, and the free practice test gives staff a low-stakes way to check their knowledge before the real assessment.