By Sreecharan Challa

Every consultant will walk you through the ISO 27001 requirements. Annex A controls, ISMS scope, risk treatment plans, the framework is well documented and widely explained.

What’s less talked about is what actually happens when organizations try to get certified. After leading multiple ISO 27001 certifications from gap assessment through to successful audit, here are the top four things I wish every client knew before we started.

“We’re basically already doing everything, we just need someone to document it.”

This is the single most common thing I hear walking into a new engagement. And I understand why. Organizations that have been operating for years have controls in place. They have policies, they have processes, they have security tools. It feels like certification should just be a formality.

It rarely is.

ISO 27001 isn’t just asking whether your controls exist. It’s asking whether you built your entire security approach with a “security by design” ideology, whether security is baked into how you build, operate, and govern, not bolted on afterward. That’s a fundamentally different question.

And here’s the part that catches most organizations off guard: the People component.

Everyone talks about the People, Process, and Technology trio in security. But in practice, most organizations spend 80% of their energy on technology and process — and treat people as an afterthought. ISO 27001 doesn’t let you do that. Your awareness programs, your training records, your culture of security, these are assessed just as rigorously as your firewall configuration. The organizations that struggle most with certification are the ones that have invested heavily in tools but haven’t brought their people along for the journey.

Coordinating your own organization is a project in itself.

One of the things that genuinely surprised me, even after supporting multiple clients through their certification journeys, is how siloed organizations can be internally. Teams operating independently, each with their own priorities, their own timelines, their own interpretations of what security means for their function.

This matters for ISO 27001 in a way it doesn’t for SOC 2. SOC 2 certifies against specific system requirements; it’s more bounded. ISO 27001 scopes tend to run much broader in practice; your ISMS often has to span every relevant function, not just one system. That means getting IT, HR, Legal, Operations, and leadership all rowing in the same direction, often for the first time.

I’ve seen technically strong organizations stumble on this. Not because their controls were weak, but because getting cross-functional alignment and evidence from siloed teams became a project that dwarfed the technical work itself.

If your organization operates in distinct internal silos, budget time and executive support for that coordination challenge before you start. It will not resolve itself.

What every client should know on day one.

There is a real, non-trivial commitment required from your organization, not just from the project team, but from every layer of the business.

Management sponsorship isn’t a formality here. If your leadership isn’t actively engaged, teams won’t prioritize audit requests, evidence collection will drag, and the program will stall. I’ve seen certifications take twice as long as planned not because the controls weren’t there, but because stakeholder availability became the bottleneck.

From the CISO or Security Manager owning the program, all the way to the analyst pulling evidence on a Tuesday afternoon, everyone needs to understand that this requires their time and their attention. The organizations that get through certification smoothly are the ones where leadership made that commitment visible and real from day one.

What auditors actually care about — and what they don’t.

Here’s where I see the most energy misspent.

Organizations obsess over documentation. Policies get rewritten three times. Procedures get formatted and reformatted. Binders get built. And then the audit happens, and the auditor spends far less time on the documents than expected.

This is because ISO 27001 is about control effectiveness, not control existence.

An auditor doesn’t want to see a beautiful Acceptable Use Policy sitting in a SharePoint folder. They want to know whether employees have read it, whether it’s enforced, whether it’s reflected in how people actually behave. A well-written policy that nobody follows is a finding, not an asset.

The organizations that pass cleanly are the ones that can demonstrate their controls working in practice, through evidence of operation, through records of review, through people who can speak to what they actually do, not just what the document says they should do.

Stop over-documenting. Start over-evidencing.

The bottom line.

ISO 27001 is worth pursuing — it builds real security maturity and is far more than just a certificate on the wall. But it rewards organizations that approach it honestly: understanding where they actually are, committing real resources to the process, breaking down internal silos, and focusing on making controls work rather than making controls look good.

The organizations that treat it as a checkbox exercise tend to find out, somewhere in the audit process, that it isn’t one.