SOC 2 for Retirement Platforms: Why Your Rollover Provider Needs It
Your rollover provider handles Social Security numbers, financial account details, and beneficiary information under ERISA fiduciary obligations. Here is what SOC 2 Type II actually means, what to look for in a vendor's report, and the specific controls that separate compliant platforms from the rest.
TrustRails Team
• Security & ComplianceIf you work on a security or procurement team at a custodian, TPA, or plan sponsor, you have probably seen "SOC 2 compliant" on a dozen vendor pitch decks this quarter. The phrase has become table stakes marketing language, which makes it easy to gloss over. That is a mistake when the vendor in question handles retirement rollover data.
Rollover processing sits at the intersection of two high-stakes domains: financial services regulation and personally identifiable information at scale. A single rollover transaction can touch a participant's Social Security number, date of birth, bank routing numbers, account balances, beneficiary details, and employment history. Under ERISA, the custodians and plan sponsors who select rollover vendors carry fiduciary liability for how that data is handled.
This article is written for the people who have to make that vendor selection decision. We will break down what SOC 2 Type II actually requires, why retirement data creates unique compliance obligations, and exactly what controls to look for when you open a vendor's SOC 2 report.
What SOC 2 Type II Actually Means
Beyond "We Passed an Audit"
SOC 2 is a framework developed by the AICPA (American Institute of Certified Public Accountants) that defines criteria for managing customer data. Unlike a point-in-time certification, SOC 2 Type II evaluates whether an organization's controls are not only designed correctly but operating effectively over a sustained examination period, typically 6 to 12 months.
The distinction matters. A Type I report says "on this specific date, the controls were in place." A Type II report says "over this entire period, the controls were operating as intended, and here is the evidence." For retirement data, you want the latter, because a vendor who can demonstrate security on audit day but not on a random Tuesday in month four is not actually protecting your participants.
Type I vs. Type II: The Critical Difference
SOC 2 Type I
- Point-in-time snapshot of control design
- Evaluates whether controls exist on a specific date
- No evidence of ongoing operational effectiveness
- Often used as a stepping stone to Type II
- Insufficient for ERISA fiduciary diligence
SOC 2 Type II
- Continuous evaluation over 6-12 month period
- Tests that controls actually work in practice
- Auditor samples evidence across the full period
- Documents any exceptions or deviations found
- Required standard for financial services vendors
The Five Trust Services Criteria
SOC 2 is organized around five Trust Services Criteria (TSC). A vendor can choose which criteria to include in their audit scope. For retirement platforms, all five are relevant, and you should be skeptical of any rollover provider that only covers one or two.
1. Security (Common Criteria)
The foundation of every SOC 2 report. Covers protection against unauthorized access, both physical and logical. Includes access controls, firewalls, intrusion detection, and vulnerability management. This is the only mandatory criterion; the other four are optional add-ons. For a rollover provider handling SSNs and financial data, Security alone is necessary but not sufficient.
2. Availability
Evaluates whether the system is operational and accessible as committed. For rollover processing, downtime can mean missed market windows, delayed transfers, and regulatory reporting failures. Availability controls include disaster recovery plans, failover mechanisms, capacity monitoring, and incident response procedures with defined RTOs and RPOs.
3. Processing Integrity
Ensures system processing is complete, valid, accurate, and timely. In rollover context, this means transfer amounts are not altered in transit, state transitions follow valid paths, and financial data maintains integrity from initiation through completion. A rollover that silently drops a decimal point or processes a duplicate transfer is a Processing Integrity failure.
4. Confidentiality
Protects information designated as confidential. This goes beyond Security by addressing how data is classified, who can access what, and how confidential data is disposed of. For retirement platforms, this covers encryption of SSNs and account numbers at rest, access restrictions by role and custodian, and data retention and destruction policies.
5. Privacy
Addresses the collection, use, retention, disclosure, and disposal of personal information. Privacy is distinct from Confidentiality: Confidentiality asks "is this data protected?" while Privacy asks "are we handling this person's information according to our stated policies and applicable regulations?" For ERISA-governed data, this criterion maps directly to participant consent, data minimization, and regulatory disclosure obligations.
Why Retirement Data Is Different
ERISA Creates a Higher Standard
Most SaaS vendor assessments focus on standard PII categories: email addresses, names, phone numbers. Retirement rollover data is categorically different. A single rollover file can contain the participant's full SSN, date of birth, employer details, account balances across multiple plan types, bank routing and account numbers, beneficiary names and relationships, and in some cases health savings account details.
This is not just a data sensitivity question. Under ERISA (Employee Retirement Income Security Act), plan fiduciaries have a legal obligation to act in the best interest of participants. When a custodian or plan sponsor selects a rollover vendor, that selection is itself a fiduciary act. If the vendor suffers a breach, the fiduciary who chose them faces potential personal liability, not just organizational liability.
The Fiduciary Liability Chain
DOL Advisory Opinion 2019-01 reinforced that fiduciaries must conduct prudent due diligence on service providers handling participant data. The 2021 cybersecurity guidance from the DOL explicitly states that plan fiduciaries should evaluate service providers' cybersecurity practices, including whether they have completed SOC 2 audits.
- Plan sponsors bear fiduciary duty to prudently select and monitor service providers
- Custodians must verify that rollover intermediaries protect participant data to at least the same standard they maintain internally
- TPAs processing rollovers on behalf of plans share the obligation to ensure data handling meets fiduciary standards
- Failure to assess a vendor's security posture can itself constitute a fiduciary breach, even if no data loss occurs
What a Rollover Transaction Actually Touches
To understand why generic SaaS security assessments fall short, consider the data elements flowing through a single 401(k)-to-IRA rollover:
Highest Sensitivity (Restricted)
- Full Social Security Number (SSN)
- Bank account and routing numbers
- Account balances and transfer amounts
- Beneficiary SSNs and personal details
High Sensitivity (Confidential)
- Date of birth and full legal name
- Employer and plan details (EIN, plan name)
- Investment allocations and fund selections
- Mailing address and contact information
The Compound Risk Factor
What makes retirement data particularly dangerous in a breach is the combination. An attacker who obtains a name and email from a CRM breach can attempt phishing. An attacker who obtains a full SSN combined with date of birth, employer details, financial account numbers, and beneficiary information from a rollover provider breach can execute comprehensive identity theft, tax fraud, and financial account takeover. The compound value of rollover data to an attacker is orders of magnitude higher than typical SaaS customer records.
What to Look for in a Vendor's SOC 2 Report
Reading the Report Like an Auditor
Most SOC 2 reports run 80 to 150 pages. Security teams pressed for time often skip to the auditor's opinion and the exceptions section. That is understandable but incomplete. Here are the sections that matter most for retirement platform assessment, and what to look for in each.
1. Scope of the Audit
The scope section defines what systems, processes, and data flows were actually examined. This is where vendors can create a misleading impression.
Red flags to watch for:
- Scope excludes specific production systems or data stores that handle rollover data
- Only the "Security" criterion is covered (no Availability, Processing Integrity, Confidentiality, or Privacy)
- Third-party subprocessors are carved out via "carve-out method" without their own SOC 2 reports
- Examination period is less than 6 months
2. Auditor's Opinion
The opinion is the auditor's formal conclusion. There are three types, and only one should be acceptable for a retirement data vendor:
Unqualified (Clean)
Controls are suitably designed and operating effectively. This is the standard you should require.
Qualified
Controls are effective except for specific noted areas. Requires careful review of what was excluded and why.
Adverse
Material control failures found. A disqualifying finding for any vendor handling retirement data.
3. Exceptions and Deviations
Even in an unqualified report, the auditor may note specific exceptions where a control did not operate as designed during the examination period. The existence of exceptions is not automatically disqualifying, but the nature of the exceptions matters enormously.
- Acceptable: Minor procedural exceptions (e.g., one access review completed 3 days late) with documented remediation
- Concerning: Exceptions in encryption, access control, or audit logging, especially if the same exception appears in consecutive reports
4. Complementary User Entity Controls (CUECs)
This is the section most commonly overlooked. CUECs define what the vendor expects you to do to maintain the overall security posture. If the vendor's SOC 2 report assumes you will enforce MFA on your admin accounts, rotate API keys quarterly, and restrict IP ranges for API access, those obligations fall on your organization.
Action required:
Map every CUEC in the vendor's report to a control owner in your organization. If you cannot fulfill a CUEC, discuss it with the vendor. An unfulfilled CUEC is a gap in the overall control environment, regardless of what the vendor's report says.
Download Our Security Summary
See how TrustRails maps to all five SOC 2 Trust Services Criteria.
Common Gaps in Non-SOC-2 Rollover Providers
Through our work with custodians and TPAs, we see the same security gaps repeatedly in rollover providers that lack SOC 2 Type II certification. These are not theoretical risks; they are the specific control failures that auditors would flag.
Gap 1: No Structured Audit Logging
The most common gap. Many rollover providers have application logs for debugging, but no structured, tamper-evident audit trail that records who accessed what data, when, and from where. Without this, you cannot answer the most basic forensic question after an incident: "What participant records were exposed?"
What SOC 2 requires: Timestamped, immutable logs of all data access and administrative actions with sufficient detail to reconstruct events during incident investigation. Logs must be retained according to a defined policy and protected from modification.
Gap 2: Shared Infrastructure Without Isolation
Some providers run all custodian data in a single shared database without logical tenant isolation. A query error or SQL injection in one custodian's workflow can expose another custodian's participant records. Without SOC 2 controls around data segregation, there is no assurance that Custodian A's data cannot leak to Custodian B.
What SOC 2 requires: Logical or physical separation of customer data with access controls that prevent cross-tenant data exposure. Regular testing to validate that isolation controls are effective.
Gap 3: No Encryption Key Management
"We encrypt data at rest" is not a complete answer. The critical question is: who controls the encryption keys, how are they rotated, and what happens when an employee with key access leaves? Providers without formal key management often store encryption keys alongside the data they protect, in application configuration files, or in plain text environment variables.
What SOC 2 requires: Formal key management procedures including key generation, distribution, storage, rotation, and destruction. Keys must be stored separately from encrypted data with access restricted to authorized personnel.
Gap 4: No Incident Response Plan
When asked "what happens if you discover a breach at 2 AM on a Saturday?" many providers cannot produce a documented, tested incident response plan. Without one, breach notification timelines are ad hoc, forensic evidence may be destroyed during triage, and affected custodians may not learn about the incident for days or weeks.
What SOC 2 requires: A documented incident response plan that is tested at least annually, with defined roles, escalation paths, notification timelines, and forensic preservation procedures.
Gap 5: No Formal Access Review Process
Employee access to production systems accumulates over time. Without quarterly access reviews, former employees retain access, engineers who changed roles keep permissions they no longer need, and service accounts with broad access go unmonitored. This is a classic privilege escalation vector.
What SOC 2 requires: Periodic review of user access rights, prompt revocation of access upon role change or termination, and documentation of access approval and review decisions.
How TrustRails Implements Each Trust Services Criteria
We believe vendor security claims should be specific and verifiable. Below is a mapping of each Trust Services Criteria to the concrete technical controls we have implemented. These controls are designed to meet SOC 2 Type II requirements as we prepare for formal audit.
Security (Common Criteria)
Network & Infrastructure
- Cloud Armor WAF with OWASP Top 10 rule sets, geo-based filtering, and adaptive rate limiting at the edge
- TLS 1.3 enforced on all external connections; TLS 1.2 minimum for internal service-to-service communication
- VPC Service Controls creating a security perimeter around GCP resources with ingress/egress policies
- Cloud Run isolation with per-service IAM, no shared compute, and automatic scaling behind Google Front End
Access Control
- Keycloak RBAC with role-based access control, enforced MFA via TOTP/WebAuthn, and session management
- Tiered API rate limiting at 1,000/min (Tier 1), 500/min (Tier 2), 100/min (Tier 3) with per-key tracking
- API key authentication with environment separation (live/test), permission scoping, and IP allowlisting
- Quarterly access reviews with automated deprovisioning on role change, documented approval workflows
Availability
Infrastructure Resilience
- Multi-region Cloud Run deployment with automatic failover and zero-downtime rolling updates
- Firestore multi-region replication with automatic failover and point-in-time recovery
- Auto-scaling from 0 to N instances based on request load, with minimum instance guarantees for critical paths
Monitoring & Response
- Cloud Monitoring alerts on latency, error rate, and saturation with defined escalation paths
- Health check endpoints on every service with automated restart on failure detection
- Documented incident response with RTO/RPO targets, tested annually via tabletop exercises
Processing Integrity
Transaction Integrity
- 22-state state machine with validated transitions preventing invalid state changes; every transition is event-sourced
- Zod schema validation on all API inputs and state transitions with strict type enforcement
- Idempotent operations with request-level deduplication to prevent double-processing of transfers
Verification
- HMAC-SHA256 webhook signatures on all outbound notifications, verifiable by receiving custodians
- Blockchain-anchored audit trail providing immutable, independently verifiable record of transfer events
- Smart contract enforcement of business rules on-chain, eliminating single points of manipulation
Confidentiality
Encryption
- AES-256 encryption at rest via Google Cloud KMS with customer-managed encryption keys (CMEK)
- HSM-backed SSN encryption with field-level encryption for Social Security numbers; decryption requires explicit authorization and is audit-logged
- Automatic key rotation on a defined schedule with no service disruption; previous key versions retained only for decryption of existing data
Data Segregation
- Custodian-scoped data access enforced at the query layer; every database operation is filtered by custodian ID
- API key isolation binding each key to a specific custodian with environment separation (live vs. test)
- Data classification policy with four levels (Public, Internal, Confidential, Restricted) governing access and handling requirements
Privacy
Data Governance
- Data minimization collecting only the fields required for rollover processing; no ancillary data collection
- Purpose limitation with data used exclusively for the stated rollover processing purpose, not for analytics, marketing, or model training
- Defined retention schedules aligned with ERISA record-keeping requirements and DOL guidance
Audit & Accountability
- 7-year audit log retention in Google Cloud Logging with tamper-evident storage and restricted access
- Every PII access logged with actor identity, timestamp, source IP, resource accessed, and action performed
- SOC 2 audit event categories covering authentication, authorization, data access, administrative, security, financial, compliance, and system events
Control Architecture at a Glance
| Layer | Technology | TSC Mapping |
|---|---|---|
| Edge Protection | Cloud Armor WAF, DDoS mitigation | Security, Availability |
| Transport | TLS 1.3, certificate management | Security, Confidentiality |
| Authentication | Keycloak RBAC, MFA, API key auth | Security, Privacy |
| Authorization | Role-based permissions, custodian scoping | Security, Confidentiality |
| Rate Limiting | Tiered limits (100-1,000/min), per-key tracking | Security, Availability |
| Encryption at Rest | AES-256 via Cloud KMS (CMEK) | Confidentiality |
| Field Encryption | HSM-backed SSN/account encryption | Confidentiality, Privacy |
| State Machine | 22-state validated transitions, Zod schemas | Processing Integrity |
| Webhook Integrity | HMAC-SHA256 signatures, secret rotation | Processing Integrity, Security |
| Audit Logging | Cloud Logging, 7-year retention, SOC 2 categories | All Five Criteria |
| Blockchain Audit | Immutable on-chain event records | Processing Integrity, Security |
Questions to Ask Your Rollover Provider
Use this checklist during vendor security assessments. These questions are designed to surface the specific gaps described above. A vendor who can answer all of these clearly and with specifics, not marketing language, is demonstrating the operational maturity that SOC 2 Type II validates.
Certification & Audit Status
- Do you hold a current SOC 2 Type II report? What is the examination period and which Trust Services Criteria are in scope?
- Can we receive a copy of the full report (not a summary or bridge letter)? Under what NDA terms?
- Were there any exceptions or qualifications noted in the most recent report? If so, what remediation has been completed?
- Who is the auditing firm? Are they an AICPA peer-reviewed firm with financial services experience?
Encryption & Key Management
- What encryption algorithm and key length do you use for data at rest? Is it AES-256 or equivalent?
- How are encryption keys stored and managed? Do you use a hardware security module (HSM) or cloud KMS? Are keys stored separately from encrypted data?
- How are SSNs specifically protected? Is field-level encryption applied, or only volume-level encryption?
- What is your key rotation schedule? What happens to data encrypted with the previous key version?
- What TLS version do you enforce for data in transit? Do you support TLS 1.3?
Access Control & Authentication
- Is multi-factor authentication required for all administrative access to production systems?
- How do you ensure our participant data is segregated from other custodians' data? Is this enforced at the application layer, database layer, or both?
- How frequently do you review employee access to production systems? What is the process for revoking access when an employee leaves or changes roles?
- Do you support IP allowlisting for API access? Can we restrict which IP ranges can call your API with our credentials?
Audit Logging & Monitoring
- What events are captured in your audit logs? Does this include all data access, administrative actions, authentication events, and API calls?
- How long are audit logs retained? Can we access logs pertaining to our data for forensic or regulatory purposes?
- Are audit logs tamper-evident? What prevents an insider from modifying or deleting log entries?
- Do you have real-time alerting on suspicious access patterns or anomalous API usage?
Incident Response & Business Continuity
- Do you have a documented incident response plan? When was it last tested? Can we review a redacted version?
- What is your committed notification timeline to affected custodians after discovering a security incident?
- What are your Recovery Time Objective (RTO) and Recovery Point Objective (RPO)? How have these been validated?
- Have you experienced any security incidents or breaches in the past 24 months? If so, what was the scope and what changes were made?
Data Handling & Processing Integrity
- How do you prevent duplicate rollover processing? What idempotency mechanisms are in place?
- How do you validate that transfer amounts and participant data are not modified in transit between systems?
- What is your data retention policy? When a rollover completes, how long is participant data retained, and how is it eventually destroyed?
- Do you use participant data for any purpose other than processing the rollover (analytics, model training, benchmarking)?
How to Score the Responses
Vendor assessment is not pass/fail on individual questions. What you are evaluating is operational maturity and specificity. Use this framework:
Strong Response
Names specific technologies, provides documentation, references SOC 2 controls by ID, and can schedule a technical deep-dive with their security team.
Adequate Response
Describes controls at a process level, has documentation but it is not current, is willing to address gaps with a timeline. Requires follow-up.
Insufficient Response
Uses vague language ("we take security seriously"), cannot name specific technologies or policies, deflects technical questions to sales, or has no SOC 2 report.
Making the Right Vendor Decision
SOC 2 Type II is not a silver bullet. It does not guarantee a vendor will never have an incident. What it does guarantee is that an independent third party has verified, over a sustained period, that the vendor has controls in place and that those controls are actually working.
For retirement data specifically, the combination of ERISA fiduciary liability, the compound sensitivity of rollover data elements, and the regulatory expectation set by the DOL's cybersecurity guidance makes SOC 2 Type II the minimum credible standard for rollover vendor selection.
When you open a vendor's SOC 2 report, you now know what to look for: all five Trust Services Criteria in scope, a clean auditor opinion, limited and remediated exceptions, and reasonable CUECs that your organization can fulfill. When you sit across from a vendor in a security review, you have 25 specific questions that distinguish operational maturity from marketing language.
Key Takeaways for Your Assessment
Require, Do Not Request
- SOC 2 Type II with all five TSC, not Type I
- Unqualified opinion from a reputable firm
- Full report access, not just a summary letter
- Annual report renewal with bridging letters
Verify, Do Not Trust
- Read the scope, not just the opinion
- Map CUECs to internal control owners
- Ask the 25 vendor assessment questions
- Compare specific controls, not certifications
Ready to Evaluate TrustRails?
Schedule a security review with our compliance team or request detailed control documentation.
Security Is Not a Feature. It Is the Foundation.
TrustRails was built from day one with SOC 2 Type II-ready controls embedded into every layer of the platform. We welcome the scrutiny that comes with handling retirement data, and we make it easy for your security team to review our control documentation.