.svg){kind=logo}
You’re on a call with a prospect’s security team. They ask: “Can you share your risk management policy?” You know your company thinks carefully about risk. You just haven’t written it down anywhere.
That’s the gap a risk management policy exists to close.
A risk management policy is a formal document that defines how your organisation identifies, assesses, treats, and monitors risks to its systems, data, and operations. It sets out who is responsible for risk management, how risks are scored (typically by likelihood and impact), what thresholds trigger action, and what treatment options are available (mitigate, transfer, avoid, or accept).
Findings are tracked in a risk register. The policy owner is usually a CISO, CTO, or a designated risk officer. The policy applies to everyone: employees, contractors, vendors, and the systems they use.
Without it, risk decisions happen in people’s heads. One person accepts a risk another person would have escalated. An auditor asks for your risk register and there isn’t one. A vendor with access to production data was never assessed. These aren’t hypothetical problems. They come up in almost every first-time compliance audit I’ve seen.
Frameworks that require a formal risk management policy:
- SOC 2 (CC3.1, CC3.2 — risk identification and analysis)
- ISO 27001 (Clause 6.1 — actions to address risks and opportunities)
- HIPAA (§164.308(a)(1) — security risk analysis, legally required)
- NIST CSF (ID.RA domain — risk assessment)
- GDPR (Article 32 — risk-based approach to security)
By the end of this, you’ll know exactly what a risk management policy needs to cover, how to write one that holds up in an audit, and how to right-size it for your company.
Here’s what I’ll cover:
- What a risk management policy is and how it differs from a risk register
- What to include in yours, with a free template
- How it maps to SOC 2, ISO 27001, HIPAA, and NIST CSF
- Common mistakes that create audit problems
- How to scale it as your company grows
Free Template
Download the Free PDF Template
Pre-built and compliance-ready. Customise and use immediately.
What a Risk Management Policy Actually Does
A risk management policy governs how your organisation handles risk. It defines the process for identifying risk, measuring it, deciding what to do about it, and keeping track of it over time.
Key insight
A risk management policy is not a risk register. The policy defines your methodology — how you identify, score, and treat risks. The register is the output. Auditors want to see both: the policy proves you have a repeatable process; the register proves you're running it.
It sounds administrative. It isn’t. The policy is what stops risk management from being everyone’s vague responsibility and nobody’s actual job. It defines the methodology, the thresholds, the owners, and the evidence trail. Everything else follows from it.
What Makes a Risk Management Policy Different From a Risk Register?
These three things are related but distinct, and mixing them up is one of the most common gaps I see in audit prep.
The policy is the rulebook. It defines your risk methodology: how you score risks, what treatment is required at each level, who can accept a High risk, and how often assessments happen.
A risk assessment is the periodic exercise of actually running that methodology. You identify threats, score them against your criteria, decide on treatment. It’s a time-bounded activity, not an ongoing document.
The risk register is the living output of your assessments. It’s the tracked list of identified risks with scores, owners, treatment status, and next review dates.
Auditors want all three. A policy with no register shows rules that aren’t being followed. A register with no policy means data without a consistent methodology. They’re designed to work together.
Types of Risk Management Policy: IT, Vendor, Enterprise, and More
“Risk management policy” is a broad category. In practice, organisations implement it in a few different forms:
Information security / IT risk management policy: Scoped to cyber and technology risk — systems, infrastructure, cloud services, endpoints, access controls. This is the variant most directly referenced by ISO 27001 and SOC 2.
Third-party / vendor risk management policy: Covers risks from vendors and suppliers with access to your systems or data. Some organisations fold this into the main policy; others separate it out.
Operational risk management policy: Focuses on process failures, human error, and internal controls rather than technology-specific threats.
Enterprise risk management (ERM) policy: An organisation-wide framework covering strategic, operational, financial, and compliance risk. Usually found at larger companies or those with board-level risk oversight.
Other variants: Supply chain risk management policy, insider risk management policy, cyber risk management policy, financial risk management policy. These are typically sub-policies or named sections within a broader risk framework.
For most companies, a single unified policy with a clearly defined scope handles all of this. Separate structures make more sense as you scale.
Why “We Know Our Risks” Isn’t a Risk Management Policy
I’ve heard some version of “we think about risk all the time” from almost every team that doesn’t have a written policy. It’s probably true. But thinking about risk and managing risk are not the same thing.
Free Demo
Risk management is the first thing auditors ask for in a SOC 2 or ISO 27001 engagement
ComplyJet generates a compliant risk management policy, builds your risk register, and maps every risk to the controls in your compliance framework — so audit prep takes hours, not weeks.
The compliance problem. SOC 2, ISO 27001, and HIPAA don’t ask whether your team is aware of risks. They ask for documented evidence of a risk management process. CC3.1 requires that management identifies and analyses risks. Clause 6.1 requires that risks are assessed against defined criteria and documented. HIPAA §164.308(a)(1) makes risk analysis a legal requirement. “We know our risks” satisfies none of these.
The security problem. Risks that live in people’s heads don’t get tracked. They don’t get treated. A threat that one person is aware of can go unmitigated for months because it was never logged, never assigned an owner, never reviewed. A security risk management policy forces risks into a system where they can be prioritised and acted on.
The operational problem. Without a policy, risk decisions are inconsistent. One person accepts a vendor with admin access to production. Another person would have flagged it immediately. There’s no shared threshold, no documented rationale, nothing to show an auditor or a customer security team when they ask why you made a particular call.
The policy is what turns informal risk awareness into a defensible, auditable process.
When Does a Company Actually Need a Risk Management Policy?
The short answer: if you have data, you have risk. If you have risk, you need this.
Why it matters
HIPAA makes the security risk analysis a legal requirement — not a nice-to-have. HHS has issued fines specifically for organisations that conducted no formal risk assessment. Having a policy without a documented analysis to back it up is not sufficient.
You’re pursuing SOC 2 or ISO 27001. Risk management is a core requirement for both. You can’t complete either audit without a documented policy, a methodology, and a populated risk register.
You handle health information. HIPAA makes risk analysis a legal requirement, not a best practice. There’s no way around it for covered entities or business associates.
You sell B2B into enterprise. Enterprise customers routinely include risk management in security questionnaires. Procurement teams want to see a formal risk programme before signing contracts with vendors who’ll have access to their data.
You process or store sensitive customer data. GDPR’s Article 32 requires a risk-based approach to security. That starts with knowing what your risks actually are.
You’re growing fast. New systems, new vendors, new team members — every growth event is a risk event. A policy ensures you’re assessing those changes systematically rather than hoping someone mentions the right concern in a Slack message.
What Goes in a Risk Management Policy
The table below covers what every risk management policy needs. The sections after it go into the areas most likely to get scrutinised in an audit.
| Policy section | What to include |
|---|---|
| Purpose | Why the policy exists and which risks or compliance requirements it addresses |
| Scope | Systems, employees, contractors, vendors, data types, and locations covered |
| Definitions | Risk, risk appetite, threat, vulnerability, residual risk, risk register |
| Roles and responsibilities | Policy owner, risk register owner, department heads, all employees, executive approvers |
| Risk assessment process | How risks are identified, scored (likelihood x impact), and evaluated |
| Risk acceptance criteria | Scoring thresholds (Low / Medium / High) and treatment required at each level |
| Risk treatment options | Mitigate, transfer, avoid, accept — with rules for when each applies |
| Residual risk | How remaining risk after treatment is scored and who must accept it |
| Risk register | Where it lives, who maintains it, how often it’s updated |
| Third-party risk | How vendor and supplier risk is identified, tiered, and assessed |
| Review cadence | Annual minimum; specific triggers for off-cycle review |
| Exceptions | How to request an exception, who approves it, what gets documented |
| Enforcement | Consequences for non-compliance |
Third-Party Risk Management Policy Requirements
Every vendor with access to your systems or data is a risk you’ve inherited. Your own controls only go so far. If a supplier has admin access to your environment and no security programme of their own, that risk is now yours to manage.
A third party risk management policy section (or a standalone third-party policy) needs to cover:
- A vendor inventory: who has access to what
- Risk classification by tier (High / Medium / Low) based on access level and data sensitivity
- Assessment requirements by tier: what due diligence is required and how often
- Contractual controls: DPAs, BAAs, security requirements in vendor agreements
- Offboarding: how access is revoked and confirmed when a vendor relationship ends
For most organisations, this lives as a dedicated section in the main risk policy. A separate vendor risk management policy makes sense when your vendor estate is large or when your ISO 27001 reviewer specifically calls for it.
IT Risk Management Policy: Systems and Infrastructure
The IT risk management policy scope covers the assets that generate the most common audit findings: systems and infrastructure, cloud services, endpoints, access controls, and patch status.
A few things that often get missed:
Asset inventory first. You can’t assess risk on systems you haven’t catalogued. If your IT asset list is incomplete, your risk assessment is incomplete.
IT risk categories to cover explicitly: Unauthorised access (from inside and outside), configuration drift, unpatched vulnerabilities, third-party integrations with elevated permissions, and dependency failures.
What auditors check: Risk register entries for IT-specific risks, treatment status, evidence of remediation, and named owners for each risk.
Information Security Risk Management Policy and ISO 27001
ISO 27001 has specific requirements for how information security risk management must work — a generic risk policy doesn’t satisfy them. Clause 6.1 requires that you:
- Define a risk assessment methodology with consistent, reproducible criteria
- Identify risks associated with loss of confidentiality, integrity, and availability
- Produce a risk treatment plan linked to specific Annex A controls
- Document residual risk and have it formally accepted by an appropriate owner
The information security risk management policy for an ISO 27001 programme must reference all of this explicitly. Auditors look at the policy and then check whether the risk register shows that methodology being applied consistently. If the policy says “risks are scored by likelihood x impact” but the register has no likelihood or impact scores, that’s a nonconformity.
For teams building toward NIST CSF, the ID.RA controls (ID.RA-1 through ID.RA-6) map almost directly to the same requirements: asset vulnerabilities identified, threats catalogued, risk responses determined, and risk tolerance defined.
Insider and Operational Risk: What Your Policy Needs to Cover
Insider risk doesn’t mean you distrust your team. It means your policy accounts for the access that employees and contractors hold — and what happens when it’s misused or misconfigured.
Cover: privileged access controls, employee offboarding (access revoked and confirmed, not just requested), contractor access scoping, and data exfiltration detection.
Operational risk is broader: process failures, configuration drift, over-reliance on a single person or system, supply chain dependencies. A supply chain risk management lens here asks what happens if a key vendor or critical dependency goes down or is compromised. Include detection controls, an escalation process, and a requirement to reassess operational risks after any significant process or infrastructure change.
Free Risk Management Policy Template
Writing a risk management policy from scratch takes longer than it should. The template below is a complete, usable starting point. Fill in the bracketed fields, adjust the scope and thresholds to match your environment, and you have something you can take straight into an approval workflow.
Free Template
Download the Free PDF Template
Pre-built and compliance-ready. Customise and use immediately.
Risk Management Policy Example and Sample
This risk management policy sample covers all the sections required for SOC 2, ISO 27001, and HIPAA compliance. Use it as a risk management policy example and adapt it to your organisation’s systems, scope, and risk appetite.
[Company Name] Risk Management Policy
Policy Owner: [Risk Management Role — e.g. CISO / CTO / Engineering Lead] Effective Date: [Date] Last Updated: [Date] Approved by: [Top Executive Role — e.g. CEO / Co-founder] Next Review Date: [Annual — set a calendar reminder]
1. Purpose
To define actions to address [Company Name] information security risks and opportunities, and to define a plan for achieving information security and privacy objectives.
2. Scope
All [Company Name] IT systems that process, store, or transmit confidential, private, or business-critical data. Risks affecting medium to long-term goals shall be considered, as well as day-to-day service delivery risks. This policy applies to all employees of [Company Name] and all external parties (consultants, contractors, business partners, vendors, suppliers, outsource providers, etc.) with access to [Company Name] networks and system resources.
3. Definitions
| Term | Definition |
|---|---|
| Risk | The potential for loss or harm arising from a threat exploiting a vulnerability |
| Risk Assessment | The process of identifying, analysing, and evaluating risks |
| Risk Appetite | The level and type of risk the organisation is willing to accept in pursuit of its objectives |
| Risk Register | A record of identified risks, their scores, treatment status, and owners |
| Residual Risk | The risk remaining after treatment controls have been applied |
| Threat | A potential event or actor that could exploit a vulnerability |
| Vulnerability | A weakness in a system, process, or control |
| Risk Treatment | The action taken in response to an identified risk |
4. Risk Management Statement
Inadequate IT risk management exposes [Company Name] to compromise of systems and services, cyber-attacks, contractual and legal issues, and reputational damage. [Company Name] will ensure risk management is integrated into governance at both strategic and operational levels. The purpose of risk management is to help achieve business plan aims and objectives.
5. Risk Management Strategy
[Company Name] has processes to identify risks that hinder strategic and operational objectives. The organisation ensures it can identify, analyse, control, and monitor these risks using best practices. The strategy and policy are regularly reviewed, and internal audit ensures:
- The policy is applied consistently across [Company Name]
- The policy and its application are regularly reviewed
- Non-compliance is reported to relevant officers and authorities
6. Practical Application of Risk Management
[Company Name] uses a standard format for identifying, classifying, and evaluating risks, based on:
- ISO 27005 (information security risk management)
- NIST 800-30 (risk assessment guide)
- NIST 800-37 (risk management framework)
Risks are assessed and ranked by impact and likelihood. A formal risk assessment and network penetration test will be conducted at least annually.
7. Risk Categories
[Company Name] considers and assesses risks across the following categories:
- Reputational
- Contractual
- Regulatory / Compliance
- Economic / Financial
- Fraud
- Privacy
- Environmental and Sustainability
- Impact on People
- Use of Cloud Services
- Operational Capacity
Each risk is rated on a 1–5 scale for both impact and likelihood.
8. Risk Criteria
Risk is determined by the combined likelihood and impact of events adversely affecting confidentiality, availability, integrity, or privacy. [Company Name] management may adjust risk rankings based on the nature and criticality of the system, exploitability factors, and other relevant context.
9. Roles and Responsibilities
| Role | Responsibility |
|---|---|
| [Top Executive Role] | Ultimately responsible for risk acceptance and treatment decisions |
| [Risk Approval Role] | May approve avoidance, remediation, transference, or acceptance of any risk in the register |
| [Risk Management Role] | Identifies information security risks, develops treatment plans, communicates to management, and implements treatments as directed |
10. Risk Assessment Process
Risk assessments follow a four-phase process based on NIST 800-30:
Phase 1: Prepare. Identify the purpose, scope, assumptions, and constraints of the assessment.
Phase 2: Conduct. Identify threats and vulnerabilities, determine likelihood and impact, calculate overall risk score.
Phase 3: Communicate. Share results with decision-makers and senior leadership.
Phase 4: Maintain. Keep risk data current through ongoing monitoring; reassess at least annually.
Risk Scoring: Risk Score = Likelihood x Impact
Likelihood scale:
| Score | Description |
|---|---|
| 1 | Very unlikely |
| 2 | Unlikely |
| 3 | Somewhat likely |
| 4 | Likely |
| 5 | Very likely |
Impact scale:
| Score | Description |
|---|---|
| 1 | Very low impact |
| 2 | Low impact |
| 3 | Medium impact |
| 4 | High impact |
| 5 | Very high impact |
Risk levels:
| Risk score | Level |
|---|---|
| 1–4 | Low |
| 5–12 | Medium |
| 15–25 | High |
Risk matrix (Likelihood x Impact):
| Impact 1 | Impact 2 | Impact 3 | Impact 4 | Impact 5 | |
|---|---|---|---|---|---|
| Likelihood 5 | 5 | 10 | 15 | 20 | 25 |
| Likelihood 4 | 4 | 8 | 12 | 16 | 20 |
| Likelihood 3 | 3 | 6 | 9 | 12 | 15 |
| Likelihood 2 | 2 | 4 | 6 | 8 | 10 |
| Likelihood 1 | 1 | 2 | 3 | 4 | 5 |
11. Risk Response, Treatment, and Tracking
Risks are kept in a risk register, prioritised, and mapped to treatment decisions. Possible responses:
| Option | Description |
|---|---|
| Mitigate | Reduce risk via controls or process changes |
| Accept | Monitor risk at present level without further action (Low risks; Medium requires written justification) |
| Transfer | Shift risk to a third party (e.g. insurance, vendor contractual controls) |
| Avoid | Cease or alter the activity that creates the risk |
When a risk is not accepted or avoided, [Company Name] shall create a Risk Treatment Plan documenting: the risk, the chosen treatment, the owner, target completion date, and residual risk score.
12. Risk Management Procedures
- Maintain a Risk Register and Treatment Plan — updated at least annually and after any significant change
- Rank risks by likelihood (1–5) and impact (1–5); classify as High, Medium, or Low
- Overall risk = Likelihood x Impact
- Monetarily value potential losses where feasible
- Respond to risks considering cost, effort, and available resources — multiple remediations may run in parallel
- Provide regular risk reports to [Company Name] senior leadership, ensuring alignment with business priorities
13. Information Security in Project Management
[Company Name] will consider information security risk in all technical projects or those posing company risk, regardless of scale or domain. From initial planning to completion:
- Perform initial security risk assessments at project outset
- Identify and address security requirements early in the project lifecycle
- Continuously manage risks throughout the project, particularly around system integrations and communications
14. Third-Party and Vendor Risk
All vendors and third parties with access to [Company Name] systems or data must be assessed as part of this risk management process.
| Vendor tier | Criteria | Assessment frequency |
|---|---|---|
| High | Processes or stores sensitive data; has privileged system access | Before onboarding; annually thereafter |
| Medium | Limited access to internal systems; no sensitive data | Before onboarding; every 2 years |
| Low | No direct system access or data processing | As needed; upon material change |
High-tier vendors require: a completed security questionnaire, review of security certifications (SOC 2, ISO 27001, or equivalent), and a signed data processing agreement (DPA) or business associate agreement (BAA) where applicable.
15. Exceptions
Exceptions to this policy require a written request submitted to [Risk Approval Role] documenting the exception, the business justification, the compensating control in place, and the proposed expiry date. All approved exceptions must be logged in the risk register with the approval date and expiry. Exceptions are reviewed at the next scheduled risk review or at expiry, whichever comes first.
16. Enforcement
Violations of this policy — including failure to report known risks, failure to complete treatment by agreed dates, or intentional circumvention of risk controls — may result in disciplinary action up to and including termination of employment or contract.
17. Review and Maintenance
This policy is reviewed annually. Off-cycle reviews are triggered by a security incident, a major system or infrastructure change, a new vendor with elevated access, a new regulatory requirement, or a material change in business operations.
18. Version History
| Version | Date | Author | Changes |
|---|---|---|---|
| 1.0 | [Date] | [Name] | Initial version |
How to Write and Roll Out a Risk Management Policy
A policy that lives in a document and never gets used isn’t a policy. Here’s how to write one and actually operationalise it.
Free Demo
Build your risk register and policy together — not separately
ComplyJet connects your risk management policy directly to your control library, so every risk maps to a treatment and every treatment links to evidence. No spreadsheets.
Risk Management Policy and Procedure: Step-by-Step Rollout
Step 1: Assign a policy owner. Before drafting anything, decide who owns this. Usually the CISO, CTO, or head of security. One person, clearly named. If ownership is shared, accountability disappears.
Step 2: Run an initial risk assessment first. Don’t draft the policy in a vacuum. Do a rough assessment of your current risk landscape: what assets you have, what threats are realistic, what your biggest gaps are. The policy’s scoring thresholds should reflect the actual risks you face, not a generic template.
Step 3: Define your risk appetite and acceptance criteria. This is the hardest part of the whole policy, and most teams skip it. Your risk appetite determines everything downstream: what you treat, what you accept, what level of sign-off is needed. Get executive alignment on this before drafting anything else.
Step 4: Draft the policy. Use the template above as your base. Customise it: update the scope to match your actual systems, adjust the scoring thresholds if needed, name the specific roles in your organisation rather than generic titles.
Step 5: Legal and executive review. For SOC 2 and ISO 27001, auditors want executive sign-off. Route the draft through legal if applicable, and get approval from the CEO or board. Document it — email confirmation is sufficient.
Step 6: Communicate to all staff. Publish the policy and let everyone know it exists. Most teams do this via email, a Slack message, and a link in the onboarding checklist. Don’t just post it to a shared drive and assume it’s been read. A security awareness training policy is the right companion here — it’s where ongoing communication and acknowledgement gets structured.
Step 7: Collect acknowledgements. For SOC 2 and ISO 27001, auditors ask for evidence that employees read the policy. Collect acknowledgements — a signature or checkbox in your HRIS or compliance tool works.
Step 8: Populate the risk register. The policy alone isn’t evidence of a risk management programme. Run your first full assessment, score the risks using the methodology you just defined, and populate the register. This is the evidence that the policy is in actual use.
Step 9: Map to compliance controls. If you’re working toward SOC 2, ISO 27001, or HIPAA, map your risk management policy to the relevant controls in your GRC tool. It makes audit prep significantly faster. If you’ve had a recent system change, cross-reference with your change management policy — major changes are a risk assessment trigger.
Step 10: Set a review reminder. Calendar. Recurring. Annual. The number one reason risk management policies fail is that the review never happens and the register goes stale. Block the time now.
Risk Management Policy and Compliance: SOC 2, ISO 27001, and HIPAA
Risk management shows up across every major compliance standard, each with slightly different requirements.
| Framework | Relevant requirement | What the auditor checks |
|---|---|---|
| SOC 2 | CC3.1, CC3.2 | Risk identification and analysis process; populated risk register; treatment decisions documented |
| ISO 27001 | Clause 6.1, Annex A | Formal risk assessment methodology; risk treatment plan; residual risk acceptance; review history |
| HIPAA §164.308 | §164.308(a)(1) | Security risk analysis documented; risk management plan in place; periodic reassessment |
| NIST CSF | ID.RA-1 through ID.RA-6 | Asset vulnerabilities identified; threats documented; risk responses determined; tolerance defined |
| GDPR Article 32 | Article 32 | Risk-based approach to security; DPIA conducted for high-risk processing activities |
ISO 27001 Risk Management Policy Requirements
ISO 27001 is the most prescriptive of the bunch. Clause 6.1 requires a risk assessment process with consistent, reproducible criteria, a risk treatment plan linked to specific Annex A controls, and formal acceptance of residual risk by an appropriate owner.
The ISO 27001 risk management policy must reference your methodology explicitly. Auditors look at the policy, then check whether the risk register shows that methodology being applied consistently. If the policy says “risks are scored by likelihood x impact” but the register has no scores, that’s a nonconformity.
A note on HIPAA: the security risk analysis is a legal requirement, and HHS has issued fines specifically for organisations that skipped it. Having a policy without a documented risk analysis to back it up isn’t enough.
What Auditors Actually Want to See
A common mistake is treating the policy as the deliverable. Auditors want the policy, but they also want evidence that it’s being used. Here’s what they look for.
| Evidence type | What this looks like |
|---|---|
| Signed policy document | Latest version with owner name, approver signature, effective date, and next review date |
| Risk register | Current entries with scores, owners, treatment status, and review dates — not a blank template |
| Risk assessment report | A dated, owner-attributed record of the last full assessment; not just the register |
| Risk treatment evidence | Proof controls were completed: a closed ticket, a tool enabled, a vendor contract signed |
| Policy acknowledgements | A log showing employees read and acknowledged the policy; dated and attributed |
| Executive sign-off | For High risks: email, meeting minutes, or signed approval from the relevant authority |
| Review history | Evidence the policy has been reviewed — a version log with dates and what changed |
The register alone isn’t enough. The assessment report alone isn’t enough. Auditors want the full chain: policy defines the process, assessment applies it, register tracks the output, treatment evidence shows it was acted on.
Seven Mistakes That Derail Your First Risk Audit
Most of these aren’t obvious until you’re sitting across from an auditor.
Watch out
The most dangerous mistake is treating the risk assessment as a one-time pre-audit exercise. ISO 27001 Clause 6.1 requires periodic reassessment — and SOC 2 auditors will ask whether your risk register has been reviewed and updated since it was first created.
1. Policy exists; register doesn’t. The policy says “we maintain a risk register.” There’s no register, or it was last touched eighteen months ago. Auditors always ask for both. The policy without the register is a statement of intent, not evidence of a programme.
2. Risk acceptance criteria set too loosely. If your scoring thresholds mean almost every risk lands as Low, auditors notice. A register where nothing is ever Medium or High isn’t credible. Set thresholds that reflect the actual risk landscape your organisation operates in.
3. No vendor or third-party risk coverage. The policy covers your own systems and processes but says nothing about vendors with access to your data. SOC 2 CC3 and ISO 27001 Clause 6.1 both scope risk processes to include extended infrastructure — third parties included.
4. Annual review that never actually happens. “Reviewed annually” is in the policy. The document was last updated two years ago. The version history is blank. Always log and date your reviews, even if the content barely changed. The absence of a review record is a finding.
5. Policy communicated only to the security team. Auditors ask for acknowledgement records. If the only person who has ever signed is the CISO, that’s a gap. Acknowledgement across engineering, ops, and other data-handling teams is what auditors expect.
6. Residual risk never reassessed after treatment. A risk gets treated, marked complete in the register, and never looked at again. Residual risk — what remains after controls are applied — needs to be scored and accepted by an appropriate owner. Closing a risk without a residual score is an incomplete entry.
7. Downloaded template, zero customisation. Generic templates lifted from the internet often have placeholder company names, processes that don’t match actual operations, and criteria that weren’t calibrated to the organisation. Auditors are experienced at recognising them. A policy that doesn’t reflect how you actually work creates more problems than it solves.
Right-Sizing Your Risk Management Policy by Stage
Startups: Simple, Focused, and Auditable
If you’re under 20 people and pursuing SOC 2 for the first time, the goal is a policy that’s real: one that describes a process you’ll actually run, not a document built to impress an auditor that gets filed and forgotten the moment the audit ends.
Quick tip
At pre-Series A with 10–20 people: a one-page methodology, a risk register with 15–25 identified risks, and quarterly review cadence is enough for both SOC 2 and ISO 27001. Don't write a 40-page enterprise risk framework — it creates more audit burden, not less.
Keep it simple. One policy, one risk register, one annual assessment. A spreadsheet-based register is completely acceptable at this stage. Target scope: your top 10–15 risks. Identify them, score them, assign treatment. That’s enough to satisfy SOC 2 CC3 requirements for an early-stage audit. Don’t try to build an enterprise risk management programme before you have the team or the complexity to need it.
Growing Companies: More Rigour, More Scope
At 20–100 people, the informal approach starts to break. New systems, new vendors, new team members — the risk surface grows faster than one person can track informally.
Move to quarterly risk register reviews instead of annual-only. Expand scope to formally cover third-party vendors. Assign a dedicated risk register owner separate from the policy owner. Start mapping risk treatment decisions directly to your compliance controls in your GRC tool. This is when the extra structure pays off: you’re building a mature programme rather than scrambling before an audit.
Enterprise Risk Management Policy (100+ Employees)
At this scale, risk management typically becomes a formal programme with board-level oversight. The enterprise risk management policy expands beyond IT and security to cover strategic, operational, legal, and financial risk — each with defined owners and review cadences.
Expect a risk committee or working group, separate sub-policies for specific risk domains (third-party, insider, operational, financial), continuous risk monitoring integrated into security tooling, and formal board reporting on risk posture. The single unified policy that served you at 30 people gets replaced by a governance framework with dedicated structures.
Managing Your Risk Management Policy with ComplyJet
Building a risk management programme from scratch is one thing. Keeping it running — reviews on schedule, register current, acknowledgements collected, controls mapped — is where most teams fall down.
ComplyJet gives you a pre-built risk management policy template mapped to SOC 2, ISO 27001, HIPAA, and GDPR. Customise it, route it through an approval workflow, collect team acknowledgements — all in one place with a full audit trail.
The built-in risk register lets you log risks, score them against your defined methodology, assign owners, and track treatment status. When an auditor asks for your risk register, it’s current and exportable.
Every treatment decision maps directly to the relevant compliance controls in your framework. Evidence collection is automatic: acknowledgements, review history, approval records, control mapping — packaged and ready without manual chasing.
Review reminders go out before the annual review date. The policy doesn’t go stale because someone forgot to set a calendar reminder.
FAQs
What is a risk management policy and why do I need one?
A risk management policy is a formal document that defines how your organisation identifies, assesses, treats, and monitors risks to its systems, data, and operations. You need one because without it, risk decisions are inconsistent and undefensible — different people apply different thresholds, nothing gets tracked, and auditors have nothing to review. SOC 2, ISO 27001, HIPAA, and GDPR all require a documented risk management process, and most enterprise security questionnaires ask for it too.
What are the key elements of a viable risk management policy?
A viable policy includes: a defined scope, clear roles and responsibilities, a documented assessment methodology, risk acceptance criteria with scoring thresholds, treatment options (mitigate, transfer, avoid, accept), a linked risk register, third-party risk coverage, a review schedule, and enforcement language. The template in this article covers all of these.
How do I write a risk management policy?
Start with your risk appetite — how much risk are you willing to accept, and at what level does a risk require executive sign-off? Define your assessment methodology (likelihood x impact is standard), draft the policy, get executive sign-off, communicate it to staff, run your first assessment, and populate the risk register. The step-by-step in this article walks through the full process.
How often should a risk management policy be reviewed?
At minimum, annually. Off-cycle reviews are triggered by security incidents, major system changes, new vendors with elevated access, new regulatory requirements, or significant changes in business operations. The review date should be documented in the policy itself, and someone needs to own the calendar reminder.
What’s the difference between a risk management policy and a risk register?
The policy defines how you manage risk: the methodology, thresholds, treatment options, and responsibilities. The risk register is the output: the live record of identified risks with scores, owners, treatment status, and next review dates. Both are required for any compliance audit — the policy without a populated register shows intent but not execution.
Do I need a separate vendor risk management policy?
Not necessarily. Most organisations cover third-party and vendor risk in a dedicated section of their main policy. A separate vendor risk management policy makes sense when your vendor estate is large enough to warrant its own governance structure, or when your compliance framework specifically calls for it. Either way, the coverage needs to be there — SOC 2 and ISO 27001 both check for it.
Which SOC 2 Controls Does This Policy Address?
Primarily CC3.1 (management identifies and analyses risks) and CC3.2 (management designs and implements controls to address risks). Auditors also look for the risk register, treatment evidence, and review history alongside the policy. The policy establishes the framework; the evidence shows it’s operational.
What Evidence Do Auditors Expect to See?
Signed policy document, a current risk register with populated entries, at least one dated risk assessment report, evidence of risk treatment completed, employee acknowledgement records, executive sign-off for any High risk acceptances, and a review history showing the policy is maintained. The evidence checklist earlier in this article covers it in full.
Related Policies
Data Classification Policy: how your data is categorised drives the impact scores in your risk assessment. Sensitive data carries higher impact ratings. Data classification is a prerequisite to a meaningful risk register.
Change Management Policy: major system changes are one of the primary triggers for an off-cycle risk assessment. The two policies reference each other directly.
