Security

Spinaker is a multi-tenant SaaS platform for LinkedIn Ads operations, hosted on Google Cloud Platform. Security is built into every layer: server-side authorization on every request, encryption at rest and in transit, and a strict least-privilege architecture. This page describes how we protect your data.

Infrastructure

Spinaker runs entirely on Google Cloud Platform in the us-east1 region. We use managed services exclusively — there are no self-managed servers.

GCP maintains SOC 1, SOC 2, SOC 3, and ISO 27001 certifications. For details, see Google Cloud compliance.

Data handling

What we store

• OAuth tokens — LinkedIn refresh tokens, used to sync and publish ad data on your behalf
• Ad account metadata — Campaign structures, targeting specs, budgets, and creative references synced from LinkedIn
• User profile data — Name, email, and profile image from Google OAuth sign-in
• Audit logs — Records of every mutation (who, when, what changed), retained for 90 days

Payment data is processed by Stripe and never stored on our infrastructure.

Encryption

• In transit: All data encrypted via TLS 1.2+
• At rest: All database data encrypted by GCP-managed encryption
• OAuth tokens: Additional envelope encryption using AES-256-GCM with a Key Encryption Key (KEK) managed by Cloud KMS. The KEK never leaves the GCP Hardware Security Module (HSM) and auto-rotates every 90 days.

Retention

• Firestore automatic daily backups with 7-day retention
• Audit logs: 90-day TTL, then automatically deleted
• Transactional emails: 30-day TTL, then automatically deleted

Log redaction

Sensitive fields (accessToken, refreshToken, secret, apiKey, authorization, cookie) are automatically redacted at the logging boundary before being written to Cloud Logging. Secrets are never shipped to analytics or monitoring services.

Access control

Authentication

Users authenticate via Google OAuth through Firebase Authentication. Multi-factor authentication is enforced through the user's Google account. Only pre-approved email addresses can sign in (allowlist-based access).

Authorization

Spinaker enforces role-based access control at the subscription (organization) level:

Tenant isolation

Every database read and write includes an explicit scope filter (subscription ID, ad account ID). Authorization is enforced server-side on every request — client claims are never trusted. Firestore security rules provide an additional layer of enforcement via real-time membership checks.

CSRF protection

All state-changing requests (POST, PATCH, DELETE) require Origin/Referer header validation. Only trusted domains are accepted.

Compliance

Data subject rights

We respond to all data subject requests (access, rectification, erasure, portability) within 30 days. User deletion is a hard delete — user data is permanently removed in a single transaction. Reach out to [email protected] for requests.

Secure development

• Version control: All code changes go through Git-based pull requests with mandatory code review
• Automated CI: Every change runs lint, type-checking, and tests before merge
• Input validation: All inputs validated at API boundaries using Zod schemas — no silent coercion
• Dependency scanning: Dependabot monitors for known vulnerabilities in dependencies
• Secret scanning: Automated scanning prevents credentials from being committed to the repository
• Server boundary enforcement: Build-time analysis prevents server-only code from leaking to the client bundle
• Audit logging: Every mutation is recorded with actor, timestamp, before/after state, and request correlation ID

Incident response

We maintain a documented incident response plan with severity-based triage:

Notification timelines: Supervisory authorities are notified within 72 hours. Affected customers are notified within 48 hours. Data subjects are notified without undue delay when there is a high risk to their rights.

Post-incident reviews are conducted within 5 business days for Critical and High severity events. All incidents are logged regardless of whether they meet reporting thresholds.

Subprocessors

The following third-party services process data on our behalf. For the full subprocessor list with data handling details, see our Subprocessors page.

Contact

For security questions, vulnerability reports, or data subject requests:

[email protected]