Evidence vs. Attestation

The single biggest misunderstanding in SOC 2 preparation: teams think *saying* a control exists is evidence. It isn't.

A written policy says you require MFA. Evidence is a screenshot of your IAM credential report showing every user has MFA enrolled, timestamped within the audit period.

Auditors are trained to distinguish between:

• Design evidence — proof that a control is configured
• Operating effectiveness evidence — proof that the control ran consistently over time

Type I audits primarily need design evidence. Type II audits need both.

What Makes Evidence Valid

Good evidence has four characteristics:

Timestamp — when was this captured? Screenshots with no date are nearly useless.

Source — where did this come from? A screenshot of an AWS console is stronger than a spreadsheet someone filled in.

Completeness — does it cover the full population, not just selected examples?

Integrity — can it be verified? SecureSpect checksums all evidence it collects so auditors can verify it hasn't been modified.

Evidence by Control Category

Access Control (CC6)

What auditors want:

• Complete list of users with system access, their roles, and whether MFA is enabled
• Evidence of access reviews — who reviewed, when, what was changed as a result
• Offboarding records — when was access removed for departed employees?

Strong evidence:

• AWS IAM credential report (system-generated, timestamped, complete)
• HRIS offboarding tickets with access termination confirmation
• Quarterly access review meeting notes signed by reviewer

Weak evidence:

• "We reviewed access" without a record of what was reviewed and by whom

Change Management (CC8)

What auditors want:

• Evidence that changes to production systems go through a review and approval process
• Pull request records showing reviews before merge
• Deployment logs showing who deployed what and when

Strong evidence:

• GitHub PR history showing required reviewers approved before merge
• CI/CD pipeline logs showing tests passed before deployment

Weak evidence:

• A change management policy document without any deployment records to match it

Monitoring and Alerting (CC7)

What auditors want:

• Evidence that security events are logged and reviewed
• Proof that alerts fire when anomalies occur and that someone responds

Strong evidence:

• CloudTrail enabled with multi-region logging (SecureSpect checks this automatically)
• GuardDuty findings log with documented responses
• On-call incident records showing response to alerts

Encryption (CC6.7)

What auditors want:

• Encryption at rest for databases, object storage, and secrets
• Encryption in transit (TLS) for all external-facing endpoints

Strong evidence:

• RDS instance details showing StorageEncrypted: true
• S3 bucket policy enforcing aws:SecureTransport
• KMS key configuration with rotation enabled

Organizing Evidence for Submission

Create a folder structure mirroring the TSC control IDs:

SOC2-Evidence/
├── CC2 - Communication and Information/
│   ├── security-policy-v2.3.pdf
│   └── employee-training-completions-Q3-2026.csv
├── CC6 - Logical and Physical Access/
│   ├── iam-credential-report-2026-09-01.csv
│   ├── access-review-Q2-2026-signed.pdf
│   └── offboarding-tickets-2026.xlsx
├── CC7 - System Operations/
│   ├── cloudtrail-enabled-all-regions.png
│   └── guardduty-enabled-screenshot.png
├── CC8 - Change Management/
│   └── github-pr-policy-screenshot.png
└── CC9 - Risk Mitigation/
    └── vendor-security-questionnaires/

Continuous vs. Point-in-Time Collection

The traditional approach — collecting evidence the week before an audit — creates three problems:

You can't prove controls operated over the full period

You scramble to find evidence that may no longer exist (log retention, configuration history)

Auditors can tell when evidence is rush-assembled

The better approach: collect evidence continuously throughout the observation period. SecureSpect does this for technical controls automatically — every sync produces timestamped, checksummed evidence that builds your audit trail day by day.

For manual controls (access reviews, training records), establish a recurring calendar reminder and file evidence immediately after each process runs.