Security Overview

1. Summary at a glance

2. Encryption

At rest

All Customer Data is encrypted at rest using AES-256-GCM with Google-Cloud-managed encryption keys (CMEK). This applies to Firestore documents, Cloud Storage objects, ClickHouse Cloud tables, and Cloud Functions deployment artefacts. Key rotation follows Google Cloud's default schedule (every 90 days for new data encryption keys; key encryption keys held in Google's HSM infrastructure).

Customer-Managed Encryption Keys (CMEK with Customer-supplied material) are not generally available on the Effective Date. Customers requiring CMEK as a procurement gate should contact [email protected]; an enterprise tier with CMEK is on the roadmap subject to sufficient demand.

In transit

All traffic between the Customer's SDK / dashboard and the Service is encrypted with TLS. The minimum supported version is TLS 1.2; TLS 1.3 is preferred and is negotiated by default for every modern client. Legacy SSL and TLS < 1.2 are rejected at the load balancer.

Inter-service traffic inside Google Cloud is encrypted on Google's internal network. External webhook deliveries (e.g. Stripe → Crossdeck) require valid TLS 1.2+ on the third party's side.

Application-level encryption

Sensitive credentials (API keys' secret components, OAuth tokens, webhook signing secrets) are stored encrypted at the application level in Google Cloud Secret Manager, never in Firestore or the primary application database. Access requires a service-account credential and is logged.

3. Access control

Crossdeck personnel access

• All Crossdeck administrative access requires multi-factor authentication (TOTP or WebAuthn / passkey).
• Role-based access control is enforced via Google Cloud IAM and the dashboard's own RBAC layer. Production access is granted on a least-privilege basis; permissions are reviewed quarterly.
• Just-in-time elevation for incident response: emergency production access is granted for the duration of the incident, with full audit trail; standing production write access is restricted to a small named group.
• Personnel access is revoked within 4 business hours of role change or departure; account deactivation and credential revocation are documented.

Customer-side access

• Customer dashboard accounts are authenticated via Firebase Authentication (email + password, or OAuth via Google / GitHub).
• MFA is offered to all Customers and required for admin-tier accounts on Paid plans (target: Q3 2026).
• Per-project role-based access (Owner, Admin, Member, Viewer); customers may invite or revoke other team members at any time from the dashboard.
• Session timeout is 30 days idle by default; configurable down to 8 hours on enterprise plans.
• API keys (publishable and secret) are issued per-project and rotatable from the dashboard; rotation invalidates the prior key on the next ingest cycle.

4. Network & infrastructure

• Infrastructure runs on Google Cloud Platform (Firebase, Cloud Run, App Hosting, Firestore, Cloud Storage, Cloud Functions). GCP's underlying physical security, environmental controls, and personnel screening are inherited (SOC 2 Type II, ISO 27001, ISO 27017, ISO 27018 certified).
• Production services run in private VPC networks with egress controlled via service-account-bound rules.
• Edge requests are fronted by Cloudflare (cross-deck.com marketing + docs) and Google Front End (the SDK API path), each providing DDoS mitigation and TLS termination.
• A managed Web Application Firewall is in place on the SDK API path with rule-sets covering the OWASP Top 10 categories.
• Rate limits apply per API key + per IP; sustained excess triggers throttling and, where abuse is suspected, automatic blocking with notification to the affected Customer.
• No public administrative endpoints. Internal admin tools live on a separate domain protected by Identity-Aware Proxy with mandatory MFA.

5. Audit logging

• Every administrative action against Customer Personal Data is logged with: actor (Crossdeck personnel UID), action (read / write / export / delete), target (project ID + object reference), timestamp, source IP (truncated for privacy where the actor is a Customer end user).
• Logs are immutable — written to an append-only log sink and retained for 7 years before automated destruction.
• Customer-visible audit log: paid-tier Customers can review their project's audit trail from the dashboard (target: Q1 2027 — currently surfaces a curated subset).
• Authentication events (logins, MFA challenges, failed attempts) are logged separately, with anomaly detection on suspicious patterns (unfamiliar location, brute-force, impossible travel).

6. Backups & disaster recovery

• Firestore: daily full export to Cloud Storage in nam5 multi-region, encrypted; point-in-time recovery enabled (last 7 days, second-level granularity).
• Cloud Storage: object versioning enabled with a 90-day retention window for deleted objects.
• ClickHouse: daily snapshots within ClickHouse Cloud's snapshot service, retained 14 days.
• Secret Manager: secret versions retained indefinitely (immutable history of every secret value, restricted access).
• Disaster recovery exercises are conducted at least annually; a written DR playbook is maintained and reviewed quarterly.
• Recovery point objective (RPO): 24 hours for Firestore; 24 hours for ClickHouse. Recovery time objective (RTO) target: 4 hours for material outages affecting all Customers.

7. Secure SDLC & dependency management

• All source code is hosted in private GitHub repositories with branch protection requiring pull request review and passing CI.
• CI runs the bank-grade contract test suite (the contracts/ directory's structural invariants) on every pull request and blocks merge on failure.
• Dependency scanning: Dependabot is enabled on every repository; critical and high-severity advisories are triaged within 1 business day.
• Snyk weekly scans on production container images and the SDK packages.
• SDK supply-chain integrity: published SDKs are mirrored to public read-only repositories (crossdeck-swift, crossdeck-android, npm packages under the @cross-deck scope) with annotated git tags. SDK package signatures and provenance attestations are on the roadmap (Q2 2027).
• Secrets in CI: GitHub Actions secrets, scoped per workflow; rotated on departure of any contributor with prior access.
• Third-party penetration testing: targeted at least annually beginning Q4 2026; broadened to a full external red-team engagement before SOC 2 audit.

8. Incident response

SLAs

• 24 hours from confirmation: initial notification to affected Controller Customers (DPA §7.1). The 24-hour clock starts at confirmation, not at time-of-occurrence; confirmation is defined as the security incident response team's escalation of a verified incident affecting Personal Data.
• 72 hours from initial notification: written preliminary report with the timeline and immediate containment steps (DPA §7.3).
• 14 days from initial notification: written full root-cause analysis including remediation completed and prevention measures implemented (DPA §7.4).

Runbook

An incident response runbook is maintained, exercised at least annually, and updated after every incident. Phases: Detect → Triage → Contain → Eradicate → Recover → Post-incident review. A dedicated on-call rotation covers production hours; off-hours paging is via PagerDuty (target: in place by Q3 2026; until then, on-call coverage is provided by the founding engineering team directly).

Public communication

For incidents affecting service availability, a status page is maintained at status.cross-deck.com (target: in place by Q3 2026); incident updates are posted in real time during a live incident. Post-mortems for material outages are published within 30 days, redacted only where necessary to protect the security of the Service or other Customers.

9. Vulnerability disclosure program

Reporting channel

Security researchers and customers should report suspected vulnerabilities to [email protected]. PGP key for sensitive reports is published at cross-deck.com/.well-known/security.txt (RFC 9116 format).

Response SLAs

• Acknowledgement: within 2 business days of receipt.
• Initial triage and severity assessment: within 5 business days.
• Remediation timeline communicated within 14 calendar days.
• Critical and high-severity issues remediated within 30 calendar days where reasonably possible; medium within 90 days; low within 180 days. Where remediation is not reasonably possible within the stated window, the reasoning is communicated to the reporter and a revised timeline is agreed.

Safe harbour

Crossdeck will not pursue legal action against a security researcher who, in good faith, reports a vulnerability to us via the reporting channel, provided the researcher:

• does not access, modify, or destroy Customer Data beyond what is necessary to demonstrate the vulnerability;
• does not exfiltrate, store, or share Customer Data outside what is necessary to demonstrate the vulnerability and reports promptly;
• does not disrupt the Service for other Customers (e.g. no sustained denial-of-service testing);
• gives Crossdeck reasonable time (the agreed remediation window) to address the issue before public disclosure;
• complies with applicable law.

We coordinate public disclosure with the reporter where they wish to publish. We credit reporters in published advisories unless they opt out.

Bug bounty

A formal bug bounty program is not in place on the Effective Date. Discretionary monetary rewards may be paid for impactful reports during the safe-harbour window.

10. Personnel security

• Background checks (criminal record + reference verification) are conducted on every hire with production access, scoped to what is legal in the candidate's jurisdiction.
• Every contributor with production access signs a written confidentiality undertaking before access is granted.
• Annual security training (phishing recognition, secrets handling, incident response) is mandatory for all personnel with production access.
• Departures: access revocation within 4 business hours of role change or termination; offboarding checklist documented and signed.

11. Data residency

• Primary processing region: Google Cloud us-central1 (Council Bluffs, Iowa, US).
• Disaster-recovery snapshots: nam5 multi-region (Google Cloud's US multi-region).
• Edge content delivery (cross-deck.com marketing + docs): Cloudflare global edge.
• Analytical aggregation: ClickHouse Cloud us-east-2 (AWS Ohio).
• EU- / UK- / Switzerland-specific data residency on dedicated EU regions is on the roadmap subject to demand; until then, Restricted Transfers are governed by EU SCCs + UK IDTA + FDPIC adaptation as set out in the DPA.

12. Certifications, attestations, roadmap

Current state

On the Effective Date, Crossdeck has not yet completed any third-party security attestation. Customers requiring SOC 2 or ISO 27001 as a procurement prerequisite are notified at sign-up and may defer onboarding until the relevant attestation is available. We make this commitment explicit rather than attempting to fudge — a partial answer here loses enterprise deals at the security review stage.

SOC 2 Type II — committed roadmap

Crossdeck is committed to obtaining SOC 2 Type II attestation. The plan and timeline:

• Q4 2026: SOC 2 readiness assessment with an established audit firm; gap closure.
• Q1 2027: SOC 2 Type II audit period commences (minimum 6-month observation window).
• Q3 2027: Initial SOC 2 Type II report available; provided to Customers under NDA on request.
• Annual recertification: ongoing.

The audit will cover the Trust Services Criteria for Security, Availability, and Confidentiality. Processing Integrity and Privacy criteria are added at the discretion of customer demand; Privacy is likely added at the second-year audit given the named-regimes commitment in the DPA.

ISO 27001

Not pursued for v1. Revisited annually as customer demand evolves.

HIPAA, PCI DSS, FedRAMP, IRAP, BSI C5

Not pursued. Crossdeck is not in HIPAA, PCI, or FedRAMP scope by design; the AUP prohibits use cases that would put us in those scopes without a separate written supplemental agreement.

13. Diagnostic telemetry hardening

The SDK Diagnostic Telemetry endpoint (Privacy Policy §6) is operated under tighter retention and minimisation rules than the primary event ingestion path, in line with our position that it is an independent-controller flow.

• Payload schema lock. The payload contents are pinned to the seven fields enumerated in Privacy Policy §6, enforced by a contract in the public contracts/ directory and asserted by per-SDK unit tests in CI. Adding a field requires an open pull request, contract update, and Privacy Policy amendment.
• IP truncation at the edge. The full requesting IP is visible only to the load balancer for request handling. Application-level logging receives the IP truncated to network prefix (/24 for IPv4, /48 for IPv6). No durable storage of the full IP.
• User-Agent retention. User-Agent is read for sdk_version envelope validation, then discarded. Not persisted.
• No geolocation derivation. No MaxMind or equivalent IP-to-location lookup on this endpoint.
• No TLS fingerprinting.
• Operational log retention. 7 days for anti-abuse purposes only; older logs deleted automatically.
• Anti-abuse rate limit. Per source IP, low enough that a malicious actor cannot flood the endpoint without first being detected and blocked.
• Annual review. The runbook, including the contract and the retention windows, is reviewed annually; any change is announced in the Privacy Policy change history.

14. Change history

Material changes to this Overview are tracked in the public repository's commit history under legal/security/. The initial publication on the Effective Date is v1.0.

Contact for security questions: [email protected].