The screenshot problem
Most SOC 2 programmes still rely on quarterly screenshot collection. It is fragile, expensive, and tells you nothing about the state of controls in between.
A pull based pipeline turns that around. The audit asks for evidence by reading the system, not by asking a human to gather it.
Architecture
Sources of truth (Okta, GitHub, AWS Config, JAMF, Jira) expose APIs. A collector (Drata, Vanta, or a small custom service) pulls state on a schedule and writes it to a structured store.
A control mapping translates between system state and the control library (SOC 2, ISO, CIS). Continuous tests run hourly and raise findings when controls drift. Findings flow into an exceptions register with owners and due dates.
For the auditor
The auditor gets a read only portal. Evidence is dated, hashed, and tied to a control. The immutable archive is an S3 bucket with object lock. Nothing in the audit window can be quietly amended.
- control owner assigned to every control, named in the system
- exception register with executive sign off
- quarterly board pack auto generated from the same store
- risk register cross linked to controls and exceptions
- customer trust portal serves a curated subset
What it feels like
Audit season stops being a season. It becomes a Monday morning report. The team focuses on remediating real drift rather than packaging old screenshots.
References
Official documentation and standards we draw on for this pattern.
AICPA Trust Services Criteria
aicpa-cima.com
ISO/IEC 27001
iso.org
NIST Cybersecurity Framework
nist.gov
AWS S3 Object Lock
docs.aws.amazon.com
CIS Controls v8
cisecurity.org
Links open in a new tab
Takeaway
If the audit cannot read your controls directly, you are paying twice. Once to run the controls, once to prove they ran.