Security foundations before ISO 27001
Certification is a statement about your system of management. Most companies need the system a good deal earlier than they need the statement.
Nearly every founder who asks us about ISO 27001 is really asking about something else. They have a deal in the pipeline, a buyer has asked whether they are certified, and certification looks like the object standing between them and the revenue. It rarely is.
ISO 27001 certifies that you operate an information security management system: that you have decided how you manage security risk, written it down, and can show you follow it. The certificate is a statement about that system. You need the system before the statement is worth anything, and most companies discover the hard way that building the system is the work and the audit is the receipt.
What a buyer is usually asking
Procurement asks about certification because it is a cheap proxy. It is one question that stands in for forty. When a company cannot answer it, the sensible response is to answer the forty directly — which is entirely possible, and much faster than a certification cycle. We have written about how that conversation actually goes in passing enterprise procurement without a big ops team.
What sits behind the proxy is a small number of things a buyer genuinely needs to believe: that you know what data you hold, that not everyone can reach all of it, that changes to your systems are deliberate, that you would notice a problem, and that somebody is accountable when one happens. A company that can evidence those five will clear most reviews without a certificate. A certified company that cannot will struggle in the follow-up questions.
The foundations worth building first
In rough order of how much they buy you:
- Know what you hold and where. A written record of the data you process, which systems hold it, and which of it is customer data. Not a formal register — a page that is true. Almost everything else depends on it.
- Identity and access. Single sign-on, multi-factor authentication, and a real answer to “who can reach production, and who removed them when they left?”. Joiner and leaver steps that someone actually performs are worth more than a policy describing them.
- Change control that engineers will keep. Reviewed changes, a deployment path that is the only path, and separated environments. If the control makes shipping meaningfully worse it will be routed around, and a routed-around control is worse than none because it makes you believe something untrue.
- Logging you would actually look at. Enough to reconstruct what happened, retained long enough to be useful, in a place where an attacker with one set of credentials cannot quietly edit it.
- A supplier list. Every third party touching customer data, what it touches, and who owns the relationship. This one is nearly free and comes up in every questionnaire.
- An incident response plan short enough to be read during an incident. Who to call, who decides, who tells the customer, and where the plan is when the systems it describes are down.
A modest control that is written down, owned and followed clears review faster than a better one nobody can describe.
Why this order
Because each one makes the next cheaper. A certification effort started without a data inventory spends its first month building a data inventory, at consultancy rates, under audit pressure. And because these controls reduce real risk on the day you put them in, whereas a certificate reduces risk only insofar as it made you build them. If you are going to end up with the foundations either way, having them before the deal is worth more than having them because of it.
There is also a scale argument. At twenty people, run properly, most of this is a few weeks of deliberate work. At eighty, spread across more systems and more history, the same work is a project with a budget and a steering group.
When certification becomes the right next step
When it is being asked for repeatedly by buyers you intend to win, when the sales cycle cost of answering the forty questions each time exceeds the cost of the certificate, or when a regulator or a partner requires it. At that point you are certifying a system that already exists, which is a shorter and far less painful exercise than it is usually described as.
To be clear about what we are: Groundwork is not a certification body and does not audit or certify anything. What we do is build the security and evidence foundations, and get a company into the state where an audit is a formality rather than a discovery exercise — see startup security and risk for how that work is scoped. Certification itself is done by an accredited body, and it should be.
