Article
Has your supplier register outgrown a spreadsheet?
Test whether a spreadsheet still supports supplier-risk decisions, then compare tools using evidence continuity, access, handoffs, exports and whole-life cost.
Contrata editorial team · Published · Prepared on

A supplier register has outgrown its current spreadsheet when the team cannot reliably maintain the evidence, responsibilities and decision history it needs, using the controls and effort it can sustain. There is no universal supplier-count threshold. Test the workflow before buying another system.
A controlled workbook linked to a well-managed evidence repository may be sufficient. A sophisticated platform can still hold stale information or hide a decision behind an unexplained score. Compare what people can demonstrate with the same review record, including what happens when someone leaves or the organisation changes tools.
This is a neutral evaluation method for lean Australian financial-services risk teams. It does not claim that a particular product passes, that software guarantees compliance or that a small headcount changes regulatory obligations.
Define the problem you need a tool to solve
Take a recent review and trace the actual friction. Was a source document difficult to find? Did a supplier answer overwrite the earlier response? Could nobody tell who accepted an exception? Did the person preparing a report need to reconstruct qualifications from email?
Separate missing process from missing capability. If nobody owns the service or has authority to accept risk, moving the record into software will not resolve that. Start with named responsibilities and a workable decision record.
For APRA-regulated entities, CPS 230 requires effective operational-risk and service-provider management. It does not prescribe a particular software product. Use the current standard and the entity's policy to define the outcomes your system must support, rather than treating a vendor's compliance label as evidence.
Run the same record-continuity trial on every option
Use fictional or appropriately sanitised data. Do not upload real supplier evidence or personal information to a trial without the organisation's approval and relevant checks. Give each option the same representative scenario, including the current workbook and repository setup.
In this fictional scenario, a super fund reviews a communications service. One document describes hosting. A later supplier reply leaves support access unclear. The service owner must obtain a decision before renewal, and a colleague will take over during leave.
- Create the provider and arrangement records. Attach the first source with its date, version and scope.
- Add the later reply. Retain the earlier evidence and record the unresolved access question.
- Assign a bounded follow-up to a named owner and set a due date chosen for the renewal decision.
- Have the deputy take over using only the record and documented permissions. Can they find the current position without a briefing from the author?
- Record a decision with its authority, rationale and any condition. Confirm that receiving a file cannot silently close the condition.
- Export the record, evidence references, open action and history. Reopen or reconstruct it in an independent permitted environment and reconcile what survived.

The export test does not require every product to share an identical file format. It asks whether your team can recover the information needed for its decisions and retention duties. A spreadsheet export containing only the latest score may omit the very record you need.
Compare observable results
| Criterion | Demonstration to request | Evidence to retain |
|---|---|---|
| Record identity | Distinguish one provider from its separate services and arrangements | Stable identifiers and links that survive export |
| Evidence continuity | Show the source, scope, version and qualifications behind an assessment answer | Retrieved source and change history; any gaps explicitly recorded |
| Ownership and handover | Let the deputy find the open question and perform only authorised actions | Role permissions, handover result and escalation path |
| Review and approval | Keep a supplier reply separate from internal acceptance | Named authority, rationale, conditions and time of decision |
| Monitoring and follow-up | Turn a relevant change into an owned review without closing unrelated issues | Trigger source, assigned action and observed workflow |
| Access and protection | Test ordinary roles, sensitive evidence separation and removal of a user's access | Agreed permission design and test results; specialist review where needed |
| Reporting and exit | Export a readable, reconcilable record including unresolved matters | Export files, attachment inventory, missing fields and recovery steps |
Mark each result demonstrated, partly demonstrated or not demonstrated, with a reason. Avoid combining critical failures into an average that looks acceptable. A tool that cannot enforce an essential permission boundary is not rescued by a convenient dashboard.
The NIST Cybersecurity Framework offers a voluntary outcomes-based reference for discussing cyber risk with specialists. It is broader context for an evaluation, not an Australian mandate or a product certification. The organisation still needs to define and test its particular access, retention and resilience requirements.
When keeping the spreadsheet is a reasonable decision
Keeping the existing setup can be reasonable if a responsible person can maintain it, users can access only appropriate evidence, changes remain traceable, handovers work and a useful record can be recovered. Record how those controls operate and what would trigger reconsideration.
For example, a controlled register may point to versioned documents in an approved repository while a separate action log preserves decisions. That design has dependencies of its own: permissions must stay aligned, links must remain valid and someone must reconcile the records. Test those dependencies rather than dismissing the setup because it uses spreadsheets.
The register-maintenance guide explains the underlying record structure. Buying software should improve that work, rather than introduce a second inconsistent register.
Include implementation and exit in the cost comparison
Ask for costs and effort across subscription, setup, data cleaning, migration, integrations, training, administration, storage, support and eventual export or exit. Check contractual limits and charges rather than assuming that all advertised capabilities are included.
Build a worksheet with a source and owner for each input. Separate quoted fees from internal estimates. Record current measured task time only where you actually have it; otherwise measure a sample before projecting an annual benefit. Distinguish staff capacity that could be redirected from cash savings that would actually be realised. Do not count the same reduction in follow-up work under several benefit headings.
Run a limited migration trial before committing the whole register. Reconcile record counts, duplicates, relationships, source versions, open actions and permissions. Agree who fixes failures and which conditions prevent go-live. Preserve a usable copy under the organisation's retention and access rules until the migration is accepted.
Make a bounded recommendation
Write down the problem, the trial results, unresolved constraints, total-cost assumptions and the person authorised to decide. The recommendation may be to retain and strengthen the workbook, pilot a tool or defer the purchase until a missing ownership decision is resolved.
For software-specific checks, use the supplier accessibility evidence guide and end-of-support review. Those examine important parts of a purchase; the continuity trial establishes whether the whole record remains usable through work, handover and exit.