The risk assessment methodology is the rulebook for the risk register. It defines the scales, the criteria for accepting risk, who does what, and how often. Without it, two people scoring the same risk produce different answers, and nobody can explain afterward why one risk was accepted and another was not. ISO 27001 auditors treat the methodology as a mandatory document and test the register against it line by line. This template gives you a starting structure aligned with ISO/IEC 27005; the decisions inside it are yours to make and defend.
What ISO 27001 clause 6.1.2 actually requires
Clause 6.1.2 of ISO/IEC 27001:2022 requires a defined and applied risk assessment process that establishes risk acceptance criteria and criteria for performing assessments, and ensures repeated assessments produce consistent, valid, and comparable results. The process must identify risks associated with loss of confidentiality, integrity, and availability within the ISMS scope, identify risk owners, assess potential consequences and realistic likelihood, determine levels of risk, and compare results against the criteria to prioritize treatment. Documented information about the process must be retained.
Every one of those elements should map to a section of your methodology. If an auditor cannot find where you define acceptance criteria or how you ensure comparable results, expect a finding. The ISO 27001 page and the ISMS explainer show how the methodology fits the management system as a whole.
Decisions the methodology has to make
Define scales in words, not just numbers
A likelihood of 3 means nothing unless the methodology says what 3 is. Anchor each level to a frequency or probability and each impact level to concrete consequences across several dimensions. The example below shows the style; calibrate the thresholds to your organization's size and sector.
Illustrative impact scale
Roles and approvals
- Methodology owner: usually the security or risk lead; maintains the document and facilitates assessments.
- Risk owners: business leaders who confirm scores for their risks, approve treatment, and accept residual risk within their authority.
- Approval authority tiers: for example, owners may accept low risks, an executive must accept high risks, and critical risks go to the leadership team or board.
- Approver of the methodology: top management, since the acceptance criteria express their risk appetite.
Beyond ISO 27001
The same methodology can serve other frameworks with small additions. SOC 2 CC3.1 through CC3.4 cover specifying objectives, identifying and analyzing risks, considering fraud risk, and assessing changes, so add a fraud prompt to the identification step if you pursue SOC 2. The HIPAA Security Rule's risk analysis under §164.308(a)(1)(ii)(A) must consider risks to electronic protected health information, so make ePHI an explicit asset class. PCI DSS 4.0.1 Requirement 12.3.1 introduces targeted risk analyses to justify how often certain requirements are performed. NIST SP 800-30 Rev. 1 is a useful companion reference for threat and vulnerability identification.
How auditors test a methodology
- Confirm the document is approved, current, and covers each element of clause 6.1.2.
- Select risks from the risk register and re-perform scoring using the documented scales.
- Check that acceptance decisions match the documented thresholds and approval authority.
- Ask when the last full assessment ran and what triggered any interim updates.
- Trace selected risks through to treatment actions and the statement of applicability.
Mistakes that undermine the methodology
- Copying a methodology whose scales assume a company ten times your size, so everything scores minor.
- Acceptance criteria that no executive has actually agreed to.
- A documented annual cycle with no record of it running.
- Allowing assessors to override scores without recording why.
- Changing scales mid-cycle, which breaks comparison with prior assessments.
Asurvo's AI learns the organization's context and builds a risk assessment specific to it rather than generic boilerplate, which is a practical starting point once your scales and criteria are defined. The Risk Management product covers the register, scoring, and treatment workflow.