Build an ISMS Without Spreadsheets

How it works today in most organizations

The starting point is almost always the same. Someone transfers the requirements into a spreadsheet – either the controls from Annex A of ISO/IEC 27001 or the modules of BSI IT-Grundschutz. The result is a file with more than 90 rows, usually called "ISMS_Controls.xlsx" or "Action_Plan_ISMS.xlsx", with columns for requirement, implementation status, comment and – if things go well – a responsible person.

The action plan sits on the second worksheet: revise the password policy, review permissions in the ERP system, update the business continuity plan, reassess service providers. The evidence is somewhere else again – in a folder on the file share, sorted by chapter number: "05_Organizational_Measures", "08_Technical_Measures". Inside: screenshots, configuration extracts, signed policies as PDF and the occasional printed email proving that an approval really was granted.

That is a reasonable start. A spreadsheet is available immediately, costs nothing, anyone can work with it, and for a first inventory it is the fastest tool available. The split makes sense too: assessment, measures and evidence come in different formats. The difficulties therefore do not arise during the build – they arise in operation.

Because a management system is not a document written once. It is a cycle: assess, derive measures, implement, provide evidence, assess again. That cycle is exactly what does not happen in the spreadsheet. Between two audits nothing happens there, because nothing and nobody sends a reminder. A server is replaced, a line-of-business application is added, a department is outsourced, two-factor authentication is finally rolled out – and the row in column C still says "partially implemented", because nobody opens the file when no appointment is due.

The moment it becomes visible

It shows up in three situations: when the internal audit is due, when a certification or surveillance audit has been scheduled, or when a customer asks about the state of the ISMS during a supplier review. Then a week of copying together begins: the spreadsheet worked through row by row, the folder searched for matching evidence, the statement of applicability updated from a third file, the action plan cleared of deadlines that passed long ago. Anyone who has lived through that week knows the point at which nobody can say for certain whether a piece of evidence still holds or is merely old.

The auditor's question, however, is not "Do you have a list of controls?" It is: "Show me the current evidence for A.8.16, the associated measure, who owns it and by when it will be implemented." A spreadsheet has no answer – not for lack of diligence, but because it structurally knows nothing about the connection between requirement, evidence, measure and deadline.

The target process in six steps

A workable ISMS differs from a control spreadsheet not by holding more content, but by a process that keeps running when no audit is due. These six steps describe it – whatever tool you work with.

1. Adopt the existing status instead of reassessing it. The spreadsheet you have is the basis. Implementation status, comments and justifications are mapped onto structured fields rather than collected a second time. Whatever is documented stays.

2. Activate a requirement catalog instead of maintaining rows. The requirements come from a ready-to-use catalog – for ISO/IEC 27001 and SiKoSH; for BSI IT-Grundschutz, CISIS12 and VdA ISA there are finished audit catalogs (optional, subject to a fee). Manual retyping of the standard text is gone, and the structure stays comparable for years.

3. Keep assessment, applicability and exclusion in one place. Every requirement gets an implementation status and a maturity level. Applicability, reason for inclusion and the justification for an exclusion are recorded on the requirement itself and feed into the statement of applicability (SoA). A third file is no longer needed.

4. Store evidence on the object. Evidence belongs on the requirement, not in a folder. It is uploaded directly or requested by link from whoever can supply it; expiring evidence is checked automatically. Evidence covering several requirements is stored once and linked several times.

5. Give measures an owner and a deadline. A deviation becomes a measure with a responsible person and a due date right away. The action plan is no longer a worksheet but a work list – and each user group sees only the requirements, tasks and deadlines assigned to it.

6. Assess on a recurring basis instead of catching up when prompted. Follow-up dates schedule the next review, the cockpit shows the degree of fulfillment as a heat map, list or board, and regular snapshots make the development over time visible. The cycle runs without anyone keeping it in mind.

Why data protection and information security belong together

preeco | data protection and preeco | information security share one platform. License both products and you work on a shared data set, switching between the two views with a toggle. That is not a sales argument but a maintenance argument: assets and data processing systems, technical and organizational measures and employee training are maintained once, not kept twice.

In the spreadsheet world this is the second major source of error. The data protection systems list and the information security asset list describe the same servers, cloud services and providers – only at different states. When a provider is replaced at the latest, someone has to change both files. Usually nobody does.

Before and after in direct comparison

What the switch means in practice

The most common objection is that the ISMS would have to be assessed from scratch. That is not the case. The existing assessment is adopted, mapped onto structured fields and supplemented where the spreadsheet had nothing to offer anyway: ownership, deadline and evidence. Those gaps are the actual gain – they become visible before an auditor makes them visible.

The effort rarely lies in the technology, but in clarifying the substance: who owns which requirement, which asset is actually behind it, and which evidence is still valid. That work is due in any case – in the spreadsheet model it is merely bundled into the week before the audit instead of spread across the year.

Three mistakes that make the switch harder than it needs to be

Wanting to start with the complete catalog. Begin with the requirements flagged in the last audit and with those that already have evidence. The rest follows in the regular cycle, not in one great effort.

Leaving the evidence in the folder. Moving the assessment into a system while the evidence stays on the file share only relocates the spreadsheet logic. Evidence on the requirement is the point at which audit preparation actually becomes shorter.

Leaving the departments out. An ISMS that only the information security officer maintains stays as fragile as before – just in a different interface. Only distributed ownership makes the cycle independent of individual people.

How to tell that it is time

A control spreadsheet is not a mistake. It becomes a risk once at least one of these points applies:

• The implementation status has not been touched since the last audit.
• You cannot show the matching evidence for any given requirement within a minute.
• The statement of applicability differs from the list of controls.
• The action plan contains deadlines that have passed without anyone following up.
• A certification, a surveillance audit or a customer review is coming up.

If none applies, the spreadsheet is fine. If two or more apply, it is already working against you.