What ISO/IEC 27005 Actually Looks Like in Practice
This is my second blog post. The first one was about building a private 5G network. This one is about something quieter but equally important: learning to think like someone who protects organisations from threats they may not even know exist.
Most people learn cybersecurity risk management by reading about it.
I got to do it for real.
During my studies at Turku University of Applied Sciences, I completed a course called Advanced Information Security Risk Management. The assignment was not a textbook exercise or a made-up scenario. We conducted actual ISO/IEC 27005 risk assessments for real organisations, delivered real risk reports, and made real recommendations. The organisations knew who we were and were expecting our findings.
That changes everything about how you approach the work.
What ISO 27005 actually is
It gets confused with ISO 27001 a lot so I'll clear that up quickly.
ISO 27001 is about building and certifying an Information Security Management System. It tells you what structures need to exist. ISO 27005 is specifically about risk management — it tells you how to actually find, evaluate and treat the risks that the ISMS is supposed to handle. They're designed to work together but 27005 is the one you open when you need to sit down and do the risk work, not just prove a system exists.
The process goes like this: you establish context, identify risks, analyse and evaluate them, then recommend treatment. Simple enough on paper. In practice each of those steps has a way of being harder than it looks.
The context phase catches you off guard
I expected the first phase to be straightforward. Read some internal documents, talk to a few people, define what's in scope. Move on.
It was not like that.
Before you can identify a single risk you need to genuinely understand what the organisation does, what it depends on, and what it would actually mean if something broke or got exposed. That sounds obvious. But when you're sitting across from someone and asking them to explain their systems and workflows, you realise how much you were assuming going in.
I spent a lot of time on questions that felt almost too basic to ask. What data do you hold? Who has access to it? What happens if that system goes down for three days? The answers kept shifting the picture of where the real risks were. The scope conversations alone took longer than I expected and almost every substantive disagreement during the assessment came back to something we hadn't locked down clearly enough in that first phase.
If I'd rushed through context establishment to get to the "real work" of identifying risks, the whole assessment would have been generic. Applicable to any company, useful to none.
Vulnerability and risk are not the same thing
This one took me a while to internalise properly.
A vulnerability is a weakness. No MFA on a system is a vulnerability. An employee who's never had security training is a vulnerability. An unlocked door is a vulnerability.
A risk is what you get when a credible threat could actually exploit that weakness and cause harm that matters. The unlocked door is only a risk if valuable things are behind it and someone who wants them knows it's there.
Early on I kept cataloguing weaknesses without stopping to ask whether anyone would realistically exploit them, or whether the impact would be serious enough to do anything about. ISO 27005 forces you to be disciplined about this. For every scenario you have to estimate likelihood and impact separately and combine them into a risk level. Some vulnerabilities just don't produce high risks. The threat isn't credible, or the damage is recoverable, or both.
That discipline matters because organisations have limited time and money. If you hand someone a report with 40 equally weighted items they won't know where to start and most of it won't get fixed. The whole point of the framework is helping you focus on what actually needs attention.
What I found on a real assessment
One of the organisations I worked with was a Finnish tech company — small, growing, working in the data analytics space. Not the kind of name that makes headlines when something goes wrong. But when you sit down and map the assets properly the picture changes.
The primary source for the assessment was their head of security. Not a junior IT contact, the person actually responsible for the organisation's security posture. That made the conversations different. They knew exactly what was in place and what wasn't, and they were candid about both.
Customer analytics data. Source code. Employee personal data. Internal tools, code repositories, cloud storage, communication platforms. When you start walking threat scenarios through those assets the risk levels climb fast even for a modest-sized company. A phishing attack hitting the right person on the right platform doesn't need to be sophisticated to cause serious damage.
What struck me most wasn't the technical picture though. It was the maturity gap.
This company had a genuinely good security culture. MFA was enforced everywhere. When something went wrong people responded quickly. There was real awareness, and the head of security knew exactly where the gaps were. But the formal structures weren't there. No regular external audits. No documented training programme. No scheduled risk reviews. Nothing written down that would survive a key person leaving.
The security posture depended almost entirely on the people currently in the building caring about it. That's fragile. It works until it doesn't.
The highest risk we identified wasn't a technical vulnerability. It was phishing leading to credential compromise on their internal communication platforms. High likelihood, meaningful impact, and directly addressable through something as unglamorous as a structured awareness training programme. Not a firewall upgrade. Not a new tool. A process.
That gap between culture and process is something I've seen discussed a lot in the Finnish security community. A lot of growing companies are sitting in exactly that position.
Writing a report someone will actually use
The output of all this work is a report. And writing a useful one turned out to be harder than I expected.
The people who read your report aren't always technical. A board member or a founder needs to understand the findings well enough to make decisions about what to fix and how much to spend. That means the report can't be a flat list of everything that could go wrong. It needs to tell them what matters most, why, and what to do about it in an order that makes sense.
For every significant risk we identified we included a description of the scenario, a likelihood and impact assessment, a severity rating, and specific recommendations. The severity ratings were uncomfortable in a useful way. You have to commit to a judgement. High, medium, low and you have to be able to defend it when someone pushes back.
Knowing a real organisation was going to read this and act on it made the writing feel different from anything I'd done academically. There's no safety net of it being hypothetical. You say a risk is high, that's what they're going to prioritise.
The part nobody really prepares you for
After you recommend controls, risk doesn't disappear. There's almost always residual risk, something that remains even after the recommended measures are in place. ISO 27005 asks you to document it and present it explicitly.
That conversation, about what level of risk the organisation is willing to accept and live with, is the one I hadn't really thought about going in. It's not a technical discussion. It's a business one. And it's sometimes uncomfortable because the honest answer is that some risk is just going to stay there.
That's not a failure of the assessment. It's reality. But presenting it plainly to an organisation takes a bit of nerve when you're doing it for the first time.
Why I think this skill matters right now
ISO 27005 risk assessments are not a niche academic exercise. GDPR requires documented risk assessments from any organisation handling personal data. ISO 27001 certification depends on having a solid risk management foundation. Finnish critical infrastructure is under increasing regulatory pressure around cybersecurity.
The demand for people who can actually do this work, not summarise the framework but sit with a real organisation and produce something defensible and useful — is only going up. And based on what I saw during this course, the supply is not keeping pace.
What is next for me
I completed this as part of my B.Eng. in ICT at Turku University of Applied Sciences, graduated in December 2025. I'm looking for my first full-time role in cybersecurity or information security in Finland or Europe.
If you work in cybersecurity risk, ISMS, or compliance and want to connect, I'd genuinely enjoy the conversation.
Ravi Sanghani is a cybersecurity and 5G engineer based in Turku, Finland.
hello@ravisanghani.com · ravisanghani.com · linkedin.com/in/ravi-sanghani