ISO 27001:2022 Clause 6.1.2 Information Security Risk Assessment: The Lead Auditor’s Guide.

ISO 27001 Clause 6.1.2 is a security control that mandates a formal process to identify, analyze, and evaluate information risks. The Primary Implementation Requirement necessitates establishing risk acceptance criteria and performing consistent assessments to determine risk treatment. The core Business Benefit is enabling organizations to prioritize threats effectively and align security measures with business objectives.

In this guide, I will show you exactly how to implement ISO 27001 Clause 6.1.2 and ensure you pass your audit. You will get a complete walkthrough of the control, practical implementation examples, and access to the ISO 27001 templates and toolkit that make compliance easy.

I am Stuart Barker, an ISO 27001 Lead Auditor with over 30 years of experience conducting hundreds of audits. I will cut through the jargon to show you exactly what changed in the 2022 update and provide you with plain-English advice to get you certified.

What is ISO 27001 Clause 6.1.2?

The ISO 27001 standard requires an organisation to establish and maintain information security risk assessment processes that include the risk acceptance and assessment criteria.

This clause is all about risk assessment. The ISO 27001 standard for ISO 27001 certification wants you define and implement a risk assessment process.

That risk assessment process has to set out risk criteria which are the parameters of your risk management.

Definition

ISO 27001 defines ISO 27001 Clause 6.1.2 as:

The organization shall define and apply an information security risk assessment process that:

a) establishes and maintains information security risk criteria that include:
the risk acceptance criteria; and
criteria for performing information security risk assessments

b) ensures that repeated information security risk assessments produce consistent, valid and
comparable results

c) identifies the information security risks:
apply the information security risk assessment process to identify risks associated with the loss of confidentiality, integrity and availability for information within the scope of the information security management system; and
identify the risk owners

d) analyses the information security risks:
assess the potential consequences that would result if the risks identified were to materialise;
assess the realistic likelihood of the occurrence of the risks identified; and
determine the levels of risk

e) evaluates the information security risks:
compare the results of risk analysis with the risk criteria established ; and
prioritise the analysed risks for risk treatment.

The organisation shall retain documented information about the information security risk assessment process.

What are the ISO 27001:2022 Changes to Clause 6.1.2?

If you look strictly at the text of Clause 6.1.2, there are minimal changes between the 2013 and 2022 versions of the standard. However, stating “there are no changes” is a dangerous oversimplification that could cause you to fail your transition audit.

While the risk assessment methodology (the rules) remains the same, the risk treatment options (the controls) have been completely overhauled. Because Clause 6.1.2 is inextricably linked to the controls in Annex A, the impact of the 2022 update is significant.

Aspect	Status	The Impact on Your Risk Register
Clause Text	No Change	The requirement to establish criteria, identify assets, and calculate risk scores remains identical. You do not need to rewrite your Risk Management Policy.
Annex A Controls	Major Overhaul	The 2022 update reduced the number of controls from 114 to 93 and introduced 11 completely new controls (e.g., Threat Intelligence, Cloud Security).
Risk Treatment	Action Required	Any existing Risk Register mapping risks to the old 2013 controls (e.g., A.9.2.1) is now obsolete. You must re-map every risk to the new 2022 control set to ensure valid treatment.

The Bottom Line: You can keep your existing risk assessment process (the “how”), but you must update the content (the “what”) to align with the new ISO 27001:2022 Annex A controls.

ISO 27001 Clause 6.1.2 Implementation Guidance

Risk acceptance criteria

You will set out what your risk acceptance criteria is. This is straightforward, and is a definition under what circumstances you will accept risks. This can also be very straightforward, and the easiest way is to implement risk scoring and set a particular score at which you will accept risk. Of course, you will also have the ability to override this structured approach to risk acceptance. Usually this is done by allowing the Management Review Team or the Senior Management Team to accept risks.

Criteria for performing information security risk assessments

The circumstances in which you perform a risk assessment will be defined and documented. You will perform a complete risk assessment at least annually or when significant change occurs. In addition, risk assessments will form part of your supplier onboarding process, your change management processes and potentially other areas of your business.

Consistent Risk Assessment

Under the standard you are to ‘ensure that repeated information security risk assessments produce consistent, valid and comparable results;’. This is straightforward to do by writing and documenting your risk management process, implementing a risk register and having consistent and effective risk scoring. By ensuring the process is in place and can be easily followed, with strict definitions and scoring the process will produce consistent results.

Risk Identification

Risk identification can often be confusing if you are not used to it. There is a usual approach to over complicate matters. This leads to a complicated risk framework with a risk register overpopulated with risks which can easily become unwieldy and unmanageable.

We must bear in mind that risk identification only applies to the in-scope products and services. The thing that we are going for ISO 27001 certification for. There is a benefit to widen the risk management coverage, but the standard only applies to what is in scope.

In addition, we are only concerned for ISO 27001 certification with risks associated with the loss of confidentiality, integrity and availability for information.

Identify Risk Owners

Risk owners must be identified. It is expected that risks are assigned to individuals and not to teams. This ensures accountability and true ownership. It is acceptable to assign risk ownership to roles rather than named individuals but assigning them to teams should be avoided.

Analyse the information security risks

Once identified and assigned to owners’ risks will be analysed.

• assess the potential consequences that would result if the risks identified in 6.1.2c) were to materialise
• assess the realistic likelihood of the occurrence of the risks identified in 6.1.2 c)
• determine the levels of risk

Evaluate the information security risks

Once we have the risks, we are going to analyse the information security risks to compare the results of risk analysis with the risk criteria established  and prioritise the analysed risks for risk treatment.

What Comes Next? Linking Clause 6.1.2 to the SoA

Implementing Clause 6.1.2 is not the finish line; it is merely the starting point. A common mistake during implementation is treating the Risk Assessment as a standalone document. In reality, the output of your risk assessment (Clause 6.1.2) is the direct input for your Risk Treatment Plan (Clause 6.1.3) and your Statement of Applicability (SoA).

You cannot pass an ISO 27001 audit with just a Risk Register. You must demonstrate the “handshake” between identifying a risk and selecting the control to fix it. Here is how the data flows from assessment to treatment:

Step	Clause	Action Description	Output Document
1. Assessment	Clause 6.1.2	You identify that a “Phishing Attack” is a High Risk (Score 20) to your email servers.	Risk Register (Risks Listed)
2. Decision	Clause 6.1.3	You decide to “Treat” this risk rather than accept, transfer, or avoid it.	Risk Treatment Plan (Decisions Recorded)
3. Selection	Annex A	You select Control A.5.7 (Threat Intelligence) and A.5.10 (User Endpoint Protection) to mitigate the risk.	Statement of Applicability (SoA) (Controls Selected)

Critical Success Factors for the “Handshake”

• Traceability: An auditor must be able to pick a risk in your register (e.g., Risk #42) and see exactly which Annex A control covers it in your SoA.
• Justification: If you identify a high risk in 6.1.2 but mark the corresponding control as “Not Applicable” in your SoA, you will receive a non-conformity. The two documents must tell a consistent story.
• Residual Risk: After applying the controls from the SoA, you must update the Risk Register to show the new “Residual Risk” score. If the score remains too high, further treatment is required.

How to implement ISO 27001 Clause 6.1.2

  Implementing ISO 27001 Clause 6.1.2 requires a structured, repeatable process to identify, analyse, and evaluate information security risks. This section outlines the practical steps to establish a compliant risk assessment framework, ensuring that your organisation systematically addresses threats to the confidentiality, integrity, and availability (CIA) of its information assets.

Step 1: Formalise the Risk Assessment Methodology

• Define Risk Criteria: Establish clear risk acceptance criteria (risk appetite) approved by senior management. Determine the specific score or level at which a risk becomes unacceptable and requires treatment.
• Set Scoring Scales: Develop consistent scales for Likelihood (probability of occurrence) and Impact (consequence of compromise). A standard 5×5 matrix (1=Very Low to 5=Very High) is recommended for calculating risk levels.
• Determine Scope: Explicitly define the boundaries of the risk assessment, ensuring it covers all assets, processes, and locations within the ISMS scope.

Step 2: Construct the Information Asset Inventory

• Identify Assets: Create a comprehensive Asset Register cataloguing all information assets, including hardware, software, data sets, physical locations, and human resources.
• Assign Ownership: Designate a specific “Asset Owner” for every item. This individual is responsible for the asset’s security and for validating the associated risks.
• Classify Assets: Label assets based on their criticality to the organisation, considering the potential impact on Confidentiality, Integrity, and Availability.

Step 3: Execute Threat and Vulnerability Analysis

• Map Threats: Systematically identify potential threats to each asset, such as malware, phishing, physical theft, or insider error. Utilise threat intelligence feeds and industry reports to ensure relevance.
• Identify Vulnerabilities: Assess weaknesses that could be exploited by these threats. Use technical tools like vulnerability scanners for systems and physical audits for premises.
• Link Scenarios: Pair specific threats with corresponding vulnerabilities to create clear risk scenarios (e.g., “Unpatched server [Vulnerability] exploited by Ransomware [Threat]”).

Step 4: Calculate and Evaluate Risk Levels

• Score Risks: For each identified scenario, assign a value for Likelihood and Impact based on your defined methodology.
• Calculate Risk Rating: Multiply Likelihood by Impact (e.g., 4 x 5 = 20) to derive the inherent risk score.
• Compare Against Criteria: Evaluate the calculated score against your risk acceptance criteria. categorise risks as “Acceptable” (requiring monitoring) or “Unacceptable” (requiring treatment).

Step 5: Document the Risk Register

• Centralise Findings: Record all identified risks, owners, scenarios, scores, and evaluation decisions in a formal Risk Register or GRC platform.
• Verify Consistency: Ensure that the assessment process yields consistent results across different departments by reviewing the register for anomalies or subjectivity.
• Approve Results: Have risk owners and management review and sign off on the risk assessment results to confirm accuracy and acceptance of the findings.

Step 6: Review and Update the Risk Landscape

• Schedule Reviews: Conduct full risk assessments at planned intervals (e.g., annually) to ensure the documentation remains current.
• Monitor Triggers: Implement a process to trigger ad-hoc risk assessments when significant changes occur, such as new system implementations, mergers, or emerging security threats.
• Maintain History: Retain historical versions of risk assessments to demonstrate continual improvement and traceability for auditors.

ISO 27001 Clause 6.1.2 Implementation Checklist

Information Security Risk Assessment ISO 27001 Clause 6.1.2 Implementation Checklist

1. Establish the Scope of the Risk Assessment

Define the boundaries of the assessment, including assets, processes, and locations.

Challenge: Difficulty in defining clear and comprehensive boundaries. Overlooking critical assets or processes.

Solution: Involve key interested parties from all relevant areas. Use asset inventories and process maps to identify everything within scope. Regularly review and update the scope as needed.

2. Identify Information Assets

Catalog all information assets within the scope, including data, software, hardware, and physical resources.

Challenge: Difficulty in identifying all information assets, especially intangible ones. Lack of up-to-date asset inventory.

Solution: Conduct a thorough asset inventory. Categorise assets by sensitivity and importance. Use automated asset discovery tools. Establish a process for maintaining the asset inventory.

3. Identify Threats

Determine potential threats that could exploit vulnerabilities and harm information assets.

Challenge: Difficulty in identifying all potential threats, especially new and emerging ones. Lack of threat intelligence.

Solution: Conduct threat modelling exercises. Subscribe to threat intelligence feeds. Involve security experts. Regularly review threat landscape.

4. Identify Vulnerabilities

Identify weaknesses in the ISMS that could be exploited by threats.

Challenge: Difficulty in identifying all vulnerabilities, especially in complex systems. Lack of vulnerability scanning and penetration testing.

Solution: Conduct regular vulnerability scans and penetration tests. Perform security audits and code reviews. Implement a vulnerability management program.

5. Analyse the Likelihood of Threats

Estimate the probability of each threat occurring.

Challenge: Subjectivity in estimating likelihood. Lack of historical data.

Solution: Use a consistent likelihood scale. Gather historical data and expert opinions. Document the rationale behind likelihood estimations.

6. Analyse the Impact of Threats

Estimate the potential harm that could result from a successful threat exploit.

Challenge: Difficulty in quantifying the impact of different types of harm (e.g., financial loss, reputational damage).

Solution: Develop a consistent impact scale. Consider different types of impact (financial, operational, legal, reputational). Document the rationale behind impact estimations.

7. Evaluate Risks

Combine the likelihood and impact of threats to determine the level of risk for each identified vulnerability.

Challenge: Difficulty in prioritising risks with different likelihood and impact combinations.

Solution: Use a risk matrix or other risk assessment tool. Establish clear criteria for risk acceptance.

8. Document the Risk Assessment Results

Record the identified risks, their analysis, and assigned risk levels in a risk register or equivalent document.

Challenge: Difficulty in maintaining and updating the risk register. Lack of integration with other ISMS processes.

Solution: Use a centralised risk management system. Regularly review and update the risk register. Integrate the risk register with other ISMS processes.

9. Communicate the Risk Assessment Results

Communicate the risk assessment results to relevant interested parties.

Challenge: Difficulty in communicating complex technical information to non-technical audiences. Lack of interested parties engagement.

Solution: Tailor communication to the audience. Use visual aids and plain language. Actively solicit feedback from interested parties.

10. Review and Update the Risk Assessment

Regularly review and update the risk assessment to reflect changes in the threat landscape, vulnerabilities, and business environment.

Challenge: Difficulty in keeping the risk assessment up-to-date. Lack of resources for regular reviews.

Solution: Establish a schedule for regular risk assessment reviews. Assign responsibility for maintaining the risk assessment. Integrate risk assessment with other ISMS processes, such as change management and incident management.

Applicability of ISO 27001 Clause 6.1.2 across different business models.

Business Type	Applicability	Why it is Important	Examples (Clause 6.1.2)
Small Businesses	Streamlined & Proportionate. Focuses on critical assets and “business-ending” risks rather than complex bureaucracy.	Prevents operational paralysis. ensures limited resources are targeted at actual threats (e.g., Ransomware) rather than theoretical ones.	Asset: CEO Laptop / Office 365. Threat: Phishing or Physical Theft. Risk: Loss of sensitive client PII leading to reputational damage.
Tech Startups	Scalable & Integrated. Risk assessment must account for rapid growth, SDLC velocity, and cloud infrastructure.	Critical for passing Enterprise Vendor Risk Assessments and protecting Intellectual Property (IP) to secure funding/exits.	Asset: Source Code / AWS Production Environment.             Threat: Insider threat or API Key leakage.             Risk: Unauthorised access to proprietary code or customer data.
AI Companies	Specialised & Data-Centric. Requires assessing risks specific to data ethics, model integrity, and training sets.	Mitigates unique vulnerabilities such as data poisoning and model inversion, ensuring compliance with GDPR and the EU AI Act.	Asset: Training Data Sets / Inference Models. Threat: Prompt Injection or Model Theft. Risk: Corruption of model outputs or leakage of training data privacy.

ISO 27001 Clause 6.1.2 Audit Checklist

How to audit ISO 27001 Clause 6.1.2 Information Security Risk Assessment

1. Review the Risk Assessment Methodology

Verify the existence and appropriateness of a documented methodology for identifying, analysing, and evaluating risks.

Audit Techniques: Document review (policies, procedures), interviews with risk management personnel, comparison against ISO 31000 principles, observation of a risk assessment in progress.

2. Examine the Scope Definition

Ensure the risk assessment scope is clearly defined and comprehensive, covering all relevant assets, processes, and locations.

Audit Techniques: Document review (scope definition document), interviews with interested parties across different departments, review of asset inventory and process maps, site visits to verify physical locations are included.

3. Evaluate the Asset Identification Process

Verify the process for identifying and cataloging information assets, including data, software, hardware, and physical resources.

Audit Techniques: Document review (asset register, data flow diagrams), interviews with asset owners, review of automated asset discovery tools output, sampling of assets to verify their inclusion in the inventory.

4. Assess Threat Identification

Verify the process for identifying potential threats, including both internal and external threats, and emerging threats.

Audit Techniques: Interviews with security experts and threat intelligence analysts, review of threat intelligence feeds and reports, analysis of incident history, review of threat modelling exercises.

5. Evaluate Vulnerability Identification

Verify the process for identifying weaknesses in the ISMS that could be exploited by threats.

Audit Techniques: Review of vulnerability scanning and penetration testing reports, analysis of security audit findings, review of code review results, interviews with technical staff.

6. Assess Likelihood Analysis

Verify the process for estimating the likelihood of threats occurring, including the criteria and data used for estimations.

Audit Techniques: Review of risk assessment documentation, interviews with risk assessors, analysis of historical data and industry trends, review of likelihood scales and their justification.

7. Evaluate Impact Analysis

Verify the process for estimating the potential impact of successful threat exploits, including the criteria and data used for estimations.

Audit Techniques: Review of risk assessment documentation, interviews with business impact analysis (BIA) team, analysis of potential financial, operational, legal, and reputational impacts, review of impact scales and their justification.

8. Examine Risk Evaluation and Prioritisation

Verify the process for combining likelihood and impact to determine risk levels and prioritise risks.

Audit Techniques: Review of risk matrix or other risk assessment tool, analysis of risk levels assigned to different risks, interviews with risk management personnel, review of risk acceptance criteria.

9. Review Risk Assessment Documentation

Inspect the risk register or equivalent documentation for completeness, accuracy, and consistency.

Audit Techniques: Document review (risk register, risk assessment reports), data analysis (trends in risk levels), sampling of risk entries for detailed review, interviews with risk owners.

10. Assess the Review and Update Process

Verify the process for regularly reviewing and updating the risk assessment to reflect changes in the threat landscape, vulnerabilities, and business environment.

Audit Techniques: Review of risk assessment update schedule, interviews with risk management personnel, review of change management records, analysis of how new threats and vulnerabilities are incorporated into the risk assessment.

What an auditor looks for ISO 27001 Clause 6.1.2

Audit Focus Area	What the Auditor Wants to Verify	Required Evidence Examples
Defined Methodology	The auditor checks if you established the “rules of the game” before playing. They want to see a documented process that defines how risks are identified, scored, and accepted, ensuring the process is repeatable and not just guesswork.	Risk Management Policy: A document clearly defining Likelihood/Impact scales (e.g., 1-5) and the Risk Acceptance Criteria (e.g., “Risks above score 15 must be treated”).
Asset-Based Identification	They will verify that your risk assessment isn’t just a generic list of IT problems. It must be tied to specific information assets within your scope. They will look for a clear link between Assets, Threats, and Vulnerabilities.	Asset Register: Must show owners and classifications.             Risk Register: Rows mapping specific assets (e.g., “CRM Database”) to threats (e.g., “SQL Injection”).
Consistency & Validity	The auditor will test your math. They will pick a random risk and ask, “Why is this a Likelihood of 3?” They want to see that the scoring guidelines were applied consistently, rather than arbitrary numbers picked to make the report look green.	Scoring Rubric: A reference sheet used during the assessment.             Audit Trail: Notes or minutes from risk workshops showing how the team debated and agreed on scores.
Risk Ownership	They will interview people listed as “Risk Owners.” They are looking to see if these individuals actually know they are responsible for the risk and its treatment, or if their name was just added to a spreadsheet without their knowledge.	Job Descriptions: Or roles including risk responsibilities.             Interviews: The auditor will ask the Head of Sales, “What are the top security risks to your data?”
Management Sign-Off	Risk acceptance cannot be decided by the IT Manager alone. The auditor needs proof that Senior Management is aware of the risks and has formally agreed to accept them, especially where residual risk remains high.	Meeting Minutes: Management Review Meeting minutes explicitly stating “The Risk Assessment Report v2.0 was reviewed and accepted.”             Signed Statement of Applicability (SoA): Often signed by the CEO/Director.

ISO 27001 Clause 6.1.2 related controls

Clause / Control	Category	Relationship to Clause 6.1.2 (Risk Assessment)
Clause 6.1.1	Core Requirement	The Umbrella. This is the general requirement to address risks and opportunities. Clause 6.1.2 is the specific methodology you must use to fulfill the mandate set in 6.1.1.
Clause 6.1.3	Core Requirement	The Solution. This is the immediate successor. Once 6.1.2 identifies and evaluates the risks, 6.1.3 dictates how you treat them (e.g., mitigate, transfer) and produce the Statement of Applicability (SoA).
Clause 8.2	Operational	The Execution. While 6.1.2 defines the methodology (the rules), Clause 8.2 requires the actual performance of the assessment at planned intervals or after significant changes.
Clause 9.3	Operational	The Reporting. The results generated by your 6.1.2 risk assessment must be presented to leadership during the Management Review to ensure they understand the organisation’s risk profile.
Clause 4.1	Context	The Source. Understanding the organisation’s context (internal/external issues) provides the raw scenarios (e.g., “Competitor activity” or “New Legislation”) that must be evaluated as risks.
Clause 5.1	Leadership	The Enabler. Leadership must ensure the resources (time, budget, personnel) are available to conduct the 6.1.2 assessment effectively and that it aligns with business strategy.
Control A.5.7	Annex A (Input)	Threat Intelligence. Provides the necessary data on active threats (e.g., Ransomware trends). Without this, your 6.1.2 assessment is based on guesswork rather than real-world danger.
Control A.5.9	Annex A (Input)	Asset Inventory. The foundation of the assessment. You cannot assess risk if you do not know what you own. This control provides the list of hardware, software, and data to be evaluated.
Control A.8.8	Annex A (Input)	Vulnerabilities. Provides data on technical weaknesses (e.g., unpatched software). The 6.1.2 process combines these vulnerabilities with A.5.7 threats to calculate risk.
Control A.5.19	Annex A (Input)	Supply Chain. Ensures that risks originating from third-party vendors and suppliers are identified and integrated into the central 6.1.2 risk assessment.

Watch the ISO 27001 Clause 6.1.2 Video Tutorial

Fast track ISO 27001 Clause 6.1.2 compliance with the ISO 27001 Toolkit

Feature	ISO 27001 Toolkit (Word/Excel)	SaaS GRC Platform	Why The Toolkit Wins for Clause 6.1.2
Data Ownership	Complete Control. You own the files (XLSX, DOCX) forever. They sit on your secure servers/SharePoint.	Rented Access. Your risk data is held hostage on their servers. Stop paying, lose your data.	For a critical document like the Risk Register, permanent ownership is vital. You cannot afford to lose access to your compliance history if you switch vendors.
Usability & Training	Zero Learning Curve. Everyone on your team already knows how to use Microsoft Excel and Word.	High Friction. Requires staff training on complex, proprietary dashboards and workflows.	Risk assessments require input from various department heads. Sending them a simple spreadsheet ensures higher engagement than forcing them to log into a new tool.
Cost Structure	One-Off Payment. Pay once, use indefinitely. No hidden fees or “per-user” costs.	Recurring Subscription. Expensive monthly/annual fees that often increase as you add users or assets.	Clause 6.1.2 is a process, not a subscription. A well-structured Excel Risk Register performs the exact same calculations without the recurring drain on your budget.
Vendor Freedom	No Lock-In. You are free to modify, migrate, or share your documents as you see fit.	High Lock-In. Migrating data out of a SaaS platform is notoriously difficult and often incomplete.	ISO 27001 is a long-term commitment. Using standard formats ensures you remain agile and aren’t tied to a single software provider’s roadmap or pricing changes.
Customisation	Infinite Flexibility. Add columns, change formulas, and tweak layouts instantly to fit your specific risk methodology.	Rigid Frameworks. You are often forced to use their pre-defined logic, risk matrices, and report formats.	Every organisation’s risk appetite is unique. A Toolkit allows you to adapt the methodology (e.g., 3×3 vs 5×5 matrix) perfectly to your business needs.

ISO 27001 Clause 6.1.2 Templates

These individual templates help meet the specific requirements of ISO 27001 clause 6.1.2.

Top 3 ISO 27001 Clause 6.1.2 Mistakes and How to Fix Them

Common Mistake	How to Fix It	Real-World Example
Confusing Risks with Issues	Focus on Uncertainty. An “Issue” is a problem that is happening now (e.g., “The server is down”). A “Risk” is the possibility of an event happening in the future (e.g., “The server might fail due to lack of maintenance”). Your Risk Register should only contain future possibilities, not a to-do list of broken things.	Bad: “Firewall license has expired.” (This is an issue).             Good: “Unauthorised network access due to expired security licenses.” (This is the risk).
Subjective Risk Scoring	Define Criteria First. Without a defined scoring methodology (e.g., “Likelihood 3 = Occurs once a year”), different departments will guess. Implement a standard rubric for Likelihood and Impact before you start the assessment to ensuring consistency across the organisation.	Bad: Marketing rates “Data Loss” as a ‘2’ because they don’t value it; IT rates it as a ‘5’.             Good: Both teams rate it based on the defined financial impact threshold of >£10,000.
Ignoring Asset Ownership	Assign Accountability. Risks are often orphaned because they are assigned to a department (e.g., “IT Dept”) rather than a specific role. Assign every asset and risk to a specific “Owner” (e.g., “CTO” or “HR Manager”) who has the authority to approve the risk treatment plan.	Bad: “Laptop theft risk assigned to IT Support.” (They can’t enforce policy).             Good: “Laptop theft risk assigned to Head of Operations.” (They can enforce clean desk policies and physical security).

5×5 matrix Risk Matrix Example

 

Likelihood / Impact	1: Negligible	2: Minor	3: Moderate	4: Major	5: Catastrophic
5: Almost Certain	Medium (5) Spam Emails (Daily occurrence, zero impact)	High (10) Password Sharing (Common habit, moderate risk)	Critical (15) Unpatched Software (Known CVEs not updated)	Extreme (20) Insider Data Theft (Malicious employee exfiltration)	Extreme (25) Ransomware Attack (Full encryption of production data)
4: Likely	Low (4) Misaddressed Email (Internal only)	Medium (8) Lost Mobile Device (Encrypted device)	High (12) Phishing Click (Credential harvesting)	Critical (16) Cloud Misconfiguration (Public S3 Bucket)	Extreme (20) Supply Chain Breach (Major vendor compromised)
3: Possible	Low (3) Minor Hardware Failure (Mouse/Keyboard break)	Medium (6) Office Entry (Tailgating) (Unauthorised visitor)	Medium (9) Vendor SLA Breach (Service degradation)	High (12) DDoS Attack (Temporary outage)	Critical (15) Data Centre Fire (Physical destruction)
2: Unlikely	Low (2) Website Typo (Minor reputation hit)	Low (4) Brief Power Cut (UPS handles load)	Medium (6) Key Staff Illness (Short-term absence)	Medium (8) Legacy System Failure (Old archive inaccessible)	High (10) Regulatory Fine (Minor GDPR breach)
1: Rare	Low (1) Meteor Strike (Theoretical only)	Low (2) False Alarm (Fire drill error)	Low (3) Archive Corruption (10-year old tape fails)	Low (4) Fibre Cable Cut (Redundant line active)	Medium (5) State-Sponsored Attack (Advanced Persistent Threat)

Risk Assessment Cycle

Stage	Description	Practical Example (The Journey of a Laptop)
1. Asset Identification	Identifying the specific information, hardware, or software that holds value to the organisation. You cannot protect what you do not know you have.	Asset: Sales Director’s MacBook Pro. (Contains sensitive customer data and pricing strategies).
2. Threat Identification	Determining what could potentially go wrong with that asset. Threats can be accidental (spilled coffee), deliberate (theft), or environmental (fire).	Threat: Physical theft of the device from a car or train.
3. Vulnerability Identification	Identifying the weakness that allows the threat to succeed. A threat without a vulnerability is not a risk (e.g., rain is a threat, but a waterproof roof removes the vulnerability).	Vulnerability: The laptop hard drive is not encrypted, and the user has a weak login password.
4. Risk Analysis	Calculating the level of risk by combining the Likelihood of the threat occurring and the Impact if it does.	Likelihood: 3 (Possible – theft happens).             Impact: 5 (Catastrophic – GDPR breach).             Score: 15 (High Risk).
5. Risk Evaluation	Comparing the calculated score against your Risk Acceptance Criteria to decide if action is needed.	Decision: The score of 15 exceeds our acceptance threshold of 10. This risk is Unacceptable and must be treated.
6. Risk Treatment	Selecting controls from Annex A to modify the risk (reduce likelihood or impact) to an acceptable level.	Action: Implement Control A.8.1 (User Endpoint Devices) by enforcing full-disk encryption (BitLocker/FileVault) via MDM.
7. Residual Risk	Re-calculating the risk score after the controls are applied.	New Impact: 1 (Negligible – data is unreadable).             New Score: 3 (Low Risk – Acceptable).

How ISO 27005 Supports Clause 6.1.2

While ISO 27001 Clause 6.1.2 provides the mandatory requirements (the “what”) for risk assessment, it does not tell you how to actually perform the calculations or facilitate the workshops. This is where ISO/IEC 27005 comes in.

ISO/IEC 27005 is the supplementary standard dedicated entirely to Information Security Risk Management. It provides the detailed guidelines, techniques, and examples necessary to build a robust methodology that satisfies the requirements of Clause 6.1.2. Aligning your process with ISO 27005 is the strongest way to demonstrate competence to an external auditor.

Mapping ISO 27001 Requirements to ISO 27005 Guidance

                                                                                                                                                                                                       

ISO 27001 Clause 6.1.2 Requirement	ISO 27005 Guidance (The “How-To”)	Practical Application
Risk Criteria (6.1.2 a) Establish criteria for accepting risks and performing assessments.	Context Establishment ISO 27005 provides frameworks for defining risk appetite scales and impact criteria (e.g., financial vs. reputational damage).	Use the ISO 27005 annexes to build your 5×5 Likelihood and Impact scales.
Identify Risks (6.1.2 c) Identify risks associated with the loss of Confidentiality, Integrity, and Availability.	Risk Identification Techniques It outlines both “Asset-Based” and “Event-Based” identification methods, helping you list threats relevant to specific asset types.	Use ISO 27005 lists of typical threats (e.g., fire, theft) and vulnerabilities (e.g., lack of patching) to populate your register.
Analyse Risks (6.1.2 d) Assess consequences (Impact) and realistic likelihood.	Risk Analysis Methodologies It details how to perform Qualitative (High/Medium/Low) vs. Quantitative (Annualised Loss Expectancy) analysis.	Adopts the ISO 27005 guidance on calculating “Inherent Risk” before controls and “Residual Risk” after controls.
Evaluate Risks (6.1.2 e) Compare results against risk criteria and prioritise.	Risk Evaluation & Treatment It provides logic for prioritising risks based on business objectives rather than just IT severity scores.	Helps you justify why a “High” risk might be accepted temporarily due to business constraints, documenting it formally.

Key Takeaway: You are not required to be certified against ISO 27005, but stating in your Risk Management Policy that “Our methodology aligns with the guidance of ISO/IEC 27005” acts as a gold standard trust signal during your certification audit.

The relationship between 6.1.2 (Assessment) and 6.1.3 (Treatment/SoA)

One of the most common points of failure in an ISO 27001 audit is treating Clauses 6.1.2 and 6.1.3 as separate, siloed activities. In reality, they are two halves of a single logical process: Diagnosis and Prescription.

Clause 6.1.2 identifies the “symptoms” (Risks), while Clause 6.1.3 prescribes the “medicine” (Controls). You cannot have one without the other. If 6.1.2 is the question (“What could go wrong?”), 6.1.3 is the answer (“What are we going to do about it?”).

The Operational “Handshake”: Input vs. Output

The output of your risk assessment is the mandatory input for your risk treatment. The table below illustrates how data transforms as it moves between these two clauses.

                                                                                                                                                                                                       

Feature	Clause 6.1.2 (The Diagnosis)	Clause 6.1.3 (The Prescription)
Primary Goal	To identify and score risks to determining if action is needed.	To select specific measures (controls) determining how to reduce that risk.
Key Action	Calculating Inherent Risk (Likelihood × Impact).	Calculating Residual Risk (Score after controls are applied).
Role of Annex A	Used passively to identify missing controls (Vulnerabilities).	Used actively to select controls for the Statement of Applicability (SoA).
Mandatory Output	Risk Register (List of risks and scores).	Statement of Applicability (SoA) (List of controls and justifications).

Data Flow Example: The Lifecycle of a “Phishing” Risk

To make this abstract relationship concrete, let’s follow a single risk scenario through the entire process to see how the two clauses interact.

                                                                                                                                                                                                                                                                                           

Step	Clause	Action Taken	Documented Evidence
1. Assessment	6.1.2	You identify that employees clicking malicious links is a threat. You score it: Likelihood 4 x Impact 5 = Risk 20 (Critical).	Risk Register (Inherent Score Column)
2. Evaluation	6.1.2	You compare the score (20) against your risk appetite (10). Result: Unacceptable.	Risk Register (Decision Column)
3. Treatment Decision	6.1.3	You choose one of the four treatment options: Mitigate (Apply controls).	Risk Treatment Plan
4. Control Selection	6.1.3	You browse Annex A and select Control A.5.7 (Threat Intelligence) and A.6.4 (Security Awareness Training).	Statement of Applicability (SoA)
5. Re-Assessment	6.1.3	You re-calculate the score assuming these controls are working. New Score: Likelihood 2 x Impact 5 = Risk 10 (Acceptable).	Risk Register (Residual Score Column)

ISO 27001 Clause 6.1.2  FAQ