Risk management
Identify, rate and track technology risk in terms leadership can act on, with treatment decisions recorded and revisited rather than written once and filed.
What we review
- Risk identification: What could realistically go wrong, drawn from the actual environment rather than a generic list.
- Business impact: What each risk would cost in downtime, recovery effort, data loss or obligation.
- Likelihood basis: Why a risk is rated as it is, stated so the rating can be challenged.
- Existing controls: What already reduces each risk, and whether it has been verified rather than assumed.
- Risk appetite: What level of risk the organization is willing to carry, made explicit rather than implied.
- Treatment options: Reduce, transfer, avoid or accept, with the cost and consequence of each.
- Ownership: Who owns each risk and who has authority to accept it.
- Review cycle: When each risk is revisited, so the register reflects the current environment.
Deliverables
- Risk register: Identified risks with impact, likelihood, rationale and owner, in business language.
- Treatment plan: Recommended action per risk, with cost, expected reduction and dependencies.
- Acceptance record: Risks the organization has chosen to carry, who accepted them, and when.
- Prioritised spending view: Where a limited budget reduces the most risk.
- Board-ready summary: A plain-language position suitable for leadership reporting.
- Review schedule: When each risk is revisited and what would trigger an earlier review.
Engagement boundaries
- Risk management supports decisions; it does not make them. Risk acceptance is the organization's decision.
- Ratings are judgements based on available evidence and stated assumptions, not statistical prediction.
- This work does not certify compliance with any framework or standard.
- It is not legal advice, insurance advice, or financial advice.
- A risk register does not prevent incidents. It makes exposure visible and decisions deliberate.
- Risks depending on information you do not disclose cannot be assessed.
- Quantification is expressed as ranges and assumptions, not false precision.
- Treatment costs are estimates; actual vendor and labour costs will vary.
- The register ages. Without the review cycle it reflects the environment at a point in time only.
Questions before the work starts
How is this different from your security policy and governance service?
Governance work defines how the organization intends to operate and writes that down. Risk management identifies what could go wrong, rates it, and tracks treatment decisions. They complement each other, and can be scoped together or separately.
Will you tell us our risk in dollars?
Where there is a defensible basis, impact is expressed as a range with the assumptions stated. Precise single figures for security risk usually imply a confidence the underlying data does not support.
Who decides what risk we accept?
You do. The engagement makes the exposure, the options and the cost visible, and records who accepted what and when. That record is often what an insurer or board is actually asking for.
We have a risk register already. Is this still useful?
Often, yes, depending on its state. The common problems are registers built from generic templates rather than the real environment, ratings with no stated reasoning, and no review since the day they were written.
Does a risk register satisfy our insurer or client?
It frequently forms part of what they ask for, but requirements vary and we cannot promise any third party will accept a given document. What the work provides is a defensible register with visible reasoning and recorded decisions.
The platforms this work covers
Risk identification draws on the platforms your business actually depends on, so the register reflects real exposure.
- Microsoft 365 and Entra ID
- Microsoft Azure
- Amazon Web Services
- Cisco
- Palo Alto Networks
- Check Point
- Fortinet FortiGate
- F5
- Cloudflare
- On-premises and colocation data centre
Audits available
- Concentration risk review: where a single platform, tenant or provider carries disproportionate business impact.
- Control verification: whether the controls assumed to reduce a rated risk actually operate as believed.
- Dependency risk review: third-party and supply-chain dependencies that would halt operations if unavailable.
Other ways we can help
Engagements are often scoped together; these are the closest neighbours to this one.
Need a second set of eyes on a security or infrastructure decision?
Describe the environment, the risk and the outcome you need.