SOC 2 has no fixed evidence retention period. The AICPA doesn’t tell service organizations to keep evidence for one year, three years, or seven. What it does require is proof that every in-scope control operated across the entire audit period. That’s stricter than it sounds, because a log that expires before your auditor samples it is a control you can no longer prove.
That makes evidence retention one of the few SOC 2 topics where a configuration default can cost you a clean report. Below, we walk through what the AICPA and the Trust Services Criteria require and how long to keep each type of evidence. We also cover where HIPAA, PCI DSS, ISO 27001, and GDPR change the answer, and how to store and automate evidence so it holds up when the auditor tests it.
For most SaaS teams, the short answer is this. Keep evidence for the current observation period plus at least one prior period, and keep security logs searchable for 12 months. Go longer only when a contract, a regulation, or a legal hold says you have to.
What Is SOC 2 Evidence Retention vs. Data Retention: Key Distinctions
Teams often lump the two into one policy, which causes trouble later. Data retention governs the information your product processes: customer records, personal data, backups. Evidence retention governs the proof that your security program ran: who approved a change, when an account was revoked, whether a quarterly review happened.
The two pull in opposite directions. Data minimization pushes you to delete customer data once its purpose ends. Audit needs push you to keep evidence until the period has been tested and reported. So you need a separate schedule for each, plus a plan for where they overlap. A screenshot of a user list is both audit evidence and personal data.
Why Evidence Retention Matters for SOC 2 Audits
A SOC 2 report is an opinion on what your auditor could verify. Auditors don’t accept recollection or a policy statement as proof that a control operated. They request populations, pull samples from across the period, and test each one. When the evidence for a sample no longer exists, the auditor records an exception, and enough exceptions against one criterion can push the report toward a qualified opinion.
You can’t backfill, either. Auditors treat evidence created after the fact far more harshly than the gap it was meant to cover. We cover how that plays out in practice in our breakdown of SOC 2 controls auditors reject even when your compliance tool says passing.
Types of Evidence Auditors Expect to See
Auditors work from an evidence request list, often called a PBC list (“provided by client”). Most requests fall into six types:
- Policies and procedures, with version history and approval dates
- System-generated populations: every new hire, termination, production change, or incident during the period
- Records of control operation: tickets, approvals, review sign-offs, meeting minutes
- Configuration evidence: settings exports or screenshots showing MFA, encryption, logging, and retention
- Logs and monitoring output from identity providers, cloud platforms, and security tools
- Third-party artifacts: vendor SOC 2 reports, penetration test reports, insurance certificates
Be careful with populations. Before they sample, auditors test the completeness and accuracy of any list your systems produce, so keep the underlying records and not just the summary.
SOC 2 Evidence Retention Requirements
No Trust Services Criterion sets a retention period for audit evidence. Your real requirements come from three places: the auditor’s need to test the full period, the commitments in your system description and customer contracts, and the laws that apply to the data you handle.
AICPA Guidance on Evidence Preservation
SOC 2 examinations are attestation engagements performed under the AICPA’s attestation standards (SSAE 18, codified as the AT-C sections). AT-C section 105 places its retention rules on the service auditor, not on you. The CPA firm must assemble its final engagement file within 60 days of the report release date, may not discard documentation before its retention period ends, and must keep it long enough to satisfy the firm’s needs and any legal requirements. Many firms keep engagement files for five years or more, which mirrors the AICPA’s floor for private-company financial statement audits. Some state accountancy boards set their own minimums on top of that.
This part is easy to miss. Your auditor’s workpapers contain copies of what you supplied, but they belong to the firm, so you can’t treat them as your archive. Your own obligation is defined by what your controls, policies, and contracts say you retain, and the auditor will test you against exactly that.
Trust Services Criteria Tied to Evidence Retention
Several criteria in the AICPA’s 2017 Trust Services Criteria (with revised points of focus, 2022) either address retention directly or can’t be tested without it. The Confidentiality and Privacy rows apply only when those categories are in scope.
| Criterion | What it covers | Retention implication |
|---|---|---|
| CC2.1 | Relevant, quality information supports internal control | Evidence must be complete, accurate, and attributable |
| CC4.1 | Ongoing and separate evaluations of controls | Monitoring results must persist across the period |
| CC7.2 | Monitoring system components for anomalies | Security logs must cover the full observation window |
| CC7.3 and CC7.4 | Evaluating and responding to security incidents | Incident records kept through investigation and audit |
| CC8.1 | Authorizing, testing, and approving changes | Change tickets, approvals, and deployment records kept |
| A1.2 | Backup processes and recovery infrastructure | Backup jobs and restore test results kept |
| C1.1 and C1.2 | Retaining and disposing of confidential information | A retention schedule plus proof of disposal |
| P4.2 and P4.3 | Retaining and disposing of personal information | Retention limited to the stated purpose; disposal proven |
Type 1 vs. Type 2 Evidence Retention Considerations
- A Type 1 report assesses control design at a single point in time, so the evidence burden is lighter: policies, configurations, and records that show each control existed on the report date. The catch is dates. Each artifact has to show the state of things on the report date itself, not the week before or after.
- A Type 2 report tests operating effectiveness over an observation window of at least three months, usually six to twelve. The auditor can sample any occurrence of any recurring control, so your retention clock starts on day one of the window, not when fieldwork begins.
Audit Period vs. Post-Audit Retention Obligations
During the audit period, keep everything that evidences a control and make sure you can find it again. After the report is issued, four things drive how long you keep it:
- The next audit. Reports usually run back to back, and auditors follow up on prior-period exceptions and remediation.
- Bridge letters. Management signs these to cover the time from the end of the report period to today, typically up to three months. You should be able to support what you sign.
- Customer contracts. MSAs and DPAs often grant audit rights and specify record retention, commonly three to seven years.
- Regulation. HIPAA, PCI DSS, and privacy law set their own clocks, covered below.
How Long Should You Retain SOC 2 Evidence?
Retain evidence for at least the full observation period plus fieldwork, and for most evidence types, through the following audit cycle as well. Anything shorter leaves you exposed to sample requests you can’t answer.
Minimum Retention Periods for Audit Evidence
The practical floor runs from the first day of the observation period until the report is issued. With a twelve-month window and two to three months of fieldwork and reporting, your oldest evidence needs to survive roughly fifteen months. Keep less, and you’re hoping the auditor skips the early months.
Insider Note: Some of the most avoidable first-year Type 2 exceptions start with a default setting rather than a missing policy. Many identity providers, SaaS admin consoles, and cloud audit trails only keep 90 days of history until someone sets up an export or longer storage. AWS CloudTrail’s built-in event history, for example, covers 90 days. If the auditor then samples an access change from month two of a twelve-month window, the record is already gone, and no policy document can stand in for it.
Recommended Retention Windows by Evidence Type
The AICPA doesn’t prescribe these windows. Treat them as sensible defaults for a SaaS company on an annual SOC 2 cycle, and lengthen them where a contract or regulation asks for more.
| Evidence type | Practical minimum | Recommended default | Reason to go longer |
|---|---|---|---|
| Security and audit logs (identity provider, cloud, endpoint, SIEM) | Observation period plus fieldwork | 12 months searchable, archived to 3 years | Incident investigations, PCI DSS alignment |
| Access provisioning, reviews, and terminations | Current period | Current plus two prior periods (about 3 years) | Follow-up on prior exceptions, access disputes |
| Change management records | Current period | About 3 years | Root-cause analysis on old releases |
| Policies and procedures (every version) | Versions in effect during the period | 6 years after superseded | HIPAA documentation rule, contract disputes |
| Risk assessments, pen tests, vulnerability scans | Current period | 3 years | Showing remediation trends over time |
| Incident response records | Current period | 3 years, longer under legal hold | Litigation, regulator inquiries, breach notices |
| Vendor reviews and vendor SOC reports | Current period | Life of the relationship plus 3 years | Questions about subservice organizations |
| HR, onboarding, and training records | Current period | Per local employment law | Labor law usually sets the longer clock |
| Issued SOC 2 reports, bridge letters, management assertions | Life of the current report | 7 years | Customer due diligence and M&A requests |
Overlapping Requirements (HIPAA, PCI DSS, ISO 27001, GDPR)
When SOC 2 sits alongside other frameworks, the strictest applicable rule sets the clock for any evidence that serves both. Unlike SOC 2, some of them give you a number.
| Framework | Retention rule | Effect on SOC 2 evidence |
|---|---|---|
| HIPAA Security Rule | Documentation kept 6 years from creation or last effective date (45 CFR 164.316) | Policies, risk analyses, and safeguard records for ePHI systems follow the 6-year clock |
| PCI DSS v4.0.1 | Requirement 10.5.1: 12 months of audit log history, latest 3 months immediately available (PCI SSC document library) | Logs for in-scope systems need 12 months, with 3 months searchable on demand |
| ISO 27001:2022 | No fixed period; Clause 7.5.3 requires controlled retention and disposition, Annex A 5.33 protects records | Retaining evidence across the 3-year certification cycle keeps surveillance audits simple |
| GDPR | Article 5(1)(e) storage limitation: personal data kept no longer than necessary (Regulation (EU) 2016/679) | Evidence containing personal data needs a justified, documented retention period |
NIST CSF doesn’t set retention periods either, though its logging and recovery outcomes assume you keep enough history to investigate and restore. Teams running SOC 2 and ISO 27001 together can collect most evidence once and tag it to both. Our guide to mapping SOC 2 controls to ISO 27001 shows where the overlap sits.
Handling Legal Holds and Litigation
A legal hold overrides every retention schedule you have. Once litigation or a regulatory investigation is reasonably anticipated, you must preserve relevant records, including evidence already scheduled for deletion. In US federal courts, Federal Rule of Civil Procedure 37(e) allows courts to sanction parties that lose electronically stored information they should have preserved.
Your policy should name who can issue a hold, how it reaches every system that deletes data automatically, and how it gets lifted. The middle part is the one teams tend to skip.
Important: Automated deletion is the easiest legal hold risk to miss. A lifecycle rule on a log bucket or a retention setting in your GRC platform will keep deleting on schedule unless the hold procedure explicitly pauses it. Test that pause before you need it.
Categories of SOC 2 Evidence to Retain
Most of what lands on a SOC 2 evidence request list falls into seven categories. Each one tends to fail in its own way, so it helps to know what auditors test in each.
Access Control and Identity Evidence
Keep provisioning tickets with approvals, MFA and SSO enforcement settings, privileged access grants, and termination records with timestamps from the identity provider and any application outside SSO. For access reviews, auditors look for four things: the full population of accounts at review time (service accounts and admin roles included), who reviewed it and when, a disposition for each account, and proof that flagged access was actually removed.
Auditors look hardest at timing when they test terminations. If your policy says access is revoked within 24 hours, the auditor will compare HR termination dates against revocation timestamps for every sampled leaver. Our employee offboarding checklist lists the records worth capturing at each step.
Change Management Records
Retain pull requests with reviewer approvals, linked tickets, CI/CD run results, deployment records, and documentation for emergency changes. Auditors typically pull the population of production changes from your system of record (merged pull requests or deployment history) and sample from it, so that history needs to stay intact for the whole period.
Keep configuration history too. If branch protection was disabled for two weeks in month four, the auditor will want to know which changes were merged during that window and who approved them.
System and Security Monitoring Logs
This category covers identity provider authentication logs, cloud audit trails, endpoint detection alerts, SIEM alerts, and vulnerability scan results. NIST’s Guide to Computer Security Log Management (SP 800-92) remains a solid reference for deciding what to log and how to protect it.
Raw logs alone won’t satisfy CC7.2, though. Auditors want evidence that someone reviewed alerts and acted on them: triage tickets, escalation records, and closure notes. Retain the review trail alongside the logs, because a perfectly preserved log nobody looked at is still an exception.
Vendor and Third-Party Review Documentation
Keep your vendor inventory, risk ratings, completed security questionnaires, contracts and DPAs, and each critical vendor’s SOC 2 report with any bridge letter. Retain the version of the vendor’s report that was current during your observation period, not just the latest one.
If you rely on a subservice organization such as a cloud host, also keep evidence that you reviewed its complementary user entity controls and confirmed you operate the ones that apply to you.
Risk Assessments and Incident Response Records
Retain the annual risk assessment with a dated risk register and treatment decisions, plus incident tickets, timelines, root-cause analyses, customer or regulator notifications, and tabletop exercise records. Incident evidence often needs a longer retention window than anything else, because it can resurface in litigation or a regulator inquiry years later.
A quiet year still produces evidence. If no incidents occurred, keep the incident log that shows none were recorded and the tabletop exercise that proved the plan works.
HR and Onboarding/Offboarding Evidence
Auditors test CC1 controls through HR records: signed confidentiality agreements, background check confirmations where local law permits them, onboarding checklists, performance reviews, and termination checklists. This is some of the most sensitive evidence you hold, so restrict access tightly and redact anything the auditor doesn’t need to see.
Local employment law usually sets a longer retention clock than SOC 2 does. Follow it, and make sure your HR system and your evidence repository agree on when records get deleted.
Policy Acknowledgments and Training Records
Keep signed policy acknowledgments, security awareness training completions with dates, and phishing simulation results. Each acknowledgment should tie to the specific policy version the employee accepted, which means you also need to retain every version of every policy that was in effect during the period.
Building a SOC 2 Evidence Retention Policy
A good evidence retention policy fits on a few pages and answers four questions: what’s covered, who owns it, how long it lives, and how it dies. Auditors will test whether you follow it, so leave out anything you won’t do.
Defining Scope and Evidence Owners
Start with the in-scope systems from your system description and the control set they support. Every control gets a control owner who is responsible for producing its evidence on schedule and confirming it lands in the repository. One person, usually the security or compliance lead, owns the policy itself and reviews it annually.
Assign owners by name or role rather than by team. When “Engineering” owns the quarterly access review, nobody in particular does it.
Classifying Evidence by Sensitivity and Control
Apply your existing data classification scheme to evidence. Most access lists and HR records are confidential, and some screenshots capture customer data that is more sensitive still. Classification decides who can view each item and how it must be stored.
Then tag every item with the control it supports and the audit period it belongs to. With that metadata in place, you can answer an auditor’s request in minutes and apply retention rules automatically later.
Pro Tip: Tag Each Piece of Evidence
Tag each piece of evidence with three things at upload: the control ID (for example CC6.2), the audit period, and the source system. If you also run ISO 27001 or HIPAA, add those control references too. Once it's tagged, you can find it in seconds and expire it by rule. Untagged evidence piles up until someone sorts through it by hand the week before fieldwork.
Setting Retention Schedules per Evidence Category
Your retention schedule is a table: evidence category, retention period, the event that starts the clock, and the disposal method. Don’t skip the trigger, either. “Three years” means something different when the clock starts at creation, at the end of the audit period, at an employee’s termination, or at the end of a vendor relationship.
Use the windows earlier in this guide as a starting point, then check them against your customer contracts and any regulation in play. Review the schedule annually and whenever you sign a contract with unusual record-keeping terms.
Documenting Destruction and Disposal Procedures
Your policy also has to cover how evidence gets destroyed. Define approved methods for each storage type, such as verified deletion, cryptographic erasure, or a vendor’s certificate of destruction. Require approval before anything is destroyed, and log what was deleted, when, and by whom. Every disposal run should check for active legal holds first.
If Confidentiality or Privacy is in scope, the auditor will test disposal under C1.2 or P4.3 directly. Our guide to secure data disposal requirements across ISO 27001, SOC 2, and GDPR covers the methods and records in detail.
Secure Storage of SOC 2 Evidence
Your evidence repository holds access lists, configuration details, and incident timelines. To an attacker, that’s a map of your security program, so protect it at least as well as the systems it describes.
Encryption and Access Controls
Encrypt evidence at rest (AES-256 is the common baseline) and in transit (TLS 1.2 or higher). Limit write access to control owners and the compliance lead, give auditors read-only access scoped to the current engagement, and require MFA for everyone.
Separation of duties is the piece teams tend to forget. The engineers whose activity a log records shouldn’t be able to edit or delete that log. If a cloud administrator can prune the audit trail of their own actions, an auditor will question every log you produce.
For logs and finalized evidence, use immutable storage, often called WORM (write once, read many). Object storage with retention locks, log platforms with integrity validation, and cryptographic hashes recorded at collection all make tampering detectable or impossible.
Immutability supports chain of custody: a record of who collected each item, from which system, and when, showing it hasn’t changed since. Auditors rarely ask for a formal chain-of-custody document in a routine SOC 2, but the moment evidence ends up in a dispute or an investigation, you’ll be glad you have one.
Backup, Redundancy, and Disaster Recovery
Treat the evidence repository as a production system. Back it up to a separate account or region, include it in your business continuity plan, and test a restore at least once a year. A ransomware incident that encrypts your evidence store mid-period creates an audit problem on top of a security one.
Centralized Evidence Repositories vs. Distributed Storage
Most teams end up choosing between a central repository (usually a GRC platform or dedicated storage) and leaving evidence in the source systems that generated it.
| Factor | Centralized repository | Distributed in source systems |
|---|---|---|
| Auditor experience | One place to look; fast responses to requests | Requests become scavenger hunts across tools |
| Retention control | One schedule, enforced in one place | A different default in every tool |
| Risk from tool changes | Low, if the repository is stable | High: migrations and cancellations erase history |
| Raw log volume | Expensive and awkward to centralize | Logs stay where they’re cheapest to keep |
| Best for | Reviews, sign-offs, snapshots, policies | High-volume logs with enforced retention settings |
In practice, most teams land on a hybrid. Raw logs stay in the logging platform or cloud storage with enforced retention, while the central repository holds review records, approvals, snapshots, and pointers to the source logs, all tagged by control and period.
Automating SOC 2 Evidence Retention
Manual evidence collection breaks down in predictable ways. People forget, people leave, and screenshots get taken on the wrong day. Automation fixes most of that, as long as you know what it captures and what it misses.
Continuous Evidence Collection Tools
A GRC platform connects through APIs to your cloud provider, identity provider, HR system, code repositories, and device management tools, then collects configuration snapshots and runs control tests on a schedule. That replaces the pre-audit screenshot scramble with a running record, and continuous monitoring flags drift while there’s still time to fix it.
There’s a limit, though. Most platforms capture point-in-time snapshots and test results, not your full raw logs. The logs themselves stay in the source system, which means their retention settings still need your attention.
Integrating GRC Platforms with Source Systems
Map every integration to the controls it evidences, then list the in-scope systems that have no integration. Those gaps need manual evidence on a calendar with a named owner, or they will go uncollected for months.
Monitor integration health as well. An expired API token can stop evidence collection for weeks without anyone noticing, and the auditor will find that gap long after you can do anything about it.
Automating Retention Enforcement and Expiry
Enforce retention where the data lives: lifecycle rules on object storage, retention settings in your log platform, scheduled exports from SaaS tools with short native history. Define those settings in infrastructure-as-code where you can, so changes go through review and leave a record.
Automated expiry needs the same discipline. Deletion jobs should run against the retention schedule, check for legal holds first, and log what they removed.
Audit Trails for the Evidence Itself
Auditors sometimes ask a follow-up question: how do you know this evidence hasn’t changed since you collected it? Answer it with versioning on the repository, access logs showing who uploaded or changed each item, and integrity checks on finalized evidence.
It’s the same logic SOC 2 applies to your production systems. A repository with no record of its own changes asks the auditor to take your word for it, and auditors are paid not to.
Common SOC 2 Evidence Retention Pitfalls
Most evidence problems surface during fieldwork, which is the worst time to find them. These four come up again and again.
Gaps in Evidence Across the Audit Period
Gaps come from a handful of sources: a log retention setting shorter than the observation window, a quarterly review skipped during a busy quarter, a broken integration nobody noticed, or a new system added mid-period without logging switched on. Each one turns into an exception for every sample that lands in the gap.
A gap you can’t explain can end up as a qualified opinion your customers will read. Even if you catch it early, you may have to restart the observation window, which pushes your report back by at least a quarter.
Important: Once a period has passed, you can’t fix its evidence. You can disclose the exception, show remediation, and point to compensating controls, which auditors generally treat as a minor finding. Recreating evidence after the fact can escalate to a qualified opinion or end the engagement.
Inconsistent Timestamps and Metadata
A screenshot with no visible date proves nothing about when it was taken. Neither does a file’s modified date, which changes every time someone copies it. Mixed time zones cause their own confusion: a termination logged in UTC and an HR record in local time can make a same-day revocation look late.
Standardize on UTC, capture system-generated timestamps in every export, keep server clocks synchronized, and require that screenshots show the date, the system, and any filters applied.
Lost Evidence from Tool Migrations or Offboarded Staff
Tool migrations are one of the most common ways evidence disappears. Moving from one ticketing system, identity provider, or GRC platform to another frequently leaves old records behind, and cancelling the old subscription deletes them for good. Export everything still within a retention window before you decommission anything.
Staff turnover does the same thing. When a control owner leaves and their account is deleted, evidence stored in their personal drive or direct messages goes with them. Keep evidence in shared repositories owned by a team or service account, never an individual.
Over-Retention and Privacy Risk
Keeping everything forever feels safe, but it isn’t. Every extra year of retained evidence widens the impact of a breach, raises storage costs (high-volume logs get expensive fast), and expands what you may have to produce in litigation. It can also conflict with GDPR’s storage limitation principle, since evidence routinely contains employee and sometimes customer personal data.
Apply data minimization to evidence: redact what the auditor doesn’t need, prefer metadata over full content where it proves the point, and delete on schedule, keeping a record that you did.
SOC 2 Evidence Retention Checklist
Use this checklist at three points in the audit cycle. Each item maps to a failure covered earlier in this guide.
Pre-Audit Evidence Review
- Confirm the observation period dates with your auditor and list every expected occurrence of each recurring control.
- Verify that log retention on every in-scope system covers the full period plus fieldwork.
- Pull populations (new hires, terminations, production changes, incidents) and spot-check them against source systems for completeness.
- Check that every evidence item shows a date, a source system, and a control mapping.
- Document any gaps you can’t close, along with remediation and compensating controls, before the auditor finds them.
Ongoing Retention Maintenance
- Review GRC integration health at least monthly and fix broken connectors the same week.
- Keep a control calendar with a named owner for every recurring control.
- Review retention settings quarterly and alert on any change to them.
- Export evidence before decommissioning a tool or offboarding a control owner.
- Re-check the retention schedule annually against customer contracts and applicable regulations.
Post-Audit Archival Steps
- Archive the final evidence set, the request list, and your responses in read-only storage.
- Store the issued report, management assertion, and any bridge letters with your long-term records.
- Record remediation for every exception so next year’s follow-up is straightforward.
- Apply retention dates to the archive and confirm no legal hold applies before scheduled deletion.
- Feed lessons learned into the next period’s control calendar.
Getting SOC 2 Evidence Retention Right
SOC 2 won’t hand you a retention number, so you have to pick one that holds up under testing. At a minimum, cover the full observation period plus fieldwork, and keep most evidence through the next audit cycle. Where HIPAA, PCI DSS, or a customer contract sets a longer clock, follow it, then delete on schedule once the reason to keep something runs out. Most failures come from defaults nobody changed and evidence nobody owned. Both are cheap to fix before the observation window opens and impossible to fix after it closes.
At Axipro, we assign evidence owners and check retention settings early in every engagement through our SOC 2 compliance services, because the evidence an auditor samples in month eleven has to exist from month one.
Frequently Asked Questions
How long must SOC 2 evidence be retained after an audit?
There’s no AICPA-mandated period for the service organization, so your own policy, contracts, and regulations set it. A sensible default is to keep evidence until the next audit is complete, which covers prior-year follow-up, and around three years for most categories. Go longer wherever HIPAA, PCI DSS, a customer contract, or a legal hold calls for it.
Is there a 7-year retention rule for SOC 2 evidence?
No. The seven-year figure comes from the Sarbanes-Oxley Act, which requires auditors of public companies to keep their audit workpapers for seven years, a rule the SEC approved in the PCAOB’s audit documentation standard. It applies to those audit firms, not to SOC 2 evidence held by a service organization, although some customer contracts adopt seven years by choice.
Can evidence be stored with a third-party vendor?
Yes, and most companies do, whether in a GRC platform or cloud storage. Treat that provider like any other vendor: review its security, confirm the contract lets you export your evidence and keeps it available after termination, and include it in your vendor management program.
What happens if evidence is missing during a SOC 2 audit?
The auditor can’t test the affected sample, so it gets reported as an exception, and widespread gaps against one criterion can lead to a qualified opinion. You may get a chance to supply alternative evidence during fieldwork, but never recreate evidence after the fact. Disclose the gap, show remediation, and point to any compensating controls.
How does evidence retention differ between SOC 2 Type 1 and Type 2?
A Type 1 needs evidence showing that controls were designed and in place on a single date, so retention mostly concerns accurately dated artifacts. A Type 2 needs evidence for every occurrence of every control across an observation window of at least three months, usually six to twelve, so retention has to cover the entire window from its first day.
Do auditors require original evidence or are screenshots acceptable?
Screenshots are usually acceptable when they show the source system, the date and time, and any filters or parameters used. For populations, auditors prefer system-generated exports and will test them for completeness and accuracy, and some will ask to observe a query run live. Copies are fine as long as you can show they haven’t changed since collection.
