Key Takeaways
- Structure an audit evidence repository around stable records and relationships: entity, period, control, request, sample, file version, testing result, and review.
- Use folders as navigation where useful, but preserve metadata and history that support retrieval.
- Define permissions, retention, and legal holds with the responsible owners rather than adopting generic deletion periods.
Design around the questions reviewers ask
A reviewer may need every file for a selected sample, the version used in an approved test, or the evidence for a control in an earlier period. Design the repository to answer those questions without depending on one person's memory of folder names.
A well-organized folder structure can remain useful. Metadata adds other ways to retrieve the same artifact without making unnecessary copies. The goal is reliable context and access, not a categorical rejection of folders.
Establish a minimum metadata record
| Field | Purpose |
|---|---|
| Evidence ID | Stable reference independent of filename |
| Entity and system | Operational context |
| Period and source date | Coverage and timing |
| Control, request, and sample IDs | Connection to planned work |
| Version and source | Which artifact was used and where it came from |
| Owner and classification | Accountability and access handling |
| Retention or hold status | Applicable lifecycle instruction |
Use a controlled set of required fields and allow additional detail when the evidence type needs it. Too many unexplained mandatory fields can produce low-quality entries rather than better governance.
Distinguish duplicates from versions
Two byte-identical files may be duplicates, but two similarly named files may contain important changes. Do not delete one merely because the names match. Preserve the version used for an approved test and identify how later support relates to it.
Deduplication can reduce storage, but it must not break relationships or remove the record of what was provided and reviewed. A hash can help identify identical bytes; it does not establish that the original file was accurate or appropriate.
Keep links explicit
An artifact may support several attributes or controls. Record the specific purpose of each link rather than assuming that attaching a file to a control proves every requirement. A policy may support design understanding while a separate record supports operation.
For a hypothetical quarterly access review, retain the reviewed population, the review record, investigation notes, and evidence of any resulting access changes. A current user list may not replace the population actually reviewed during the quarter.
Apply permissions to every retrieval path
Test file access, previews, search, AI retrieval, notifications, shared links, and exports. A user who cannot open a file should not obtain its sensitive contents through a generated answer or preview. Review temporary access when an engagement ends or a person changes roles.
OWASP's sensitive information disclosure guidance provides relevant LLM-application risk context. Have the security team validate the actual authorization behavior.
Define retention without inventing a universal schedule
Retention periods depend on the records, organization, applicable obligations, and legal holds. Do not use blanket claims such as 'all ITGC logs require three years' or 'all employee documents require seven years' without a valid basis. A legal hold may also override ordinary deletion.
PCAOB AS 1215 addresses documentation for applicable external audits; it does not supply a complete company-wide retention policy for every evidence type.
Test the repository before relying on it
Select an earlier reviewed workpaper and retrieve each referenced artifact. Check permissions with a restricted account and confirm that an export retains useful identifiers and relationships. Record broken links, missing versions, and ambiguous periods as issues to fix.
IABuddy connects evidence with requests, samples, testing, review, and follow-up. Evaluate the evidence management workflow using an older record and a corrected file, not only a new upload. Reliable retrieval is a tested capability, not a promise implied by centralization.
Frequently asked questions
Should duplicate-looking evidence always be deleted?
No. Determine whether the files are identical copies, different versions, or separate records with similar names. Preserve the evidence and history required to explain prior testing and meet retention or hold obligations.
Can we use one retention period for every audit file?
Only when a properly approved policy and applicable obligations support it. Different records, legal holds, contracts, and jurisdictions may require different treatment.
