Every man and his dog has a GRC tool they’ve vibe-coded together lately. The pitch is always the same: buy the platform, connect a few things, and ISO 27001 sort of happens to you. Don’t fall for it.

I’ve watched more than one team learn this the expensive way. The pattern goes like this: certification lands on the roadmap, someone gets nervous, and the first instinct is to go shopping. They sign up for a slick GRC platform — dashboards, a control library, the lot — on the assumption that the tool is the programme. Six months later they’ve got a beautifully designed system that nobody fills in, a pile of “controls” that don’t map to anything they actually do, and a subscription renewal they’re now too embarrassed to cancel. The tool didn’t fail them. They just asked it to do a job it was never going to do.

Now the contrast. One of the nicest ISMSs I’ve ever audited was run by a small team with no dedicated GRC platform at all. Everything lived in Jira and Confluence — tools they already used every day. When I asked to see their risks, they pulled up a Jira report. Each risk was linked to the controls that treated it and the assets it touched. Their findings sat there too, as evidence, joined to the same threads. The board got a risk report straight out of the same system the team worked in every day. It was a genuine pleasure to audit, because nothing was performed for my benefit — I was just looking at how they already worked.

The difference between those two teams was never the software. It was whether the management system existed first.

The tool is downstream of the system

Here’s the thing the vendors gloss over: ISO 27001 is a management system. It’s the rhythm of identifying risk, deciding what to do about it, doing it, checking it worked, and improving. A tool can organise that beautifully. It cannot create it. If you don’t have the rhythm, the fanciest platform on the market just gives you a tidier place to not do the work.

So before you spend a cent, get the bones right: a scope you can defend, a risk process you actually run, controls that are proportionate to your real risk, and the recurring habits — internal audit, management review, risk reviews — that keep the thing alive. Then pick somewhere to keep it all. Do it in that order and the tool question gets a lot smaller.

When automation actually earns its keep

The big automated platforms — Vanta, Drata and friends — have a real sweet spot: cloud-heavy organisations where the tool can plug into your stack and pull evidence automatically. If most of your world is AWS, Google or M365 and the platform can watch it for you, that automation genuinely saves time and the cost makes sense.

If you’re not cloud-heavy, a lot of that magic evaporates. You’re paying for connectors you’ll never wire up, and you end up doing the evidence work by hand anyway — just inside a more expensive interface. I’ve seen people certify on one of those platforms and admit afterwards that something far simpler would have done the job. Be honest about which of those two worlds you live in before you sign anything.

Doing it well in Atlassian

If you already live in Jira and Confluence — and plenty of teams do — you can run a real ISMS there. It won’t be handed to you on a plate. Atlassian started a little video series on setting this up and never quite finished it, so there are gaps, and there’s no clean template to import. You build it out as a company-managed project in your own tenant, and yes, that takes some upfront time. Here’s where I’d spend it.

Make an issue type for everything, and link them. Risks, controls, assets, findings — each becomes its own issue type. The power isn’t in having them; it’s in the links. A risk joined to the controls that treat it and the assets it affects is a risk you can justify. When the board (or an auditor) asks “why are you doing this?”, the answer is right there in the chain. Treat findings as an issue type too — that’s your evidence, kept with everything else instead of scattered across someone’s downloads folder.

Automate the operating cadence. This is the bit that keeps an ISMS alive instead of letting it quietly die after certification. Use Jira automation and workflows to nudge the recurring work — control reviews coming due, risks needing a fresh look, tasks that have to happen every quarter whether or not anyone remembers. The records that generate themselves are the ones that survive a busy month. The ones that need a human to remember are the ones that won’t be there when you go looking.

Use Jira’s asset management if you can justify the cost. The newer asset features are genuinely good for keeping your asset register linked to everything else. If the budget stretches, it’s worth it.

Put your policies in Confluence — with metadata. This is my favourite tip, and it’s the one that makes an auditor’s day. Use page properties on each policy page, then build a page-properties report that lists every policy with its owner and last/next review date. That “policy library” view is the single fastest way to show an auditor your documentation is real and maintained, not a graveyard of files last touched the week before the audit. I genuinely light up when a client has one.

The honest bottom line

There’s no prize for the most expensive ISMS. The best tool is the one your team will still be using in month nine, long after the certificate is on the wall and the initial adrenaline has worn off. For a lot of teams — especially if you’re already in Atlassian and you’re not drowning in cloud — that’s Jira for the moving parts, Confluence for the documentation, automation for the rhythm, and a clear head about what the standard actually asks of you.

Buy the platform if and when it earns its place. But build the system first. The system is the thing that gets you certified. The tool just decides how pleasant the ride is.

TL;DR: use Jira, issue types for everything, automate the cadence, policies in Confluence. And don’t buy a GRC platform to do a job only your team can do.