Why we did it

In September 2023, Extenda Retail passed its initial ISO/IEC 27001 certification audit. It took us roughly a year from the first approved ISMS document to the auditor’s sign-off. This post is about how we got there, and what I would do the same way again.

Our customers are retailers. They run their stores, their checkouts and their warehouses on our software, and a growing share of that runs as SaaS in our cloud. Every serious RFP we answered had a security section, and every security section asked the same question in different words: how can we trust you with our operations and our data?

We could answer that question one questionnaire at a time, or we could answer it once, with an independent certificate. We chose the certificate. Not as a badge, but as a forcing function to build a security organisation that would hold up under scrutiny.

Starting point: scope, sponsorship and an honest gap analysis

The first formal step was small. In November 2022 our CEO approved version 1.0 of the Information Security Management System procedure. That one approval mattered: it made information security an executive commitment, not an IT project.

We then drew the scope wide on purpose. It covered the development, maintenance and support of our cloud-based and on-premise software, plus our professional and consulting services for retail, warehouse management, logistics and point of sale. Carving out only the easy parts would have given us a certificate our customers could not rely on.

The gap analysis was humbling, and useful. It surfaced a short list of high-severity risks that no amount of policy writing would fix on its own:

  • Business continuity planning that had not been managed or tested reliably
  • Incident management that depended on individuals rather than a process
  • Inconsistent treatment and classification of information
  • An incomplete picture of our assets
  • Too little ongoing monitoring of suppliers
  • Project management practices that varied from team to team

Building the ISMS: risks with names on them

The most important design choice we made was to give every high-severity risk two names. A risk owner from the Executive Management Team was accountable for the outcome. A treatment owner, usually closer to the work, was responsible for fixing it. I owned incident management and asset management myself; our CEO owned project management.

We ran the remediation as a programme in spring 2023, with a dedicated project per risk area:

  1. Supplier management
  2. Asset management
  3. Business continuity and disaster recovery
  4. Incident management
  5. Project management and a corporate PMO
  6. A “rest list” project that closed every smaller gap the others did not cover

The programme ran on short, visible milestones. All projects were staffed and scoped by the end of April, a minimum viable scope was delivered in May, and phase one closed at the end of June. On 19 June 2023 we signed off version 1.0 of our Statement of Applicability, which became the reference document for the audit.

We were deliberately cost-conscious. Where we already owned a tool or a method, we reused it. The PMO, for example, was built on the project model and portal we already had, not on new software.

People and culture: making it part of the day job

A management system that lives in a document library does not survive its first audit. Auditors interview people, and people answer honestly. So the work had to show up in how teams actually operated.

In practice that meant a few unglamorous things. Mandatory security training for everyone, not just engineers. Incident handling that followed the same steps whoever was on call. Supplier reviews built into procurement rather than bolted on afterwards. And a corporate PMO that gave every internal and external project a clear owner, a risk log and a follow-up rhythm.

The ISO work also gave cover to structural IT improvements we had wanted for a while. During 2023 we moved all authentication to a single cloud identity platform, closed down legacy on-premise infrastructure, rolled out centralised patch management, and raised our endpoint security score by 40 to 60 percent. None of these were done “for the auditor”, but the certification deadline made them happen faster.

The certification audit

Our initial certification audit was run by DNV in September 2023, against ISO/IEC 27001:2013. It covered our headquarters in Solna and our other sites, and it tested two things: does the management system conform to the standard, and does it actually work in day-to-day operations?

DateMilestone
Sep 2023DNV initial certification audit, headquarters and sites
19 Jun 2023Statement of Applicability v1.0 signed off
30 Jun 2023Remediation programme phase one closed
May 2023Minimum viable scope delivered across all risk projects
Apr 2023All ISO projects staffed, scoped and running
Nov 2022ISMS procedure v1.0 approved by the CEO

The audit week itself was intense but rarely surprising. That was the point of the preparation: by the time the auditor asked a question, the answer already existed in a process someone owned. We came out certified, with findings we could work on rather than findings that stopped us.

What I would tell another software company

Get the CEO’s signature first. Not on the certificate, on the first procedure. Everything after that becomes easier to prioritise.

Scope for your customers, not for the audit. A narrow scope is cheaper to certify and worth less to the people you are certifying for.

Put two names on every risk. An executive who is accountable and a doer who is responsible. Risks without owners do not get treated.

Run it as a programme with short milestones. Monthly decision points kept momentum and made slippage visible early.

Reuse before you buy. Most of what we needed, we already had. The gap was ownership and discipline, not tooling.

Treat certification as the start line. The certificate proves you built the system. Keeping it alive is the harder part, and that is the subject of my next post.