ISO 27001 Risk Assessment: ISO 27001 vs ISO 27005 for Information Security Risk Management
ISO 27001 sets the audit requirements for information security risk management, while ISO 27005 gives practical guidance for building the risk process behind them. An organization seeking certification should treat ISO 27001 as the rulebook and ISO 27005 as a detailed playbook.
TLDR: ISO 27001 requires a repeatable risk assessment and risk treatment process, but it does not prescribe one fixed method. ISO 27005 helps security teams design that method, including how to identify assets, threats, vulnerabilities, likelihood, impact, and treatment options. For example, a 250-person SaaS company might reduce 40 identified risks to 9 high-priority risks after scoring, then use ISO 27001 Annex A controls to treat them before audit. The practical result is less guesswork and better evidence.
ISO 27001 vs ISO 27005: the short version
ISO 27001 is the certifiable standard for an Information Security Management System, often called an ISMS. It tells an organization what must be in place to manage information security, including leadership support, scope, risk assessment, risk treatment, controls, audits, and continual improvement.
ISO 27005 is not a certification standard. It supports ISO 27001 by explaining methods for information security risk management. It gives structure to the work that sits behind the risk assessment requirement in ISO 27001.
The catch is that many teams expect ISO 27001 to hand them a ready-made risk formula. It does not. That gap is where ISO 27005 becomes useful.
What ISO 27001 requires for risk assessment
ISO 27001 requires an organization to define and apply an information security risk assessment process. That process must produce reliable and repeatable results. It must also be tied to risk acceptance criteria and treatment decisions.
In practical terms, ISO 27001 expects the organization to:
- Define risk criteria, including how likelihood and impact are judged.
- Identify information security risks that affect confidentiality, integrity, and availability.
- Analyze and evaluate risks using a consistent method.
- Decide which risks need treatment and which can be accepted.
- Select controls, often from ISO 27001 Annex A.
- Create a risk treatment plan with owners, actions, and timeframes.
- Produce a Statement of Applicability, also known as the SoA.
The standard cares less about whether the organization uses a 3×3 or 5×5 scoring scale. It cares more that the method is defined, approved, used consistently, and supported by evidence.
What ISO 27005 adds
ISO 27005 gives more depth. It helps teams decide how to perform the risk assessment in a structured way. It explains the risk management cycle and helps connect business assets, threats, vulnerabilities, consequences, and controls.
ISO 27005 commonly supports activities such as:
- Context establishment, including internal and external requirements.
- Asset identification, such as databases, applications, laptops, contracts, and staff knowledge.
- Threat analysis, including phishing, ransomware, insider misuse, supplier failure, and system outage.
- Vulnerability review, such as weak passwords, missing patches, poor access reviews, or unclear ownership.
- Risk estimation, using qualitative, quantitative, or mixed methods.
- Risk treatment planning, including avoidance, modification, sharing, or acceptance.
- Risk communication and monitoring, so risk is not trapped in a spreadsheet no one reads.
Honestly, it feels wasteful when an organization spends three weeks building a 200-row risk register, then cannot explain why one risk scored “high” and another scored “medium.” ISO 27005 helps reduce that kind of mess.
How they work together
ISO 27001 says the organization must assess and treat information security risks. ISO 27005 helps it design a sensible process for doing that work. The two standards are not rivals. They serve different jobs.
In a typical certification project, the organization may start with ISO 27001 to define the ISMS scope. Then it may use ISO 27005 guidance to design a risk assessment method. After risks are assessed, the organization chooses controls, documents the treatment plan, and prepares the Statement of Applicability.
For example, a healthcare software provider may identify patient data, cloud infrastructure, support systems, and employee devices as key assets. It may then identify threats such as account takeover, API abuse, accidental data sharing, and backup failure. ISO 27005 can help shape this assessment. ISO 27001 then gives the audit structure for proving that the process exists and works.
Main differences between ISO 27001 and ISO 27005
| Area | ISO 27001 | ISO 27005 |
|---|---|---|
| Purpose | Defines ISMS requirements | Guides information security risk management |
| Certification | Certifiable | Not certifiable |
| Risk method | Requires a defined process | Explains how to build one |
| Controls | Includes Annex A control set | Supports control selection through risk thinking |
| Best use | Audit readiness and ISMS governance | Risk assessment design and improvement |
Which standard should an organization use?
An organization seeking ISO certification needs ISO 27001. That is the standard auditors use. Without it, there is no ISO 27001 certificate.
An organization that wants a stronger risk process should also use ISO 27005. This is especially helpful when the business has complex systems, regulated data, many suppliers, or several departments involved in risk decisions.
Small companies can still benefit from ISO 27005, but they should keep the method lean. A 20-person firm does not need a risk model so heavy that updating one risk takes 15 minutes. The method should fit the business, not bury it.
Common mistakes in ISO 27001 risk assessment
Many audit problems come from weak evidence rather than weak controls. The process may exist, but no one can prove how decisions were made.
Common mistakes include:
- Using vague risk descriptions, such as “cyber attack” without context.
- Scoring risks without criteria, which makes results look random.
- Skipping asset owners, causing unclear accountability.
- Copying generic risks that do not match the business.
- Ignoring accepted risks, with no approval or review date.
- Treating Annex A as a checklist instead of linking controls to risk.
Best practice approach
A practical approach is to use ISO 27001 for compliance structure and ISO 27005 for risk method design. The organization should keep the process simple enough for managers to understand and detailed enough for auditors to trust.
A good flow looks like this:
- Define the ISMS scope.
- Set risk criteria and acceptance rules.
- Identify assets, threats, and vulnerabilities.
- Score likelihood and impact.
- Prioritize risks.
- Select treatment options.
- Map controls to risks.
- Approve the risk treatment plan.
- Review risks on a planned schedule.
This structure gives auditors what they need and gives management a clearer view of real exposure.
FAQ
Is ISO 27005 required for ISO 27001 certification?
No. ISO 27005 is not mandatory for ISO 27001 certification. It is guidance. An organization can pass an ISO 27001 audit without using ISO 27005, as long as its risk process meets ISO 27001 requirements.
Can an organization be certified to ISO 27005?
No. ISO 27005 is not a certifiable management system standard. It supports risk management practice but does not provide a certification framework.
Does ISO 27001 require a specific risk scoring method?
No. ISO 27001 requires a defined and consistent method. The organization may use qualitative scoring, quantitative scoring, or a mixed model if it is documented and repeatable.
How often should ISO 27001 risks be reviewed?
Risks should be reviewed at planned intervals and after major changes. Common triggers include new systems, supplier changes, incidents, legal changes, and major business projects.
What is the biggest benefit of using ISO 27005 with ISO 27001?
The biggest benefit is clarity. ISO 27005 helps the organization build a stronger, more defensible risk process, while ISO 27001 turns that process into audit-ready ISMS evidence.