Security and compliance

Your capital providers expect you to protect borrower data. Banks and insurance companies will require evidence of security controls before funding. This isn’t optional: data breaches destroy lender confidence and can trigger facility defaults. Beyond lender requirements, privacy regulations impose specific obligations on consumer lenders.

SOC 2 type II: the table stakes requirement

SOC 2 Type II is the standard security certification for technology service providers. For ABF operations, it’s often the minimum bar for working with institutional capital.

What SOC 2 covers

The framework addresses five trust service criteria:

Security: Protection against unauthorized access. This is the mandatory category that every SOC 2 covers.

Availability: System uptime and recovery capabilities. Important if your systems affect lender operations.

Processing integrity: Accurate, complete, authorized data processing. Relevant for loan tape generation and calculations.

Confidentiality: Protection of information designated as confidential. Covers borrower data and facility terms.

Privacy: Personal information handling per your privacy notice. Required for consumer-facing operations.

Most ABF originators pursue SOC 2 covering Security and Confidentiality at minimum. Processing Integrity is often added for servicing operations.

What it takes

Preparation (6-12 months):

Policy documentation (security, access, incident response)
Control implementation (technical and administrative)
Evidence collection procedures
Readiness assessment (many firms engage a consultant)

Observation period (6-12 months):

Auditor monitors your controls in operation
You maintain evidence of control effectiveness
Address any gaps identified during observation

Audit cost:

$30-100K+ depending on scope and complexity
Annual renewal required

When you need it

Required: Working with banks, insurance companies, or institutional investors. They’ll ask during due diligence.

Probably needed: $100M+ facilities or multiple capital providers. SOC 2 becomes a de facto requirement at institutional scale.

Can defer: Under $100M with a single smaller fund. You might negotiate alternative security representations, but expect more scrutiny.

Security controls checklist

Implement these controls regardless of SOC 2 timing. They’re foundational for protecting borrower data and maintaining lender confidence.

Access controls

Role-based permissions: Not everyone sees everything. Define roles (admin, user, read-only) with appropriate access levels.

Multi-factor authentication: Required for all systems with personally identifiable information. SMS is acceptable; authenticator apps or hardware tokens are better.

Regular access reviews: Quarterly review of who has access to what. Remove access when roles change.

Offboarding procedures: Access revoked same day as departure. Document the process and verify compliance.

Privileged access management: Admin accounts have extra controls. Separate admin accounts from daily-use accounts.

Data protection

Encryption at rest: Database, file storage, backups. Use AES-256 or equivalent. Cloud providers typically handle this by default, but verify.

Encryption in transit: TLS 1.2+ for all connections. No exceptions for internal traffic.

Key management: Document who can access encryption keys. Rotate keys periodically. Never store keys alongside encrypted data.

Data classification: Know which data is sensitive (PII, financial data) and apply appropriate controls.

Monitoring and logging

Audit logs: Record sensitive actions (data access, modifications, exports, login attempts). Include timestamp, user, and action details.

Log retention: 12+ months minimum. Some regulations require longer retention.

Alerting: Automated alerts on suspicious activity (failed login attempts, unusual data access patterns, after-hours activity).

Log protection: Logs should be tamper-evident and stored separately from the systems they monitor.

Vendor management

Security assessments: Evaluate critical vendors’ security posture. Request SOC 2 reports or complete security questionnaires.

Data processing agreements: Contractual terms for how vendors handle your data. Required under most privacy regulations.

Subprocessor inventory: Know who your vendors share data with. Maintain current list.

Privacy compliance

Consumer lending triggers specific privacy regulations. Your compliance obligations depend on where you operate and what you originate.

GLBA (Gramm-Leach-Bliley Act)

Applies to most consumer lenders in the United States.

Privacy notices: Inform consumers about data collection and sharing practices. Provide at account opening and annually.

Safeguards Rule: Implement and maintain comprehensive security program. Requires written information security plan, designated coordinator, risk assessment, and ongoing monitoring.

Recent updates: The FTC’s updated Safeguards Rule (effective 2023) added specific technical requirements including encryption, multi-factor authentication, and access controls.

State privacy laws

State laws add requirements beyond federal minimums:

California (CCPA/CPRA): Consumer rights to access, delete, and opt out of sale of personal information. Detailed disclosure requirements. Applies if you have California customers meeting revenue or data thresholds.

Other states: Virginia, Colorado, Connecticut, Utah, and others have enacted privacy laws. Requirements vary but generally follow the California model.

Compliance approach: Design for California requirements and you’ll likely meet most state obligations. Monitor legislative developments.

Data retention

Define and enforce retention policies:

By data type:

Loan application data: Life of loan + 7 years (regulatory requirements)
Payment history: Life of loan + 7 years
Collection records: Life of loan + 7 years
Marketing data: Per consent, typically shorter

Secure deletion: When retention period expires, delete data securely. Document deletion procedures and maintain records of what was deleted when.

Litigation holds: Process to suspend deletion when litigation is anticipated or pending.

Disaster recovery and business continuity

Lenders want to know you can keep operating if something goes wrong. DR/BC planning demonstrates operational maturity.

Recovery objectives

Define your targets before building plans:

RPO (Recovery Point Objective): How much data can you afford to lose?

Loan data: Maximum 24 hours (daily backups)
Payment data: Maximum 4 hours (more frequent replication)
Production databases: Real-time replication preferred

RTO (Recovery Time Objective): How long can you be down?

Critical systems (LMS, payment processing): 4-24 hours
Secondary systems (reporting, analytics): 24-72 hours
Nice-to-have systems (dashboards, portals): 72+ hours acceptable

What lenders expect

Documented DR plan: Written procedures for recovery scenarios. Include contact information, system priorities, and step-by-step recovery procedures.

Geographic redundancy: Data stored in multiple locations. Cloud providers make this straightforward with multi-region replication.

Backup verification: Regular testing that backups actually restore. Untested backups are worthless.

Annual DR testing: Simulated failure with documented results. Test your ability to recover within stated objectives.

Business continuity plan: How you operate if your office is unavailable. Remote work capabilities, communication procedures, alternative work locations.

Cloud infrastructure advantages

If you’re on cloud infrastructure (AWS, GCP, Azure), geographic redundancy is straightforward:

Database replication to secondary region (often a checkbox)
Automated failover for critical services
Infrastructure-as-code for rapid rebuild
Provider-managed physical security and availability

On-premises infrastructure requires more investment to achieve equivalent redundancy. This is one reason cloud-first is the default for most modern implementations.

Security governance

Controls need governance to be effective over time.

Policies required

Document these policies and review annually:

Information security policy (overall framework)
Access control policy (who gets access to what)
Data classification policy (what data requires what protection)
Incident response policy (what happens when something goes wrong)
Acceptable use policy (employee expectations)
Vendor management policy (third-party risk)

Incident response

Before incidents happen:

Define what constitutes an incident
Establish response team and roles
Create communication templates
Identify outside resources (legal, forensics, PR)

During incidents:

Contain the incident
Assess impact
Notify affected parties as required
Document everything

After incidents:

Conduct post-incident review
Update controls to prevent recurrence
File required regulatory notifications

Training

Security awareness training: All staff, annually. Cover phishing, social engineering, data handling.

Role-specific training: Technical staff need deeper training on secure development, infrastructure security.

Phishing simulations: Test whether training is working. Track results over time.

Common security mistakes

Delaying SOC 2 until required. The process takes 12-18 months. Start early so you’re not scrambling when a lender asks.

Assuming cloud providers handle everything. They secure the infrastructure; you secure your data and access controls. The shared responsibility model requires you to do your part.

Weak access controls. Shared credentials, no MFA, no access reviews. These are audit findings waiting to happen and real security risks.

Incomplete vendor assessment. Your vendors’ security is your security. A breach at a subprocessor affects you.

No incident response plan. When something goes wrong, you don’t want to figure out the process in real time.

Investor portals and integration - securing data in transit to counterparties
Data and analytics infrastructure - securing stored data
Technology and infrastructure - overview and implementation roadmap