A security assessment before ISO 27001: measure first, then build

The enquiry reaches us almost always in the same week as the email from the key account. Attached, a supplier questionnaire with several dozen items, and somewhere in the cover text the sentence "We expect our partners to operate an information security management system in line with ISO 27001". And then, on the phone, the question we understand well: "What does the certificate cost, and how fast can we get it?"

It is the wrong first question, because at that moment something more basic is missing: Nobody in the company knows where it stands. That is exactly what a security assessment before ISO 27001 is for. Measure first, then build.

The reflex the questionnaire triggers

What typically happens after such a customer email follows a remarkably stable sequence. First, a project is set up, with a deadline, because the customer named one. Then an ISMS tool gets evaluated, because the vendors promise it will speed up certification considerably. And in parallel, someone orders a set of policy templates so that documents exist quickly.

All of that is understandable. The pressure is real, and so is the deadline. But this order turns the project upside down. An ISMS describes how your company deals with its information risks. Whoever builds one without knowing their own starting position describes a company that does not exist. The templates do not match your processes, the tool manages controls that nobody operates, and the auditor notices both.

The trigger is not always a customer, by the way. Since the Swiss Information Security Act (ISG) started requiring an ISMS from operators of critical infrastructure, the same reflex also comes from regulation. The questionnaire is then called a law, but the mechanics are the same. Whether you fall under this obligation at all is something we sorted out in our post on the ISG ISMS obligation 2026.

The problem is almost never a lack of motivation. It is a lack of local knowledge. You can only plan a route once you know the starting point, and in information security, in our experience, the starting point is never where gut feeling assumes it. In both directions.

What is already in place, without anyone ever writing it down

Here comes the part that surprises most managing directors, in a good way. In our experience, a Swiss SME with a working IT setup has considerably more information security than it believes. The backups run and were even tested after the last server migration. Multi-factor authentication has been mandatory since the cyber insurance policy. The MSP contract covers patching and incident handling. When employees leave, there is a checklist that HR does use.

None of this is called an ISMS. Much of it is documented nowhere. But it exists, it works, and it is a substantial part of what ISO 27001 requires.

An assessment makes exactly that visible. It answers the question "What do we already have?" before anyone asks the question "What do we need to buy?". That changes the project noticeably: "We need to build an ISMS" becomes "We need to document what exists and close what is missing". The second is smaller and more honest than the first.

There is a flip side, and it belongs to the same exercise: Some things everyone relies on do not survive a closer look. The emergency plan that still lists the names of two people who left. The admin account of the former apprentice that was never deactivated. That, too, ends up on the map, and it does so before the auditor or someone less friendly finds it.

Gaps sorted by risk, not by standard chapter

You can also do the baseline purely formally: take the standard, query control by control, tick boxes. The result is a gap analysis against ISO 27001, and it has a built-in flaw: It prints all gaps at the same size.

On such a list, the missing screen lock policy sits right next to the missing access concept for the ERP that your entire production hangs on. Formally, both are deviations. For your company, there is an abyss between them.

A security assessment, as we understand it, therefore starts not with the standard but with your business: Which processes must not stand still, which data must not leak, and where are you vulnerable on those points? Only then does the standard come in as a grid on top. The result is the same list of gaps, but with a ranking that comes from your risk instead of the chapter number. The first measures then reduce risk instead of only raising the compliance score.

For clarity: An assessment is not a penetration test. The pen test checks technically whether someone can get in. The assessment checks whether your company is organisationally and technically set up the way it believes it is. We took apart what makes sense when in our post Security assessment vs. penetration test.

On the process, because people often have the wrong picture in mind: A baseline of this kind is not a months-long project, and it installs nothing in your systems. It consists mostly of conversations with the people who do the work, of a look into configurations, contracts and the existing documentation, and of matching all that against what your business needs. At the end stands a report that gives management and IT the same picture, with a prioritised list instead of one standard citation per line.

The scope: the biggest lever, the earliest decision

There is one decision in the whole ISO 27001 project that determines effort and cost more than any other: the scope. Do you certify the whole company or the part that is relevant to your customers? We described in our post on the cost of ISO 27001 why the scope is the real cost lever.

The catch: This decision falls right at the beginning, and it requires exactly the knowledge an assessment delivers. Which systems and teams are involved in the service your key account buys? Where do the boundaries run cleanly, and where would too narrow a cut look artificial? Whoever sets the scope from gut feeling either certifies too much and pays for it for years, or too little and fails with the customer who reads the certificate closely.

With a clean baseline, the scope goes from a bet to a decision. That alone saves more in many projects than the assessment costs.

How to read the result without going shopping

A word on the effect of such reports, because this is where it is decided whether the exercise pays off. An assessment report with thirty findings triggers the same reflex in many recipients as the customer questionnaire at the start: the urge to procure something quickly so the list gets shorter.

A second look at the nature of the gaps is worth it. In our experience, the majority of them are organisational: unclear responsibilities, missing rules, procedures that were never tested, knowledge that exists in one head only. No product closes gaps like these. They cost working time and decisions, but rarely new licences. A report that mainly triggers purchases was read wrongly, or it was written by someone who wants to sell you something.

And yes, sometimes a purchase does stand at the end. If a relevant risk is open and no existing tool covers it, procuring is the right answer. As the last answer, after checking what you already have. Not as the first. What an ISMS looks like that works with what exists rather than against it is in our post on building a pragmatic ISMS.

When you can skip the exercise

For completeness: There are cases in which a separate assessment adds little. If you did a clean baseline in the last twelve months and it still holds, work with that. If your parent company operates a certified ISMS and your site is meant to be absorbed into it, a different question arises, namely the one about integration.

And if the customer does not demand a certificate at all, only a completed questionnaire, sometimes exactly that is enough: fill in the questionnaire honestly and attach an action plan to the two or three uncomfortable answers. We have recommended that as well, even though it is the smaller mandate for us. An assessment is a tool, not a ritual.

First the map, then the route

Back to the company with the questionnaire. The answer to the key account that holds up, in our experience, is not the hasty promise of "certificate by next summer". It is a plan with substance: This is where we stand, backed by an external baseline. This is our scope, this is how we close the relevant gaps, in this order, by this date. A procurement officer who evaluates suppliers can work with an answer like that. He cannot work with a promise that has nothing underneath it.

This order costs a few weeks at the start. It earns them back several times over, because the project then runs on facts instead of assumptions, and because nobody builds controls that already exist or certifies things no customer has asked for.

If a questionnaire like that is sitting on your desk right now and you want to know where you stand before anyone sets up a project: Baselines like these are exactly what we do. A first conversation is non-binding.

By the way, the same thing interests us first every time: What already runs smoothly at your company without anyone ever having written it down?