You're deciding how to structure your risk assessment process for ISO/IEC 27001 or SOC 2. This decision isn't just about tools; it's about whether you'll treat risk estimation as a repeatable engineering discipline or a periodic documentation exercise.
The stakes are higher than you might think. Executives often distrust risk assessments because they can't see the reasoning behind the numbers. When your risk register shows a vendor breach as "medium likelihood, high impact," what's that based on? Expert judgment? Historical incident rates? A team discussion? If you can't answer with specifics, you're presenting opinion as analysis.
The Decision You're Facing
Your choice breaks down to three approaches:
Traditional risk registers: Periodic workshops where teams estimate likelihood and impact, usually in a spreadsheet or GRC platform. Risks get scored, prioritized, and reviewed quarterly.
Structured risk models: Explicit frameworks that document assumptions, use defined inputs, and produce repeatable outputs. Think decision trees, fault trees, or attack graphs that you can run multiple times with different parameters.
Hybrid approach: Risk registers for broad coverage, models for critical scenarios where you need defensible estimates.
This isn't about sophistication for its own sake. ISO/IEC 27001 Clause 6.1.2 requires that you "retain documented information" on your risk assessment process. SOC 2's CC3.2 criterion expects you to identify risks that could affect trust services criteria. Both frameworks care whether your process produces reliable inputs for decision-making.
Key Factors That Affect Your Choice
Strength of available knowledge: Can you point to directly observed facts about the risks you're assessing? If you're estimating ransomware likelihood, do you have incident data from similar organizations, or are you guessing based on news coverage?
When your knowledge is weak, you lack historical data, you're assessing novel threats, or you're working from theoretical models you haven't validated, you need to make that weakness visible. A traditional risk register often hides this. A structured model forces you to document what you know and what you're assuming.
Executive comfort with uncertainty: Some leadership teams want definitive risk scores. Others understand that information security operates under deep uncertainty and want to see the reasoning, not just the conclusion.
If your executives reject risk assessments because "the numbers change every quarter" or "we don't know where these ratings come from," that's a signal. The problem isn't the uncertainty, it's that you're presenting estimates without showing the underlying knowledge.
Resource availability for model development: Building explicit risk models takes time. You're documenting assumptions, defining variables, testing whether your model produces sensible outputs. For a team running lean, this can feel like overhead.
But consider the alternative cost: re-litigating the same risk discussions every quarter because no one documented why you estimated something the way you did.
Path A: Traditional Risk Registers
Choose this when:
- You're maintaining an existing ISMS and need broad risk coverage across many scenarios.
- Your audit history shows assessors accept your current process.
- Your organization treats risk assessment as a compliance checkpoint, not a strategic input.
- You lack the technical depth to build and maintain explicit models.
What you're committing to: You'll run periodic risk workshops. Subject matter experts will estimate likelihood and impact, usually on a 1-5 scale. You'll document the results in a register that maps to ISO/IEC 27001 Annex A controls or SOC 2 trust services criteria.
The hidden cost: When an executive challenges a risk rating, you'll have limited ability to defend it beyond "this is what the team assessed in Q2." If the same risk gets re-scored differently six months later, you can't easily explain why, because the original assessment didn't document the assumptions or data that led to it.
Make it work: At minimum, add an "assessment basis" field to your register. For each risk, note whether you're working from direct observation, theoretical models, or expert judgment. When knowledge is weak, say so explicitly. ISO/IEC 27001 Clause 6.1.3(e) requires you to define criteria for performing risk assessment, "strength of underlying knowledge" is a legitimate criterion.
Path B: Structured Risk Models
Choose this when:
- You're assessing high-consequence scenarios where executives need to trust the analysis (data breaches, system outages, supply chain compromises).
- You have technical staff who can build and validate models.
- Your organization makes significant resource decisions based on risk assessment outputs.
- You're facing skepticism about current risk processes.
What you're committing to: You'll develop explicit models for your critical risks. A vendor security model might include variables like access level granted, data sensitivity, monitoring coverage, contract terms. You'll document the assumptions ("we assume detection within 48 hours if monitoring is in place") and test whether the model's outputs match your intuition and any available data.
This becomes your documented risk assessment methodology under ISO/IEC 27001 Clause 6.1.2. For SOC 2, it demonstrates that your risk identification process (CC3.2) uses systematic analysis, not ad-hoc judgment.
The hidden cost: Model development takes time you might not have before your next audit. Models can also create false precision, if you're estimating with weak knowledge, a sophisticated model doesn't make the estimate more reliable, it just makes it look more authoritative.
Make it work: Start with one critical scenario. Build a simple model, even a decision tree is better than undocumented judgment. Test it: does it produce different outputs when you change inputs? Can someone else run it and get the same results? Document what you learned and what you assumed.
As you validate the model against real events (incidents, near-misses, external data), you improve the strength of knowledge underlying your estimates. That's the goal.
Path C: Hybrid Approach
Choose this when:
- You need comprehensive risk coverage for compliance but want defensible analysis for critical decisions.
- You're transitioning toward more rigorous risk management but can't rebuild everything at once.
- Your audit scope includes both routine operational risks and high-stakes strategic risks.
What you're committing to: Maintain a traditional risk register for broad coverage. Identify your top 5-10 scenarios where consequences could be severe or where executives regularly question your estimates. Build explicit models for those.
Your risk register becomes the compliance artifact. Your models become decision support tools. Both feed into your Risk Treatment Plan (ISO/IEC 27001 Clause 6.1.3).
Make it work: Be clear about which risks you're modeling and why. Document the selection criteria: "We model risks where potential impact exceeds X or where we lack direct observational data." This prevents the perception that you're cherry-picking which risks get rigorous analysis.
Summary Matrix
| Approach | Best for | ISO/IEC 27001 fit | SOC 2 fit | Time investment | Defensibility |
|---|---|---|---|---|---|
| Traditional register | Broad coverage, established programs | Meets 6.1.2 minimum | Satisfies CC3.2 | Low (quarterly reviews) | Weak (undocumented judgment) |
| Structured models | Critical scenarios, skeptical executives | Strong 6.1.2 evidence | Strong CC3.2 demonstration | High (model development) | High (explicit reasoning) |
| Hybrid | Transition state, mixed risk portfolio | Exceeds 6.1.2 for critical risks | Demonstrates maturity | Medium (selective modeling) | Medium to high (where modeled) |
The question isn't whether your current process passes an audit. It probably does. The question is whether it produces risk information your organization can actually use to make decisions. If executives don't trust your risk assessments, adding more risks to the register won't fix that. Making your reasoning visible might.
