ISMS in practice: what nobody tells you about implementation
Implementing a real Information Security Management System is different from what certification teaches you. Here's what I've learned in the field.
After years implementing and consulting on information security management systems, I’ve learned there’s a huge gap between what the ISO 27001 standard describes and what happens when you try to apply it in a real company.
This post is about that gap.
The problem with the standard approach
Most ISMS implementations start in the wrong place: documentation.
Teams hire consultants, buy templates, spend months creating beautiful policies in Word, build an immaculate document repository — and then discover that nobody reads them, nobody follows them, and the production environment still has the same attack surface as before.
This isn’t a failure of commitment. It’s a failure of sequence.
The right sequence
After numerous implementations, I’ve learned the correct order is:
1. Real inventory, not aspirational
Before any policy, you need to know what exists. Not what should exist — what actually exists. This means:
- Mapping all assets (including shadow IT that “officially” doesn’t exist)
- Data inventory: where it lives, who accesses it, how it flows
- Mapping third-party integrations (APIs, SaaS, legacy systems)
Most companies are surprised by what they find in this phase. Surprises are the goal — they reveal real risk.
2. Risk analysis with the technical team, not for the technical team
Risk analysis done by external consultants and delivered in a report to the technical team doesn’t work. The technical team needs to participate in the analysis, not receive the result.
Why? Because the technical team has context that no consultant has. And because risk analysis the team didn’t participate in is risk analysis the team will ignore.
3. Controls that work in operational reality
Security controls need to be compatible with the company’s operational reality. A control that makes work impossible will be circumvented. And a circumvented control is worse than no control — it gives a false sense of security.
The goal isn’t the most secure possible control. It’s the most secure control that people will actually use.
What ISO 27001 doesn’t tell you
The standard defines the what, not the how. And the how is 90% of the work.
Incident management: The standard says you need a process. What it doesn’t say is that this process needs to be simple enough to work at 3am with a tired engineer. If the runbook is more than one page, it won’t be followed during an incident.
Business continuity: Continuity plans that have never been tested aren’t plans — they’re expensive science fiction. Regular, realistic testing is the only way to know if it works.
Vendor management: This is the most ignored control in implementations I see. Third parties with access to your systems are part of your security perimeter, regardless of what the contract says.
What works
After many implementations, what consistently works:
- Start from risk, not documentation
- Involve the technical team as protagonists, not recipients
- Gradual controls that fit into the existing workflow
- Real operational metrics (incident response time, patch coverage, successful phishing rate)
- Regular, honest reviews — including things that didn’t work
The right question
When evaluating an ISMS implementation, the question isn’t “do we have the documentation in order?”. The question is:
If a serious incident happens today, are we prepared to respond?
If the answer is no — and in most companies it is no, regardless of documentation — then the ISMS still has work to do.
This is the kind of work we do at INIT4: ISMS implementations that work in the real world, not just on paper. If you want to talk about your company’s security reality, get in touch.