ISO 27001 in twelve months: what it took to get certified

We just received our ISO 27001 certificate from BSI. The scope: how we deliver our services, how we handle client data, how we run our cyber operations. We have been audited on our practice, not on yours.

If you’re an owner or director thinking about ISO 27001 for your own business, the marketing version of “go through an audit, get a certificate” leaves out almost everything that mattered for us. Twelve months is what it took. This is how it went.

The trigger

ISO 27001 has always been a good standard. The control set is sound, the framing of risk is sensible, and we already agreed with most of it. For a firm our size though, the cost of certification never quite cleared the value bar. We were going to keep running the controls regardless. Paying an external body to confirm what we already knew was hard to justify.

A government grant changed the calculation. Our cash outlay on consultants and the audit landed somewhere between $20,000 and $30,000, with the grant covering roughly half of that figure. The three of us also put in enough internal hours across the project that I couldn’t begin to tally them, and that part never appears on any invoice. The grant conditions required all activities completed by end of financial year, and that locked in a deadline. Deadlines work on us. We tend to get things done when there’s a date on the calendar with money attached to it.

We didn’t pursue ISO 27001 because a customer asked, or because an insurer demanded it, or because a tender locked us out. The grant made the timing work, and we wanted the discipline of an independent check on the operational side of our practice. That was the whole reason.

How the twelve months actually broke down

The twelve-month framing flattens a project that ran in five distinct phases, each with a different shape. If you’re scoping this for yourself, the phasing matters more than the total.

The first three months: scoping and the grant application. We spent the opening window understanding the grant conditions, walking through the ISO 27001 control set against what we already did, and putting the application together. The application went in. Then we waited.

The next stretch: vendor selection. Once the grant came back approved, we engaged with consultants and auditors. We compared pricing, scopes, methodology, and chemistry. We landed on 3Lights for the consultancy work and BSI for the audit. The selection took real time and shouldn’t be rushed.

From January: policy work. Lee worked with 3Lights to get the procedure set, supporting processes, document templates, registers, and matrices into shape. Deon and I were aware of this stream and not yet hands-on inside it. The Stage 1 prep mistake belongs to this phase: Lee carrying it alone to spare us, well-meant and costly.

The following couple of months: internal implementation. Once the policies were drafted, Deon and I joined the work. We built the document library, set up approval workflows, formalised change management inside the PSA, populated the asset register, set calendar-triggered review schedules, and created ticket types for access requests. This was the phase where “we do it in practice” turned into “we do it in a way an auditor can verify”.

The closing weeks: audit and approval. Stage 1 raised areas of concern, which triggered a flurry of corrective work over the following weeks. Stage 2 was about three days for us: one day onsite, the rest spread across remote evidence sharing and follow-up. Then BSI’s approval window, with the certificate landing on 30 April 2026. The very last activity, which I’m working through now, is logging all the evidence the grant requires before EOFY so the funded portion gets released.

The whole arc was a year. The intensive multi-person execution was the back half. Both numbers are worth holding in your head if you’re planning this for your own business.

The discovery: we already did the controls, we just couldn’t prove it

3Lights’ first job with us was a discovery phase against our existing posture. The diagnosis was clear. Our technical controls were strong. Our culture was strong. Risk came up in conversation often. Deon, our lead DevOps engineer, and I could tell you where every piece of infrastructure lived, what its criticality was, and what the top live risks against it were. Asked directly, we’d answer without hesitating.

Asked by an auditor though, what we had was harder to surface. The processes we ran for clients were formal and documented. The processes we ran internally were looser: shaped by culture and judgement, with conversations in Teams channels, decisions sitting in chats, and a cadence driven by whatever surfaced that week. There was a trail; it just wasn’t built for an outsider to follow.

Your systems should trigger the action, not anyone’s memory.

A culture of caring about security is a good place to start, and it isn’t the same thing as an ISMS. The work was real. The gap was formalisation: the cadence with named owners, the registers with review dates, the evidence stored where the next person can find it without asking the last person. Calendar entries, ticket types with required fields, scheduled actions. The fix is structural. The culture was already there.

3Lights drafted policy templates and adapted standard documents to fit our business, which was real and valuable work. Every one of those documents still needed modification, internal review, and director approval before it could become a real policy inside our ISMS. A consultancy can accelerate the policy work and steer you through the standard’s requirements; the decisions, the approvals, and the lived ownership of the policy stay inside your organisation. Expect to do the work yourself even with help in the room.

It can’t be delegated

Three of us drove the project. I led it as managing partner, ran the ISMS steering committee, and owned the staff education side. Lee, our other director, did the grant paperwork and worked with 3Lights on the policy framework. Deon handled the systems work, building the formalised controls into our existing platforms.

Once Deon and I joined Lee inside the work, the three of us met fortnightly for two to four hours, every fortnight, until the certificate was issued. That sustained cadence over the back half of the project was the part I underestimated going in.

Our biggest single mistake came earlier than that, during the Stage 1 prep window. Lee took ownership of it on his own, intending to keep the workload off Deon and me while we kept the business running. The intent was kind. The execution backfired. A few weeks out from the Stage 1 audit, Deon and I realised we weren’t across the timeline, the expected evidence, or the format of the engagement. The panic that followed cost more in stress than the workload would have cost us if we’d stayed in the loop from the start of the policy phase.

If I could rerun the project, the directors and the technical lead would all sit through prep together from the start. Shielding senior people from compliance work to “let them focus” is the well-meaning instinct that quietly fails most teams.

There’s a structural point underneath that experience. ISO 27001 pulls in a director who would otherwise be silent in day-to-day operations. Even when one partner drives the project, the standard requires the rest of leadership to stay in the room, sign off on policy, attend the steering meetings, and own the management-system responsibilities the standard assigns to top management. No version of ISO 27001 runs cleanly when leadership has handed the whole thing to a middle manager. That’s the number-one cause of failure I’ve heard about, by some distance.

Change management: a worked example

The clearest case of “we already do this, we just can’t prove it” was change management.

Our pattern before certification was the one most small firms use. Identify a change, talk about it, plan it, implement it in one motion, document it after the fact. The thinking was sound. The order was wrong. ISO 27001 expects the assessment, the back-out plan, the affected-party communication, and the approval to happen before the change touches production. We rearranged the work we were already doing onto a timeline an auditor could read.

We built the new flow into our PSA platform, which had been capable of it the whole time. Approvals, fields for the reason behind the change, fields for what success looks like, a documented owner. The cost was a few weeks of process design. The benefit was unexpected: ticket handoffs between technicians got noticeably cleaner. The receiving engineer on a handed-off job reads three lines of structured context and is up to speed without scrolling through Teams to find the backstory.

The client-facing side of our work hasn’t transformed yet, and I won’t claim it has. Service requests already required the same considered thinking we now apply formally, and we’ve only just been certified. The handoff and audit-trail benefits are real internally though, and the same shape will reach client change work as we tune it.

The audit

BSI audited us. The process runs in two stages: Stage 1 focused on policy, Stage 2 focused on evidence.

Stage 1 reads as collaborative. The auditor isn’t looking for reasons to fail you, and they’re not playing gotcha. They have their own accreditation to protect, so they’ll name gaps directly, but the framing of the engagement is “let us understand what you’ve built”. Our policy set held up. The areas of concern raised at Stage 1 were the ones we’d already named ourselves, all around centralised evidence.

The one genuine point of confusion in Stage 1 was around coding. We use PowerShell scripts for internal automation. We don’t publish software for anyone to consume, and we don’t run a SaaS that customers log into. The Stage 1 auditor asked us to cover code-specific controls anyway. I made the case in the room that scripting and software development are different categories, and the Stage 1 auditor’s position was that we should still write the policy, implement the controls, and gather the evidence in case Stage 2 saw it the same way.

So we did. We put real work into a policy area that didn’t apply to us, because the cost of being unprepared was higher than the cost of preparing. The Stage 2 auditor reviewed the evidence, accepted the distinction between automation scripts and consumed software, and excluded the area from scope. The work wasn’t wasted. The policies exist, they’ll hold up if our scope ever changes, and we know more about our own scripting practice than we did. It’s the kind of thing you can’t call until you’re in the room.

Stage 2 ran as one day on site and the rest remote. The auditor’s job at that stage is to test whether the evidence supports the policy. We don’t recall any areas of concern raised at the end, which on a first-time audit is a strong result. The Stage 2 auditor made a point that’s stayed with me: ISO 27001 audits are cut and dry pass or fail. There’s no comparative grading and no “this company does it better than that one”. You meet the requirements or you don’t. The clean result speaks for itself, without commentary.

The biggest stressor through the audit window wasn’t the audit. It was the grant deadline. The grant required all activities completed by EOFY, and a few of those activities sat on the critical path. The fortnightly meetings in the closing months carried more anxiety than they should have, and some of that anxiety leaked from leadership down into the technical team. With hindsight, that’s a business risk that belonged with the partners, not with the team executing the work. The risk of the grant not landing was ours to carry. The project would have been calmer if I’d held it that way more visibly.

I was starting at 4:30am and finishing at 7pm most weekdays for two months to keep my existing workload, new clients, and the ISO 27001 work all moving in parallel. Without the compression of the grant deadline, the schedule would have been workable. With it, the cost was real.

Life after the certificate

We’re on the other side of the certificate now, and a rhythm has bedded in.

The quieter benefit is harder to describe in a brochure, and it’s the one I keep coming back to. You can always be confident you’re doing the work right. The independent audit is the moment another party checks that for you and corrects the minor non-conformities you wouldn’t have spotted on your own. Walking out of Stage 2 with nothing surfaced took weight off shoulders we hadn’t fully recognised we’d been carrying.

Our ISMS steering committee meets quarterly to look at gaps and decide on continual improvement. Asset records, including physical items like door keys, sit in a register with an owner, a criticality rating, and a date for the next risk review. Access requests are now ticket types in our PSA, with an approval board attached. Cyber awareness training reporting gets checked monthly. Policy comprehension across the team gets reviewed annually. Some of those touchpoints are triggered by the systems themselves. Others are scheduled with a pre-defined action, which is a step on from “spreadsheets everywhere” without yet being as integrated as we eventually want.

A proper GRC tool sits on the roadmap. Our consultants’ advice during discovery was that most certified organisations live in spreadsheets, and to settle for that. We disliked the answer enough to push back, and converted as many controls as possible into ticket types or asset-register processes inside the PSA. More work upfront. More durable behind it.

One philosophy carried us through implementation: version 1 is better than version none. There are controls in our ISMS that we already know we’ll refine, and we shipped the first version anyway, with the next iteration on the plan. The auditors noted the dedication in the implementation. They also didn’t require perfect. The standard rewards consistent, evidenced practice over performative completeness.

What the certification means, and what it doesn’t

The scope of our certification reads as follows on the certificate issued by BSI:

The Information Security Management System (ISMS) is applicable to CCP’s environment and encompasses people, processes, and technology hosted in a cloud environment, covering data storage, backup, recovery, cybersecurity monitoring and incident response management. This scope is defined in accordance with the Statement of Applicability, Version 1.0 dated 30/04/2026.

The audit covers how we handle your data, how we run our incident response, how we manage access internally, how we control change, how we monitor security, and how we recover. The boundary is around our environment and our practice.

The audit doesn’t cover your environment. ISO 27001 certification on your MSP isn’t a substitute for your own controls. It does mean the vendor inside your supply chain who handles a meaningful share of your operational technology has been independently checked, rather than self-attested, so when you run your own vendor due diligence one of the harder boxes is already ticked for you.

Some of our clients knew we were pursuing it and were excited about it. We haven’t won new business off the back of the certificate yet, and we haven’t advertised it. The certification wasn’t done as a sales tool. It was done so the org would change. The commercial benefit, where it lands, lands downstream.

What I’d tell another business considering it

• Top-down, or don’t bother. ISO 27001 is the responsibility of leadership. Not the director who likes IT alone, not the security person alone, and not a middle manager handed the project on someone’s behalf. The standard requires top-management involvement, and the reality requires it more. This is the most common cause of failure I’ve heard about.
• It’ll take longer than you think. Twelve months was achievable. Twelve months was also brutal. If you can afford eighteen, take eighteen.
• Do it for the controls, not the certificate. If you wouldn’t run the ISMS without a certificate hanging on the wall, the certificate won’t survive either. The cadence has to mean something to the people inside the building.

One last thing. We pursued ISO 27001 for ourselves. The grant made the timing work, and we wanted the discipline of an external check on the operational side of how we run. No customer asked us to do it, and no insurer required it. We could have kept running the controls without a certificate for another decade and most outside parties would have been none the wiser.

We saw the value and went after it. Our clients are the second-order beneficiaries: the vendor handling a meaningful share of their operational technology is now independently audited, rather than self-attested. That’s the practical effect of taking the harder route through compliance.