Why the ISO 27001 supplier register decays
Every company going through ISO 27001 builds a supplier register. Most of them build it twice: once for the certification audit, and again a year later when the surveillance audit is three weeks away and nobody can remember who added the twelve new tools. The register was accurate on the day it was finished and has been drifting ever since.
That's because a SaaS supplier register is a list of things that change weekly. Cledara data shows the average company on the platform paid for about 35 software tools in the last twelve months, with a quarter of companies above 48, and new tools arrive the way they always have: someone needs one, someone pays for it, and the register finds out later, if at all. One prospect our team spoke to recently had 117 tools in a Notion database kept purely for ISO 27001, and described keeping it current as a thankless job. Fair enough.
Key takeaways
- Five ISO 27001:2022 controls (5.19 to 5.23) depend on a current supplier register, and auditors expect in-date contracts, in-date certificates and at least annual reviews for each supplier.
- Every SaaS and AI tool that stores, processes or transmits your data is a supplier, so a 35-tool company has a 35-row register before it adds a single consultancy or data centre.
- Registers decay because the trigger that adds a row (a payment or a login) is disconnected from the document itself.
- Make the payment the trigger, give every tool one owner, pull certificates rather than promises, and diff the register against real payments and logins each quarter.
- A register that is also your software list, with owners, renewal dates and access, stops being a document you rebuild and becomes something you simply keep.
What ISO 27001 actually asks of your supplier register
The 2022 edition of the standard puts supplier management in five Annex A controls. The names are a mouthful, but what they want from a register is quite plain.
| Control | Name | What it means for the register |
| 5.19 | Information security in supplier relationships | A policy for how you manage supplier risk, and a record of each supplier's risk level |
| 5.20 | Addressing information security within supplier agreements | Security requirements agreed with each supplier and written into the contract, with a copy you can find |
| 5.21 | Managing information security in the ICT supply chain | Your suppliers' own suppliers, which for SaaS usually means their hosting and sub-processors |
| 5.22 | Monitoring, review and change management of supplier services | Regular reviews, typically annual, recorded against each supplier, and reassessment when a service changes |
| 5.23 | Information security for use of cloud services | A policy for cloud use, a risk assessment before you sign, and management acceptance of any residual risk |
Control 5.23 is the one that matters most for SaaS, because almost everything a modern company buys is a cloud service. According to ISO guidance summarised by DQS, agreements should cover confidentiality, integrity, availability and information handling, and any residual risk must be formally accepted by management. In practice an auditor wants to see, for each supplier that touches your data: what they do for you, what data they hold, whether there's a contract with security clauses, whether they hold a current certificate, when you last reviewed them and when you'll review them next. Hightable's guide to the ISO 27001 supplier register puts the review expectation at least annually, and more often for high-risk suppliers.
None of that is hard for ten suppliers. It's hard for 50, when a third of them were bought on a card by someone in marketing.
Why SaaS makes the ISO 27001 supplier register hard
Traditional supplier management assumed a procurement step: someone negotiated a contract, so someone knew the supplier existed. SaaS removed the step. A tool can be in use, holding customer data, for a year before anyone outside the team that bought it knows. Jenny Liu, Head of Finance at Marshmallow, has said that connecting Cledara Engage immediately captured 15% more subscriptions her team hadn't heard of. Those tools were all suppliers under 5.19 the whole time.
Then there's ownership. The person who bought the tool is the only one who knows which plan it's on and what data went into it, and they change jobs. One finance team our team spoke to this month could access the admin settings of about one in ten of their applications; the rest sat with people who had moved on or didn't see compliance as their problem. A register can't be reviewed by someone who can't get into the tool.
And there's churn. Tools get replaced, consolidated and cancelled. Cledara data shows that a quarter of companies on the platform run more than 48 software tools, and at that scale a few change every month. A register that isn't connected to what's actually being paid for will be wrong within a quarter, and an auditor who finds one dead row will go looking for the live ones you missed.
An ISO 27001 supplier register template for SaaS
Keep it to the columns you will actually maintain. A twenty-column register is a register nobody updates. These twelve do the job for 5.19 to 5.23.
| Column | What goes in it | Why the auditor cares |
| Supplier | The vendor and the product (one row per product if they differ) | Identifies the relationship |
| Owner | One named person who can log in as admin | Someone has to answer the review |
| What it does for us | One line | Context for risk |
| Data held | None, internal, employee, customer, special category | Drives the risk score (5.19) and cloud policy (5.23) |
| Risk level | Low, medium, high | Sets the review frequency |
| Contract | Link to the signed terms, DPA and any security schedule | 5.20 |
| Security clauses | Yes or no, with a note on gaps | 5.20 |
| Certification | ISO 27001, SOC 2 or none, with the expiry or report date | Evidence for 5.22 |
| Sub-processors | Where it's hosted and who else sees the data | 5.21 |
| Renewal date | When the contract or subscription renews | The natural review date |
| Last review and next review | Dates, with who did it | 5.22 |
| Exit plan | How you get the data out and close the account | 5.23 and common sense |
Tip: the renewal date and the review date should be the same date. A renewal is the one moment you have bargaining power with a vendor and attention from the owner, so do the review then.
How to keep the ISO 27001 supplier register alive
The register decays because adding a row is a separate task from buying a tool. Close that gap and most of the maintenance disappears. Seven habits, in the order to adopt them:
- Make the payment the trigger. A new software payment creates a new row, automatically or by rule. If every tool is paid from one place, nothing can be a supplier without appearing on the list.
- Give every tool one owner. Owners do the reviews, hold the admin login and answer the questionnaire. When an owner leaves, reassigning their tools is part of offboarding.
- Classify data once, at purchase. Ask "what data will this hold?" in the software request form. It's the only moment the answer is fresh.
- Pull certificates rather than promises. Record the certificate or SOC 2 report with its date, and diary the expiry. "They said they were certified" is not evidence.
- Tie reviews to renewals. Set the next review date equal to the renewal date, and let the renewal reminder be the review reminder.
- Diff quarterly against reality. Compare the register to two sources: what was actually paid for, and what people actually logged in to. Anything in reality and missing from the register is a finding waiting to happen.
- Record exits. When a tool is cancelled, note the date, confirm the data was exported or deleted, and keep the row. Auditors like a trail.
Those seven habits are a system, and systems are easier to run inside software than inside a spreadsheet. Which is why many companies end up running the register inside the same tool that manages their subscriptions.
What to put in the supplier questionnaire
For anything above low risk, a short questionnaire answered by the owner (and, for the technical parts, the vendor) covers what the controls need. Cledara's Software Compliance module ships five templates that map neatly to the standard: the business case, product and service details, a risk assessment, a contract review and an exit plan. The questions that earn their place are:
- What data will the tool hold, and where is it hosted?
- Does the vendor hold ISO 27001 or SOC 2 certification, and when does it expire?
- Who are the sub-processors?
- Does the contract include security requirements, a data processing agreement and breach notification?
- How do we get our data out, and how is it deleted when we leave?
- Who in our company will be admin, and how is access granted and removed?
Note: don't send the full questionnaire for a £20-a-month tool with no customer data. Risk-tier the questionnaire the same way you tier approvals, or people will route around it.
Where Cledara fits
Cledara keeps one list of every software and AI tool a company pays for, with its owner, cost, renewal date and who has access, built from the payments themselves. That list is most of a supplier register already. The Software Compliance module adds the rest: ISO 27001 and SOC 2 certification tags on each vendor, the five questionnaire templates above, delegation of questions to the owner or the vendor, and compliance steps embedded in the approval flow so a new tool can't be bought without the register being filled in. Cledara Engage shows the tools people actually use, including the ones nobody approved, and Cledara Agent removes leavers from every tool they had, which closes the access part of 5.22 without a quarterly scramble.
Peter Fallowfield, IT Manager at Solidatus, described starting with "a lot of shadow IT and people with their own subscriptions" while the company worked towards ISO 27001, and said that without Cledara "it would have been quite tricky to pass some aspects". We wrote about why SaaS management helps with ISO 27001 back in 2021; the standard has been updated since, and the problem has got bigger. The Software Compliance page has the current detail, and the pricing page shows how the module is added to a plan.
An ISO 27001 supplier register you never have to rebuild
The goal is a supplier register that is simply true, every day, because it's generated by the things that make it change: payments, logins, joiners and leavers. The audit then becomes a report rather than a project. I think that's where every certified company ends up eventually. The ones that get there first spend their audit weeks on the risks that matter, and none of them on finding out what software they own.