The risk assessment policy template, with a scoring scale
How risks are found, scored, treated and accepted, and what makes you look again.
A risk assessment policy template sets how often you look for risks, how you score them, who decides what to do about each one, and what makes you look again. For SOC 2 it answers CC3.1 to CC3.4: objectives clear enough to assess, risks identified and analyzed, fraud considered, and significant changes reassessed.1
The policy below uses a 1 to 5 scale for likelihood and impact, the same one the risk register template uses.
What an auditor checks
- An assessment in the period. A dated record of the annual assessment and who took part.
- A register that follows the method. Every row scored on the written scale, with an owner and a treatment.
- Fraud on the list. At least one row about misuse or override of a control, because CC3.3 asks for it.
- Acceptances with a signature. For each accepted risk, the approver, the date and the revisit date.
- Change that triggered a look. A new vendor or product in the period and the register rows updated for it.
The full policy text
The scoring follows the likelihood and impact approach in National Institute of Standards and Technology (NIST) Special Publication 800-30, reduced to a five-point scale a small team can apply the same way every time.2
[Company name]
Risk Assessment Policy
- Owner
- [Security owner role]
- Approved by
- [Policy approver role]
- Effective date
- [Effective date]
- Next review
- [Next review date]
- Version
- [Version]
1. Purpose and scope
This policy supports the SOC 2 common criteria CC3.1, CC3.2, CC3.3 and CC3.4 by establishing the process for identifying, assessing, and managing information security risks.
The risk management process covers all [In-scope systems], applications, business processes, and third parties.
2. Annual risk assessment
A formal risk assessment is conducted at least annually to identify threats, vulnerabilities, and the potential impact on service commitments.
3. What the assessment considers
- The Company objectives and the commitments made to customers.
- Threats and weaknesses in the systems in scope, including those found by vulnerability scans and tests.
- Vendors and subservice organizations, and what they can reach.
- Fraud and misuse by insiders, including how a control could be overridden.
- Changes since the last assessment: new products, systems, vendors, locations and staff.
4. Scoring
Each risk is rated for likelihood and impact on a scale of 1 to 5. The score is likelihood multiplied by impact, from 1 to 25, and higher scores are treated first.
| Rating | Likelihood | Impact |
|---|---|---|
| 1 | Not expected in the next three years | Minor inconvenience, no customer effect |
| 2 | Could happen in the next three years | Limited internal disruption |
| 3 | Could happen in the next year | Some customers affected or a contract breached |
| 4 | Expected in the next year | Customer data exposed, or the service down for every customer |
| 5 | Expected within months | Severe harm to customers or the business |
5. Risk register
All identified risks are tracked in a central [Risk register location]. Each entry includes a description, likelihood, impact, risk rating, owner, and treatment plan.
6. Risk treatment
Risks are treated by accepting, mitigating, transferring, or avoiding them. Mitigation plans are tracked to completion.
A risk is accepted only by the [Policy approver role], in writing, with the date of acceptance and a date to look at it again. The person who identified a risk does not accept it.
7. Reassessment between reviews
A significant change triggers a reassessment of the risks it touches before or as it happens: a new subservice organization, a major architecture change, a new product or market, a serious incident, or a change in the team that owns key controls. Results are reported to the [Management review body].
8. Roles and responsibilities
| Role | Held by | Responsibility |
|---|---|---|
| Policy approver | [Policy approver role] | Approves this policy, each new version, and any risk the Company accepts instead of meeting it. |
| Policy owner | [Security owner role] | Maintains this policy, makes sure the controls in it operate, keeps the evidence, and reviews it at least once a year. |
| All personnel | Everyone in scope | Follow this policy and report a suspected breach of it to the [Security owner role]. |
9. Evidence and records
The records below show that this policy operates. Each is dated, kept for at least [Evidence retention period], and stored where an auditor can be given it.
| Record | What it shows | Where it is kept |
|---|---|---|
| Approved policy | This document, signed by the approver, with its version history. | [Documentation system] |
| Risk assessment report | Annual assessment findings and results. | [Evidence storage location] |
| Risk register | All identified risks with their status. | [Risk register location] |
| Risk acceptance records | Each accepted risk with its approver, date and revisit date. | [Risk register location] |
10. Exceptions and enforcement
A deviation from this policy needs a written exception approved by the [Security owner role] before it begins. Each exception records the rule not met, the business reason, the compensating control and an expiry date no more than 12 months away. Exceptions are reviewed at each annual review.
A breach of this policy is handled under the Company disciplinary process and may lead to action up to and including termination of employment or contract. A breach that exposes customer data is also handled as a security incident.
11. Review and approval
The [Security owner role] reviews this policy at least once a year and after any significant change to the business, the systems in scope or the risks they face. The [Policy approver role] approves each version. Personnel are told of material changes and acknowledge the current version.
| Version | Date | Summary of change | Approved by |
|---|---|---|---|
| [Version] | [Effective date] | First version. | [Policy approver role] |
Sign-off. Name, signature and date for: Policy approver.
12. Fields to complete
Replace every bracketed field in this document with your own detail, then delete this section.
| Field | What to enter |
|---|---|
| [Company name] | Your legal company name. |
| [Effective date] | The date the approver signs this version. |
| [Version] | Start at 1.0 and increase it each time the document changes. |
| [Security owner role] | The role that runs the security program day to day, for example Chief Technology Officer. |
| [Policy approver role] | The officer who approves policies and accepted risks, for example Chief Executive Officer. |
| [Management review body] | The group that oversees security, for example the leadership team meeting or an advisory board. |
| [Evidence storage location] | The shared folder or system where evidence is kept. |
| [Documentation system] | Where policies and procedures are published, for example the company wiki. |
| [In-scope systems] | The product, cloud accounts and tools inside the audit boundary. |
| [Risk register location] | Where the risk register is kept. |
| [Evidence retention period] | How long audit evidence is kept, for example three years. |
| [Next review date] | The date this version must be reviewed by, at most 12 months after the effective date. |
How to adapt it in an afternoon
- Fill the brackets. The approver, the management review body and where the register lives.
- Read the scale aloud. If your team cannot tell a 3 from a 4 for likelihood, rewrite the definitions until it can.
- Run the first assessment. An hour with the people who own production, vendors and hiring. Start from the six example rows in the risk register template.
- Decide each treatment. Mitigate, transfer, avoid or accept, and get the approver signature on anything accepted.
- Approve the policy and date the register. Both before the audit period opens.
What produces a finding
A register last reviewed before the period began. A risk marked accepted with no name against it. A new vendor in production that never reached the register. The vendor side is covered by the vendor management policy, and a SOC 2 gap analysis is a useful input to the first assessment. The information security policy says who receives the results, and the SOC 2 policy list shows the rest of the set.
Polara G.R.C. onboarding is $2,000 one time. It writes the thirteen policies in its pack, which cover risk assessment, from your intake answers, with your systems, owners and review dates named, for you to review and approve. No template passes an audit on its own, this one included. An independent licensed U.S. CPA firm tests whether the policy operated.
Polara Labs is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.
Questions
Does SOC 2 require a risk assessment policy?
How often is a SOC 2 risk assessment required?
Who can accept a risk?
What is the difference between the risk assessment policy and the risk register?
Is a risk assessment policy template enough to pass SOC 2?
Sources
Get audit-ready without a compliance team.
The readiness assessment is free, with no payment and no card. Onboarding is $2,000 one time, then SOC 2 Type 2 is $600 a month on a 12-month term, and your first SOC 2 Type 2 audit is included in the term. You can be audit-ready starting at about a week.
Take the free assessmentPolara Labs is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.