Ensuring SOC 2 Compliance in Mobile Applications
SOC 2 is not a law or regulator. It's an audit standard (AICPA) that large corporate customers require from SaaS vendors and mobile apps processing their data. If B2B app wants to work with Enterprise clients in USA and Western Europe — SOC 2 Type II report opens doors otherwise closed.
What SOC 2 Means for Mobile App
SOC 2 builds on Trust Service Criteria (TSC). For most mobile apps relevant are three:
- Security — always mandatory
- Availability — if app is business-critical for client
- Confidentiality — if processing client confidential data
Each criterion — set of controls (CC). Auditor checks not intentions but evidence: logs, configs, procedures, test results. SOC 2 Type II — audit over period (usually 12 months), not snapshot.
Technical Controls on Mobile Client Side
Most SOC 2 controls implemented server-side. Mobile client owns few specific areas:
CC6.1 — Logical and Physical Access Controls
Multi-factor authentication. For corporate users SOC 2 effectively requires MFA. In mobile app — TOTP (Google Authenticator / Authy compatible), push-based auth (Firebase or custom) or biometric + PIN.
// Check if biometrics available as second factor
val biometricManager = BiometricManager.from(context)
when (biometricManager.canAuthenticate(BIOMETRIC_STRONG)) {
BIOMETRIC_SUCCESS -> enableBiometricMFA()
BIOMETRIC_ERROR_NO_HARDWARE -> requireTOTP()
BIOMETRIC_ERROR_NONE_ENROLLED -> promptUserToEnrollBiometric()
}
Auto-logout and session lock. Session timeout after inactivity period — typical CC6.1 control. For B2B apps: 15–30 minutes inactivity → lock, requires re-auth (not full logout).
CC6.7 — Transmission of Data
Certificate pinning for all API endpoints. Not just production — staging with test client data also must be protected. Separate pin for staging, documented in rotation runbook.
Log all API requests with 4xx/5xx errors — not on device, on server. Auditor asks for log examples over period.
CC7.2 — Monitoring of System Components
Tampering detection. SOC 2 auditor asks: how do you detect if client app is modified? Answer must include technical solution:
// SafetyNet Attestation API (deprecated, replacement — Play Integrity API)
val integrityManager = IntegrityManagerFactory.create(context)
val integrityTokenResponse = integrityManager.requestIntegrityToken(
IntegrityTokenRequest.builder()
.setNonce(serverGeneratedNonce)
.build()
)
// Token verified on server via Google API
On iOS — DeviceCheck + AppAttest for app authenticity verification on server.
CC9.2 — Vendor and Business Partner Management
Each SDK in app — vendor. SOC 2 auditor asks: vendor assessment for Firebase, Amplitude, Braze? What data do they get? Their SOC 2 status?
Answer: inventory of all SDKs indicating data they receive, links to SOC 2 reports (Firebase, AWS, Amplitude have public or NDA ones). This vendor inventory — document kept current.
Evidence (Artifacts) for Auditor
SOC 2 audit — proof collection. For mobile app typical artifacts:
| Control | Evidence |
|---|---|
| CC6.1 MFA | UI screenshots + code + test cases |
| CC6.1 Session timeout | Config file + autotests |
| CC6.7 TLS | SSL Labs or Qualys SSLTest result |
| CC6.7 Certificate pinning | Code + pentest or mitmproxy test result |
| CC7.2 Integrity check | Play Integrity logs over period |
| CC8.1 Vulnerability management | SAST reports (MobSF, Semgrep), pentest report |
Continuous Compliance
SOC 2 Type II — 12 months of proof. Can't implement controls week before audit. Need pipeline:
- SAST in CI/CD (Semgrep, Snyk) with block on critical findings
- Automatic dependency updates with Dependabot / Renovate
- Periodic access review — who has production data access
- Documented incident response procedure with examples
Timeline
SOC 2 Type I (snapshot) preparation: 4–8 weeks technical work + docs. SOC 2 Type II requires 6–12 months of control operation before audit. Cost calculated after gap analysis.