Assurance readiness as a software selection criterion

Every software comparison in this category lists assurance readiness as a criterion. Almost none of them say what it means. It sits in the feature grid with a tick next to it, and the tick is doing no work at all.

It is the one dimension worth examining properly, because it is the dimension that decides how your next assurance engagement goes.

The criterion everyone lists and nobody defines

Here is the working definition I would use. A system is assurance ready when a practitioner who was not present during your reporting cycle can take what the system retained and test your figures against it, without asking anyone to remember anything.

Notice what that excludes. It is not about having a nice report. It is not about dashboards. It is about whether the record holds up when it is examined by a stranger, months later, with the people who built it gone.

ISSA 5000 does not require your software to do any of this. It binds your assurance provider. But it broadens tests of controls and encourages a controls-based approach, so a system that produces testable records means your assurer can lean on controls instead of testing figure by figure. That difference arrives on your desk as fewer requests.

Test 1: can the record be altered after the fact

Ask the question precisely, because the vague version gets a vague answer.

Not "is there an audit log". Almost everything has an audit log. Ask: who has the technical ability to edit or delete an entry in it? Include the vendor's support engineers and database administrators in the question.

Most systems, answered honestly, have somebody who can. That is not automatically disqualifying. It is something you should know before you rely on the record.

The distinction is enforcement. A policy that says records must not be edited depends on everyone following it, including people you have never met. A system where the database itself refuses the operation does not.

You can try to alter our log from a public page and read the refusal the database returns. I mention it because it is the only way I know to answer this question without asking you to take my word for it.

Test 2: is every change attributed and timestamped

A figure changes from 4,812.6 to 4,796.3. Three things need to survive: what it was, who changed it, and when.

Ask to see a changed figure in the vendor's demo data and read the record. If the previous value is gone, the system stores state rather than history, and your change history is only as good as whoever remembers.

Watch for the halfway version, which is common: the system records that a change happened, but not what the value was before. That is enough to raise a question with your assurer and not enough to answer it.

Test 3: are approvals records or status flags

Most products have a field that says Approved. Far fewer have an approval record.

A status flag says the current state. A record says who approved it, under what role, which version, at what time, and on what basis. The first is metadata that can be flipped back. The second is evidence.

Ask what happens to the approval when the underlying figure changes afterwards. If the flag stays green, the system is telling your assurer that someone approved a number they never saw. The mechanics are in who signs off on a climate disclosure figure.

Test 4: is the source document linked to the figure

A document library is not evidence. The link between a specific number and the specific document supporting it is the thing being tested.

Ask the vendor to pick any figure in their demo and produce the document behind it in front of you. Then ask what happens to that link if the person who uploaded the file leaves the company.

The good version keeps the file, a hash taken at upload, and a reference from the figure to the file. The weak version has a folder and a naming convention.

Test 5: can a figure be reproduced from what is retained

Take a disclosed number. Using only what the system holds, rebuild it. Same inputs, same factor, same boundary, same answer.

The input that usually breaks this is the emission factor version, because publishers revise factors and few systems record which release was applied. This is covered at length in could you reproduce this figure in eighteen months.

Ask specifically: does the system record the factor source and its publication year against the figure, or does it hold a single factor table that gets updated in place? The second answer means last year's numbers quietly stop reproducing the moment the table changes.

Test 6: can your assurer test the export, not just read it

Ask to see the export you would hand an assurance provider. Then look at what is inside it.

What a practitioner needs is the figures, the evidence files themselves, the activity log including previous values, a manifest with a hash per file so they can confirm nothing changed since upload, and an index mapping figures to documents.

What they usually get is a PDF of the report. That is a deliverable for a board, not evidence for an engagement.

The checklist to take into a vendor call

The pattern in the right-hand column is the same each time: a true statement that does not answer the question. That pattern is the signal, more than any individual answer.

If your current system fails these tests

Most will fail at least two, and replacing everything before your next cycle is usually not realistic. Some of it can be closed without changing systems.

Attribution and approvals can be handled outside the tool if you are disciplined about it. A dated approval memo naming the person, the figure, the version and what they reviewed is weaker than a system record, but it is testable, and it is far better than a green flag nobody can date.

Factor versioning is a documentation fix rather than a software one. Record the publisher, the release year and the factor value alongside each figure, even if that means a column in a controlled register.

Alterability is the one you cannot patch. If the record can be rewritten, no procedure sitting on top of it changes what a practitioner can rely on. That is why it sits first on the list, and why it is the test worth applying before you commit to a system rather than after.

The sequence I would suggest: fix what documentation can fix this cycle, note the gaps you cannot close, and tell your assurance provider about them before they find them. A known limitation discussed early is a different conversation from one discovered during fieldwork.

Try the tests on a live system

Two of these you can run right now, on ours, without talking to anyone.

Our public tamper page lets you attempt to edit, delete or forge an entry in a real activity log and shows you the database's actual refusal. It also records your attempt, which is the second test demonstrating itself.

Being even-handed about our own product: we do not do heavy multi-entity financial consolidation, we have no built-in emission factor library, and our SOC 2 is in progress rather than certified. Those are real limits and they belong in this conversation, alongside the wider evaluation criteria and our published pricing.

The position: assurance readiness is the only evaluation criterion that gets harder to fix later. You can add users, buy more entities, or change your factor source at any point. You cannot retroactively create a record of who approved a figure in March, or recover a previous value that was overwritten. Test this one before you sign, because it is the one you cannot buy your way out of afterwards.

Common questions

What does assurance ready actually mean in reporting software?

That the record behind a figure can withstand being tested by someone who was not there when it was made. In practice that means six things: the record cannot be altered afterwards, every change is attributed and timestamped, approvals are records rather than status flags, source documents are linked to specific figures, a figure can be reproduced from what is retained, and the export gives an assurance provider material they can test rather than a report they can only read.

How do I test whether a vendor is really append-only?

Ask who has the technical ability to edit or delete a recorded entry, including the vendor’s own staff and support engineers. Then ask them to attempt it in front of you and show the refusal. A policy that says records must not be edited is a different thing from a system in which they cannot be.

What should an assurance export contain?

The figures, the evidence files themselves rather than links to them, the activity log including previous values for every change, a manifest with a hash per file so the practitioner can confirm nothing changed since upload, and an index mapping each figure to its supporting documents. A PDF of the finished report is not an export.

Does ISSA 5000 require my software to be assurance ready?

No. ISSA 5000 binds the assurance practitioner, not your software. But it broadens tests of controls and encourages a controls-based approach, so a system that produces testable records lets your assurer lean on controls rather than testing individual figures. That difference shows up as fewer requests landing on your team.