Common Risk Assessment Mistakes That Sink Certifications
The Reality Check Every ISMS Manager Needs
I've conducted over 200 ISO 27001 certification audits, and I can tell you that risk assessment failures account for roughly 60% of all major nonconformities that derail certifications. Not because organizations don't grasp risk management conceptually—most security professionals understand threats, vulnerabilities, and impacts. The problem is they've implemented a version of risk assessment that satisfies no one: not auditors, not management, and certainly not the organization's actual security posture.
The gap between "we have documented our risks" and "we have an effective risk-based approach to information security" is where certification attempts go to die. After reviewing hundreds of risk assessments across manufacturing, healthcare, financial services, and technology sectors, I've identified five critical mistakes that appear with alarming consistency. These aren't subtle implementation nuances—they're fundamental misunderstandings of what Clause 6.1.2 actually requires.
Mistake #1: The Generic Risk Register Disaster
The most common failure I encounter is the "download-and-rebrand" approach to risk assessment. Organizations acquire comprehensive risk register templates, change the company logo, and present them as their own analysis. I once audited a software development firm in Dublin whose risk register included "flooding from monsoon rains" as a high-priority physical threat. When I asked the IT director about monsoon preparedness, he stared at me blankly before admitting he'd never actually read the document his team maintained.
This represents a fundamental misunderstanding of Clause 6.1.2(a), which requires organizations to identify risks "taking account of" the context established in Clause 4. Your risk register must reflect your specific business operations, geographic location, technology stack, regulatory environment, and threat landscape. A generic template that could belong to any organization demonstrates exactly the opposite of contextual analysis.
Auditors identify copy-paste risk registers within minutes through these telltale signs:
- Risk scenarios that contradict the organization's established context (cloud-based firms with extensive physical server risks)
- Uniform impact ratings across fundamentally different risk types
- Risk owners who cannot explain the rationale behind their assigned risks
- Absence of industry-specific or technology-specific risks that should obviously be present
- Treatment plans consisting of generic statements like "implement appropriate controls"
The solution requires actual analysis. Convene stakeholders who understand your operations, conduct structured threat modeling sessions, and build your risk register from your documented context. Reference Control 5.7 for threat intelligence requirements that should inform this analysis.
Mistake #2: Obsolete Asset Inventories
Your risk assessment quality directly correlates with your asset inventory accuracy. Clause 6.1.2 requires identifying risks to information confidentiality, integrity, and availability within your ISMS scope. You cannot identify risks to assets you don't know exist or that no longer exist.
I recently audited a fintech startup that had migrated entirely to AWS over 18 months, implemented infrastructure as code, adopted containerization, and integrated with six new payment processors. Their risk register still focused primarily on the on-premises Windows servers they'd decommissioned a year earlier. When I inquired about risks related to their Kubernetes clusters—which now processed all customer transactions—the risk manager gestured vaguely toward a line item about "server maintenance."
This organization treated Control 5.9 (inventory of information and other associated assets) as a compliance checkbox rather than a foundational risk management activity. Their asset inventory hadn't triggered risk assessment updates despite fundamental infrastructure changes.
Effective asset management requires:
- Regular inventory updates tied to change management processes
- Clear asset classification that supports risk assessment (not just compliance)
- Integration between asset discovery tools and risk assessment workflows
- Asset ownership assignments that include risk assessment responsibilities
When your organization can deploy new systems, migrate platforms, or adopt SaaS tools without updating risk assessments, your process has failed. Consider implementing Control 8.32 (change management) to ensure asset changes trigger appropriate risk analysis.
Mistake #3: The "Everything is Medium Risk" Problem
Risk assessment demands difficult judgment calls. What constitutes "high" versus "medium" impact? How do you justify likelihood estimates? Many organizations resolve this discomfort by rating everything as medium risk—it feels defensible, avoids difficult decisions, and generates fewer questions from management.
It also signals to auditors that your risk assessment process lacks analytical rigor.
I've reviewed risk registers containing 150+ risks where 140+ received "medium" ratings. When I asked risk owners to explain their assessment criteria, responses typically revealed that ratings were assigned to avoid creating high-priority items that might require immediate attention or low-priority items that might seem inadequately considered.
This approach violates the risk-based thinking that underpins ISO 27001. Clause 6.1.2(c) requires analyzing and evaluating risks, which necessarily means distinguishing between different risk levels. A risk register where everything receives the same priority provides no basis for resource allocation or control selection.
What the auditor looks for: Risk assessments with meaningful distribution across priority levels, clear criteria for ratings, and evidence that high-priority risks receive proportionally more attention in treatment planning.
Effective risk assessment requires:
- Documented criteria for impact and likelihood ratings that reflect your organization's risk appetite
- Reasonable distribution of risks across priority levels
- Evidence that rating decisions were made deliberately, not defaulted
- Treatment plans that reflect risk priority levels
Mistake #4: Risk Treatment Plans Without Teeth
Many organizations treat risk treatment planning as a documentation exercise rather than a management tool. They generate treatment plans that read like compliance checklists: "implement access controls," "conduct security awareness training," "establish backup procedures."
Effective risk treatment requires specific, actionable plans that address identified risks. Clause 6.1.3(b) requires selecting information security risk treatment options, and Clause 6.1.3(c) requires determining all controls necessary for implementing risk treatment options.
During a recent audit of a healthcare organization, I reviewed their treatment plan for "unauthorized access to patient records"—a high-priority risk given their regulatory environment. Their treatment plan stated: "Implement appropriate access controls and monitor compliance." When I asked for details about specific controls, timelines, or success criteria, the compliance manager admitted they hadn't progressed beyond documenting the intent to address the risk.
Effective treatment plans must include:
- Specific controls selected from ISO 27002:2022 or equivalent frameworks
- Implementation timelines with defined milestones
- Resource requirements and assignments
- Success criteria for measuring treatment effectiveness
- Residual risk assessments after treatment implementation
Reference Control 5.8 (information security in project management) to ensure risk treatment plans integrate with broader project management processes.
Mistake #5: Static Assessment in a Dynamic Environment
The most sophisticated mistake I encounter involves organizations that conduct thorough initial risk assessments but fail to maintain them as living documents. They treat risk assessment as a point-in-time exercise rather than an ongoing management process.
Clause 6.1.2(g) requires retaining documented information about the information security risk assessment process. More importantly, Clause 9.3 requires management review of risk assessment results, and Clause 6.1.2 itself requires considering "changes in the organization and its context."
I audited a manufacturing company whose risk assessment had been conducted three years prior and never updated despite:
- Acquisition by a larger corporation with different security requirements
- Implementation of IoT sensors across production lines
- Remote work adoption following the pandemic
- New data protection regulations in their primary market
Their risk register remained frozen in time, reflecting none of these significant changes. When incidents occurred—including a ransomware attack via compromised IoT devices—they scrambled to understand risks they should have identified and treated years earlier.
What the Auditor Looks For
During risk assessment evaluation, I examine several specific evidence areas:
Documentation Review: Risk registers that demonstrate clear methodology, appropriate scope alignment, and regular updates. I look for evidence that risks were identified through systematic analysis rather than template adoption.
Interview Evidence: Risk owners who can explain their assigned risks, rating rationale, and treatment progress. I test whether people understand the risks they're supposedly managing.
Process Integration: Evidence that risk assessment results drive control selection, resource allocation, and management decision-making. The risk assessment should be visibly connected to other ISMS processes.
Currency Validation: Recent updates reflecting organizational changes, new threats, or lessons learned from incidents. I verify that the risk assessment reflects current reality, not historical assumptions.
Cross-Reference Checking: Alignment between documented context (Clause 4), asset inventories (Control 5.9), and identified risks. These should tell a coherent story about your organization's threat landscape.
Building Audit-Ready Risk Assessment
Effective risk assessment combines analytical rigor with practical implementation. Start with your documented context from Clause 4 analysis—your business objectives, stakeholder requirements, and operational environment. This context should directly inform risk identification.
Maintain current asset inventories that support rather than burden risk assessment. When systems change, ensure risk assessment updates follow automatically through integrated change management processes.
Develop rating criteria that reflect your organization's actual risk appetite and tolerance. Document these criteria clearly enough that different assessors would reach similar conclusions about similar risks.
Create treatment plans that specify exactly which controls from ISO 27002:2022 you're implementing, when, and how you'll measure success. Generic statements about "implementing appropriate controls" indicate planning failure, not risk management.
Most importantly, embed risk assessment into regular management processes rather than treating it as an annual compliance exercise. Reference guidance from ISO 27005:2022 for detailed risk management methodology that supports rather than complicates your ISMS implementation.
Your risk assessment should tell a clear story about how your organization identifies, analyzes, and manages information security risks. When auditors review this story, it should demonstrate thoughtful analysis, practical treatment planning, and ongoing management attention. Anything less suggests fundamental misunderstanding of what risk-based information security management actually requires.
---Need deeper guidance on risk assessment implementation? Connect with experienced practitioners in our ISO 27001 Info Hub or explore our comprehensive risk management resources.
Need personalized guidance? Reach our team at ix@isegrim-x.com.
