SOC 2 Type II Readiness Data & Evidence Checklist for Fintechs
First-time SOC 2 audits stall on a predictable set of evidence gaps: missing access-review logs, inconsistent change-management trails, customer-data inventories that don't match the system actually under audit, and policy documents whose 'last reviewed' date is older than the audit window. This checklist enumerates the specific data and log artifacts a Type II auditor walks through in week one. The earlier you have these structurally captured, the shorter (and cheaper) the engagement.
Common Criteria — control environment & governance
- Information security policy with annual review trail
A current information-security policy document with explicit version, owner, last-reviewed date (within 12 months), and approval signature. Auditors flag policies whose review trail predates the audit window even if the content is sound.
policies.infosec.version, policies.infosec.last_reviewed, policies.infosec.approved_by - Risk assessment register
Documented risk-assessment register with each identified risk, likelihood/impact rating, the control mitigating it, and the owner. Auditors will sample three risks and trace each through to a working control.
risk_register[].risk_id, .control_ref, .owner, .last_reviewed - Vendor / sub-service organization inventory
List of every sub-service organization that handles customer data (cloud providers, observability, customer support tooling) with the SOC 2 / ISO 27001 report on file and the date of last review. Carve-out vs. inclusive method choice must be documented.
vendors[].name, .data_categories_handled, .latest_attestation, .review_date - Org chart & segregation-of-duties map
Current org chart with reporting lines plus an explicit segregation-of-duties matrix showing who can develop, deploy, approve, and access production. SoD violations are the most-cited finding for fintech startups.
org.chart_version, org.sod_matrix
Logical & physical access controls (CC6)
- User access review (quarterly minimum)
Per-system access review with reviewer, review date, accounts reviewed, accounts removed, and exceptions noted. Auditors will sample one quarter and trace a removed-account decision end-to-end.
access_reviews[].system, .quarter, .reviewer, .accounts_removed[] - Provisioning and de-provisioning tickets
JIRA / ServiceNow ticket trail for every joiner / mover / leaver. Termination de-provisioning must show same-day removal of production access — auditors will sample one terminated employee.
iam_tickets[].employee_id, .action, .systems[], .completed_date - MFA enforcement evidence
Identity-provider report showing MFA enrollment for 100% of employee accounts and the configured MFA policy for production access. Service-account exceptions must be documented with compensating controls.
idp.mfa_enrollment_report, idp.mfa_policy_export - Privileged access logs
Logs of every privileged session (sudo, db admin, IAM role assumption) with timestamp, user, action, and target system. Retention typically 12 months minimum.
privileged_access_log
Change management & development (CC8)
- Code-review + approval evidence per merge
Git history showing every production-bound merge has at least one approving review by someone other than the author. Auditors will sample five recent merges to production.
vcs.merge_log[].pr_id, .author, .approvers[], .merged_at - Production deployment trail
CI/CD deployment record with deployer, source commit, target environment, and completion status for every production deploy in the audit window.
ci.deployments[].environment, .commit_sha, .deployer, .completed_at - Emergency change procedure
Documented break-glass procedure for emergency changes with retroactive review requirement. Each break-glass invocation must have a post-event ticket explaining why, who approved, and what was changed.
policies.emergency_change, breakglass_invocations[]
Confidentiality / Privacy (when in scope)
- Data inventory & classification
Inventory of every system that stores customer data with the data classes present (PII, financial, behavioral) and the classification (public / internal / confidential / restricted). The inventory must match the system architecture diagram.
data_inventory[].system, .data_classes[], .classification, .retention_years - Encryption-at-rest and in-transit evidence
Configuration evidence (KMS key policy, TLS certificate inventory, RDS encryption screenshots) for every system in the data inventory. Cleartext stores in dev/staging that mirror prod data structurally are a finding.
encryption.at_rest_evidence, encryption.in_transit_evidence - Subject-data request (SDR) handling log
If subject to CCPA / GDPR, log of every access / deletion / portability request with intake date, response date, and the systems searched. Response-time SLA breaches are findings.
privacy.sdr_log[] - Synthetic vs. production data segregation
Documented use of synthetic data for non-production environments. Auditors increasingly view 'we mask in staging' as inferior to fully-synthetic test data and ask the question explicitly.
data_inventory[].non_prod_substitute_strategy
Availability & monitoring (CC7)
- Incident response log with severity classification
Per-incident record with detection time, severity (P0 / P1 / P2), remediation actions, root cause, and post-mortem link. Auditors sample one P1+ incident and trace end-to-end.
incidents[].id, .severity, .detected_at, .resolved_at, .post_mortem_url - Monitoring & alerting coverage map
Map showing which alerts cover which systems with SLAs for response. Systems not covered must have a documented exception.
monitoring.alert_coverage_map - Backup & restore test evidence
Quarterly restore-test results from production backups with elapsed restore time and integrity check. 'We have backups' without a restore-test record is a finding.
backups.restore_tests[].quarter, .restored_system, .elapsed_minutes, .integrity_passed - Business-continuity / DR plan with last-tested date
Current BC/DR plan with explicit last-tested date (within 12 months) and the test results. Tabletop exercises count if documented.
policies.bcdr.version, policies.bcdr.last_tested
Key takeaways
- Type II is about the operating effectiveness of controls over time, not just their design — every control needs an evidence trail covering the audit window, not just a current screenshot.
- The most-cited findings in first-time fintech audits cluster around access reviews (missed quarters), de-provisioning lag (terminated employees retaining access), and missing approver trails on production merges.
- Synthetic-data-in-non-prod is increasingly an explicit auditor question. 'We mask in staging' is treated as inferior to a documented synthetic-data substitution policy.
- Sub-service organizations (your cloud, observability, support tooling) need their own SOC 2 reports on file with a documented review — your audit inherits their gaps if you don't carve out.