Why Clause 6.1.2 Is the Engine of Your ISMS
If you have spent any time working with ISO 27001, you will know that the standard is built around one central idea: identify what could go wrong with your information, understand the likelihood and impact, and do something proportionate about it. Clause 6.1.2 is where that idea becomes a formal requirement. It is the information security risk assessment process, and it is one of the most scrutinised clauses in any ISO 27001 certification audit.
On this page
The challenge is that many organisations approach this clause as a documentation exercise. They build a spreadsheet, assign numbers, get a total score, and call it done. Auditors see through that quickly. What ISO 27001 actually requires is a repeatable, consistent, and owned process that produces comparable results each time it runs. This article walks through every element of Clause 6.1.2 in plain language, with practical guidance on how to build a process that will hold up under scrutiny.
Before diving in, it helps to understand where this clause sits. Clause 6.1.1 sets the general requirement to address risks and opportunities. You can read more about that in our article on risks and opportunities under Clause 6.1.1. Clause 6.1.2 then builds on that foundation by specifying exactly how the risk assessment must be designed and carried out.
What the Clause Actually Requires
Clause 6.1.2 is structured around five core requirements. The organisation must define and apply an information security risk assessment process that does the following.
- Establishes and maintains information security risk criteria, including risk acceptance criteria and criteria for performing risk assessments.
- Ensures that repeated risk assessments produce consistent, valid, and comparable results.
- Identifies risks associated with the loss of confidentiality, integrity, and availability of information within the scope of the ISMS.
- Analyses and evaluates those risks against the defined criteria.
- Prioritises the risks for treatment.
Each of these elements has practical implications that are worth unpacking in detail.
Exemplar Global Recognised Training ProviderRTP No. 310970
Step 1: Define Your Risk Criteria Before You Touch a Risk
The most common mistake organisations make is jumping straight to listing risks without first deciding how they will be measured. ISO 27001 requires you to establish risk criteria before you start, and there are two distinct types you need to define.
Risk Acceptance Criteria
This is the threshold at which your organisation is willing to accept a risk without further treatment. It needs to be specific enough to be applied consistently. A statement like “we accept low risks” is not sufficient unless you have defined what “low” means in quantifiable terms relative to your scoring methodology.
In practice, many organisations define acceptance criteria as a numerical score. For example, if you use a five by five likelihood and impact matrix, you might define any risk scoring eight or below as acceptable and anything above that as requiring treatment. The exact threshold is a business decision, not a standard requirement. What matters is that it is documented, approved by management, and applied consistently.
Criteria for Performing Risk Assessments
This covers the methodology itself. How will you score likelihood? How will you score impact? Will you use qualitative descriptors, numerical scales, or a combination? Will you assess inherent risk before controls and residual risk after controls, or only residual risk? These decisions need to be made upfront and documented in your risk assessment methodology.
The reason the standard emphasises consistency and comparability is practical. If one person scores a risk using a different mental model than another person, or if the same risk is scored differently in two successive assessments, the results are not comparable. That makes trend analysis meaningless and undermines the entire purpose of the process.
Step 2: Identify the Risks
Once your criteria are defined, you move to risk identification. Clause 6.1.2 specifies that you must identify risks associated with the loss of confidentiality, integrity, and availability of information. This is the CIA triad applied to risk identification.
Identifying Information Assets and Their Owners
You cannot assess risks to information without first knowing what information you have and who is responsible for it. The standard requires that risk owners are identified during this process. In practice, this means linking risks to specific information assets or groups of assets and assigning a named individual as the risk owner. That person is accountable for the risk and for any subsequent treatment decisions.
Asset ownership is a common area of nonconformity. Organisations often document assets and risks but assign ownership to a role or department rather than a named individual. When the auditor asks who owns the risk, nobody can give a clear answer. Assign ownership to a person, not a position.
Identifying Threats and Vulnerabilities
The standard does not prescribe a specific approach to identifying threats and vulnerabilities, but the process needs to be systematic. A common approach is to work through each information asset and ask what could cause a loss of confidentiality, integrity, or availability. Threat sources can include external actors such as cybercriminals, internal actors such as employees making errors, natural events, and system failures.
Vulnerabilities are the weaknesses that threats can exploit. An unpatched system is a vulnerability. Weak access controls are a vulnerability. Lack of staff awareness is a vulnerability. The combination of a threat and a vulnerability is what creates a risk.
Some organisations use established threat catalogues or reference frameworks to support this step. ISO 27005 provides detailed guidance on information security risk management and is a useful companion to this process, though it is not mandatory.
Step 3: Analyse the Risks
Risk analysis involves assessing the likelihood that a risk will materialise and the impact if it does. This is where your scoring methodology is applied.
Likelihood Assessment
Likelihood should be assessed in the context of your existing controls. If you have strong access controls in place, the likelihood of an unauthorised access event is lower than if you have no controls at all. This is why many organisations assess residual risk rather than inherent risk, though some choose to document both to demonstrate the value of existing controls.
Define your likelihood scale clearly. A five point scale might look like this: rare, unlikely, possible, likely, almost certain. Each descriptor should be supported by a plain language definition so that different assessors reach the same conclusion when evaluating the same scenario.
Impact Assessment
Impact needs to be assessed across multiple dimensions. The obvious ones are financial loss and operational disruption, but information security impacts also include reputational damage, regulatory penalties, and harm to individuals whose personal data is involved. For organisations subject to the Australian Privacy Act or the Notifiable Data Breaches scheme, a data breach involving personal information can carry significant regulatory consequences that should be reflected in your impact scoring.
As with likelihood, define your impact scale with clear descriptors. Avoid leaving assessors to interpret what “high impact” means without guidance.
Step 4: Evaluate the Risks Against Your Criteria
Risk evaluation is the step where you compare the results of your analysis against the risk acceptance criteria you established at the beginning. The output is a prioritised list of risks, with a clear indication of which risks require treatment and which fall within acceptable limits.
This step is where the risk register becomes a decision tool rather than just a record. Risks that exceed the acceptance threshold are carried forward into the risk treatment process under Clause 6.1.3. Risks that fall within acceptable limits are documented as accepted, with the risk owner formally acknowledging that acceptance.
Documented Information Requirements
ISO 27001 requires you to retain documented information about the results of the risk assessment. This means your risk register, or equivalent document, needs to capture the risk identification, analysis, evaluation, and acceptance decisions in a way that can be reviewed and reproduced. The auditor will ask to see this documented information, and they will test whether the process that produced it is consistent with your documented methodology.
A common audit question is: if you ran this assessment again next month with the same inputs, would you get the same results? If the answer is no, because the process is too subjective or undocumented, that is a problem.
Step 5: Ensure Repeatability and Comparability
This is the requirement that catches many organisations out. The standard explicitly states that repeated risk assessments must produce consistent, valid, and comparable results. This is not just about having a documented process. It is about ensuring that the process is actually followed consistently.
In an audit, an experienced auditor will look at multiple iterations of your risk assessment and compare them. If the scoring methodology changed between assessments without a documented reason, or if risks that were previously rated high have mysteriously dropped to low without any corresponding improvement in controls, those are findings worth investigating.
Practical steps to ensure repeatability include using a fixed scoring matrix, providing guidance notes for each scale descriptor, training risk owners on the methodology, and having a consistent review process where someone checks the outputs before they are finalised.
Connecting Risk Assessment to the Rest of the ISMS
Clause 6.1.2 does not sit in isolation. The risk assessment feeds directly into Clause 6.1.3, which covers risk treatment and the Statement of Applicability. The risks you identify and prioritise determine which Annex A controls you select and why. An auditor will trace that connection during a certification audit, checking that the controls in your Statement of Applicability are genuinely linked to the risks in your risk register.
The risk assessment also connects to Clause 8.2, which requires you to perform the risk assessment at planned intervals or when significant changes occur. This means your risk assessment is not a one time exercise. It needs to be reviewed regularly and triggered by events such as new systems, changes to business processes, new regulatory requirements, or significant security incidents. Our article on why Clause 8.2 makes you repeat the risk assessment covers this in more detail.
Common Nonconformities Auditors Find in Clause 6.1.2
Having conducted hundreds of audits across a range of sectors, the same issues appear repeatedly when it comes to information security risk assessments. Knowing what auditors look for helps you build a process that will stand up.
Risk Acceptance Criteria Not Defined or Not Applied
Some organisations document a risk methodology but never formally define what level of risk they are willing to accept. Others define it but then treat every risk regardless of its score, which suggests the criteria are not actually being used. The criteria need to be defined, documented, and demonstrably applied.
Risk Owners Not Identified or Not Engaged
The standard requires risk owners to be identified. A common finding is that risks are assigned to the IT manager or the information security manager by default, regardless of whether those individuals actually own the underlying business process. Risk ownership should reflect who has the authority and accountability to make decisions about the risk.
Inconsistent Scoring Across Assessments
When an auditor compares two versions of a risk register and finds that the same risk has been scored differently without explanation, that raises questions about the reliability of the process. Document your rationale for scoring decisions, particularly when scores change between assessments.
No Link Between Risks and Controls
The risk register and the Statement of Applicability need to be connected. If a risk is rated high but the corresponding Annex A controls are marked as not applicable without justification, that is a significant gap. Every control selection or exclusion decision should be traceable back to the risk assessment.
Treatment of Accepted Risks Not Documented
Accepting a risk is a legitimate decision, but it needs to be documented and formally approved. An informal decision by the IT team to accept a risk without management sign off is not sufficient. The risk owner needs to formally acknowledge acceptance, and that acknowledgement needs to be retained as documented information.
Practical Tips for Building a Robust Risk Assessment Process
The following advice comes from real audit experience, not theory.
- Keep the methodology simple enough that non specialists can apply it consistently. Overly complex scoring systems often produce inconsistent results because assessors interpret the scales differently.
- Use a fixed template for your risk register so that every risk is assessed against the same criteria in the same format.
- Schedule risk assessment reviews in advance and treat them as a standing agenda item for your management review.
- Document the rationale for scoring decisions, particularly for high rated risks. This creates an audit trail that demonstrates the process was applied thoughtfully.
- Involve risk owners in the assessment, not just the information security team. The person running a business process understands the operational risks better than a central security function.
- Review the risk assessment whenever there is a significant change to the business, its systems, or its operating environment. Do not wait for the annual cycle if something material has changed.
Exemplar Global Recognised Training ProviderRTP No. 310970What Auditors Look for During a Clause 6.1.2 Audit
When an auditor reviews your risk assessment process, they are testing several things simultaneously. They want to see that a documented methodology exists and is being followed. They will sample risks from the register and ask the risk owner to explain how the score was arrived at. They will check that risk acceptance criteria are defined and that accepted risks have been formally acknowledged.
They will also look at the history of the risk register. Has it been updated since the last assessment? Are there new risks that should have been identified given changes in the organisation or its threat environment? Is there evidence that the risk assessment was reviewed at the interval specified in your documented process?
For a more detailed look at what auditors specifically test during an ISMS audit, our article on auditing the risk assessment: is it repeatable, owned and documented? covers the audit perspective in depth.
The risk assessment is also the document that certification body auditors will spend the most time on during a Stage 2 audit. If it is robust, consistent, and clearly linked to your control selections, it builds confidence in the entire management system. If it is thin, inconsistent, or disconnected from the rest of the ISMS, it will generate findings that delay certification.
Building Auditor Competence in Information Security
If you are an internal auditor responsible for auditing your organisation's ISMS, or a quality or compliance professional looking to expand into information security auditing, understanding Clause 6.1.2 in depth is essential. The risk assessment process is the foundation that everything else in the ISMS is built on. Auditing it effectively requires both an understanding of the standard's requirements and the practical ability to evaluate whether a risk assessment process is genuinely fit for purpose.
Audit Workshop offers training for those looking to develop competence in ISO 27001 auditing, from foundation level through to lead auditor. The courses are built around practical audit scenarios, not just clause recitation, so you come away knowing how to actually apply what you have learned in a real audit environment.
