# Evidence Collection and Audit Readiness
Evidence collection and audit readiness is the operational discipline of continuously gathering, organizing, and maintaining documented proof that security controls are functioning as designed. In the context of compliance frameworks such as SOC 2 Type II, ISO 27001, PCI DSS, HIPAA, and FedRAMP, an auditor's job is to verify that controls are not merely documented on paper but actually operating in practice over an extended period. Evidence is the raw material that makes that verification possible.
Evidence in a compliance context is any artifact that demonstrates a control was in place and working at a specific point in time. A firewall rule export proves your network segmentation policy is configured as intended. A terminated employee's account disable log proves your offboarding process executed within the required window. A completed access review report proves that someone with authority looked at who has what access and made deliberate decisions about it.
The distinction between audit readiness and simply "passing an audit" is one of the most important operational concepts in the Risk Governance and Assurance space. An organization that scrambles to collect evidence in the six weeks before an audit is not audit-ready. It is audit-reactive. The difference is not semantic. Scrambling produces incomplete records, introduces gaps in the evidence timeline, creates pressure on staff to reconstruct historical activities from memory, and significantly increases the probability of audit findings.
Within the Planetary Defense Model, evidence collection and audit readiness sit squarely in the RGA domain: Risk Governance and Assurance. RGA is the outermost orbital layer, the place where the entire defense posture is measured, reported, and held accountable. CDA's methodology for RGA is Perpetual Compliance Assurance (PCA), built on the principle that compliance is not an event but a state. Evidence collection is the operational engine that keeps that state continuously valid.
Audit readiness programs center on six categories of evidence, each serving a distinct purpose in proving that controls operate effectively.
Category 1: Screenshots and Configuration Exports
Configuration-based evidence proves that a system is set up the way policy requires. This includes firewall rule exports that prove network segmentation is configured correctly, access control list exports that show which roles have which permissions, multi-factor authentication configuration screenshots showing MFA is enforced on privileged accounts, and encryption configuration exports showing data at rest is protected with approved algorithms. Configuration evidence has a critical weakness: it proves the system was configured correctly at the moment of capture, not that it has been configured correctly throughout the audit period. This is why point-in-time screenshots must be collected on a defined schedule, typically monthly or quarterly, so auditors can see a timeline of consistent configuration rather than a single snapshot taken the day before the audit.
Category 2: Reports
Reports document the results of recurring control activities. Vulnerability scan reports prove the organization runs scheduled scans and shows the remediation status of findings. Access review completion reports show that access certifications were completed within the required timeframe. Penetration test reports with remediation tracking demonstrate that the organization not only identifies weaknesses through testing but closes them. Background check completion reports provide evidence for personnel security controls. Reports are most valuable when they carry consistent metadata: who ran the report, when it was generated, and what action was taken based on the findings.
Category 3: Logs
Logs are the continuous audit trail of system activity. SIEM (Security Information and Event Management) logs provide evidence of monitoring, alerting, and investigation activity. Access logs show who authenticated to what system and when. Privileged access logs document the use of admin credentials, which is a high-attention area for virtually every compliance framework. Change logs record when system configurations were modified and by whom. The challenge with logs is volume and retention. Most compliance frameworks specify minimum log retention periods (SOC 2 commonly expects 12 months of audit log retention). Organizations that have not configured centralized log retention with appropriate timeframes will find themselves unable to produce evidence for the full audit period.
Category 4: Policies
Policies are the documented intent behind controls. Signed and dated policy documents with version control demonstrate that governance decisions were made deliberately and that accountability was assigned. Policy evidence must show not just that a policy exists but that it was approved by the appropriate authority (typically a member of leadership or the security committee), communicated to employees, and acknowledged. Most frameworks want policies reviewed and re-approved at least annually. A policy document with a last-reviewed date from three years ago is a finding waiting to happen.
Category 5: Training Records
Training records prove that employees received the security awareness training required by policy. This includes completion certificates from the security awareness training platform, attendance records for live training sessions, and phishing simulation results that demonstrate ongoing education. Training evidence is commonly underestimated. Organizations frequently complete the training but neglect to retain the completion records in an organized, exportable format. GRC platforms that integrate with training tools solve this by pulling completion data automatically.
Category 6: Tickets
Ticket evidence from IT service management and change management systems provides a chronological record of operational decisions. Change management tickets show that production changes went through an approval process before deployment, addressing the change management ITGC that auditors test in every SOX and SOC 2 engagement. Incident tickets document how security events were identified, escalated, and resolved, providing evidence for incident response controls. Vendor review tickets show that third-party risk assessments were conducted on schedule.
The "annual scramble" is one of the most predictable and expensive dysfunctions in enterprise security operations. Organizations that do not maintain continuous evidence collection spend six to twelve weeks before each audit in reactive mode. Security and GRC staff pull historical records from systems that were not designed for evidence export. They request logs that may or may not have been retained. They reconstruct access reviews that were completed verbally without documentation. They track down policy acknowledgment records scattered across email inboxes.
This scramble is expensive in three ways. First, direct cost: GRC analyst time spent reconstructing historical evidence is time not spent on forward-looking risk management. At mid-market organizations, this can consume 30 to 40 percent of GRC capacity during audit season. Second, risk of findings: when evidence reconstruction is incomplete, auditors identify gaps that represent actual findings, not just missing paperwork. A finding for "access reviews not completed" is far more damaging than the actual gap in access review completion, because it becomes part of the audit report shared with customers and regulators. Third, potential misrepresentation: under extreme pressure, teams sometimes present evidence that overstates the completeness of the control, creating legal and regulatory exposure that compounds the original problem.
Continuous evidence collection eliminates the scramble entirely. When evidence is collected automatically throughout the year, the auditor's request for 12 months of evidence is answered by opening the GRC platform and exporting what was already collected. Audit preparation becomes logistics rather than archaeology.
The modern approach to continuous evidence collection relies heavily on automation. Three categories of tooling have emerged to solve this problem at scale.
GRC Platform Evidence Connectors
Commercial GRC platforms including Vanta, Drata, Secureframe, and Tugboat Logic offer native integrations with the cloud infrastructure, security tools, and business systems that generate compliance evidence. A Vanta connector to AWS pulls configuration exports from EC2, RDS, S3, and IAM on a defined schedule and stores them in the evidence vault. A Drata connector to Okta pulls MFA enforcement configuration and user access data. Connectors to CrowdStrike pull endpoint protection status. Connectors to GitHub pull repository access controls and code review completion evidence. These integrations mean that a significant portion of evidence collection requires zero manual effort after the initial configuration.
The value of this approach compounds over time. After the first year, the GRC platform contains a full 12-month evidence history for every connected system. Each subsequent year adds to that history, making the organization demonstrably more audit-ready and providing trend data that supports continuous improvement narratives in board reporting.
API-Based Custom Collection
For systems without native GRC platform connectors, scripted collection using API integrations fills the gap. Organizations write scheduled scripts (typically in Python or Go) that authenticate to internal tools, extract compliance-relevant configuration data or activity records, and push them to the GRC platform's evidence vault or a designated secure storage location. These scripts run on a defined cadence (weekly or monthly for configuration captures, daily for high-frequency operational evidence like access logs) and produce timestamped artifacts that are immediately usable as audit evidence.
Screenshot Automation
Some controls are most naturally evidenced by UI configuration screenshots because the underlying data is not available via API. Tools built on headless browser frameworks can capture configuration screenshots on a schedule, automatically timestamping and storing each capture. This is particularly useful for SaaS applications where API access to configuration data is limited.
Evidence Vault Structure
A well-structured evidence vault organizes artifacts by control, by time period, and by collection method. The most effective structure mirrors the control framework being audited: each SOC 2 Common Criteria control or ISO 27001 Annex A control has its own evidence folder, with time-stamped artifacts organized chronologically. When an auditor requests evidence for CC6.1 (Logical Access Controls), the GRC team can produce a complete, organized set of artifacts without searching across multiple systems.
Retention and Access Controls
Evidence must be retained for the duration of each audit period plus the retention period required by the applicable framework and any applicable law. SOC 2 evidence is typically retained for 12 months. HIPAA requires retention of compliance-related documentation for six years. Evidence vaults must have access controls that prevent unauthorized modification (to preserve integrity) while allowing authorized GRC staff and auditors to access records. Version control and immutability features in modern GRC platforms serve this function.
Perpetual Compliance Assurance, CDA's methodology for the RGA domain, is grounded in a single architectural principle: the audit-ready state should be the normal operating state, not a temporary condition achieved through six weeks of intensive effort before an auditor walks in the door.
The PCA evidence engine is the operational implementation of this principle. Rather than treating evidence collection as a pre-audit project, CDA designs compliance programs where evidence collection is a continuous background process. Controls are designed with evidence generation built in from the start. If a control cannot generate its own evidence automatically, that is a signal that the control's design needs to be revisited before implementation.
This connects directly to the broader Planetary Defense Model. In the concentric domain model, RGA is the outer shell that measures and governs the entire defense posture. Evidence collection is what makes that measurement reliable. Without continuous evidence, the outer shell's assessment of the inner layers (DPS, VSD, SPH, IAT, TID) is based on documentation and assertion rather than operating proof. Controls that are documented but not practiced are not controls. The PCA approach closes this gap by ensuring that evidence of actual control operation is collected continuously, making the gap between documented posture and actual posture visible and measurable.
For organizations at the beginning of their compliance journey, CDA recommends starting with the GRC platform evidence connector deployment as the first project in the compliance program buildout. Getting connectors configured and running before the first formal audit period provides 12 months of automatically collected evidence by the time the first audit begins, rather than requiring manual collection retroactively.