ISO 27001 Clause 6.1.2 Information Security Risk Assessment: Certification Body Guide

ISO 27001 Clause 6.1.2 Information security risk assessment is a governance process used to identify, analyse, and evaluate security threats. It requires a formal methodology to assess confidentiality, integrity, and availability. This documented assessment ensures that your security resources address the most significant business risks effectively.

ISO 27001:2022 Attributes

Implementation Difficulty & Cost

ISO 27002 Control Guidance

The physical guidance for risk assessment requires evaluating threats to your tangible assets. I look for specific entries regarding unauthorised entry or hardware theft at your sites. You must assess the environment where your data resides. Site managers should participate in these threat identification sessions. I expect to see physical risks recorded in your internal SharePoint register. This ensures that physical site managers take ownership of local threats.

The technical guidance focuses on vulnerabilities within your digital stack. I find that companies often ignore legacy software in their assessments. You must analyse the likelihood of technical failures or cyber-attacks. Use Jira to link identified risks to your technical asset register. This ensures your risk assessment remains grounded in your actual technical reality. Technical risks must be specific to your actual technology stack.

The behavioural guidance involves assessing human-related security risks. You must consider the risk of social engineering or accidental data loss. I look for evidence that you have evaluated employee security awareness. Management must determine the risk posed by internal culture and staff turnover. Document these human factors in your risk management plan. This helps you tailor training to address the most likely employee errors.

10 Steps to Implement Clause 6.1.2

1. Select Your Risk Methodology

   Define a consistent set of rules for assessing risk. You must establish impact and likelihood scales that suit your business size. Store this methodology in SharePoint with formal version control. This ensures every department uses the same scoring logic. I check this methodology first during any external audit. It provides the foundation for every risk decision you make.

2. Define Risk Acceptance Criteria

   State clearly what level of risk the Board is willing to tolerate. This appetite must be documented before you start the assessment. I look for a signed statement from top management. This prevents the security team from making business-level risk decisions in isolation. It provides the boundary for your entire risk management project. Without a clear appetite, you cannot evaluate risk effectively.

3. Identify Information Assets

   List the data, software, and hardware that your business relies on. You cannot assess risk if you do not know what you are protecting. Use Jira or an internal database to maintain a live asset register. Link these assets to their respective owners. I check if your risk assessment covers every asset in your scope. This ensures no critical information asset is left unprotected.

4. Identify Threats and Vulnerabilities

   Brainstorm what could go wrong for each asset group. Consider external threats like hackers and internal vulnerabilities like weak passwords. Use workshops with department leads to capture diverse perspectives. I find that staff often identify risks that management misses. Record these findings in your internal Confluence hub. This creates a shared understanding of the specific threats your organisation faces.

5. Analyse CIA Impacts

   Evaluate the consequences of losing confidentiality, integrity, or availability for each asset. You must use your defined impact scale. I look for specific business consequences, such as financial loss or legal fines. Avoid generic descriptions that could apply to any company. This step ensures you understand the true cost of a security failure. It prioritises the assets that need the most protection.

6. Determine Likelihood

   Estimate how often each threat might successfully exploit a vulnerability. Use historical data or threat intelligence to support your scores. I often find likelihood scores that are based on pure guesswork. Use your internal incident logs to provide evidence for these scores. This makes your assessment defensible during an audit. It ensures your risk scores reflect the actual threat environment you operate in.

7. Calculate Risk Levels

   Combine the impact and likelihood scores to determine the overall risk level. Most organisations use a simple mathematical formula. I check that this calculation is consistent across the whole register. Use your SharePoint register to automate these calculations. This removes human error and ensures your risk prioritisation is mathematically sound. It allows you to focus on the highest risks first.

8. Compare Against Acceptance Criteria

   Compare the calculated risk levels against your pre-defined tolerance levels. Risks that exceed the appetite are unacceptable and require treatment. I look for a clear visual marker for these risks in your register. This step identifies where the business must invest in security controls. It prevents you from wasting budget on insignificant issues. It aligns your security spend with business priorities.

9. Assign Risk Owners

   Every identified risk must have a named human being responsible for it. Owners must be individuals with the authority to manage the risk. I often find that “IT Department” is assigned as an owner, which is a failure. Use Jira to notify owners of their specific responsibilities. This creates true accountability across the organisation. It ensures that someone is always watching the risk levels.

10. Document the Assessment Results

    Maintain the final risk register as documented information. I look for a record that shows when the assessment was performed and who was involved. Store the register in a secure SharePoint folder with restricted access. This document serves as the primary evidence for Clause 6.1.2. A well-documented register is the best way to prove compliance. It demonstrates a mature and active management system.

Requirements by Environment

• Office Environment: Risks must address physical theft, local utility outages, and unauthorised site access. Focus on site-specific vulnerabilities and local hardware protection.
• Home Working: Assessment should focus on domestic network security, device loss, and family member proximity. Evaluate the risks of data exposure in unmanaged environments.
• Cloud Environment: Focus on provider misconfiguration, API vulnerabilities, and regional availability zone failures. Assess the risk of shared responsibility gaps between you and the host.

The “Checkbox Compliance” Trap

10 Steps to Audit Clause 6.1.2 (Internal Audit Guide)

1. Verify the Methodology: Check that the assessment follows the approved internal rules in SharePoint. Ensure the math is correct.
2. Review Stakeholder Input: Confirm that department leads were interviewed during the risk identification phase. Look for workshop attendance records.
3. Check Scoring Consistency: Ensure that similar risks are scored consistently across different departments. Look for outliers that make no sense.
4. Trace Asset Coverage: Pick five assets from the register and see if they appear in the risk assessment. Check for completeness.
5. Inspect the Risk Matrix: Verify that the matrix used matches the one defined in your methodology. Ensure the borders are clear.
6. Check Acceptance Levels: Confirm that risks above the appetite level are marked for treatment. Verify that management accepted the leftovers.
7. Verify Human Owners: Ensure that every risk has a named individual assigned as the owner. No generic department names allowed.
8. Check Version History: Confirm the risk register has been updated within the last twelve months. Look for updates after major changes.
9. Test Logic: Ask a risk owner to explain why a specific risk was given a particular score. They must know the reasoning.
10. Look for Red Flags: Be wary of perfect registers where no high risks are identified. This usually indicates an ineffective process.

Clause 6.1.2 Audit Evidence Checklist

Required Policy Content: A Lead Auditor’s Checklist

• Methodology Statement: You must define exactly how you identify, analyse, and evaluate risks. Use specific terms.
• Impact and Likelihood Scales: Detailed definitions for every level (e.g., 1 to 5) must be present. Include financial and operational examples.
• Risk Acceptance Criteria: Must state the numerical or qualitative thresholds for acceptable risk. This must be board-approved.
• Ownership Definition: Must define the specific duties and authorities of a named risk owner. Link this to HR job descriptions.
• Review Frequency Clause: Must mandate at least an annual review of the entire risk assessment. Include triggers for out-of-cycle updates.

What to Teach Employees

• Risk Identification: Help staff understand how to spot security threats in their daily tasks. Encourage them to report new vulnerabilities.
• Their Role as Owners: Teach department leads how to use the methodology to score their own operational risks accurately.
• The “Why”: Explain that risk assessment is about business resilience, not just compliance. Show them how it protects the company.

Common Implementation Challenges

Sample Statement of Applicability (SoA) Entry

“ISO 27001 Clause 6.1.2 is a mandatory requirement. We satisfy this by maintaining an active risk register in SharePoint. Our methodology defines clear impact and likelihood scales. Every risk is linked to an asset and a human owner. Top management reviews the assessment annually to ensure it remains aligned with our business strategy.”

Changes from ISO 27001:2013

How to Measure Effectiveness (KPIs)

• Assessment Coverage: 100% of critical business assets covered in the annual risk assessment. Measured by asset register comparison.
• Owner Engagement: Percentage of risk owners who have reviewed their assigned risks this quarter. Tracked in Jira.
• Incident Correlation: Number of security incidents that were correctly identified as risks beforehand. Aim for over 70%.

Related ISO 27001 Controls

• ISO 27001 Clause 4.1 Context: Your internal and external issues provide the primary input for identifying risks. Read the Clause 4.1 guide.
• ISO 27001 Clause 4.2 Stakeholders: Stakeholder needs often dictate which risks are considered unacceptable. Learn about Stakeholder Requirements.
• ISO 27001 Clause 6.1.3 Risk Treatment: Once risks are assessed, you must decide how to handle them using this clause. Explore Risk Treatment.

Clause 6.1.2 FAQ