How to complete the ISO 27001 risk register?
An ISO 27001 risk register records the information security risks that could affect an organisation, explains how serious each risk may be and shows what the business will do about it. It creates a practical link between business activities, information assets, threats, weaknesses, controls and management decisions.
Completing the register properly requires more than listing technical problems. The organisation must consider people, suppliers, processes, physical information, cloud services, customer obligations and operational dependencies. Each entry should explain the risk clearly enough for a manager, control owner or auditor to understand it.
ISO/IEC 27001 does not require one prescribed risk assessment method or a particular software format. The organisation can choose an approach that suits its context, provided the method produces consistent, valid and comparable results. The documented process should define likelihood, impact, risk acceptance, treatment priorities and review arrangements.
UK Cyber Compliance provides ISO 27001 support through an automated and AI-driven platform. UK Cyber Compliance (a part of UK Cyber Security Group) provides these services and has a platform to make certification much easier and cheaper. The platform helps businesses organise risk assessments, controls, owners, actions, policies, evidence and audit preparation in one place.
Why the risk register matters
The risk register helps an organisation decide where to focus its security effort. Without it, teams may spend time on visible technical issues while overlooking serious risks involving staff, suppliers, customer information or business continuity.
A useful register gives leaders a clear view of the organisation’s exposure. It should show which risks sit within the agreed appetite, which need treatment and which require urgent attention.
The register also supports accountability. Every meaningful risk should have an owner with enough authority to review the position, approve treatment and secure the resources needed to act. ISO guidance for auditors specifically highlights the need for risk owners who have suitable accountability and authority.
Current UK data reinforces the need for structured risk management. The Cyber Security Breaches Survey 2025 to 2026 found that 43 per cent of businesses identified a cyber breach or attack during the previous 12 months. This represented about 612,000 UK businesses.
What is ISO 27001 Certification?
ISO 27001 certification provides independent confirmation that an organisation operates an Information Security Management System that meets ISO/IEC 27001 requirements.
An Information Security Management System, often shortened to ISMS, gives the organisation a structured way to protect information. It covers business context, scope, leadership, risk management, policies, objectives, resources, awareness, suppliers, controls, internal audit, management review and continual improvement.
ISO describes ISO/IEC 27001 as the best-known standard for information security management systems. It helps organisations establish, implement, maintain and continually improve an ISMS while applying a risk management process that reflects their needs.
Certification does not promise that no incident will occur. It demonstrates that the organisation has built a controlled process for identifying risk, selecting safeguards, assigning responsibility, reviewing evidence and improving its security arrangements.
The risk register provides a central source of evidence for that process. It shows how the organisation understands threats and how management turns risk information into practical action.
what is iso 27001
ISO 27001 is the commonly used name for ISO/IEC 27001, the international requirements standard for information security management systems.
The standard helps organisations preserve confidentiality, integrity and availability by applying a risk management process. Confidentiality means that only authorised people and systems can access information. Integrity means that information remains accurate and reliable. Availability means that authorised users can reach information and services when required.
ISO 27001 takes a joined approach to information security. It considers people, policies, processes, suppliers, physical assets and technology rather than focusing only on IT equipment.
A risk register supports this approach by documenting risks from across the ISMS scope. A good register may contain technical threats, but it should also include staff mistakes, supplier failures, legal exposure, physical loss, weak governance and interruptions to critical services.
Build the risk method before completing the register
Start by defining the method that everyone will use. A consistent method prevents different teams from rating similar risks in completely different ways.
The risk assessment process should explain:
How the organisation identifies risks
How it records causes, events and consequences
How it assesses likelihood
How it assesses impact
How it calculates or assigns the risk level
How it decides whether a risk remains acceptable
Who can approve acceptance
How it prioritises treatment
When it reviews the register
The ISO committee’s auditor guidance notes that organisations commonly use likelihood and impact scales such as one to three or one to five. It also stresses the need for clear rules so that relevant staff understand and apply the method consistently.
The method should remain simple enough to maintain. A complicated model may look impressive during the first assessment, but it creates little value when nobody updates it.
Define likelihood clearly
Likelihood describes how realistically the risk event could occur.
Avoid labels that have no agreed meaning. If the register uses low, medium and high, define each label. If it uses numbers, explain what each number represents.
The assessment may consider:
Past incidents
Threat activity
Known weaknesses
Exposure to the internet
Supplier dependency
Staff behaviour
Current security controls
Frequency of the relevant activity
Changes in technology or operations
A high likelihood should not mean that the event will definitely happen. It means that the available information suggests a credible chance of occurrence.
The organisation should use the same criteria across departments. This creates comparable results and makes prioritisation more reliable.
Define impact in business terms
Impact explains the harm that the organisation could suffer if the risk event occurs.
Consider more than financial loss. An information security incident may affect:
Customer service
Operational availability
Legal duties
Contractual commitments
Personal information
Business reputation
Staff productivity
Sensitive commercial information
Safety or welfare
Regulatory relationships
Confidentiality, integrity or availability
The impact scale should include clear examples. A low impact event may cause a short internal delay with no customer effect. A severe event may interrupt critical services, expose sensitive records or breach major contractual duties.
Process owners should support the impact assessment. They often understand customer and operational consequences better than the security team alone.
Set the risk acceptance criteria
Risk acceptance criteria define the level of risk that the organisation can tolerate.
A vague statement such as “we have a low appetite for risk” does not provide enough guidance. Staff need clear rules that they can apply to individual entries.
For example, the method may state that:
Low risks can receive approval from the process owner
Moderate risks need a documented treatment decision
High risks require senior management review
Critical risks need immediate action and executive oversight
The exact thresholds should reflect the organisation’s context, obligations and services. A regulated provider handling sensitive information may adopt a lower tolerance than a business with limited confidential data.
The criteria should also explain whether a manager can accept a risk temporarily while treatment remains underway. Every acceptance decision should identify the approver and review date.
Define the ISMS scope before listing risks
The risk register must cover the full ISMS scope.
Start by identifying the services, processes, systems, information, locations, people and suppliers included in certification. If the scope covers a customer platform, the register should consider every significant dependency that supports that platform.
Common scope elements include:
Customer-facing services
Cloud platforms
Business applications
Staff devices
Networks
Paper records
Remote workers
Support providers
Software suppliers
Physical workplaces
Customer information
Internal operational information
The auditor guidance warns against risk assessments that only cover IT systems while ignoring information held elsewhere, information used outside company locations or dependencies connected with the wider business context.
A clear scope reduces the chance that the register misses a critical service or supplier.
Involve people from across the organisation
Do not ask one person to identify every risk alone.
The security lead may coordinate the process, but risk identification should involve process owners, management, IT, human resources, operations, procurement and other relevant teams.
Each participant brings different knowledge. IT may understand technical weaknesses. Operations may understand service dependencies. Human resources may identify staff and leaver risks. Procurement may understand supplier exposure. Senior leaders can explain strategic and customer priorities.
Workshops provide a practical way to gather this input. Use plain language and ask participants what information they rely on, what could disrupt their work and what consequences would matter most.
The ISO committee guidance states that risk identification should involve more than the information security team.
Write each risk as a clear scenario
A useful risk entry describes a scenario rather than naming a single threat.
“Phishing” alone provides too little information. A stronger risk statement might say:
“An employee may respond to a convincing phishing message, allowing an unauthorised person to access the company email environment and disclose customer correspondence.”
This statement identifies:
The cause or threat
The event
The affected asset or service
The potential consequence
Another example could say:
“A failure at the primary cloud provider may make the customer portal unavailable, leading to missed service commitments and customer disruption.”
Clear scenarios help teams assess impact and choose relevant controls.
A practical structure uses:
Because of a cause or weakness
A threat event may occur
Which could create a business consequence
This format keeps the register focused on outcomes rather than technical language.
Give every risk a unique reference
Assign a unique identifier to every entry. References such as R001, R002 and R003 make it easier to connect the register with controls, treatment actions, audit records and management reports.
Avoid reusing deleted identifiers. The history may matter during an audit or later review.
The register should also include a concise title. A title such as “Unauthorised cloud access” helps users find the entry, while the full description explains the scenario.
Keep references stable when the risk changes. Update the content and record the revision rather than creating a completely new entry for every minor change.
Identify the affected assets and processes
Record which information, systems or processes the risk could affect.
Possible entries include:
Customer database
Staff records
Finance application
Email service
Remote access platform
Company laptops
Website
Cloud storage
Supplier portal
Paper files
Service desk
Development environment
Do not limit assets to hardware. Information, services, business processes and supplier relationships can all form part of the assessment.
The register may also identify the relevant confidentiality, integrity and availability concerns. A customer data exposure primarily affects confidentiality, while unauthorised record changes affect integrity. A system outage affects availability.
Many risks affect more than one security objective.
Record the risk owner
The risk owner should have enough authority to understand the consequences and approve action.
A risk involving the finance platform may belong to the Finance Director rather than the IT technician who manages the software. A supplier risk may belong to the manager responsible for that relationship.
The owner should:
Review the risk rating
Confirm the business impact
Approve treatment
Secure resources
Monitor action
Accept remaining exposure where authorised
Escalate when required
Use role titles where possible so that the register remains clear when personnel change.
A control owner and risk owner may not be the same person. The risk owner remains accountable for the overall exposure, while control owners manage specific safeguards.
Record existing controls before calculating the current risk
Existing controls show what the organisation already does to reduce likelihood or impact.
For a phishing risk, existing controls may include:
Multi-factor authentication
Email filtering
Security awareness
Restricted user privileges
Incident reporting
Account monitoring
Backups
Do not list a control simply because a policy mentions it. Confirm that the organisation operates the measure and can produce evidence.
The register should distinguish between controls already working and actions that the organisation only plans to introduce.
Understanding current controls helps the organisation avoid overstating exposure or giving itself credit for unfinished work.
Assess inherent and current risk carefully
Many organisations record more than one rating.
Inherent risk shows the exposure before considering controls.
Current risk shows the exposure after considering controls already in operation.
Residual risk shows the expected exposure after planned treatment finishes.
These labels can help, but ISO 27001 does not prescribe a single model. Use terminology that staff understand and define it within the method.
Avoid calculating inherent risk if it adds no management value. Some teams spend significant effort imagining a control-free environment that could never exist. The organisation should choose an approach that supports good decisions.
Whatever method you choose, apply it consistently and explain it clearly.
Calculate the risk level
A common method multiplies likelihood by impact. For example, a likelihood score of four and an impact score of five produces a risk score of twenty.
Other organisations use a matrix or defined descriptive bands.
The formula matters less than consistency. The process should produce results that staff can compare and use for prioritisation.
Check whether the calculated score makes sense. A numerical result should not replace management judgement.
A low-likelihood event with catastrophic consequences may still need strong attention. Legal duties or customer commitments may also require action even when the general score appears modest.
Record any management adjustment and explain the reason.
Compare the result with acceptance criteria
After rating the risk, decide whether it sits within the agreed appetite.
The register should show:
Whether the risk remains acceptable
Who made the decision
The date of approval
Any conditions attached to acceptance
The next review date
Risk acceptance does not mean ignoring the issue. It means that the organisation has reviewed the exposure and made an informed decision.
Accepted risks still need monitoring. Changes in threat activity, services, customers or laws may make the earlier decision unsuitable.
High risks should receive suitable visibility through management review or another senior governance process.
Select a treatment approach
The organisation usually has four broad options.
Reduce
Apply or improve controls to lower likelihood or impact.
Avoid
Stop the activity that creates the risk.
Transfer
Move part of the exposure through a contract, service arrangement or insurance.
Accept
Retain the risk because it falls within the approved criteria.
A treatment decision may use more than one option. A company may reduce supplier risk through due diligence and contracts while transferring part of the financial exposure.
Record the chosen approach in the register and explain why it makes sense.
Create clear treatment actions
Every planned action should identify:
The required work
The responsible owner
The target date
The current status
The control it supports
The expected risk reduction
The evidence needed for closure
Avoid vague actions such as “improve security” or “review supplier.”
A stronger action could say:
“Enable multi-factor authentication for all finance platform users and retain the administrator report as evidence by 30 September.”
Actions should remain realistic. Large tasks may need several milestones.
The risk owner should check that completed actions work before closing them.
Link the register to Annex A controls
Risk treatment determines the safeguards the organisation needs. The business should then compare those safeguards with Annex A to check that it has not overlooked a relevant control.
The register may include a field for linked Annex A references. A phishing risk might connect with controls for awareness, authentication, malware protection, logging and incident reporting.
Do not force every risk to connect with only one control. Several controls may support one risk, and one control may reduce several risks.
The Statement of Applicability should align with the register. If a control appears necessary in risk treatment, the SoA should explain its inclusion and implementation status.
The risk register, treatment plan and SoA should tell one consistent story.
Record residual risk
Residual risk shows the exposure that remains after treatment.
Reassess likelihood and impact once the planned controls operate. Do not lower the score automatically. Consider whether the measures have genuinely changed the risk.
For example, multi-factor authentication may reduce the likelihood of account takeover, but it does not remove phishing risk completely.
The risk owner should review the residual rating and confirm whether it falls within the agreed criteria.
When residual exposure remains too high, the organisation needs more treatment or a senior decision.
Add review dates and triggers
Every risk should have a planned review date.
The organisation may review high risks more often than low risks. It should also update the register when significant change occurs.
Useful review triggers include:
A security incident
A new supplier
A major customer contract
A cloud migration
A new service
A legal change
A serious vulnerability
A location change
A change in working practice
An audit finding
A failed control
The ISO committee guidance recommends defined rules for updating the assessment, including regular intervals and changes that affect the ISMS scope.
Keep evidence with the risk record
Evidence supports the accuracy of the register.
Relevant evidence may include:
Risk workshop notes
System reports
Supplier reviews
Vulnerability findings
Incident records
Access reviews
Contract clauses
Management approvals
Control test results
Training records
Backup reports
Audit findings
Link evidence rather than copying large documents into the register. A central platform can make these connections easier to maintain.
Evidence should remain current. An old screenshot or expired supplier certificate may no longer support the control claim.
Who needs iso 27001 certification
ISO 27001 certification can benefit organisations that handle important information and need to demonstrate reliable security management.
Technology providers, managed service providers, software businesses, professional firms, manufacturers, charities, healthcare suppliers, finance-related organisations and public sector contractors may all gain value.
Customers often request certification during supplier assurance. They want confidence that a provider identifies risk, assigns responsibility and operates suitable controls.
ISO states that organisations from any sector can apply the standard and adapt the risk management process to their own needs.
A smaller organisation does not need an unnecessarily complex register. It needs an approach that covers the full scope, supports real decisions and remains easy to maintain.
ISO 27001 Certification Levels
ISO 27001 does not award bronze, silver, gold or other formal achievement bands.
An organisation either holds certification for its stated ISMS scope or it does not.
Businesses may move through practical preparation stages, including scope definition, risk assessment, treatment, control implementation, internal audit, management review and external assessment.
Security maturity can improve after certification. The organisation may strengthen controls, improve evidence, automate monitoring or expand the ISMS scope.
Continual improvement describes that progress. It does not create official certification bands.
How the Certification Works
The organisation first defines its context, interested parties and ISMS scope.
It then establishes a risk assessment method and completes the risk register. Risk treatment identifies the controls and actions needed to reduce unacceptable exposure.
The organisation compares its selected controls with Annex A and records its control position in the Statement of Applicability.
Next, it operates the ISMS and gathers evidence. Internal audit checks conformity and effectiveness. Management review allows senior leaders to review performance, risks, resources and improvement needs.
An external certification body normally carries out a readiness assessment followed by a deeper implementation assessment.
After successful certification, ongoing assessments check that the ISMS remains active and effective.
Common risk register mistakes
One common mistake involves recording threats without consequences. “Malware” or “data breach” alone does not provide enough information for a useful assessment.
Another involves covering only IT systems. The register must consider the full ISMS scope, including people, suppliers, physical information and business processes.
Some organisations create too many highly detailed entries. The ISO committee guidance warns that overly demanding approaches can become difficult to maintain and may produce large amounts of data with little meaning.
Other common weaknesses include:
No clear risk owner
Inconsistent scoring
Undefined acceptance criteria
Planned controls recorded as complete
No connection with the SoA
Overdue treatment actions
Risks that never receive review
Generic entries copied from templates
A strong register remains specific, proportionate and current.
A practical example: phishing and email compromise
Risk reference: R001
Risk title: Email account compromise
Risk scenario: An employee may respond to a convincing phishing message, allowing an unauthorised person to access the email environment and expose customer or business information.
Affected assets: Email service, customer correspondence and staff accounts.
Owner: Operations Director.
Existing controls: Multi-factor authentication, email filtering, staff awareness and account monitoring.
Likelihood: Possible.
Impact: Major.
Current risk: High.
Treatment: Improve phishing reporting, review administrator accounts and test incident response.
Residual risk target: Moderate.
Review trigger: Significant phishing campaign, account alert or control failure.
This entry gives management a clear scenario and a practical route to action.
A practical example: cloud supplier failure
Risk reference: R002
Risk title: Critical cloud service outage
Risk scenario: A prolonged failure at the cloud provider may make the customer service platform unavailable and prevent staff from meeting contractual commitments.
Affected assets: Customer platform, service records and support operations.
Owner: Service Delivery Director.
Existing controls: Supplier review, service agreement, backup and incident communication process.
Likelihood: Unlikely.
Impact: Severe.
Current risk: High.
Treatment: Test data recovery, confirm alternative communication arrangements and review supplier continuity evidence.
Residual risk target: Moderate.
Review trigger: Supplier incident, service change or contract renewal.
The entry connects the supplier relationship with customer and availability consequences.
A practical example: lost laptop
Risk reference: R003
Risk title: Loss of staff device
Risk scenario: A staff member may lose a laptop while travelling, creating a risk of unauthorised access to company and customer information.
Affected assets: Laptop, locally accessible information and cloud credentials.
Owner: IT Manager.
Existing controls: Device encryption, screen lock, multi-factor authentication and remote management.
Likelihood: Possible.
Impact: Moderate.
Current risk: Moderate.
Treatment: Maintain device inventory, test remote response and reinforce travel guidance.
Residual risk target: Low.
Review trigger: Lost device report or control failure.
The risk remains understandable to both technical and non-technical readers.
Preparing the register for audit
Before an external assessment, confirm that:
The risk method has approval
The register covers the full scope
Every risk has an owner
Likelihood and impact follow the method
Ratings remain consistent
Acceptance decisions have authority
Treatment actions remain current
Control links agree with the SoA
Evidence supports existing controls
Residual risks have approval
Review dates remain current
Management has visibility of major risks
The auditor may select several entries and trace them through risk treatment, controls and evidence.
Control owners and risk owners should understand the entries rather than relying on a consultant to explain them.
Which UK-based firms offer ISO 27001 consultancy services?
UK organisations can seek help from information security consultancies, compliance advisers, managed service providers, internal audit specialists and platform-led providers.
UK Cyber Compliance supports ISO 27001 through an automated and AI-driven platform. Its service streamlines risk management, control tracking and audit-ready documentation.
A capable provider should help the business define its method, identify risks, set acceptance criteria, select treatment actions, connect controls and prepare for audit.
Good support should leave the organisation able to understand and maintain its own register. The adviser should not create a complicated document that nobody inside the business can update.
How UK Cyber Compliance helps manage the risk register
A spreadsheet can support a small register, but it may become difficult to manage when the organisation adds owners, actions, controls, policies, evidence and review dates.
UK Cyber Compliance brings this information into a central platform. Teams can record risks, assign owners, monitor treatment, connect controls and maintain supporting evidence.
Automation can reduce repeated administration and improve visibility. AI-driven guidance can help users work through the certification process more efficiently.
The organisation still makes every important decision. Leaders define appetite, approve treatment and accept residual exposure.
The platform supports those decisions by giving managers a clearer view of gaps, actions and audit readiness.
Make the register a working management tool
The ISO 27001 risk register should support real decisions rather than sit untouched until an audit approaches.
Begin with a clear method. Define likelihood, impact and acceptance criteria. Cover the full ISMS scope. Involve people from across the organisation and write each entry as a realistic risk scenario.
Assign an accountable owner, record existing controls and assess the current exposure consistently. Select treatment, create clear actions and calculate the remaining risk after treatment.
Connect the register with Annex A, the Statement of Applicability, policies, evidence, internal audit and management review.
UK Cyber Compliance provides an automated and AI-driven platform that helps organisations keep this work organised. A clear, current and evidence-based register gives the business a stronger foundation for certification and better day-to-day information security decisions.
UK Cyber Compliance is here to help
For more information, please do get in touch.
Please check out our Free Cyber Insurance
Other blog posts, Your ISO 27001 Questions Answered, Get ISO 27001 Certified ,
If you would like to know more, do get in touch as we are happy to answer any questions. Looking to improve your cybersecurity but not sure where to start? Begin by getting certified in Cyber Essentials, the UK government’s scheme that covers all the technical controls that will provide the protection that you need to help guard against criminal attacks.