Compliance spreadsheets
Why spreadsheets fail as a compliance system
Spreadsheets can record compliance. They do not keep it current. That single distinction explains most of what goes wrong when a compliance register outgrows the workbook it started in, and it is not a criticism of Excel.
A spreadsheet holds what somebody entered into a cell on the day they entered it. Demonstrating that your compliance system was actually operating is a different question, and it is the one that gets asked after an incident, during a client review, or when an insurer wants to see more than an assurance.
General information about Australian obligations, not legal advice.
What is a compliance spreadsheet?
A compliance spreadsheet is a workbook used as the organisation's record of its compliance position: the controls in place, the policies issued, the training completed, the risks identified, the reviews due and the evidence held. It is usually built by one person, expanded as new obligations appear, and maintained by hand.
Nothing about that arrangement is unlawful, and no Australian law requires a business to use compliance software. The Privacy Act and the Australian Privacy Principles ask what steps an organisation took and whether those steps were reasonable in the circumstances. They do not prescribe the tool.
The same pattern appears under several names. A compliance tracking spreadsheet lists obligations and marks them off. A compliance management spreadsheet adds owners and dates. An Excel compliance register sits alongside a folder of policies, a training provider's portal, an inbox of supplier questionnaires and a shared drive of screenshots. Word documents carry the policies. Email carries the acknowledgements. A calendar reminder carries the annual review, if anyone set one.
Described that way, the arrangement is a set of separate records that a person has to keep consistent with each other. That is the part that gets harder as the organisation grows, and it is where the analysis on this page is directed.
Where a spreadsheet genuinely works
Excel earned its place. It is flexible, familiar, cheap and immediate. Every manager can already use it, it needs no procurement decision and no implementation project, and it can be reshaped in an afternoon when the obligation changes. For a business with eight staff, one office, a short supplier list and a single set of obligations, a well-kept workbook is a reasonable way to hold a compliance position. Plenty of organisations have passed a client security review on the strength of one.
It also does some things a purpose-built system does not do as well. Ad hoc analysis, one-off modelling, a quick pivot to answer an unusual question, a working draft nobody else needs to see: a spreadsheet remains the right tool for all of that, and it stays useful inside an organisation that has moved its compliance record somewhere else.
What the workbook is good at
- Holding a list, in whatever shape the organisation needs this week.
- Calculating, filtering and summarising what is in the list.
- Being understood immediately by anyone who opens it.
- Costing nothing beyond the licence the business already holds.
- Producing a snapshot for a meeting without asking anyone's permission.
What it is being asked to do instead
- Know that a person joined, changed role or left the organisation.
- Know that a document has been superseded by a later version.
- Know that evidence recorded a year ago no longer proves anything.
- Prompt the owner of a control before the review falls overdue.
- Retain a record of who changed what, and when, that nobody can edit.
- Show, at a later date, that the arrangement was operating and not merely described.
The failure is structural, not clerical
The right hand column is not a list of things careful people forget. Each item is work that a manual compliance process requires somebody to perform, notice and repeat. A capable administrator can do all of it. The question is what happens to the compliance position during the weeks when that person is doing something else, and what the organisation can show for the period afterwards.
A spreadsheet records a position. It does not maintain one.
A spreadsheet is passive. It changes when a person changes it, and at no other time. Everything a compliance system does between those edits, noticing that a date has passed, that a person has gone, that a control has not been checked, that a policy has been replaced, has to be supplied by somebody remembering to look.
This is why compliance built on a workbook tends to be accurate on the day it is updated and progressively less accurate afterwards. The register is not wrong when it is written. It becomes wrong quietly, through ordinary events that nobody thought to record: a manager moves to a new role and keeps the obligations recorded against the old one, a supplier is replaced without the register being touched, a policy is amended in the shared folder while the acknowledgement emails still refer to the earlier text.
None of those events announce themselves. The organisation continues to believe the position described in the workbook, because the workbook still says it. That gap between the recorded position and the actual one is the real cost, and it widens in proportion to how much is going on.
What the spreadsheet does
Holds the statement that a control exists, a policy was issued, a person was trained, a supplier was assessed. Each cell is a claim entered on a date, by someone, for a reason that is usually not written down.
What somebody has to do
Watch every date, chase every owner, re-check every claim, retire what is no longer true and add what has changed. The workbook does not participate in this work. It is the thing the work is performed on.
What is left afterwards
A current state, and very little about how it was reached. The file shows what it says today. It rarely shows what it said in June, who changed it, or whether the change followed an actual review.
Where compliance spreadsheets break down as the organisation grows
Each row below is something a purpose-built compliance system does as part of its ordinary operation. In a manual process, each one is a task that has to be designed, assigned, performed and repeated. None of them is difficult on its own. The difficulty is that there are twelve of them, they recur, and they compound.
| What has to be maintained | What the manual process requires |
|---|---|
| Policy version control | A convention for naming and storing versions that everyone follows, and a discipline of never editing an issued document in place. Where policies live in a shared folder, the most common failure is not a missing policy but two current-looking copies of the same one. |
| Which version was current at a given date | A record of when each version was approved and when it was replaced. Without it, the organisation can say what its policy is today and cannot say what it required of staff during the period an incident actually occurred. |
| Proof that staff received and acknowledged a policy | A distribution list, a returned acknowledgement per person, a way of tying each acknowledgement to the version it covered, and follow-up for the people who did not reply. Acknowledgements collected by email end up in an inbox, ordered by date rather than by person or document. |
| Training assignment and completion | A view of who is required to complete what, based on their role, reconciled against completion records that usually live in a separate system. Reconciliation is manual, so it happens when someone asks rather than continuously. |
| Staff joining, changing roles and leaving | Adding a new person to every register that names people, changing the obligations of anyone who moves role, and removing leavers from all of it. A leaver who remains in the training register understates completion. A leaver who still owns a control means the control has no owner at all. |
| Responsibilities and ownership | A named owner against each control, policy, supplier and action, kept current as people change. Ownership recorded once and never revisited is the most common way a register becomes decorative. |
| Recurring control reviews | A cycle for each control, a prompt before it falls due, a record of the review being performed and a new due date afterwards. Calendar reminders cover the first part of this and none of the rest. |
| Overdue actions | Somebody opening the workbook, sorting by date, working out what has passed and following it up. Overdue work is found by looking rather than surfaced automatically, which means it is found when someone has time. |
| Evidence going out of date | A review date against every piece of evidence and a decision about how long each kind stays meaningful. A penetration test report, a backup restore test and a signed policy have very different useful lives, and a folder treats them identically. |
| Evidence scattered across systems | Assembling proof from a shared drive, several inboxes, a training portal, a ticketing system and an IT provider's platform, then working out which items relate to which control. This is the task that turns a client questionnaire into a fortnight of work. |
| A coherent audit trail | A record of who changed what and when, that the people being reviewed cannot amend. Spreadsheet version history exists, but it is a file history rather than a compliance record, and it does not survive a copy, a rename or a rebuild of the workbook. |
| Links between controls, policies, training, people and evidence | Maintaining, by hand, the relationships that make a compliance position readable: this control is described by that policy, assigned to that person, supported by that training, evidenced by that file, reviewed on that date. Every one of those links has to be updated when anything at either end changes. |
Why the last row matters most
A compliance position is not a list of items. It is a set of relationships between them. A control means little without an owner, a policy without an audience, training without a role requirement, evidence without the control it supports. Spreadsheets hold lists well and relationships poorly, which is why a mature manual process usually ends up as several workbooks that have to agree with each other, and usually do not.
Most compliance spreadsheets become registers rather than systems
Storing compliance information and operating a compliance system are different activities. A register answers what was recorded. A system produces the activity that gives the register its meaning: the assignment, the reminder, the review, the completion, the escalation when nothing happens.
The distinction shows up clearly in what each can demonstrate. A spreadsheet can show that a cell says a quarterly access review was completed in April. It is much harder for it to show that the organisation's access review process was running: that a review was scheduled, that a named person was asked, that it was performed on a date, that the outcome was recorded, that the exceptions found were followed up, and that the next one was raised. The first is a claim about a control. The second is evidence of a control operating.
That is the gap regulators, auditors, insurers and larger clients probe. The Office of the Australian Information Commissioner's guidance on reasonable steps under APP 11 is concerned with practices, procedures and systems, not with the format of the record. What matters is whether the arrangement existed and functioned. A register that was written once and reviewed when convenient is weak evidence of that, whatever it is stored in.
The same distinction has become sharper since compliance documentation became quick to generate. A complete policy set can now be produced in an afternoon, which makes the document folder a much weaker signal of whether an organisation has done the work. The AI compliance guide works through that version of the problem.
What reasonable steps means in practice, and what proving compliance actually involves.
If an incident happened tomorrow, could you reconstruct where you stood before it?
This is the question that separates a compliance record from a compliance system, and it is worth answering honestly before circumstances ask it. After a data breach, a client complaint or a regulator's enquiry, the relevant period is the one before the event. What was in place then is what the organisation is judged on. Work done afterwards carries much less weight, and an obviously reconstructed record can be worse than none.
Nine questions come up in some form nearly every time. Read them against your current arrangement and note which ones would need somebody to go and find out.
- Which controls were operating on the date in question, and who says so.
- Who was responsible for each of them at that time.
- Which version of each policy was current then.
- Which staff had acknowledged that version, and on what date.
- What training each person had completed, and whether it was still current.
- Which reviews had been performed, and which were overdue.
- What evidence existed before the incident, rather than after it.
- Which known gaps had been identified, and what was being done about them.
- Who changed what, and when, across all of the above.
A Monday morning, three days after a business email compromise
A twenty-eight person professional services firm discovers that an account was accessed by an outsider some time in the previous fortnight. Client information was in the mailbox. The firm has to assess whether the breach is notifiable under the Notifiable Data Breach scheme, and its insurer and two of its larger clients will ask what was in place beforehand. The compliance record is a workbook maintained by the practice manager, a policy folder on the shared drive, and a training provider's portal.
Available immediately
- The current version of the workbook, showing the position as at the last time it was edited.
- Policy documents as they stand today in the shared folder.
- Training completions in the provider's portal, for people who are still enrolled.
- The IT provider's own records of technical controls, held in their systems.
Requiring reconstruction
- What the workbook said a fortnight ago, before the last two rounds of edits.
- Which version of the acceptable use policy staff had actually been given.
- Which of the twenty-eight had acknowledged it, and when.
- Whether the quarterly access review recorded as done in the workbook was performed, and by whom.
- Whether multi-factor authentication was enabled on that mailbox before the incident or during the response.
- Which gaps the firm already knew about, and what it had decided to do.
The firm may well have done all of these things. That is the difficulty. Having done the work and being able to show it are separate, and the second one is decided long before the incident, by whether the doing left a dated record behind.
Assessment obligations under the Notifiable Data Breach scheme run to a statutory timeframe, which is one reason a slow reconstruction is a practical problem and not only an evidentiary one. See the NDB scheme explained and what happens after a breach.
The register depends on one person, and often on the systems it describes
Manual compliance concentrates. The workbook is usually built by one capable person who understands its logic, knows which tabs matter, remembers which cells are stale and carries the follow-up in their head. That arrangement works until they take leave, change role or resign. What transfers is the file. What does not transfer is the process around it, which is most of what was keeping the position current.
Testing for this is straightforward. If the person who maintains your compliance record were unavailable for a month, would anyone else know what was due, what had been chased, which entries could be relied on and which were placeholders? A system does not remove the need for a capable owner. It does mean that the ownership is recorded rather than remembered, and that the work continues to be prompted while the owner is away.
Where the compliance record is stored is worth a decision
Compliance records are frequently kept inside the same environment as the systems they are meant to provide evidence about. The register sits on the file server, the policies sit in the same tenancy, the acknowledgements sit in the mail system, and the audit trail is the version history of a file in that environment.
For everyday purposes that is convenient and unremarkable. It becomes a question in exactly the circumstances where the records matter most: ransomware that encrypts the file server, an administrator account compromise, an accidental mass deletion, a disputed departure, or a restore that brings back a version from before the last month of updates. The organisation then has to demonstrate its position using material held in the environment that was affected.
This is one advantage of holding compliance records outside the operational environment, and it is worth weighing rather than overstating. It does not by itself make a record more credible, and a compliance platform is not a backup strategy. What it does is keep the account of what was in place separate from the systems the account is about.
The maintenance is the product
Cleverer is an Australian cyber compliance platform. It does not scan systems, connect to your tenancy or monitor traffic, and it does not replace an IT provider. It holds the organisational layer that a workbook is usually being asked to carry: the policies and who adopted and acknowledged them, the responsibilities and who owns them, the training required by role, the supplier and asset registers, the risks, the open gaps and the recurring reviews, each with a date and an owner attached.
Policies that carry their own history
A revised policy is a separate record linked to the one it replaces, with its own approval date and its own acknowledgements. When the revision is adopted, the earlier policy is archived rather than deleted, so the acknowledgements collected against it stay attached to the text they covered.
Obligations that follow the role
Training requirements are derived from a person's role rather than from a list somebody maintains, so a role change produces the new requirement immediately. When access is revoked, the items that person owned are raised as work to reassign instead of quietly losing their owner.
Evidence with an expiry
Evidence is current for its own review period or the review cycle of the control it supports, and stops counting when that passes. Expired records are retained and labelled rather than removed, because a record can stop being proof without stopping being history.
No platform can guarantee compliance or legal defensibility, and Cleverer does not claim to. It also does not reconstruct what a control's state would have been on an earlier date, and says so in its own reporting. What it holds is the dated record of what was decided, assigned, completed, reviewed and evidenced, which is what makes the earlier position readable rather than remembered. How the evidence system works.
Find out what your current arrangement could actually show
The Cyber Compliance Readiness Check works through policies, training, responsibilities, registers and evidence, and reports where your organisation would be able to demonstrate its position and where it would be relying on memory. It takes a few minutes.
Common questions about managing compliance in spreadsheets
Can you manage compliance in a spreadsheet?
Yes. Australian law does not require compliance software, and a well-maintained workbook can hold a compliance position for a small organisation with a short list of obligations. The limitation is not legality but maintenance: a spreadsheet records what somebody entered and does nothing between edits, so the organisation has to supply the review cycles, reminders, version control, acknowledgement tracking and audit trail by hand.
Is it non-compliant to use Excel for a compliance register?
No. Nothing in the Privacy Act, the Australian Privacy Principles or the Notifiable Data Breach scheme prescribes a format for compliance records. What is assessed is whether the organisation took steps that were reasonable in its circumstances, and whether it can show what those steps were. A spreadsheet can contribute to that. Whether it is sufficient depends on how much has to be maintained and how well the manual process around it holds up.
At what point does a compliance spreadsheet stop working?
Usually when the number of moving parts exceeds what one person can hold. The common thresholds are staff turnover reaching the point where registers drift, obligations arriving from more than one source, evidence being requested by clients or insurers on a recurring basis, and more than one person needing to update the same records. The signal is rarely a dramatic failure. It is the growing gap between what the register says and what is actually true.
What is the difference between a compliance register and a compliance management system?
A register stores what was recorded. A compliance management system produces and records the activity that keeps those records meaningful: assigning responsibilities, prompting reviews before they fall due, tracking acknowledgements against the version of the policy they relate to, expiring evidence that is no longer current, and retaining a trail of who changed what. Most spreadsheets are registers. Some organisations build a system around one, which is possible and is a substantial amount of ongoing work.
Can a spreadsheet prove that a policy was acknowledged?
It can hold a list of names and dates. Tying each acknowledgement to the specific version of the document it covered is the harder part, particularly where the policy is edited in place in a shared folder. Without that link, the organisation can show that people signed for a policy and cannot show precisely what they signed for, which is the question that matters if the wording changed during the relevant period.
What evidence do auditors and insurers actually ask for?
Typically the policy set with approval dates, evidence that staff received and acknowledged those policies, training records by person, named ownership of key controls, records of reviews being performed on a cycle, a list of known gaps with remediation status, and supporting artefacts such as reports or screenshots with dates on them. The recurring difficulty with a manual process is not producing any one of those. It is producing all of them, consistent with each other, for a defined period.
