Most audit departments have tried building a central evidence repository at some point. Some use SharePoint. Some use a shared network folder. Some use a document management system purchased specifically for the purpose. A fair number eventually abandon it, because by the third week of audit season the auditors are emailing files directly anyway.
The technology isn't usually the problem. The failed repositories we've seen, and in building Petual we looked at quite a few, share a common structural failure: they were designed around how administrators want to store information, not around how auditors need to retrieve and link it. A repository that makes uploading slightly more convenient than the previous method but doesn't reduce the mental overhead of managing evidence against a control list will not be adopted under deadline pressure.
This post describes the three structural properties that distinguish repositories teams actually maintain from the ones that get bypassed when the season gets busy.
Property One: The Repository Is the Request, Not a Destination for Responses
In most evidence workflows, requests go out through one channel (email, a ticketing system, or a shared tracker) and evidence comes back through a different channel (email attachment, upload to a separate portal, or shared folder drop). The auditor then has to match what came in to what was requested, log the receipt somewhere, and move the file to wherever the workpaper lives.
This matching step is where repositories break down. During a typical SOX cycle covering 60 to 80 in-scope controls, an audit team might send 200 or more individual evidence requests. At any moment, 30 to 40 percent of those are in some in-between state: requested but not received, received but not reviewed, reviewed but not formally accepted. Tracking this state manually, whether in a spreadsheet or in a notes column in the repository, is overhead that auditors shed when they're under pressure.
A repository that works integrates the request loop. When an auditor requests a piece of evidence, that request exists as a record in the repository with a defined state. When the evidence arrives, whether submitted through a link sent to a control owner or uploaded by the auditor after retrieval, it lands directly against the outstanding request. The repository knows what was asked for, knows what arrived, and can surface the gap automatically.
This is not a file storage question. It's a workflow design question. The evidence repository has to own the lifecycle from request to receipt, not just receive completed items at the end.
Property Two: Files Are Tagged to Controls at Ingest, Not Filed After the Fact
The other common failure mode is a repository that stores files correctly but doesn't maintain the relationship between a file and the control it was collected to test. An auditor uploads a population of IT change tickets. It goes into a folder named "ITGCs" or "Change Management" or "Q3 Evidence." Later, when someone needs to confirm that the workpaper for control CTL-047 (change management authorization) has adequate supporting evidence, someone has to go find the file and mentally confirm the connection.
That lookup gets omitted when the cycle is compressed. The workpaper gets signed with an implicit assumption that the file in the folder covers the control. Whether the file actually covers it, specifically the right population, the right date range, the right authorization attributes, is a question that gets deferred to review, then sometimes deferred past review.
A repository that works applies control tags at ingest. When a file enters the repository, it is associated with the control objective it was collected to test. That association is explicit, searchable, and visible to anyone reviewing the workpaper. If the file doesn't cover the right scope, that gap surfaces immediately rather than at final assembly.
The tagging can be automated. Evidence files have enough structural content, file names, date ranges in the data, column headers for system-generated reports, that a system processing the ingest can make a reasonable mapping proposal. The auditor confirms or adjusts. This is faster than filing first and linking later, and it produces a repository where the control-evidence relationship is the organizing principle rather than the folder structure.
Property Three: The Status View Is Actionable, Not Historical
Audit managers live and die by their ability to see, at any moment, which controls have adequate evidence and which don't. Most repository systems provide a view of what has been collected. Very few provide a view structured around what still needs to happen.
This is a distinction that matters more than it sounds. A list of uploaded files is information. A list of controls with outstanding evidence gaps, sorted by who owns the request and how long it's been pending, is actionable. The first requires interpretation. The second drives the day's follow-up queue.
The repositories that get used during crunch periods are the ones where the actionable view is the default. When an auditor opens the system, they see their pending items: controls with no evidence received, controls with evidence received but not yet reviewed, controls with evidence that covers an incomplete population, and controls with reviewed evidence that has been accepted. This view updates as work is done. The manager can see the same view across the team.
This is different from a status tracker maintained in a separate spreadsheet. The status tracker requires manual updates, which means it's always somewhat behind the actual state of work. A repository where status is derived automatically from the evidence state, present or absent, reviewed or not, accepted or pending, is always accurate because there's nothing to manually synchronize.
What Makes These Properties Hard to Implement
None of the three properties described here are technically difficult. The challenge is that they require the repository system to be opinionated about workflow, which generic file storage tools are not designed to be. SharePoint can store evidence. It doesn't have a concept of an outstanding request, a control tag that drives workpaper assembly, or a status view tied to evidence completeness. Building those structures on top of it is a customization project that most audit departments don't have the bandwidth to run.
The result is that most audit teams end up with repositories that are either too open, a folder structure anyone can dump files into, or too rigid, a form-based system that requires more fields than auditors have patience for during busy season. Neither extreme gets maintained.
There's also an adoption curve that specific teams handle differently. A repository that doesn't yet have any evidence is less useful than an email thread that already has attachments. This is particularly true at the start of a cycle, when the first few pieces of evidence come in and it's not obvious that the repository is earning its overhead. The systems that survive this period are the ones where the overhead is genuinely lower than the alternative from the first piece of evidence, not just in aggregate over the full cycle.
Rollforward and Reuse Across Cycles
One structural advantage that repositories have over flat file storage, when they're built around control mappings rather than folder hierarchies, is rollforward. If the repository stores evidence against control IDs, those control IDs persist from cycle to cycle. The prior-period repository becomes the starting template for the current period: controls that need testing are already defined, prior-period evidence is visible for comparison, and the PBC list for the current cycle can be generated from last year's completed items.
This is operationally significant. In a flat-file model, every cycle starts from scratch. The audit program is rebuilt, the folder structure is rebuilt, the request list is rebuilt from the prior-year binder or a document that approximates it. A repository with persistent control structure carries forward what's stable and surfaces what needs updating, the population definition changes, the control owner roster, the test procedure adjustments driven by risk assessment updates.
Teams that get to this state, where the repository is the working layer for a rolling engagement rather than a temporary holding area for a specific cycle, report that it changes the character of audit planning. The question shifts from "what do we need to collect this year" to "what changed since last year." For controls that are well-understood and stable, that's a much faster starting point.
One More Thing on Adoption
No repository structure solves the adoption problem if the people sending evidence don't know what they're supposed to submit. The repository design needs to account for the control owner side of the workflow, not just the auditor side. Control owners who receive a structured request with specific content requirements, a description of what evidence satisfies the test and what format is acceptable, submit higher-quality evidence with fewer follow-up cycles than control owners who receive a generic "please provide documentation for control X" email.
The repository doesn't have to generate those requests automatically, though that's a capability worth building toward. But it does need to support the auditor in communicating clearly what was asked for, so that when the evidence arrives, the gap analysis is about evidence coverage rather than evidence comprehension.