There is often a question asked online about whether you can start your risk framework or ISMS on spreadsheets. I'm going to argue that you should. Not as a compromise, and not because tools are bad, but because if you're new to this a spreadsheet is a more forgiving tool. So the question is not whether you can certify that way. It is when, if ever, you need to stop.
The reason is specific; a spreadsheet lets you express messy thinking. You can leave a field blank, put text where a number was expected, or anything else you need to do to get your thinking onto the page.
Early on that is the whole point. Your first pass is a learning process. You know you patch things. You do not yet know who owns it, how often you are willing to claim you do it, or what you would put in front of an auditor. A platform will often push you to decide before it will save the record, so you either stall or invent an answer to clear the validation. The invented answer is what you get tested against a year later.
The tricky part of ISO 27001 is not storing information. It is deciding what the information should say, which is messy creative thinking. No tool does that for you, and the tools that try to help by handing you a control catalogue can by accident limit your ability to see what is really going to fit and work for you.
So: start in a spreadsheet, structure it deliberately. Here is the shape.
What an ISMS has to get right
Most people reading this will be looking at either an ISO 27001 or a SOC 2 process, so I'm going to spend a bit of time on what decides whether you pass those audits and, more importantly, whether you end up with a control set that does anything useful. Three things matter, and none of them is a tooling problem.
Management commitment, demonstrated. Not a signed policy statement. Whether decisions actually get made: risks accepted by the right person with the authority to accept them, resources allocated, the management review held and producing outcomes rather than minutes. An auditor tests this by asking what changed as a result. If nothing did, the system is purely performative compliance theatre.
Policies you actually follow. Write down what you do, then do it. The common failure is the downloaded forty-page template promising quarterly disaster recovery tests nobody will run. Auditors test what the policy says, and an aspirational policy generates findings worse than a missing one — you may find yourself with audit findings forcing you to do things you never wanted or felt were needed. A short policy you honour beats a comprehensive one you do not. I have written policies less than a page long and been complimented on them in audits.
A visible improvement cycle. The standard expects you to find problems, act on them, and show the loop closing. This is the criterion most first-time ISMSs are weakest on, because it cannot be produced retrospectively. It needs a record of things found, what was done, and what changed as a result, accumulated over time.
That is why the tooling question is genuinely secondary at this stage. You need clarity and the ability to find records quickly. A tool can help with that, but it is by no means essential.
Keep the risk register small
Ten to fifteen risks. Twenty at the outside.
A register is a management tool. Think of it as notation for explaining management judgement rather than a forensic inventory. A risk earns its place by changing something: a decision, a priority, or a control you would otherwise struggle to justify.
The two-hundred-row register is pointless. Every row needs reviewing on a cycle you will not keep, and it is now so busy that you cannot see the wood for the trees.
What makes a short register defensible is what sits behind it. Two artefacts, one tab each.
A methodology note. How risks are identified, who contributes, on what cycle, how they are scored, what your criteria are for accepting one. Half a page. It exists so that "how did you arrive at these" has an answer.
A taxonomy. The categories you considered. This is the coverage argument. Asked why something is missing, you point at the taxonomy: we swept that category, here is what came out of it, here is why nothing rose to the register. A good tool will likely ship with a taxonomy or set of risk classes to help with this, but you can find these online as well.
The auditor's real question is what makes you confident you have not missed something material. A short register with a documented method and a visible taxonomy answers that. A long one does not.
Then stop. The risk model is small and cheap. The year goes elsewhere.
Control design should be the bulk of the work
Most of your effort belongs here, and most first attempts are too thin to survive an audit.
Different organisations define a control in slightly different ways. The broadest will be along the lines of "any action taken to reduce risk"; I prefer a more focused "the set of decision points within the organisation that control risk". The first would lead to a control such as "anti-virus is installed", the second to "anti-virus reports are reviewed by X". Both are valid. I just find the second structure helps you think through whether the control is actually going to make a difference.
An easy trap is to take the names from a standard and treat those as a definition. "Access review." "Patch management." "Supplier due diligence." Those are labels. They give a topic, not what happens, when, or who is on the hook.
You can structure this repeatably using the old news-reporter checklist, reordered because it reads better for controls: what, when, where, who, why. Then, in the same definition, what evidence this leaves and where it lives.
[What] security patches are deployed [when] within 48 hours of vendor release [where] on all servers and end-user devices [who] by the automated patch management system [why] to reduce the likelihood of exploitation of known vulnerabilities.
Evidence: weekly patch compliance report, exported to
/isms/evidence/PR-06/.
The structure forces three things. You cannot fill in who without settling ownership, which is the internal conversation most teams postpone. You cannot fill in when without committing to a frequency you will be measured against. And you need to work out what records you can and will generate while running the control, which is ultimately what will pass or fail an audit.
Approval and review controls: the most common gap in evidence
Take any control where one person is looking at something and saying yes or no. Quarterly access reviews. Monthly reconciliation sign-off. Supplier payments above a threshold. Change approvals. Exception approvals.
They are critical controls, they read well on paper, and without thought at design time they can be miserable to evidence. The reviewing genuinely happens; the approval leaves nothing behind. Someone pulls the list, walks over to the Finance Director, they talk it through, two people get removed. Or it happens in a Teams thread that scrolls away. The control operated and you cannot show it.
A typical first draft:
Management reviews user access on a quarterly basis.
True, and untestable. It names no system, no reviewer, nothing to review against, and no outcome.
The same control through the template:
[What] access rights for all named users of the finance system are reviewed and either confirmed or revoked [when] quarterly, within ten working days of quarter end [where] across all roles, including service and shared accounts [who] by the Finance Director, working from a user list exported by IT [why] so that people who have changed role or left no longer hold access they should not.
Evidence: the exported user list, dated, annotated with a keep or remove
decision against every line, signed off by the Finance Director, saved as PDF to
/isms/evidence/PR-04/; plus service desk ticket references for any removals.
It is longer because writing the evidence line forced three unmade decisions: the review needs an artefact, the artefact needs a decision against every line rather than a general blessing, and removals need to be traceable to something showing they happened.
If you cannot name the artefact, you have learned something, and cheaply. Either the control does not operate as you think, or it needs changing so that it leaves a trace. Both are fine outcomes in month two. But saying "we do this, we just can't show it" is a painful way to fail an audit.
Evidence definition is part of control definition, not a downstream problem. It is a design review that catches your weakest controls before anyone else does.
Naming and filing
Give every control a stable identifier and make the folder structure match it.
The ID is an identity, not a mapping. Keep A.8.9 out of the
control's name. Put it there and the control belongs to one framework; re-tagging later
means renaming it in the register, the evidence tree, and every document that references
it. Mapping is a relationship. It lives in a column.
A domain prefix plus a sequence is enough. If the prefix should carry
meaning, borrow top-level domains from a framework you are not certifying against, so they
stay stable. NIST CSF 2.0's functions work well: Govern, Identify, Protect, Detect,
Respond, Recover, giving GV-01, PR-04, DE-02. Annex
A themes work too. The prefix names a domain a human recognises; the number is a sequence
that does not move when the register is re-sorted.
Retire, don't reuse. A dead control's ID dies with it. Old evidence and old Statements of Applicability still need to resolve.
Then make the evidence tree the IDs:
/isms/evidence/PR-04/2026-Q1/2026-04-08-finance-access-review.pdf
/isms/evidence/PR-06/2026-W14/patch-compliance.xlsxFiling now takes no judgement, which is the only reason it will happen. Retrieval during an audit becomes mechanical, not a search: four quarters of access reviews is one folder.
This is the dullest section here and the one that most changes how a certification audit feels.
Compliance mapping and the Statement of Applicability
For a single framework this is not the hard part, whatever the tooling vendors imply.
Tag each control to the requirements it addresses in a column. Build the SoA from that with lookups, or a pivot if one control carries several tags. It will not be elegant. It does not need to be.
Two things matter more than elegance. Every Annex A control needs a position: applicable, or excluded with a justification. Exclusions can be entirely reasonable and auditors read them as such; vague ones lead to a debate mid-audit.
And produce a dated PDF of the SoA for every audit, then keep the old ones. The SoA is a point-in-time declaration. Live in a spreadsheet only, it cannot show what you declared eighteen months ago, which is precisely what a surveillance visit asks for.
Continual improvement is essentially action tracking
Corrective actions, findings and improvements go in a queue, and whatever workflow tool you already have is fine. Jira, ServiceNow, a kanban board, another tab in the spreadsheet.
Every action needs an owner, a date, and a reference back to whatever caused it: the risk, the control, the audit finding, the incident. Asked what you did about a weak control, you follow the reference from the control to the actions raised against it, to the dates they closed, to what changed. Actions floating free cannot do that, and a queue full of them just doesn't cut it.
What are the limits of spreadsheets?
Three things break a spreadsheet risk framework. None is the reason usually given.
More than one person editing the control set. The tolerance for blanks and free text that makes a spreadsheet good for drafting is what fails under multiple authors. Consistency is entirely manual. Two people fill the same field differently, someone overwrites someone else's row, and the register drifts into something nobody trusts. Spreadsheet ISMSs work best with a single author. That holds until you want control ownership pushed out into the business, which you should want, because control owners are the people whose behaviour the ISMS exists to change.
A second or third framework. One standard, one tag column. Add SOC 2, PCI, Cyber Essentials or NIST CSF and requirement tagging becomes many-to-many, which a flat sheet models badly. You either duplicate control definitions per framework, splintering the control set and multiplying audit work, or you maintain tagging logic one person understands.
Action volume. The improvement cycle is the point of the thing, so if the ISMS is working, actions accumulate. Each one carries references to risks and controls that nothing validates and nothing updates. Cross-referencing that was a typed column at fifty actions is a synchronisation workload at five hundred, and the first symptom is that people stop maintaining the references rather than stop raising the actions. At which point you still have the queue and you have lost the evidence of the loop.
The commonly cited breaking points are survivable. Version control is a folder structure and some discipline. Reporting is a pivot table. Reminders are a calendar entry.
These three are structural. At that point you need something that models how risks, controls and actions relate, and holds the data consistent without relying on everyone remembering the formatting guidance.
Until then: define the controls properly, name the evidence, file it where the name tells you to, and keep the register short enough to actually review. Above all, make sure you are writing controls that will actually work for you, not copying them from a template because they sound good on paper.
What to do when you've outgrown spreadsheets
The work above does not go to waste. Control definitions written to the what / when / where / who / why shape, a short register with a method behind it, and an evidence tree keyed to control IDs are exactly what a platform needs on day one, and they are the reason a migration takes days rather than months. If you skipped that work and bought a tool instead, this is the point where you find out.
What you are looking for is not compliance automation. It is something that models risks, controls, actions and evidence as related objects, so the cross-references maintain themselves and several people can author without standing on each other. That is what I built RiskQuilt to be.
The quickest way to judge whether it fits is the MCP walkthrough, which shows the whole risk model being queried and updated in plain language using your own AI assistant. If your spreadsheet is still working for you, keep it. When it stops, you will know which of the three reasons it was.
Tom Whipp is the founder of RiskQuilt. He spent around thirty years in cyber and technology risk in UK financial services, including CISO and Director of Technology Risk roles.