I've been a software engineer with an ops focus for most of my career. Always had interest in compliance and information security but never had any formal training.

At TalkJS I got hired as a software engineer, but these days I fill most of my time with compliance work as our Security Officer and bridging the gap between our enterprise customers' technical requirements and our engineering teams.

Recently we've received our ISO/IEC 27001 certification, and we did this fully in house. Without an expensive governance, risk and compliance (GRC) tool or consultancy, every role is filled by someone already on the team. In my eyes that's unusual, it's impressive, and I'm insanely proud of everyone at TalkJS that we got it done.

Here's how we did it, and what I think are the most important things to keep in mind if you're considering the same.

The context

TalkJS is a remote-first chat-infrastructure-as-a-service company. We got an interesting company culture (in the good sense). A colleague aptly called us a Radical Enterprise, and that article goes into a lot more depth about how we actually operate as a company and team.

We serve a wide range of customers with very different requirements around their data and how it's protected. Over the years we've had a lot of requests for some kind of certification, ISO/IEC 27001 or SOC 2 Type II.

At some point I decided I wanted to move away from pure engineering work and focus more on compliance and enterprise. The team gave me that opportunity without blinking, and that kicked off the ISO/IEC 27001 process.

The core requirement of ISO 27001 is that you adopt and maintain an Information Security Management System (ISMS). This is a set of policies, procedures and controls that define how your organisation manages information security.

We were all a bit afraid of what compliance was going to mean. Red tape, bureaucracy, processes getting in the way of shipping? The real fear was that it would get in the way of what we're actually good at: shipping chat software you can build a company on. We did end up with some new processes and documentation, but far less than we feared, and the level of team participation we managed to get was something I haven't seen described anywhere else.

In light of that context, here’s my main learnings.

1. Formalise what you already do

Your team is probably already doing a lot of things right. Ours was. So we didn't start by designing an Information Security Management System (ISMS) from scratch. We looked at what we already do and asked: does this fit a policy or procedure we'll need? And if not, would a small change get it there?

Most of the time the answer was yes. Change management is a good example. We already had a #risky-changes channel where we discussed bigger, higher-impact changes. It wasn't a formal process, but in practice it got followed nine times out of ten. Instead of replacing it with something new, we formalised what was already there and widened its scope a bit to cover what the standard needed. The result is a change management process the team already knew, that we can now document and track inside the ISMS. Nobody had to relearn anything.

I think most people get this backwards. They treat certification as a pile of new work to bolt on top of what they do. We tried to take the things we already did well and make them legible. The gaps that remained were real gaps worth fixing. Everything else was just writing down the process.

2. Reduce friction everywhere

A lot of the work is manual without a dedicated GRC tool. I don't mind that. The point is that the rest of the team shouldn't have to feel it.

We abstracted most of the evidence collection away from them. The team keeps working in the normal places, mostly Slack, the way they always have. I pick it up from there and convert it into proper documentation for the ISMS. There's a lot to check, follow up on, and review under 27001, and my job is to make sure as little of that as possible lands on anyone else's desk.

There will always be some extra work, you can't get it to zero. But the goal is keeping the friction low enough that compliance never becomes the reason someone ships slower.

3. Write the policies as a team

In most organisations the security team writes the policies, management approves them, and they get sent down for everyone to acknowledge. People click accept and never read them again.

That was never going to work for us, we're a small company with a lot of strong and passionate opinions. So we wrote them with the whole team. Polderen, as we'd say in Dutch: you talk it through until everyone is actually on board.

It was genuinely slower than a top-down approach would have been. We spent extended time arguing specific line items and some of those discussions went on for a long time. I remember spending a significant chunk of a meeting on individual clauses in the data retention policy. From the outside that probably looks inefficient.

But the policies make sense because the people doing the work helped write them. They're coherent with how we actually operate day to day, and adoption was essentially instant, because there were no surprises to adopt. Nobody is quietly resentful of a policy they had no say in, so we just follow them, without much friction.

The writing and approval phase got a bit slower. Everything after signing got a lot easier. I believe this was a core part of how we did it and I wouldn't change it.

4. Take the internal audit seriously

My biggest recommendation from this whole internal audit process: treat it as a real audit, not a checkbox before the real one.

We did the internal audit in house too, this was picked up by Chris.

Chris did such a thorough job that we found all the big, medium, and small gaps in our system with time to spare before the Stage 2 audit. A serious internal audit is a dress rehearsal under real conditions. It gave us a good picture of what the external audit would feel like, and it showed us where the ISMS itself could be better, while we still had time to fix things without any panic.

A weak internal audit just defers the bad news to the most expensive moment. My thanks to Chris for taking it seriously. It made my life so much easier.

5. Choose an audit partner that fits you

At some point an external party has to audit you, and picking the right one matters more than most people expect. We're a remote-first SaaS with some unusual implementations, so we wanted someone with real experience in that world and a way of working that matched ours.

The temptation is to go with a big name. For a company our size and shape that's usually the wrong move. The big firms aren't really set up to sit with a small team that has odd requirements and explain why those requirements are fine. Fit matters more than brand.

After a lot of interviews we went with Tempo Audits. They're accredited by the United Kingdom Accreditation Service (UKAS). My first conversation with their founder Rob was great and a real education on all things compliance, standards and audits.

Their communication has been excellent from the start, and they paired us with an auditor, Jordan, who managed to be both thorough and pragmatic, which is honestly rarer than it should be.

I really can't recommend them enough.

Some learning items

This was my first full ISO/IEC 27001 implementation, so there's a list with some learnings.

The biggest thing: I started in a silo. Working in public view of your team matters. If I did it again I'd be a lot clearer from the start about what's ongoing and why, instead of surfacing it later when it became relevant.
Another one is tooling. Skipping a full GRC platform was the right call and I'd make it again. But the alternative we landed on, a Confluence template, gave us almost no handholding. I don't have a clean answer here yet. At our team size we genuinely don't need a full GRC suite, but the gap between ‘spreadsheet and Confluence’ and ‘enterprise GRC’ is wider than it probably should be, and it's worth thinking about before you start.

We're really happy with how this turned out. A big thank you to everyone in the team who put time and effort into making this happen. It was a real team effort and it shows. I'm looking forward to continuing this work and doing more in the compliance space.

TalkJS Resources

Message History

Delivery option(s)