An ISMS can be certified and still be dead. The binder is full, the policies are signed, the internal audit was uneventful. Then a customer asks in the walkthrough about the last risk assessment, and the room goes quiet. Whether you have a living ISMS or a paper ISMS shows in the moment somebody from outside asks a concrete question.
We see both kinds in mandates. The paper ISMS is not a sign of laziness. It almost always comes out of a wrong objective: the certificate or the ticked-off audit point was the project goal, and the operation afterwards was nobody's job any more.
You recognise a living ISMS by three things. Risks are discussed where decisions are made. Measures have an owner and a date. Incidents change the system. Everything else is documentation. A lean ISMS that runs beats the thick one in the binder in every customer audit and in every incident.
How do you recognise a living ISMS?
A living ISMS can answer questions without preparation. The risk register carries a date from this quarter. Every open measure has a name and a deadline. The management team can name the three biggest risks without looking them up. And the last incident demonstrably changed something, a rule, an ownership, a technical setting.
The difference can be pinned down with a few questions:
| Question | Paper ISMS | Living ISMS |
|---|---|---|
| When was the risk register last updated? | Before the last audit | In the current quarter |
| Who is accountable for the top risks? | "IT" or the external consultant | Named people from the line organisation |
| What did the last incident change? | Nothing, it appears in no minutes | A concrete adjustment with a date |
| Does management know the status of the measures? | Once a year, before the audit | From the last steering meeting |
What is striking is what is missing from this list: the number of policies, the page count of the security concept, the tool everything is documented in. None of that says anything about whether the system works. An auditor who knows the craft asks exactly the questions in the left column. These questions take thirty seconds to ask and, in a living ISMS, thirty seconds to answer.
Why do paper ISMS happen at all?
Because most of them are built for the auditor, not for operations. A consulting project delivers templates, the organisation fills them in, the certificate arrives, the project ends. From that day the ISMS has no owner. What remains is a set of documents resuscitated briefly each year shortly before the surveillance audit.
On top comes a sizing problem. Many SMEs adopt templates written for large corporations: thirty policies, a role model with committees that do not exist in the company, processes for cases that never occur. With 120 employees nobody reads that. A system nobody reads is a system nobody can live.
The standard is innocent here. ISO 27001 explicitly requires a management system in a cycle: assess risks, treat them, review, improve. So, operations. A dead ISMS does not over-deliver on the standard, it falls short of it, which rarely shows in the certification audit because samples are checked there and the organisation prepares. Customer audits are less comfortable. There somebody asks who wants to know whether they can trust you with their data, not whether a chapter of the standard is formally covered.
Fewer documents, more operation
The obvious reflex with a dead ISMS is a new project: rework everything, document it again, properly this time. In our experience the opposite is true. Most paper ISMS do not have too little substance, they have too much mass. The road back to life runs through deletion.
This is the same logic as with security tools: more protection, fewer tools, lower cost. An ISMS with eight policies everybody knows, a risk register with fifteen real risks and a fixed monthly rhythm protects better than forty documents nobody opens. Sizing beats completeness.
The target picture is an inventory that fits the organisation: so few policies that everybody knows them, a register with risks that can trigger a decision, processes for cases that actually occur. What remains is short enough for a new employee to read in their first week, and concrete enough that they then know what to do when something looks wrong.
The bottleneck is called accountability
Behind almost every paper ISMS sits the same gap: there is nobody whose job the operation is. Framework, tools and budget are usually in place. What is missing is a person with a mandate and time who keeps the risk register current, chases measures and shows management the status regularly.
In an SME this role usually lands with the IT lead, on top of a full day job. That works exactly as long as nothing else is on fire, so rarely for long. Management in turn gets no numbers, therefore does not ask, and without being asked the topic slides down every priority list. No decision abolishes the system. It stops being a topic, and that is enough.
So the first question with a stalled ISMS is a leadership question: who owns the system, how much time does that person have for it, and who asks for an account regularly? Whether the answer is an internal owner with a clear time budget or security leadership on a mandate is secondary. Without an answer, every rework stays another project with an expiry date.
An example from practice
A Swiss supplier, around 150 employees, ISO 27001 certified for two years. The trigger for the mandate was a customer audit, not an incident: a major customer wanted to see the last risk assessment in the walkthrough. The most recent entry was fourteen months old, the responsible employee had left the company, and the quarterly security round described in the concept had never taken place since certification. The certificate hung framed in reception. The customer renewed anyway, but demanded evidence of ongoing operation within six months.
The solution was unspectacular. The risk register was cut from around 60 entries to 18, every measure got a responsible person and a deadline, and the security round was integrated as a fixed item into the existing management meeting instead of being run as its own committee. No new documents were written and no new tool was bought, the inventory just got smaller and more binding. At the follow-up audit the question about the last risk assessment was answered in two minutes. Not because somebody had prepared, but because the answer was on the table anyway.
How much effort does a living ISMS need per month?
Less than most people fear. In our experience a few hours per month carry an SME ISMS: a steering meeting with management, a maintained risk register, a look at open measures and incidents. The ongoing operation is not the expensive part. The expensive part is the resuscitation, when the system has lain still for twelve months and an audit is due. Then somebody works two weeks in crisis mode on something that would barely have been noticed spread across the year.
The rhythm matters more than the volume. A short, fixed appointment that actually happens beats the big annual exercise. That is why we build mandates around a monthly steering meeting and a quarterly report to the board, not around document deliveries. What building an ISMS costs beforehand and how long it takes is written up in our article on ISO 27001 in an SME: effort, duration and cost.
What this means for the ISG and customer audits
The Swiss Information Security Act makes the difference between paper and operation more visible. By the end of 2026 organisations subject to the ISG need a working ISMS, and for operators of critical infrastructure the duty to report cyber attacks to BACS within 24 hours has applied since April 2025. Reporting within 24 hours assumes somebody detects incidents, assesses them and knows who reports. That is in no binder, that is operation. Who is affected and what is realistic in the remaining months is in our article on the ISG ISMS obligation by the end of 2026.
Customer audits pull in the same direction. Questionnaires can be answered with documents, walkthroughs cannot. In our experience auditors from major customers increasingly want to see not the concept but the last steering meeting, the current register, the incident that was handled. A living ISMS answers these questions as a by-product. A paper ISMS turns every customer audit into a project of its own, with preparation weeks nobody budgeted and a residual risk no document catches: that somebody answers a question honestly in conversation.
Frequently asked questions
Is a certified ISMS not automatically a living ISMS?
No. A certification audit checks samples at an announced point in time the organisation prepares for. An ISMS can pass that review and still stand still in daily work. That usually only becomes visible in customer audits or during an incident, meaning when it counts.
Should we rescue our paper ISMS or start over?
Almost always rescue it. The documents are rarely the problem, usually there are too many of them. Cutting, naming owners and introducing a fixed rhythm is considerably faster than a rebuild. An existing certification does not stand in the way, as long as the standard's requirements stay covered, and leaner documents tend to make the next surveillance audit easier.
Can we outsource ISMS operation completely to a provider?
The rhythm and the method yes, the accountability no. An external partner can run the steering meeting, the register and the reporting, and often does so more reliably than an overloaded line organisation. But the system is lived where the work happens: your own organisation implements the measures, and management stays the party that asks for an account.
You probably already know whether your ISMS is alive, otherwise you would not have read this far. The road from paper to operation is shorter than the road from zero to paper, because most of the material is already there. What such an entry looks like, from the first conversation to full operation, is shown in the course of a mandate on the homepage.