Many small businesses lack a formalized risk management policy, causing whatever risk analysis they have to be non-compliant. This isn’t an accusation; it’s a consistent pattern across regulated industries. Security frameworks are built for large enterprises and written for compliance professionals.
Regulators, however, do not care about this translation problem. HIPAA (45 CFR 164.308) and ISO 27001 (Clause 6.1), PCI-DSS, and many other frameworks mandate strict risk analysis and management programs. The moment a breach is reported or an audit is triggered, they will demand documentation. At that point, the question isn’t whether you have security gaps, it is whether you have proof you were managing them before your hand was forced.
Why Your Risk Management Policy Must Exist First
Most organizations, when pushed on compliance, will produce some version of a risk analysis — a spreadsheet, a completed template, a consultant’s report from three years ago. What almost none of them will produce is the risk management policy that should have governed that analysis before it was conducted. This distinction matters because a risk analysis produces scores, and scores without a documented framework defining what they mean and what response they require are not risk management. They are documentation that looks like risk management until someone looks closely.
The risk management policy is the framework document. It defines what a risk score of 6 requires versus a score of 2, who has the authority to accept a risk versus who can only recommend acceptance, how quickly each risk level must be remediated, and what treatment options are available at each level. Without it, your risk analysis is a list of problems with no committed organizational response — which is exactly what a regulator or auditor will note if they ever review your program.
What the Policy Needs to Define
A Scoring Scale — and It Has to Come First
Your framework may not prescribe a specific scoring methodology, but it requires that your risk analysis produce a meaningful assessment of likelihood and impact for each identified risk. The scale you use needs to be documented in the policy before the analysis runs, because defining the scale after you have already assigned scores produces a document that is not defensible.
A 1-3 scale for both likelihood and impact — generating risk scores from 1 to 9 — is simple, consistent, and grounded in NIST SP 800-30, the federal standard for conducting risk assessments. Auditors recognize it immediately, and referencing NIST 800-30 in your policy document signals that your methodology is based on an industry-accepted framework rather than something you invented.
| Score | Likelihood | Impact |
|---|---|---|
| 1 | Low — significant barriers to exploitation exist; the vulnerability is well-controlled by existing measures | Low — limited data exposure; no regulatory consequence likely |
| 2 | Medium — the threat is realistic and the vulnerability is partially controlled or commonly exploited in similar environments | Medium — moderate data exposure; potential regulatory consequence; recovery is feasible but disruptive |
| 3 | High — the threat is active and common; the vulnerability is uncontrolled or minimally controlled | High — significant data exposure; likely regulatory consequence; potential operational disruption or individual harm |
Risk score equals likelihood multiplied by impact. Scores of 1-2 are low, 3-4 are medium, and 6-9 are high. The policy must state explicitly what each level requires in terms of treatment and timing.
Risk Tolerance and Treatment Requirements
Risk tolerance is the level of risk your organization is willing to carry without taking additional action, and it must be defined and approved in writing by the accountable authority — the practice owner, the managing partner, the provider, whoever is ultimately responsible for the organization’s compliance obligations. A reasonable starting position for a small organization is that low-risk findings (scores of 1-2) are accepted within normal tolerance, documented in the risk register, and reviewed annually, while medium and high findings exceed tolerance and require a documented treatment decision.
For each risk level, the policy must specify what treatment options are available and what escalation is required. The four treatment options — mitigate, accept, transfer, and avoid — are covered in detail in Cybersecurity Risk Assessment. What the policy needs to make clear is that not every option is available for every finding, and this is where many organizations make a critical error.
Risk acceptance is a legitimate treatment option — but only for risks that are genuinely discretionary. If your framework mandates a specific control with no flexibility, you cannot document a risk acceptance decision and consider the matter closed. Under HIPAA, unique user identification (45 CFR 164.312(a)(2)(i)) is a required implementation specification. There is no flexibility in the standard.The same applies to any required control under ISO 27001 or any other framework. Your risk management policy should state explicitly that acceptance is not available as a treatment option for findings that implicate required controls with no addressable flexibility.
Remediation Timeframes
The policy must define specific remediation timeframes by risk level — not “as soon as possible,” which in practice means never. A finding that scores 9 should carry a 7-day remediation target. A score of 6 warrants 30 days. Medium findings at 3-4 can reasonably carry a 90-day window. Low findings get reviewed at the next annual cycle. These timeframes give your risk register teeth — without them, findings stay open indefinitely while everyone agrees that something should probably be done about them.
Acceptance Authority
The policy must define who can formally accept a risk at each level. The Security Officer may recommend acceptance but should not have the authority to approve it unilaterally for high-risk findings — that decision requires the accountable executive whose name is on the organization’s compliance obligations. In a small practice that is almost always the provider. Their signature on a risk acceptance decision is what makes that decision defensible to a regulator, and it ensures that someone with full organizational accountability is aware of every significant risk the organization is choosing to carry.
The risk management policy must be approved before the risk analysis is conducted. If you run the analysis first and write the policy afterward, you have produced documentation that describes a process you did not actually follow, and any auditor will catch that.
This Does Not Have to Be Complicated
A small practice does not need a 30-page policy document with elaborate governance structures. It needs two pages that define the scoring scale, reference NIST SP 800-30 as the methodological basis, state the organization’s risk tolerance, specify what treatment each risk level requires and what options are off the table for required controls, set remediation timeframes, and identify who has authority to accept a risk at each level. That document gets signed by the accountable authority and stored with the compliance documentation. It takes an afternoon to build from a solid template and it satisfies the risk management requirement under HIPAA, ISO 27001, and any other framework that requires it.
The foundational concepts that inform both the policy and the risk analysis — how to identify assets, how to think about threats and vulnerabilities, and how scoring works in practice — are covered in Cybersecurity Risk Assessment, Cybersecurity Threat Identification, and Cybersecurity Asset Inventory. Read those first if the terminology is unfamiliar, then build the policy.