A risk register with forty entries and no owner is a document. A register with eight risks and a name against each is a decision.
A risk assessment answers four questions: what could go wrong, how likely is it, what would it cost, and what are we going to do. Everything else is presentation. We work to a recognised method, quantify where quantification is honest, and hand over a register the business can actually maintain.
- Four questionsWhat, how likely, how bad, what now
- Named ownersEvery risk, and every treatment
- Recognised methodAligned to published guidance
- MaintainableA register that survives the engagement
Seven things that determine whether a risk assessment changes anything.
We start from what the business does, not from the technology
A risk assessment that begins with an asset list produces a list of technical concerns. One that begins with what the organisation does, what would stop it doing that, and what the consequence would be, produces risks a board recognises. The technology enters at the second step, as the thing that fails, not as the subject.
We keep the register short enough to be worked
The most common failure is a register with dozens of entries, none of which anybody is accountable for. A register that lists everything ranks nothing. Consolidating to the risks that genuinely warrant a decision, with the rest recorded as observations, is what makes the difference between a document reviewed annually and one that drives work.
Every risk gets an owner who is not the IT manager
A risk owned by IT is a technical issue. A risk owned by the function that would suffer the consequence is a business risk with a budget holder attached. That reassignment is frequently uncomfortable and it is the single change that most improves whether treatments actually get funded and completed.
We quantify where quantification is honest
Some risks can be expressed in money: downtime cost per hour, regulatory exposure, contractual penalty, recovery cost. Others genuinely cannot, and inventing a number for them damages the credibility of the ones that can. Being explicit about which is which is more persuasive than a uniformly quantified register that nobody believes.
Treatments map to a real control catalogue
A treatment described as improve access management is not a treatment. Mapping each treatment to specific controls, using a prescriptive catalogue such as the CIS Critical Security Controls at version 8.1, converts the register into a work plan. It also lets you show which risks a piece of security spending actually reduces.
Accepted risks are recorded as decisions, with a name and a date
Risk acceptance is a legitimate treatment and it is frequently the right one. What makes it defensible is that somebody with the authority to accept it did so knowingly, in writing, with a review date. An accepted risk with no name attached is not an acceptance, it is an omission that will be described as one after an incident.
The register is designed to be maintained by you
An assessment that produces a register only we can update has failed. Format, terminology and scoring are agreed so that your own people can add a risk when something changes, and so the next review is an update rather than a repeat engagement. That is the difference between an assessment and a risk management function.
Most risk registers fail at ownership, not at methodology.
The method is well documented and rarely the problem. What goes wrong is who is named against each entry.
- A risk owned by the IT manager is a technical issue competing with every other technical issue for the same budget and the same attention. It will be reviewed, agreed to be important, and not funded.
- The same risk owned by the finance director, the operations director or whoever would carry the consequence is a business risk with an owner who can escalate it. Nothing about the risk changed. The reassignment is what changes the outcome.
- The same applies to acceptance. An accepted risk needs a named person with the authority to accept it, a date, and a review point. Without those three it is not an acceptance and it will not be treated as one afterwards.
- This is uncomfortable to do and it is the reason we do it during the assessment rather than leaving it as a recommendation. Every risk leaves the workshop with a name against it, agreed in the room.
Four things that turn an assessment into a risk management function.
We assign business owners in the room
Every risk leaves the workshop with a named owner who would carry the consequence, agreed in front of the people who need to agree it. Doing this as a recommendation afterwards produces a register where IT owns everything, which is the most reliable predictor that nothing will be funded.
We consolidate ruthlessly
A register that lists everything ranks nothing. We consolidate to the risks that genuinely warrant a decision at leadership level, and record the rest as observations feeding the technical work plan. A short register gets read. A comprehensive one gets filed, and the difference is not the quality of the analysis.
We map treatments to a prescriptive control catalogue
The CIS Critical Security Controls at version 8.1 give eighteen named controls in a prioritised order. Mapping each treatment to specific controls converts a risk register into a work plan, lets you show which risks a piece of spending reduces, and removes the gap between the risk document and the security programme.
We are explicit about what we cannot quantify
Downtime cost per hour, recovery cost and contractual exposure can often be estimated with the business. Reputational damage generally cannot, and inventing a figure for it makes a reader distrust the numbers that were real. Saying which is which is more persuasive than a uniformly quantified register nobody believes.
Six UAE situations where a risk assessment is the right starting point.
A regulated firm asked to demonstrate a risk-based approach
UAE regulatory frameworks commonly require controls proportionate to risk without prescribing which controls. That obligation is unanswerable without a documented risk position. An assessment with named owners, recorded acceptances and treatments mapped to specific controls is what turns a proportionality requirement into an evidenced position.
An organisation completing a cyber insurance application
Insurer questionnaires increasingly ask what your material risks are and what you are doing about them, not only whether specific controls exist. A current register with owners and treatments is a materially better answer than a control checklist, and it usually improves the conversation about what is and is not covered.
A board that has started asking whether the organisation is safe
That question cannot be answered with a control list. A short register in business language, with quantification where honest, an owner against each entry and a clear statement of what has been accepted, is the artefact that answers it and that a board can act on. It also tends to make the next budget conversation shorter.
An operator whose real exposure is availability rather than data
For plants, logistics and production businesses the dominant risk is usually not disclosure, it is stopping. Framing the assessment around what halts operations, for how long, and at what hourly cost produces a register that operations recognises, and treatments that land on recovery and monitoring rather than on data controls.
An organisation before or after an acquisition
Acquisitions bring an estate nobody has assessed, contracts nobody has read and controls nobody has verified. A risk assessment scoped to the acquired entity, using the same method and format as the parent, is what makes the two comparable and what identifies the integration work that genuinely cannot wait.
An organisation with a register nobody has updated in three years
The most common situation we are called into. The right response is usually to update rather than replace, keeping whatever structure people already recognise, correcting the ownership, consolidating the length and mapping treatments to controls. A rebuilt register that nobody recognises has the same fate as the one it replaced.
How UAE organisations understand their IT risk.
| Feature | A maintained risk register | A register produced for an audit | No formal risk view |
|---|---|---|---|
Risks expressed in business terms | Yes | Partly | No |
Owner named per risk | Yes | IT, for all of them | No |
Owner able to fund treatment | Yes | No | Not applicable |
Quantified where honest | Yes | Uniformly or not at all | No |
Treatments map to specific controls | Yes | No | No |
Acceptance recorded as a decision | Yes | Implicitly | No |
Updated between reviews | Yes | No | Not applicable |
Used to prioritise spending | Yes | No | No |
Survives a regulator question | Yes | Partly | No |
Maintained by whom | You | Nobody | Not applicable |
Nine risk areas, and the question each one asks.
| Risk area | The question it asks | Where treatment usually lands | |
|---|---|---|---|
| Availability of critical services | What stops the business operating, and for how long | Data recovery, network infrastructure, incident response | |
| Confidentiality of sensitive data | What data would hurt most if disclosed, and who can reach it | Data protection, account management, access control | |
| Integrity of records and transactions | What would happen if a record were changed and nobody noticed | Audit log management, application security | |
| Identity and privileged access | Who could act as somebody else, and would you know | Account management, access control, audit logging | |
| Third parties and suppliers | Who has access to your systems and data, and under what terms | Service provider management | |
| Endpoints and the estate | What exists, what is unpatched, and what is unmanaged | Enterprise and software asset inventory, vulnerability management | |
| People and process | What could be done in error, and what would prevent it | Security awareness and skills training | |
| Regulatory and contractual exposure | What have you promised, and to whom | Varies by obligation, mapped per requirement | |
| Detection and response capability | Would you know, and what would you do | Network monitoring, incident response management |
Five steps, and the workshop is where the value is created.
- 1
Establish scope, context and what is driving it
Which entities and locations, whether this is cyber risk or IT risk broadly, whether third parties are included, and what obligation or question prompted the assessment. That last one determines what has to be evidenced and in what form, and it is worth being explicit about rather than assuming.
- 2
Understand what the business does and what would stop it
Before any technology is discussed. What the organisation actually does, which processes are critical, what the tolerance for interruption is, and what the consequence of disclosure or corruption would be. The technology enters at the next step as the thing that fails, which produces risks a board recognises.
- 3
Identify, analyse and consolidate
Risks identified from the business view, the technical position, the third-party picture and any recent incidents. Then analysis of likelihood and consequence, with quantification where it is honest and an explicit statement where it is not. Then consolidation, because a register that lists everything ranks nothing.
- 4
Assign ownership and agree treatment in the room
Each risk gets a business owner who would carry the consequence, agreed with the people present rather than recommended afterwards. Treatment decided as treat, transfer, accept or avoid, with accepted risks recorded as a named decision with a date and a review point. Treatments mapped to specific controls.
- 5
Hand over a register you can maintain
Format, terminology and scoring agreed so your own people can add and update entries. A process for how a new risk enters the register, when accepted risks are reviewed, and how treatments reach the budget cycle. The measure of success is that the next review is an update rather than a repeat engagement.
What organisations ask about risk assessments.
Fifteen things that make the output usable.
Scope
- Which entities and locations?Groups often assess one and generalise.
- Is this cyber risk or IT risk broadly?They overlap and are not the same.
- Are third parties in scope?Frequently where the largest exposure sits.
- Is there an existing register?Updating beats replacing.
- What obligation is driving this?It shapes what must be evidenced.
Participation
- Will business owners attend, not only IT?Otherwise everything gets owned by IT.
- Is finance involved for the quantification?They know what downtime costs.
- Is somebody able to accept risk present?Acceptance needs authority.
- Are operations represented?They know what actually stops the business.
- Who signs off the register?Agree before, not after.
Afterwards
- Who maintains the register?It must be updatable by you.
- How does a new risk get added?A process, not an email.
- When are accepted risks reviewed?Acceptance needs an expiry.
- How do treatments get funded?Map them to a budget cycle.
- When is the next full review?Annually, or after a material change.
The pages around this one.
Open your risk register and check who owns entry number one.
If the answer is the IT manager, and the same is true of every other entry, the register is a technical document wearing a governance label. Fixing that is a workshop, not a project, and it changes what happens next.
Related Services
Explore more solutions that work great with this service
CIS Controls Assessment
Eighteen controls, assessed and re-assessed
NIST CSF 2.0 Assessment
Know where you stand, without committing to certification
IT Audit Services Dubai
Assessment, technical test or certification, scoped properly
Cybersecurity Audit
Security assessment and compliance audit
Business Continuity Planning
BCP, RPO/RTO design, and DR runbook authoring
Third Party Risk Audit
Who can actually reach your systems, and what to do about it
Virtual CISO Dubai
Security governance and accountability, not more tools
Compliance as a Service
Keeping the position true between assessments