A structured assessment of what your business stands to lose, in what scenarios, and how likely those scenarios are. Built for the decisions that matter — where to invest, what to accept, and what to tell the board.
Most security programmes are good at measuring what they do — alerts reviewed, patches applied, tests completed. What they rarely measure is what the business stands to lose if any of those activities fail, and in which scenarios that loss is most likely to occur.
The gap is not a lack of security effort. It is the absence of a structured way to connect security decisions to business consequences. Without that connection, investment decisions are made on the basis of what security teams find alarming — not what the business would find catastrophic.
A cyber risk assessment answers the question the board is actually asking: not "what did security do this quarter" but "what are we exposed to, how exposed are we, and what would it cost us if something went wrong."
The CFO asked a single question in the quarterly review: which risks are we less exposed to than we were six months ago? Nobody in the room could answer it. The security team presented utilisation metrics — licences consumed, incidents reviewed, patches deployed. Activity had been measured. Exposure had not. The board had been approving a budget without knowing what it was buying.
The risk assessment started with the usual scope — infrastructure, endpoints, cloud configuration. Halfway through, it became clear that the single largest exposure was a payments processor dependency with no contractual SLA, no documented fallback, and a 72-hour recovery window that would have halted the business entirely. The most material risk was not a technical vulnerability. It was a commercial relationship nobody had put in a risk register.
The technical due diligence covered the codebase and the infrastructure. The risk assessment was not commissioned until after the deal completed. Six weeks in, the acquiring company discovered an unresolved regulatory notice, a third-party data sharing arrangement with no DPA, and an open insurance claim. All three were in plain sight before the close. None were in the scope of what anyone had been asked to review.
Most organisations conflate risk with threat. A threat is something that could happen. Risk is the product of how likely it is to happen, how much damage it would cause if it did, and how much of that exposure your existing controls have actually reduced. The assessment measures all three — separately and in combination.
The assessment is structured around business impact, not technical categories. The output is a risk register the board can interrogate and a treatment plan the business can act on.
Not every threat in the security literature is relevant to every business. The threat landscape analysis identifies the threat actors, scenarios, and attack vectors that are plausible given this company's industry, data, geography, and dependencies — and filters out the noise.
Risk cannot be quantified without knowing what is at stake. The impact analysis identifies the assets, processes, and relationships the business depends on — and maps what the financial, operational, and reputational consequences of losing each one would be.
The risk register produced by the assessment is not a vulnerability list with CVSS scores. It is a structured record of business risks, ranked by inherent and residual exposure, and written for the people who will govern them — not the team that identified them.
Every material risk in the register leaves the assessment with a treatment decision attached — made deliberately, not by default. Mitigations are costed and prioritised by the reduction in residual exposure they deliver, not by technical interest or ease of implementation.
A risk assessment that ends with a spreadsheet nobody reads has not reduced risk — it has produced paperwork. This one ends with a risk register the board governs and a treatment plan the business executes.
The scope of a risk assessment determines everything it can and cannot find. A scope that is too narrow produces a clean register that misses the most material risks. A scope that is too broad produces an unmanageable register nobody governs. This phase establishes the business activities, assets, and third-party dependencies that will be assessed — and explicitly records what is out of scope and why.
Days 1–3Interviews with business owners, technology leads, and operational teams — not just IT — to understand what the business does, what it depends on, and what is already in place to protect it. The most important inputs to a risk assessment are often not in a security team's possession. The commercial relationship with no fallback plan. The operational process that bypasses the approved system. The regulatory obligation that was inherited and never reviewed.
Days 3–10Each risk is assessed for the likelihood of occurrence and the business impact if it materialises — producing an inherent risk rating. Existing controls are then evaluated for their effectiveness in reducing that exposure — producing the residual risk rating. The gap between inherent and residual risk shows whether the controls in place are actually working, or whether they exist on paper but are not reducing exposure in practice.
Days 10–18The risk register is presented to the board with treatment recommendations — not as a briefing document, but as a governance artefact the board will own and review on a defined cadence. Treatment decisions are made with the business during this phase. A risk register that leaves the assessment without treatment decisions is not a governance tool — it is evidence that the assessment ended before the most important conversation happened. The register is handed over with named risk owners and a review cadence embedded.
Days 18–25The value of a risk assessment is highest before an incident, an acquisition, or a board question forces one. The organisations that get the most from it are the ones that commission it while there is still time to act on what it finds.
The board has started asking questions about security risk that the current reporting cannot answer. Utilisation metrics and incident counts do not address exposure — and the board is right to want more. A risk assessment gives the security function the structured view of business risk that makes board reporting substantive rather than defensive.
An acquisition, a funding round, or a significant new enterprise customer relationship will prompt security due diligence from the other side. A current risk assessment — with treatment decisions made and risk owners named — puts the company in a position to answer those questions from a documented position rather than assembling the answer under time pressure.
The security stack is in place. Monitoring is running. Alerts are being reviewed. But nobody has mapped what any of it is protecting against, in what priority order, or whether the investments made correspond to the risks that matter most to the business. The tools are not the problem — the absence of a risk framework to evaluate them against is.
An incident has occurred. The immediate response is complete. The question the board is now asking is: what else is out there that we have not mapped? A post-incident risk assessment answers that question systematically — covering the risks that were managed and the ones that were not, and producing a treatment plan for what remains.
The assessment ends with documents the organisation owns and uses — not a report that gets filed and referenced at the next incident review.
A structured record of material risks, ranked by residual exposure, with inherent and residual ratings documented and control effectiveness assessed. Written for the board and business owners — not for the security team that produced it. Each risk has a named owner and a treatment decision attached.
Treatment decisions for every material risk in the register — mitigate, accept, transfer, or avoid — with the rationale documented. Mitigations are sequenced by the reduction in residual risk they deliver per unit of investment. The treatment plan is a prioritised investment case, not a wish list.
A board-ready risk summary that presents the material risks, the treatment decisions made, and the residual exposure that remains. Designed to be presented by whoever owns security in the business — not to require the assessor in the room to interpret it.
A risk register that is not reviewed becomes a historical document. The assessment includes a defined review cadence — quarterly for the highest-rated risks, annually for the full register — and a process for adding new risks as the business changes. The register is a living governance tool, not a point-in-time snapshot.
When the board asks what the business is exposed to, the answer is in the register. When the CFO asks what the security budget reduced, the treatment plan shows it. When an acquirer or investor asks for a risk assessment, it exists and is current. The business is not safer because the assessment happened — it is safer because of the decisions the assessment made possible.