Risk Management · Guide
Risk management strategy: what a board-approved strategy contains risk management strategy
Risk management strategy: what a board-approved strategy contains
Key takeaways
A risk management strategy is the short, leadership-approved document that says how a company manages risk to meet its objectives: how much risk it accepts, who owns which risks, the method it uses, and how risk is reported and reviewed. In a 25 to 150-person firm, the CTO usually drafts it, the CEO or board approves it, and the register and decision records prove it is followed.
- Risk framing
- NIST SP 800-39 treats risk framing as the first component of risk management, producing a risk management strategy that sets out how an organisation will assess, respond to and monitor risk.
- Cyber Governance Code of Practice
- UK guidance for boards and directors, published in April 2025. Its actions include senior ownership of cyber risk, a defined cyber risk appetite and assurance that supplier information is routinely assessed.
- FCA outsourcing rules (SYSC 8.1)
- Apply when FCA-regulated firms outsource critical or important functions: the firm stays fully responsible, and common platform firms must require providers to disclose developments affecting their ability to perform.
- DORA Article 30
- Sets minimum contract terms between EU financial entities and ICT providers; for critical or important functions these include security measures, tested contingency plans and access, inspection and audit rights.
The enterprise customer's security questionnaire asks you to describe your risk management approach and confirm that senior management approved it. There is a risk register, somewhere, and a policy written for the last audit. Nobody is sure which one answers the question, or who signed what. A risk management strategy is the document that does.
This guide is for founders, CTOs and security leads at UK B2B technology firms with 25 to 150 staff, selling into financial services, insurance or the public sector. It explains what a risk management strategy contains, how it differs from the policy and the register, what customers and auditors actually ask for, and how to make the strategy something you can prove rather than assert.
What is a risk management strategy?
A risk management strategy is the short, leadership-approved document that says how your company manages risk to meet its objectives: how much risk it will accept, who owns which risks, the method it uses, and how risk is reported and reviewed. It is what customers and auditors mean when they ask for your risk management approach.
The four response options, avoid, reduce, transfer and accept, are one input to the strategy, not the strategy itself. The strategy sets the rules for choosing between them.
The idea is well established. NIST Special Publication 800-39 treats "risk framing" as the first component of risk management. Its purpose is to produce a risk management strategy that sets out how an organisation intends to assess, respond to and monitor risk. NIST adds that the strategy should make explicit the risk perceptions behind investment and operational decisions. Those rest on the organisation's stated assumptions, constraints, risk tolerances and trade-offs.
ISO 31000 describes the same layer as a framework that leadership mandates and commits to. Either way, the strategy sits above the day-to-day process and tells the process what good looks like.
How is a risk management strategy different from a policy, register or plan?
A risk management strategy sets direction: appetite, ownership, method and reporting. The policy turns that direction into rules staff must follow. The register records the individual risks and decisions. A treatment plan lists the actions to reduce specific risks. Customers and auditors ask different questions of each, so one document rarely answers them all.
The table shows which document answers which question. It is our working model for a small firm, not a requirement of any standard.
| Document | What it says | The question it answers | Who usually asks |
|---|---|---|---|
| Risk management strategy | How much risk you accept, who owns it, how you assess it, how leadership sees it | "Describe your risk management approach. Has senior management approved it?" | Security questionnaires, due diligence, investors, the board |
| Risk management policy | The rules: who must assess, when, with which scoring scale, who may accept a risk | "Do you have a documented risk management policy?" | SOC 2 and ISO 27001 auditors, questionnaires |
| Risk register | Each risk, its owner, score, response and status | "Show us your current top risks and how you track them" | Auditors, enterprise customers on a call |
| Risk treatment plan | The actions, owners and dates for risks you have chosen to reduce | "What are you doing about the risks above your appetite?" | ISO 27001 auditors, customer follow-up questions |
In a firm of 25 to 150 people, the strategy and the policy are often one document with two parts. That works, provided the strategic part is signed at leadership level and the procedural part can change without going back to the board.
What should a risk management strategy contain?
A risk management strategy for a 25 to 150-person firm needs eight sections: purpose and objectives, scope, risk appetite, owners and accountability, method and criteria, response principles, reporting, and review. Two to four pages is enough. Every section should name something a customer or auditor could check: a person, a threshold, a cadence or a record.
We recommend this outline. The sizing notes are our suggestion, not a requirement of any framework.
- Purpose and objectives. Two or three sentences linking risk to what the business is trying to do this year: win regulated customers, pass a SOC 2 examination, raise the next round, ship an AI feature safely. Risk only means something against an objective.
- Scope. Name the product and platform, the customer data you hold and process, and the key suppliers you depend on, such as your cloud host and payment or identity providers. Customers read this section to see whether their data is inside it.
- Risk appetite statement. A short statement of how much risk the company will take in a few areas, such as customer data, service availability, regulatory compliance and supplier dependence. Make at least one line measurable. Setting appetite in depth is its own exercise; the strategy only needs to record what leadership agreed.
- Owners and accountability. Who owns the strategy (usually the CEO or founder), who runs the process day to day (usually the CTO or security lead), and the rule that every risk in the register has a named owner with the authority to act on it.
- Method and criteria. How risks are identified and scored: the likelihood and impact scales, the triggers for a new assessment, and where the register lives. Keep the detail in the policy; the strategy states the approach.
- Response principles. Which risks must be reduced, which may be accepted, and who may accept them. For example, a risk above appetite may only be accepted by the CEO, for a fixed period, with a review date.
- Reporting. What leadership sees, how often, and what goes to the board and investors. We suggest a one-page view each quarter at this size.
- Review cycle. An annual review, plus named triggers that force an earlier one.
A strategy that names no thresholds can't be tested. An auditor or a customer's assessor will look for the line where it says what happens when a risk crosses one.
What do customers and auditors ask for about your risk management strategy?
Customers and auditors ask three things about a risk management strategy: that it exists in writing, that leadership approved it, and that the company follows it. Security questionnaires ask the first two directly. SOC 2 and ISO 27001 auditors test all three through records. Regulated customers add requirements that reach you through their contracts.
What do security questionnaires and due diligence packs ask?
Security questionnaires and due diligence packs vary in length and format, but their risk management questions follow a familiar pattern. They want to know that a documented approach exists, that leadership approved it, how often it is reviewed, whether it covers suppliers, and who decides when a risk is too high. Typical examples include:
- Do you have a documented risk management programme or approach, and when was it last reviewed?
- Has senior management or the board approved it?
- How often do you assess risk, and does the assessment cover suppliers and subcontractors?
- Who is accountable for information security risk?
- How are risks above your tolerance escalated and accepted?
A strategy written with these questions in mind answers each of them in a sentence, with a section reference.
What does SOC 2 expect?
SOC 2 examines your controls against the AICPA's Trust Services Criteria. The risk assessment criteria (CC3) cover setting objectives clearly enough to identify the risks to them, then finding and weighing those risks, including fraud and the effect of change. The control environment criteria (CC1) look at who owns security at leadership level and how oversight works.
A short strategy gives you the objectives and oversight that CC3 and CC1 start from. Our guide to the Trust Services Criteria covers each criteria group, and the SOC 2 overview explains why enterprise buyers ask for the report.
What does ISO 27001 expect?
ISO 27001 asks for a defined, repeatable information security risk assessment, with criteria for accepting risk and for performing assessments, and a treatment process whose residual risks are approved by named risk owners. Leadership must show it directs and supports the management system rather than delegating it to IT.
The strategy is where those criteria and ownership rules are agreed at the top. Our guides to Clause 6.1, actions to address risks and opportunities, and Clause 5.1, leadership and commitment, cover what auditors test.
How do a regulated customer's obligations reach you?
When a regulated customer outsources an important service to you, its obligations follow you through the contract. The regulator holds the customer responsible, so the customer writes disclosure, access and audit rights into your agreement. Your risk management strategy is one of the documents its supplier-risk team will want to see.
Two examples show how this works. The FCA's outsourcing rules in SYSC 8.1 apply when the firms they cover outsource critical or important operational functions, and the firm stays fully responsible for its regulatory obligations. Common platform firms must also require the service provider to disclose any development that could materially affect its ability to perform, and must set out inspection and access rights in a written agreement. Other firms take those two rules as guidance.
If you serve EU financial entities, Article 30 of the Digital Operational Resilience Act (Regulation (EU) 2022/2554) lists the minimum terms of their ICT contracts. For services that support critical or important functions, those terms include requirements for the provider to have security measures, tools and policies in place, to test business contingency plans, and to allow access, inspection and audit.
None of this makes you the regulated firm. It means the customer will want evidence that your risk management is real, and a signed strategy backed by records is the quickest evidence you can give.
What does UK government guidance expect of leadership?
The UK Cyber Governance Code of Practice, published by the UK government with the NCSC in April 2025, sets out what boards and directors should do about cyber risk. Its actions include agreeing senior ownership of cyber risk, defining and communicating a cyber risk appetite, and gaining assurance that supplier information is assessed routinely, in proportion to risk.
The Code is designed for medium and large organisations, and says smaller ones should still seek to apply its principles. For a 25 to 150-person firm, it is a useful checklist of what leadership ownership of risk looks like.
How do you make a risk management strategy provable?
You make a risk management strategy provable by running what it promises in the tools your team already uses. The register, the review cadence and every risk decision leave dated records as a side effect of normal work. When a customer or auditor asks, you show the records instead of writing a fresh explanation.
This is the GRC Engineering approach: compliance as an engineered system rather than an annual scramble. In practice it comes down to four habits.
Keep the register where work already happens. If engineering lives in an issue tracker, put risks there too, with an owner, a score and a review date. A register in the same place as the work gets updated because people see it.
Schedule the reviews as recurring work. The quarterly leadership review and the annual strategy review become recurring tickets or calendar items with an owner. Each one closes with a short record of what was decided.
Log every risk decision with its evidence. When someone accepts a risk, the record shows who accepted it, why, the expiry date and the supporting evidence. When a risk is reduced, the record links to the change that reduced it.
Show leadership a few metrics, not the whole register. We suggest four: risks above appetite, overdue treatment actions, accepted risks nearing expiry, and key suppliers reviewed this year. These numbers tell the board whether the strategy is working.
Done this way, one answer serves every audience. Keep a short, approved answer to the standard risk management questions, mapped to sections of the strategy and to the records behind them. The questionnaire, the SOC 2 auditor and the investor's due diligence all draw on the same source.
A strategy you can only describe is an assertion. A strategy you can show running is evidence.
How do you build a risk management strategy in a small firm?
In a 25 to 150-person firm, the CTO or security lead usually drafts the risk management strategy and the founder, CEO or board approves it. Keep it to two to four pages, base it on the decisions leadership already makes, and set triggers for an early review. In our view, a working draft should take weeks, not months.
We recommend this sequence:
- Start from the objectives. Take this year's business goals and ask what could stop each one. That gives the strategy its purpose and the first version of the appetite statement.
- Draft from the questions you are already being asked. Pull the risk management questions from recent questionnaires and audit requests, and make sure each has an answer in the draft.
- Agree appetite and acceptance rules with leadership. This is a conversation, not a document review. The output is a few lines that say where the company will and won't take risk, and who can sign off exceptions.
- Approve it formally. A dated sign-off by the CEO or the board, recorded in minutes or an approval ticket, is what questionnaires mean by "approved by senior management".
- Connect it to the register. Check that the register uses the strategy's scales and owners. If it doesn't, one of them is fiction.
Revisit the strategy at least once a year, and earlier when something changes the risk picture. Common triggers include a funding round, a first regulated customer, a new market, a major supplier change, a significant incident, or a new AI feature that changes how customer data is used.
What are the signs a risk management strategy is not working?
A risk management strategy is not working when it exists only for the audit, when the register it governs is stale, or when your questionnaire answers contradict it. Other signs are risks accepted by people without the authority to accept them, and an appetite statement that has never changed a decision.
Look for these patterns:
- It only comes out at audit time. Nobody outside the security lead has opened it since it was signed.
- The register is stale. Review dates have passed, owners have left, and the scores haven't moved in a year.
- Answers drift. Different questionnaires describe different review cycles or owners, and none of them match the document.
- Acceptances sit at the wrong level. An engineer or contractor accepts a risk that the strategy says only the CEO can accept.
- Appetite never says no. Every risk is somehow within tolerance.
The fix is rarely a rewrite. Bring the review cadence back to life, move the register to where the team works, and make the next leadership review produce a record.
Frequently asked questions
The four common risk responses are avoid (stop the activity that creates the risk), reduce (add controls to lower likelihood or impact), transfer (shift some of the impact through insurance or a contract) and accept (live with the risk, with a named owner signing for it). They are options inside a risk management strategy rather than the strategy itself. The strategy decides when each one is allowed and who can choose it.
No, though a small firm can keep both in one document. A simple test decides where a line belongs. If changing it needs leadership sign-off, such as a new appetite line or a change to who may accept risk, it belongs in the strategy. If the security lead can change it alone, such as a scoring scale or an assessment form, it belongs in the policy.
The founder, CEO or board. The record of the approval matters as much as the signature: which version was approved, when, by whom, and where the decision is minuted. We also suggest re-approving it after a change of CEO or board, so the approval belongs to the people now accountable for the risk.
At least once a year, and sooner after a material change. We suggest each review checks three things: that the appetite lines still fit this year's objectives, that the register's owners and scores are current, and that recent questionnaire answers still match the document. Record the date and the outcome even when nothing changes, because questionnaires ask when the approach was last reviewed.
A good example is two to four pages, and each section makes a promise someone can check. Compare two appetite lines. "We take a cautious approach to security risk" can't be tested. "We accept no known high-severity vulnerability on internet-facing systems for more than 30 days" can, against the register and the scan history. The second line is an illustration, not a benchmark, but every line in the strategy should meet the same test.
Domain engine
Risk Management reference directory.
Every guide in this domain, grouped by level — fundamentals, intermediate and advanced. Open any entry for its core practices, implementation steps and the evidence it produces.
01Fundamentals5 guides
Risk management frameworks: which one fits a UK tech firmRisk register: what to record, with an information security exampleRisk appetite: what it is and how a tech supplier sets oneInherent risk vs residual risk: what each score is for and how to use themRisk matrix: how to score information security risk on likelihood and impact
02Intermediate5 guides
Cyber security risk assessment: a practical method for UK firmsRisk mitigation strategies: the four treatment options and how to chooseRisk management strategy: what a board-approved strategy containsOperational risk management: what regulated customers expect from their tech suppliersThird-party risk management: what regulated customers expect from your tech firm
Risk Management Accelerator
Ready to turn your risk register into decisions?
Work with a Trust Architect to build a risk process your board and your enterprise customers can rely on: scored consistently, owned and reviewed.