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

We just received our ISO 27001 certificate from BSI, the certification body that audited us. 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 Australian owner or director weighing up ISO 27001, the marketing version leaves out almost everything that mattered for us. That version is “go through an audit, get a certificate”. Twelve months is what it took, and three of us drove it. This is how it went.

Why we certified when we did

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 was never quite worth it. 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 came to somewhere between $20,000 and $30,000. The grant covered roughly half of that figure. The three of us also put in more internal hours than I could begin to tally. None of that time appears on any invoice. The grant conditions required all activities completed by end of financial year, which 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.

Twelve months, broken into five phases

The twelve-month figure hides a project that ran in five distinct phases. Each one had a different rhythm and made a different demand on us. 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 months understanding the grant conditions and walking through the ISO 27001 control set against what we already did. Then we put the application together. It 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 chose 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 on the procedure set, the supporting processes, the document templates, the registers and the matrices. Deon and I knew the work was running and were not yet hands-on inside it. Our mistake preparing for Stage 1, the first audit visit, belongs to this phase. Lee carried it alone to spare us, which was 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 and set up the approval workflows. Change management was formalised inside the PSA, the ticketing platform we run the business on. We 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 registered on 11 May 2026. The very last activity is logging all the evidence the grant requires, which I’m working through now. That has to be done before the end of the financial year so the funded portion gets released.

The whole project took a year. The intensive multi-person work was the back half. Both numbers matter if you’re planning this for your own business.

We already did the controls, we just couldn’t prove it

3Lights started with a discovery phase against how we already worked. 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 name every piece of infrastructure, its criticality, and the top live risks against it. 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. Conversations happened in Teams channels, decisions were made in chats, and the cadence followed 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, but it is not an information security management system (ISMS). The work was real. Formalisation was what we lacked. A cadence with named owners, registers with review dates, 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 became a 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 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 every fortnight for two to four hours. That ran until the certificate was issued. The sustained cadence over the back half of the project was the part I underestimated.

Our biggest single mistake came earlier, during the Stage 1 prep window. Lee took it on alone, 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 it. We didn’t know the timeline, the expected evidence, or the format of the engagement. The panic that followed cost more in stress than the work would have cost us. Staying in the loop from the start of the policy phase would have been cheaper.

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.

The same thing is built into the standard. 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. They sign off on policy, attend the steering meetings, and own the 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, 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. No scrolling through Teams to find the backstory.

The client-facing side of our work hasn’t changed much 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 discipline will apply to client change work as we tune it.

Stage 1 and Stage 2, from the inside

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 tone 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 else to use, and we don’t run an online service 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. The Stage 1 auditor’s position was that we should still write the policy, implement the controls, and gather the evidence. That was 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. Being unprepared would have cost more than preparing did. 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 the end of the financial year, and a few of those activities were on the critical path. The fortnightly meetings in the closing months carried more anxiety than they should have. 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 losing the grant 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. That was 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 settled 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. It also corrects the minor non-conformities, the small gaps you wouldn’t have spotted alone. 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. Every asset record has an owner, a criticality rating, and a date for the next risk review. That includes physical items like door keys. 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 checks are triggered by the systems themselves. Others are scheduled with a pre-defined action. That’s a step on from “spreadsheets everywhere”, and not yet as integrated as we want.

A proper governance, risk and compliance (GRC) tool is on our roadmap. Our consultants’ advice during discovery was that most certified organisations manage all of this in spreadsheets, and that we should settle for that. We disliked the answer enough to push back. We 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. We shipped the first version anyway, with the next one already planned. The auditors noted the dedication in the implementation. They also didn’t require perfect. The standard rewards consistent practice you can evidence, not a show of being finished.

What the certification means, and what it doesn’t

The certificate issued by BSI states the scope like this:

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 and how we run our incident response. It covers how we manage access internally, how we control change, how we monitor security, and how we recover. The boundary is our environment and our practice.

The audit doesn’t cover your environment. A certificate on your IT provider is not a substitute for your own controls. What it does mean is that one of your suppliers has been checked independently, rather than self-attested. That supplier handles a meaningful share of your operational technology. So when you run your own vendor due diligence, one of the harder boxes is already ticked.

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 business would change. Any commercial benefit comes later.

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 get the benefit indirectly: the IT provider 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.