A Practical Guide to Building an ISMS That Actually Works

The Information Security Management Systems (ISMS). Everyone talks about them like they're some mystical creation that requires sacrificing your firstborn developer and performing complex rituals with your network cables at midnight.

They're not.

An ISMS is simply a fancy way of saying "how we make and keep our stuff secure without driving everyone mad in the process."

And while that might not sound as impressive at dinner parties, it's a lot more useful.

First Things First: What You Actually Need

Before you fall down the rabbit hole of security frameworks and control catalogues, let's get clear on the essentials:

• A way to identify what needs protecting (and no, "everything" isn't a helpful answer)
• Some sensible rules about how to protect it
• People who know what they're supposed to do
• A way to check if it's all working
• A plan for when things inevitably go wrong

That's it. Everything else is just details.

Starting in the Right Place (Hint: Not with Policies)

The biggest mistake companies make is starting with documentation. Yes, you'll need policies eventually. No, they shouldn't be your first port of call unless you particularly enjoy writing documents that nobody will ever read.

Instead, start here:

1. Map Your Crown Jewels

First, figure out what actually matters:

• What data would ruin your day if it leaked?
• Which systems keep your business running?
• What do your clients, customers, investors etc. trust you with and expect of you?
• Where are your secrets stored?

Write it down.

Congratulations, you've just created an asset register without needing a consultant to explain what an asset register is.

2. Get Your Risk Management Sorted (The Heart of Your ISMS)

This isn't just ISO box-ticking - it's the foundation of everything else. Miss this, and you might as well be installing security cameras to protect a house with no doors.

Risk Assessment That Makes Sense

Forget complex risk matrices for now. Start with these questions:

• What could go wrong? (threats)
• How likely is it? (probability)
• How bad would it be? (impact)
• What are we already doing about it? (existing controls)
• What else should we do? (risk treatment)

Risk Treatment That Works

For each significant risk, decide to:

• Fix it (implement controls)
• Transfer it (insurance/third-party)
• Accept it (with clear business justification)
• Avoid it (stop the risky activity)

Document these decisions - they'll drive your entire security program. And yes, "hoping nothing bad happens" isn't actually a valid treatment option. We checked.

Keep It Living

Risk management isn't a one-time exercise (much like that gym membership you're definitely going to use this year):

• Review risks when things change
• Update assessments based on incidents
• Track your risk appetite
• Measure if controls actually work

3. Enter Annex A: Your Security Control Cookbook

ISO 27001's Annex A is essentially a collection of 93 security controls that might help you manage those risks you've identified. Think of it as a security cookbook - you don't need to use every ingredient, but it's quite helpful to know what's available.

The controls are grouped into four main areas:

• Organisational controls (because someone needs to be in charge)
• People controls (because humans gonna human)
• Physical controls (for when you remember security isn't just about computers)
• Technical controls (the stuff your tech team actually enjoys)

Here's how to use it:

1. Look at each risk you identified
2. Browse through Annex A for controls that might help
3. Pick the ones that make sense for your situation
4. Document why you chose (or didn't choose) each control

For example:

• Risk: "Dave from accounting might accidentally email sensitive data to the wrong person"
• Relevant Annex A controls: Data classification, security awareness training...
• Not relevant: Physical security of server rooms (unless Dave's really creative)

4. Fix What Actually Needs Fixing

Now that you know what controls might help, it's time to implement them. Start with:

• The risks that keep you up at night
• Controls that give you the most bang for your buck
• Things that are embarrassingly broken
• Whatever made your auditor's eyebrows shoot up last time

Remember: Annex A is a helpful suggestion box, not a mandatory checklist. You don't need every control, but you do need to show you've thought about them.

"It wasn't relevant to our risks" is a perfectly valid reason for not implementing a control.

"We couldn't be bothered" isn't.

Turning Those Controls Into Reality (Without Writing War and Peace)

Now that you've got your risks sorted and your controls selected, it's time to make them real. And no, this doesn't mean writing a 400-page security manual that will serve as an excellent doorstop.

Documentation That People Might Actually Read

Yes, you need policies. No, they don't need to be awful. Think of them as user manuals for your security controls:

• Write them in human language - plain English (or plain whatever language your team speaks)
• Keep policies short and to the point
• Don't confuse policies and processes - policies set the rules and boundaries, processes tell you how to do things
• Make them findable (gathering virtual dust in SharePoint doesn't count)

Pro tip: If your policy takes longer to read than to follow, you're doing it wrong.

Make Your Controls Actually Control Things

Remember those Annex A controls you selected? Make them work. The key is:

• Start with your highest risks (because that's literally the point)
• Make secure choices the easy choices
• Automate what you can
• Build controls into existing processes - don't make your ISMS separate from your day-to-day.

Measure What Actually Matters

Don't track everything - track what tells you if your controls are working:

• Are your high-risk areas actually being controlled?
• Do your chosen controls actually mitigate the risks?
• Which controls are people constantly trying to bypass? (Hint: might need a rethink)
• Where are the gaps showing up?

Keep It Going (The Actually Hard Part)

Getting your ISMS running is one thing. Keeping it running is where the real fun begins.

1. Regular Risk Reviews (Not Just When Things Go Bang)

• Check if your risks have changed (spoiler: they have)
• See if your controls still make sense
• Look for new risks you didn't spot before
• Actually do something about what you find

2. Train People (Like They're Humans, Not Computers)

• Use real examples from your business ("Remember when Dave...")
• Keep it relevant to people's actual jobs
• Make it engaging (death by PowerPoint is still death)
• Focus on why, not just what

3. Monitor Your Controls (But Not Everything That Moves)

Focus on:

• Are your critical controls actually working?
• Do people understand what they're supposed to do?
• Are your risks actually being managed?
• What's causing the most problems?

4. Learn From Everything

Your ISMS should get better over time. That means:

• Actually review incidents (not just file them away)
• Update controls that aren't working
• Add new controls when needed
• Remove and replace controls that just create hassle

When Things Go Wrong (Because They Will)

Every security plan meets reality eventually. Be ready with:

• Clear plans (that aren't just "panic")
• Defined roles (beyond "whoever's nearest")
• Regular practice (yes, like a fire drill, but for security)
• A way to learn from mistakes (without playing the blame game)

The Secret to Making It Last

The best ISMS isn't the most comprehensive or the most detailed. It's the one that:

• Actually manages your real risks
• Helps rather than hinders your business
• Gets stronger over time
• People actually follow (revolutionary concept, we know)

The best security system is one that works in reality, not just on paper. And if you can achieve that without making your entire staff want to quit, even better.

Oh, and by the way - that's exactly what we do.

Wanna know more? Book a call.