When an auditor, an enterprise client or a supervisory authority asks to see the risk management framework, they are not looking for a PDF with the word “framework” on the cover. They are looking for evidence that the organisation identifies risks methodically, prioritises with criteria, treats what matters and reviews the outcome with a defined frequency. Without that, the ISO 27001 certification stalls, the NIS2 programme does not hold up under inspection and client due diligence becomes an exercise in improvisation.
The usual problem is not a lack of documents: it is the lack of a coherent framework that connects policy, assessment, controls and monitoring in a single cycle. And the first obstacle is often vocabulary: “Risk Management Framework”, “ISO 27005” and “NIST RMF” are used as synonyms when they actually describe distinct approaches with different scopes and audiences.
Three Different Frameworks Under the Same Name
Before choosing steps or tools, it is worth clarifying which framework is being implemented.
ISO/IEC 27005:2022 is the international guide for information security risk management. It is not certifiable on its own: it complements ISO 27001 and describes a cyclical process for identifying, analysing, evaluating and treating risks. It is the most widely used reference framework in Europe for building the risk register that ISO 27001 clause 6.1.2 requires, and that many NIS2 programmes assume as their methodological base.
NIST Risk Management Framework (RMF) is a seven-step process (Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor) defined in NIST SP 800-37 Rev. 2 for managing security and privacy risks in information systems. It is prescriptive, oriented towards the system lifecycle and highly influential in regulated US environments. In the EU it is frequently consulted by companies with US clients or by teams working with the NIST Cybersecurity Framework 2.0, but it is not the framework a Spanish or European authority expects to see as a substitute for ISO 27005 in an ISMS.
Enterprise Risk Management (ERM) framework sits at the higher level: it integrates operational, financial, legal and cybersecurity risks under management governance. ISO 31000 describes general principles; it does not replace the depth of ISO 27005 in information security, but it defines risk appetite, roles and reporting that the cybersecurity framework must respect.
For most mid-sized European organisations, the practical combination is: ISO 27005 as the security risk methodology, ISO 27001 as the management system that requires evidence, and alignment with NIS2 risk assessment requirements (Article 21) when the company is in scope or sells to entities that are.
The ISO 27005 Cycle: Six Phases That Define an Operational Framework
The 2022 revision of ISO/IEC 27005 reorganises the process into phases that run in parallel rather than in strict cascade. These are the methodological core we recommend using when building a risk assessment under ISO 27001, because each phase produces an artefact the auditor can verify.
1. Context establishment. Defines scope (systems, processes, locations), risk acceptance criteria, risk appetite approved by management and roles (asset owners, risk owners, ISMS manager). Without documented context, the rest of the framework has no boundaries.
2. Risk identification. Two valid approaches according to the standard: asset-based (threat + vulnerability on an asset) or scenario-based (risk event with defined consequences). The common mistake is mixing both in the same register without criteria, making the inventory inconsistent.
3. Risk analysis. Assigns probability and impact values using a documented scale (qualitative, semi-quantitative or quantitative). The result is the risk level before treatment. The scale must be the same throughout the register and justified in the methodology.
4. Risk evaluation. Compares the analysed level with the acceptance criteria defined in the context. Decides which risks require treatment, which are accepted and which are escalated to management. Evaluation is a decision, not an automatic calculation.
5. Risk treatment. Selects options: modify (controls), retain, avoid or share. Selected controls must be traced to the Statement of Applicability (SoA) and to Annex A of ISO 27001. The risk owner approves the treatment plan and formally accepts the documented residual risk.
6. Communication, consultation, monitoring and review. The framework does not end with treatment: it requires communicating results to interested parties, monitoring indicators and reviewing the register when there are significant changes (new system, serious incident, regulatory change, merger). ISO 27001:2022 clause A.5.30 requires review following changes; NIS2 requires continuous risk management, not an isolated annual exercise.
The Six Components Any Credible Framework Must Have
Regardless of whether the company cites ISO 27005, NIST or an internal framework, an auditor or sophisticated client looks for these elements:
- Risk management policy approved by management, with explicit appetite and acceptance criteria.
- Documented methodology (scales, formulas or matrices, probability and impact definitions).
- Live risk register with identifier, description, owner, current level, treatment and review date.
- Treatment plan linked to implemented controls and remediation timelines.
- Review procedure with triggers (incidents, changes, audits) in addition to the scheduled periodic review.
- Monitoring evidence (management reports, minutes, residual risk indicators).
A framework that only contains the methodology in a PowerPoint and an outdated spreadsheet fails on component 3 and, by extension, on all the others.
How to Connect the Framework with NIS2, GDPR and Audits
The security risk management framework does not operate in a vacuum: it feeds and receives information from other programmes.
NIS2 requires under Article 21 a documented cybersecurity risk analysis, security policies and proportionate measures. A well-maintained ISO 27005 register covers most of the analysis; NIS2 adds incident notification obligations, supply chain management and management accountability that the framework must reference in the context and treatment plans. To keep the cycle active after the first implementation, the article on how to maintain NIS2 compliance describes the review triggers worth integrating into the framework’s monitoring procedure.
GDPR requires impact assessments (DPIAs) when data processing involves high risk to people’s rights. The security risk framework and the privacy impact analysis are complementary: a data breach risk may appear in both, but the DPIA evaluates impact on people, not just IT assets.
ISO 27001 audits verify that the risk assessment process was executed, that the SoA reflects treatment decisions and that Annex A controls are justified. A prior self-assessment helps detect whether the framework is ready before investing in an external audit.
Five Errors That Turn the Framework into Silent Paper
1. Register without risk owners. If nobody is responsible for each entry, treatment does not happen and residual risk is not formally accepted.
2. Scales changed between reviews. Recalculating with a different matrix invalidates historical comparisons and raises doubts in audit.
3. Treating everything as “high”. Prioritising without discrimination exhausts resources and shows that the assessment does not distinguish real criticality.
4. Ignoring third-party risks. Cloud providers, critical SaaS and subcontractors appear in NIS2 and in ISO 27001 (A.5.19–A.5.23). A framework that only covers internal infrastructure leaves a visible gap.
5. Annual calendar-only review. Without triggers for incidents or system changes, the framework becomes misaligned with operational reality between two formal reviews.
Best Practices for Implementing and Maintaining the Framework
- Start with context and risk appetite, not the tool. The tool (GRC, spreadsheet, ISMS register) comes after defining the criteria.
- Limit the initial scope to a bounded domain (one product, one business unit, one cloud environment) and expand once the cycle is working.
- Use scenarios for business risks and an asset-based approach for technical inventory, documenting which approach is used in each part of the register.
- Link each SoA control to a risk or a justified applicability decision. Controls without traceability are the most common finding in first-certification audits.
- Report residual risk to management at a fixed frequency (quarterly or semi-annually in regulated entities), not only when the audit arrives.
- Integrate incident and pentest findings as mandatory input to the review cycle.
- Avoid duplicating frameworks for ISO 27001, NIS2 and clients: one master register with views by regulatory framework reduces work and inconsistencies.
How PrivaLex Can Help
Implementing a risk management framework from scratch, or rescuing one that exists but would not hold up in audit, is one of the projects where methodology matters more than software. PrivaLex works with organisations that need an operational framework, not a consultancy document that nobody uses after delivery.
Current framework diagnosis. We review policy, methodology, register, SoA and review evidence. We identify gaps against ISO 27001 clause 6.1.2, ISO 27005 and, when applicable, NIS2 Article 21. The output is a prioritised list of corrections with effort estimates, not a generic maturity report.
Methodology and template design. We define scales, acceptance criteria, register templates and treatment approval workflows adapted to the size and sector of the organisation. If an Excel or GRC tool already exists, we adapt the framework to what is already there rather than imposing a new format without transition.
First complete cycle construction. We accompany the first risk identification and assessment with the internal team, train risk owners in their role and leave the register in auditable condition. This includes SoA alignment and Annex A control prioritisation.
Audit or supervision preparation. We simulate the auditor’s questions about the risk management cycle: context, sample of treated risks, review evidence following incidents, residual risk acceptance by management. We adjust documentation before the external auditor or supervisory authority arrives.
We work with companies undergoing first ISO 27001 certification, entities that must demonstrate risk management under NIS2, and providers that need a coherent register for enterprise client due diligence in regulated sectors.
Conclusion
A risk management framework is not a methodology document filed away: it is the cycle that connects what can go wrong in the organisation with what the organisation decides to do to control it. ISO 27005 provides the process; ISO 27001 requires that process to produce evidence; NIS2 and the B2B market require the result to be credible before third parties. Choosing the right framework, implementing the six phases with real owners and reviews, and avoiding the errors that empty the register of meaning, is what separates decorative risk management from the kind that sustains certifications, contracts and regulatory supervision.
If you want to know whether your current framework would hold up under an ISO 27001 audit or a NIS2 review, request your free risk assessment or book a session with our team.
FAQs
No. ISO 27001 defines the requirements of the Information Security Management System (ISMS) and is certifiable. ISO 27005 is a guide describing how to perform information security risk management, which ISO 27001 requires in clause 6.1.2 but does not detail. In practice, almost all organisations certified to ISO 27001 use ISO 27005 (or an equivalent documented methodology) to build their risk assessment and Statement of Applicability.
When the organisation operates in the US public sector, provides services to US federal agencies, or its clients explicitly require alignment with NIST SP 800-53 or the Cybersecurity Framework. For compliance before European authorities or ISO 27001 certification in the EU, NIST RMF does not replace ISO 27005: it can complement the control mapping, but the European auditor will expect methodology and register aligned with ISO 27001/27005.
ISO 27001 requires review following significant changes and a planned periodic review; the frequency is defined by the organisation according to its context (semi-annual or annual is common in mid-sized companies). In addition to the calendar, the register must be updated when a significant incident occurs, a new system is deployed, a critical supplier changes, relevant regulation comes into force or a pentest reveals materially new vulnerabilities. NIS2 and supervised entities typically require shorter cycles and documented management reporting.
Inherent risk is the level before applying controls. Residual risk is what remains after treatment and control operation. Risk appetite is the threshold that management approves as acceptable for the organisation; specific acceptance criteria by risk type derive from that appetite. A coherent framework documents all three: inherent risk in the analysis, residual risk after treatment with formal acceptance by the risk owner, and acceptance criteria linked to the appetite defined by management.
It is not mandatory. Many mid-sized organisations maintain a valid register in version-controlled spreadsheets with documented approvals. GRC software adds value when the number of risks, controls and regulatory frameworks makes manual maintenance unsustainable, or when continuous integration with IT tools for monitoring is needed. What the auditor verifies is methodology, owners, decisions and reviews, not the brand of software.
It covers the cybersecurity risk analysis and treatment part, which is central to NIS2, but not all of Article 21. NIS2 adds specific obligations for incident notification to CSIRTs, supply chain management, management training and cooperation with authorities. The risk framework must reference those requirements in the context and treatment plans; a well-built ISO 27005 register is the foundation, not the complete NIS2 programme.