Why DIY ITSM Archives (CSV, SharePoint, Scripts) Fail Audits

29 Jul 2026 · By Brian Parks, CEO — Synapse Software
Former Senior Software Engineer at Cherwell Software (2017–2020)

Somewhere on a file share there is a folder called ARCHIVE, and someone is quietly proud of it. Inside are CSV exports, a few PDFs, maybe a SQL script that pulls old tickets on request. It looks like a solved problem. It survives right up until an auditor asks a question the folder cannot answer.

I have built enough systems to respect the instinct behind the DIY archive. It is cheap, it is fast, and it feels like control. The problem is not the effort. The problem is that an audit tests for things the DIY approach was never designed to provide, and you find that out at the worst possible time.

What an auditor actually asks for

Start from the test, because the DIY archive is usually built without knowing it. An auditor does not want a data dump. They want a specific record. The change that touched a financial system in Q3 three years ago, with its approvals, its linked incident, its attachments, and a way to be confident it is the complete record and has not been altered since. They want it retrieved under access controls, so that not everyone could have reached in and changed it.

That is the bar. Now hold each DIY method up to it.

CSV: keeps the rows, loses the record

A CSV export is the most common DIY archive and the most common audit failure. It keeps field values and discards everything that gave them meaning: linked records, attachments, expressions, and the form layout that showed how the record was actually used. We covered this in detail for Cherwell and for Jira. When the auditor asks for that change in context, a CSV gives you a row of values with no approvals attached, no linked incident, and no proof the file is complete. A column is not a record.

SharePoint: a folder is not an archive

Putting the exports in SharePoint feels like an upgrade because it adds search and a familiar interface. It does not fix the underlying problem, and it adds new ones. The retention rules that governed the original records do not travel into a document library. Access control is folder-level, not record-level, so you cannot show that a given record was protected from change. And there is no integrity guarantee. A file in a folder can be edited, replaced, or deleted, and nothing proves it was not. An auditor who needs to trust that a record is unaltered cannot get that assurance from a shared folder.

This is not hypothetical. A Quebec retailer of about 7,000 people moving its HR operations off a legacy platform had one non-negotiable: the historical HR records had to stay visible only to authorized people, with no room for a misconfigured permission during the move. That is a record-level access-control requirement, and it is exactly the kind of guarantee a SharePoint folder cannot make.

Scripts: the archive that leaves with the author

The most sophisticated DIY archive is a script: query the old database on demand, regenerate the record when someone needs it. It is the closest to right, and it carries the quietest risk. It depends on the person who wrote it, on the old database still being readable, and on the query logic still being correct as the source schema ages. When the author leaves, the archive becomes a black box nobody is sure how to run. When the source database finally goes away, the script has nothing to query. You have automated access to a record store that is itself unmanaged, and an auditor cannot accept “we run a script” as a controlled, repeatable, defensible process.

The hidden cost behind all three

Every DIY method shares one quiet assumption: that the source system, or a backup of it, stays reachable. Often the way teams guarantee that is by keeping the old platform alive for read access, which is its own recurring expense once you count the license, the infrastructure, and the staff time. So the “free” DIY archive frequently sits on top of a very unfree platform bill, and the moment that bill gets cut, the DIY archive loses the source it depended on.

What “audit-ready” actually requires

An archive that survives an audit has to do four things the DIY approaches cannot. Keep the whole record, with links, attachments, and history intact. Retain the whole record read-only for as long as the obligation requires, so it cannot be quietly deleted or overwritten. Control access at the record level, so you can show who could reach what. And guarantee integrity, so you can demonstrate a record is complete and unchanged.

That is the line between data and evidence, and it is the line a DIY archive sits on the wrong side of.

Why a purpose-built archive clears the bar

Cortex Archive was built against the audit test, not the convenience test. It rebuilds a familiar, read-only interface to your old platform from its own database, inside your own network. It runs as a SQL user with no write permissions, so it cannot alter a record even by accident, which is the integrity guarantee a folder of files cannot make. The record stays whole. It is read-only by design, so integrity is structural rather than promised. Access follows the source platform’s own security model, and the record is retained read-only for as long as you need it. And it does not depend on keeping the dead platform alive, because the archive is the system of record now. When the auditor asks for the change from three years ago, you open it in context, the way you would have in the live system, and you are done.

For the business, that lands as three things. Efficiency: one archive holds the records from every platform you retire, instead of a sprawl of folders, scripts, and servers kept alive for read access. Time: a request that used to mean restoring a platform or rebuilding a spreadsheet becomes a search that returns the record in seconds. Risk: because the archive is read-only and audit-ready by design, you can actually produce what a regulator or auditor asks for, which is the entire point of retention.

Build it yourself if the stakes are low and nobody will ever audit it. If a regulator, a customer, or your own board might ask for a record back in full, the folder called ARCHIVE is not going to hold.

Frequently Asked Questions

Why does a CSV export fail an audit?

Because it keeps field values but loses the links, attachments, expressions, and form context that make a record complete. When an auditor asks for a record in context, a CSV provides a row of values with no proof of completeness and no surrounding evidence. It is data, not a record.

Is SharePoint a valid place to archive ITSM records?

SharePoint adds search and a familiar interface, but it does not carry record-level retention, record-level access control, or integrity guarantees. Files in a folder can be changed or deleted with nothing to prove otherwise, so a SharePoint folder cannot satisfy an auditor who needs assurance that a record is complete and unaltered.

What is wrong with using a script to retrieve old tickets?

A script depends on the person who wrote it, on the source database staying readable, and on the query logic staying correct as the schema ages. When the author leaves or the source goes away, the archive breaks. Auditors also cannot accept an ad hoc script as a controlled, repeatable, defensible retrieval process.

What makes an ITSM archive audit-ready?

Four things: the whole record is preserved with links, attachments, and history; it is retained read-only for as long as required; access is controlled through the source platform’s security model; and integrity is guaranteed so records can be shown to be complete and unaltered. DIY methods typically provide none of these.

How long do I need to keep ITSM records?

It depends on your industry and jurisdiction, and the safe answer is usually years, not months. Financial controls under SOX, healthcare records under HIPAA, financial-services rules under GLBA, and various state and sector retention schedules commonly require IT and change records to remain retrievable for several years, with HR-related records often longer. Confirm your own obligations, but the practical takeaway is that the retention window almost always outlasts the platform, which is why the records need a home independent of it.

Do DIY archives still require keeping the old platform running?

Often, yes. DIY methods usually assume the source system or a backup stays reachable, which many teams ensure by keeping the legacy platform alive for read access. That carries a recurring cost, and the DIY archive collapses when that access is finally cut.

How is a purpose-built archive different from a DIY one?

A purpose-built archive preserves the full record read-only, controls access through the source platform’s security model, and guarantees integrity, all without keeping the source platform running. It becomes the system of record itself, so an auditor’s request can be answered in full context rather than reconstructed from a lossy export or a fragile script.

If the folder called ARCHIVE might one day face an auditor, Cortex Archive preserves the whole record, read-only and access-controlled, inside your own network, so a request from years ago can be answered in full context.