We have not completed a formal SOC 2 audit yet. What we have done is build the controls that a SOC 2 audit would look for — from day one, as part of the architecture, not bolted on later. This article is about those controls and why they matter even before you have the report.

Note: This is not legal or compliance advice. SOC 2 compliance requires a formal audit by an accredited CPA firm. This article describes engineering controls, not audit results.

Why enterprise buyers care before the audit

Enterprise security questionnaires do not ask “are you SOC 2 certified?” They ask about specific controls: how you encrypt data, how you isolate tenants, how you log access, how you handle breach notification. A well-architected system can answer those questions honestly and thoroughly even without a formal report.

The audit certifies that the controls exist and work. Building the controls first — documenting them, testing them, making them verifiable — is the prerequisite. Here is what that looked like for us.

1. Tenant isolation at the database layer

Multi-tenant SaaS has two common isolation models: application-level (a WHERE clause in every query) and database-level (Row-Level Security). Application-level isolation is fast to implement and easy to get wrong. A missing WHERE clause leaks data across tenants.

We use PostgreSQL Row-Level Security (RLS). Every table that contains tenant data has an RLS policy that restricts rows based on the current tenant context. The database enforces the isolation — not the application. A bug in the API cannot accidentally return another tenant's data because the query never reaches it.

-- Example: RLS policy on documents table

CREATE POLICY tenant_isolation ON documents

USING (tenant_id = current_setting('app.tenant_id')::uuid);

This pattern is applied to every tenant-scoped table in the schema. Independent testing verifies that cross-tenant queries return zero rows.

2. Encryption at rest and in transit

All data at rest is encrypted using AES-256 (GCP Cloud SQL default encryption, GCS storage encryption). All data in transit uses TLS 1.2+ enforced at the load balancer. Documents stored in object storage (GCS/S3) are encrypted with server-side encryption.

API keys stored in the database are hashed (bcrypt), not stored in plaintext. Secrets (database credentials, API keys for external services) are stored in GCP Secret Manager, not in environment variables committed to source control.

3. Role-based access control (RBAC)

Every API endpoint in F7 KORE is protected by a permissions guard. Permissions are attached to roles (SUPER_ADMIN, ADMIN, MANAGER, USER, VIEWER), and roles are assigned per tenant. A user can have different roles in different tenant environments.

The RBAC model is granular: read/write/delete permissions are separate for each resource type. This means you can give a user read-only access to documents and full access to tasks without granting them admin rights.

4. Audit logging

Every action that modifies tenant data creates an audit log entry: who, what, when, from which IP. The audit log is append-only (no UPDATE or DELETE on the audit_log table) and is exposed via a read-only API endpoint for compliance exports.

SOC 2 requires logging to be tamper-evident and retained for a defined period. Our audit log is retained for a minimum of 12 months. The retention policy is configurable per tenant for Enterprise plans.

5. Identity: SAML, SCIM, OIDC

SOC 2 Access Control criteria require that user access is reviewed and revoked when employees leave. Manual deprovisioning at scale is error-prone. We implement SCIM 2.0 so that when HR terminates an employee in Okta or Azure AD, their F7 KORE access is revoked automatically within minutes — without an IT ticket.

SAML 2.0 provides the SSO layer. OIDC is available for providers that prefer it. Azure AD (Microsoft Entra ID) directory sync uses the Graph API via a dedicated service.

6. Data subject rights (GDPR/CCPA)

Privacy regulations require data export and deletion. We built these as first-class features, not afterthoughts:

Data export — full tenant data export as ZIP (JSON + files), available via API and the admin UI.
Account deletion with anonymization — user records are anonymized (name, email replaced with hashes), not deleted, to preserve referential integrity in audit logs.
Data Processing Agreement (DPA) — available at f7kore.com/legal/dpa, covering sub-processors and cross-border transfer safeguards.
Cookie consent — CookieBanner component with localStorage persistence. Analytics loaded only after consent.

What we have not done yet

Honesty matters here. SOC 2 readiness ≠ SOC 2 compliance. A formal audit by an accredited CPA firm (like Vanta/Drata-facilitated audits or direct CPA engagements) is a separate step. We have implemented the technical controls. The formal audit is on our roadmap.

We also do not have a formal vulnerability disclosure program or a penetration test report yet. These are planned for the next phase. Prospective enterprise customers can request our security questionnaire responses directly.

The takeaway for SaaS builders

SOC 2 readiness is not a compliance project. It is an architecture discipline. If you build your system with RLS, RBAC, audit logging, encryption, and SCIM from the start, the audit becomes documentation of what you already have — not a scramble to backfill controls you never built.

The controls described in this article were implemented as part of the F7 KORE platform architecture, not added in preparation for an audit. That is the right order of operations.

Security built in, not bolted on

F7 KORE includes PostgreSQL RLS, RBAC, SAML/SCIM SSO, audit logging, data export and DPA. SOC 2 readiness controls implemented. 14-day free trial.

Start free trial →

Building SOC 2 Readiness Into Your Product Architecture