Privacy policy
This policy describes what personal data we collect when you use Crossdeck — the cross-deck.com dashboard, the SDKs, the underlying API — why we collect it, the lawful basis under each privacy regime that applies to you, how long we retain it, and the rights you have over it. We use the strictest regime (GDPR / UK GDPR) as the floor and name the regime-specific overlays where they grant additional rights.
If you are a developer signing up for Crossdeck, this policy describes how we handle your data. If you are an end user of an app or website that has installed Crossdeck's SDK, your data is processed by the operator of that app under their privacy policy; we act as their data processor under our Data Processing Addendum, except for the narrow SDK diagnostic telemetry described in §6 below, where we act as an independent controller.
1. Who we are
The data controller responsible for personal data processed under this policy is VistaApps (Pty) Ltd, a private company incorporated in South Africa with registered office at [address to be confirmed], trading as "Crossdeck" (referred to throughout as "we," "us," "our," or "Crossdeck"). VistaApps (Pty) Ltd is the responsible party under POPIA and the controller under GDPR / UK GDPR / equivalent regimes.
A reorganization to a Delaware (United States) parent holding company with VistaApps (Pty) Ltd as its operating subsidiary is in progress. When the reorganization completes, the Delaware entity will assume controller responsibility for non-South-African data flows, with VistaApps (Pty) Ltd remaining the controller for South African data under POPIA. This policy will be amended to reflect the change before the new structure takes effect.
Privacy contact: [email protected]. Security contact: [email protected]. We aim to acknowledge correspondence within 5 business days and to resolve substantive requests within 30 days (GDPR Article 12(3) and equivalent timeframes under UK GDPR, POPIA, CCPA/CPRA, and other named regimes).
2. Scope & the two flows of data
Crossdeck processes personal data along two distinct flows. The legal framework that applies to each flow is different, and conflating them is the most common privacy mistake we have seen in our own diligence reviews of comparable SDK vendors.
Flow A — Customer-controlled event data (we are a processor)
When a developer ("Customer") installs the Crossdeck SDK in their application, the SDK transmits event data about that Customer's end users to our servers for the purpose of populating that Customer's dashboard. Examples: a page view, a button click, a session lifecycle event, an identified user record, a captured error, a verified purchase. The Customer determines the purposes and means of this processing. We act as the Customer's data processor under GDPR Article 28 and equivalent processor designations in other regimes. The governing document is our Data Processing Addendum (DPA), which is incorporated by reference into our Terms of Service.
This Privacy Policy does not govern Flow A as between us and the end users of our Customers' applications. End users in that flow should consult the privacy policy of the application operator (our Customer) that has installed our SDK. We make available a Customer Disclosure Template our Customers may use to disclose Crossdeck in their own privacy policy.
Flow B — Crossdeck-controlled data (we are the controller)
Two narrow flows fall outside the processor relationship and are governed by this Privacy Policy directly:
- Customer (developer) account data — when you sign up for Crossdeck as a developer, create a project, configure rails, pay a subscription, or interact with cross-deck.com or our support channels, we process your personal data as a controller for those purposes. §3–§5 describe what, why, how long.
- SDK diagnostic telemetry — when our SDK is installed in a Customer's application and that SDK reports diagnostic information about its own operation (specifically: contract-test failures, version-pinning audits, and the minimum HTTP request envelope required to deliver those reports), we receive that telemetry as an independent controller and process it for the legitimate interest of operating reliable software. §6 describes this flow specifically, in line with the Breyer line of case law (CJEU C-582/14) confirming that an IP address transmitted to a remote service constitutes processing of personal data by that service.
3. Categories of personal data we collect
For Flow B (data we collect as controller), the categories are:
| Category | Examples | Source |
|---|---|---|
| Account identifiers | Email address, full name, hashed password (we never store plaintext), Firebase Auth UID, project ID, app ID. | You, directly, at sign-up and during account management. |
| Billing & tax data | Billing address, company name, VAT / tax registration number, payment-method last 4 digits (full PAN never touches our servers — Stripe Elements tokenizes in your browser). | You, directly, during checkout. |
| Dashboard usage telemetry | Pages you view on cross-deck.com, clicks, sessions, IP address, browser, operating system, approximate location derived from IP, referring URL. | Automatically captured by our own SDK installed on cross-deck.com (we use our own product). |
| Support correspondence | Email subject + body, attachments, timestamps, the support agent who handled the conversation. | You, by emailing support / sales / privacy at cross-deck.com. |
| SDK diagnostic telemetry | Contract failure events (contract_id, sdk_version, sdk_platform, failure_reason, run_context, run_id, optional test references). HTTP envelope metadata: IP address, User-Agent. See §6. | Automatically transmitted by the Crossdeck SDK installed in our Customers' applications. |
| Security logs | Failed login attempts, suspicious API requests, audit trail of admin actions, IP address truncated to network prefix. | Automatically captured by our infrastructure. |
We do not knowingly collect "special categories" of personal data under GDPR Article 9 (racial or ethnic origin, political opinions, religious beliefs, trade union membership, genetic or biometric data, health data, sex life or sexual orientation) or "sensitive personal information" under CPRA. Customers are prohibited under our Acceptable Use Policy from transmitting such data through our SDK without prior written agreement.
4. Purposes & lawful bases
| Purpose | GDPR / UK GDPR lawful basis (Art. 6) | POPIA justification (s.11) | CCPA / CPRA business purpose |
|---|---|---|---|
| Providing the Crossdeck service to you (account creation, dashboard, SDK API operation, support). | (b) Performance of contract. | (a) Consent and (b) necessary to conclude or perform contract. | Performing services; debugging. |
| Billing & tax compliance. | (c) Legal obligation; (b) performance of contract. | (c) Compliance with obligation imposed by law. | Performing services. |
| Securing the service, detecting fraud, abuse, and policy violations. | (f) Legitimate interest — protecting our customers and our service against attacks and abuse, balanced against the limited intrusion of security logging. | (d) Protection of legitimate interest; (f) pursuit of legitimate interest of the responsible party. | Detecting security incidents; protecting against malicious or fraudulent activity. |
| SDK diagnostic telemetry (operating reliable software, see §6). | (f) Legitimate interest — diagnosing SDK defects affecting all our Customers, balanced against the minimal envelope-metadata footprint and the no-payload-PII guarantee. | (f) Pursuit of legitimate interest of the responsible party. | Maintaining or servicing accounts; quality and safety control. |
| Product analytics on cross-deck.com (which features get used, how dashboard sessions flow). | (f) Legitimate interest — improving the service; you may object at any time without affecting your access. | (f) Pursuit of legitimate interest of the responsible party. | Performing services; internal research. |
| Marketing communications (only if you opt in or are an existing customer of comparable services — UK PECR / EU ePrivacy). | (a) Consent (new prospects); (f) legitimate interest (existing customers, soft opt-in, easy unsubscribe). | (a) Consent; (b) reasonably necessary for legitimate purposes. | Auditing related to a current interaction; counting ad impressions to unique visitors. |
5. Retention
We retain personal data only as long as necessary for the purposes for which it was collected, including any legal, accounting, or reporting requirements.
| Category | Retention period | Trigger for deletion |
|---|---|---|
| Account identifiers, dashboard configuration. | Duration of your contract + 90 days after termination. | 90 days after the contract ends, unless you request earlier deletion under §9. |
| Billing records, invoices, tax records. | 7 years from the end of the financial year (US, EU, UK, ZA tax law floors). | End of the statutory retention period. |
| Dashboard usage telemetry (events on cross-deck.com). | 13 months (raw events); aggregates indefinitely once anonymised beyond re-identification. | Rolling 13-month window enforced by automated TTL. |
| Support correspondence. | 3 years from the date of the last message in the thread. | Automated archival after 3 years. |
| SDK diagnostic telemetry payloads. | 90 days for raw events; 13 months for aggregated counts; longer for fingerprinted-and-anonymised failure patterns. | 90-day TTL enforced by Firestore + ClickHouse retention policies. |
| SDK diagnostic telemetry envelope (IP, User-Agent). | IP is truncated to network prefix (IPv4 /24, IPv6 /48) before any persistence. Full IP is held only in the load-balancer request-handling layer for the duration of the request, never written to durable storage. User-Agent is used to validate sdk_version then discarded. | Per-request; nothing durable. |
| Security logs. | 13 months (active); 7 years (cold archive, encrypted, restricted access — for forensics in the event of a later-discovered breach). | Tiered automated archival. |
6. SDK diagnostic telemetry (we are the controller)
When the Crossdeck SDK is installed in a Customer's application, the SDK may transmit a narrow set of diagnostic telemetry to us about its own operation. We act as an independent controller for this telemetry under GDPR / UK GDPR, with the legitimate-interest lawful basis (Art. 6(1)(f)). This processing is independent of the Customer's controller relationship over the end user's other personal data.
Payload contents — exhaustive list
The diagnostic telemetry payload contains only the following fields, enforced by a contract registered in our public contracts directory and verified by automated tests in every SDK release:
contract_id— identifier of the failed contract (string).sdk_version— semver of the SDK build that reported the failure.sdk_platform— one ofweb/node/swift/android/react-native.failure_reason— short machine-readable reason code.run_context— one ofci/dogfood/customer-app.run_id— opaque identifier of the test run; not stable across runs and never linked to an end user.test_file,test_name,device_class— optional, all opaque to end-user identity.verification_phase— optional, categorical (bootorhot_path). Identifies which layer of the SDK's runtime contract verifier produced the failure:bootfor the self-test that runs onCrossdeck.start(...),hot_pathfor a verifier observing a real customer-triggered operation. The categorical nature preserves the diagnostic-only-not-personal classification.
The payload contains no end-user identifiers, no IP address, no email, no free-form text, and no exception messages or stack frames. A schema-lock contract enforces this; any pull request that adds a new field fails CI until reviewed and the contract is amended in the open.
Envelope metadata
The HTTP request that delivers the payload necessarily carries envelope metadata: the requesting IP address, User-Agent, TLS handshake metadata, and approximate geolocation derivable from the IP. Under settled case law (Breyer v Germany, CJEU C-582/14, 19 October 2016), IP addresses constitute personal data when transmitted to a service capable of identifying the subject in combination with additional information lawfully available to it. We disclose this transmission and handle it as follows:
- IP truncation at the edge. Full IPs are visible to the load-balancer for the duration of the request only. 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: read, not persisted. Used to confirm the
sdk_versionmatches the request envelope (SDK self-audit), then discarded. - No geolocation derivation. We do not run MaxMind or equivalent on the IP for the diagnostic endpoint. We are not interested in where the failure occurred for analytical purposes.
- No TLS fingerprinting.
- Operational logs retention 7 days. Anti-abuse only.
Why this is independent-controller, not processor
The Customer does not determine the purpose of this telemetry — we do, for the legitimate interest of operating reliable software on behalf of all our Customers collectively. The Customer cannot meaningfully instruct us to stop collecting this telemetry without disabling the SDK entirely, which would defeat the contractual purpose. Under the Article 29 Working Party Opinion 01/2010 (WP169) on the controller/processor concepts, this falls cleanly on the controller side, and we document it accordingly.
Customer's privacy-policy obligation
Customers using our SDK must disclose Crossdeck as an independent recipient and controller of SDK diagnostic telemetry in their own privacy policy. We provide pre-vetted language for them to paste in our Customer Disclosure Template.
8. International data transfers
Personal data we process is stored and processed primarily in Google Cloud's
us-central1 (Iowa, United States) region. Personal data
originating in the European Economic Area, the United Kingdom, or
Switzerland is transferred outside those jurisdictions on the following bases:
- EU Standard Contractual Clauses (June 2021) — Module 2 (controller-to-processor) and Module 4 (processor-to-controller) as applicable, incorporated by reference into our DPA and into each sub-processor agreement we hold with our vendors. Latest Commission Implementing Decision (EU) 2021/914.
- UK International Data Transfer Addendum (IDTA, 2022) — appended to the EU SCCs for UK-origin data, per ICO template.
- Swiss FDPIC SCC adaptation — for Switzerland-origin data, where the Federal Data Protection and Information Commissioner's amended template applies.
- POPIA Section 72 — we rely on equivalent-protection grounds for transfers of South-African-origin data, with binding contractual provisions in our sub-processor agreements.
We do not rely on the EU–US Data Privacy Framework adequacy decision as a primary basis given the ongoing litigation risk, although our principal US sub-processor (Google LLC) is self-certified under it.
9. Your rights under each privacy regime
The rights you have depend on the regime that applies to you. The table below lists the rights you have under each named regime; in practice, where regimes grant overlapping rights, we honour the strictest version.
| Regime | Rights granted (summary) | How to exercise |
|---|---|---|
| GDPR (EU) & UK GDPR | Access (Art. 15), rectification (Art. 16), erasure / "right to be forgotten" (Art. 17), restriction (Art. 18), portability (Art. 20), objection (Art. 21), no automated decision-making (Art. 22), withdraw consent (Art. 7(3)). | [email protected] — we respond within 30 days (extendable by 60 days under Art. 12(3) where justified). |
| POPIA (South Africa) | Access to personal information (s.23), correction (s.24), deletion / destruction (s.24(1)(b)), objection to processing (s.11(3)), withdrawal of consent (s.11(2)(b)), complaint to Information Regulator. | [email protected]. Information Officer designated and registered with the Information Regulator. |
| CCPA + CPRA (California) | Right to know (categories, specific pieces, sources, purposes, third parties), right to delete, right to correct, right to opt-out of sale / sharing, right to limit use of sensitive PI, right to non-discrimination. | [email protected]; toll-free request submission is not maintained as we are an online-only service per CCPA Regulation §7060. |
| Other US state laws (VA CDPA, CO CPA, CT CTDPA, UT UCPA, TX TDPSA) | Access, deletion, correction (in some states), opt-out of targeted advertising / sale (we do neither). | [email protected]. |
| PIPEDA (Canada), LGPD (Brazil), APPI (Japan), PIPL (China) | Access, correction, deletion / withdrawal of consent, complaint to the respective regulator. Cross-border transfer notifications where required (PIPL Art. 39). | [email protected]. |
We do not charge fees for substantiated rights requests. We may charge a reasonable administrative fee for manifestly unfounded or excessive requests (GDPR Art. 12(5)), and we may refuse to act on such requests with a written justification. We verify the identity of requestors using account authentication where you are a Customer of ours, and via documentation verification where you are not.
10. Children's data
Crossdeck is a business-to-business product, not directed to children. We do not knowingly collect personal data from children under the age of 16 (GDPR threshold) or under the age of 13 (US COPPA threshold). Customers are prohibited under our Acceptable Use Policy from installing our SDK in applications directed to children under 13, and from transmitting personal data of children under 13 through our SDK, except under a specific written supplemental agreement that imposes the additional COPPA-compliance obligations the operator of a child-directed service must meet under 16 CFR Part 312.
11. Do Not Track & Global Privacy Control
Our SDK respects two browser-level signals when present:
- Global Privacy Control (GPC) — when the GPC header / DOM signal is set, the SDK treats the user as having opted out of "sale" and "sharing" within the meaning of CCPA / CPRA, which under our model means we do not initiate any advertising-related processing (we do none today regardless). We acknowledge GPC per California AG opinion 22-103.
- Do Not Track (DNT) — the legacy DNT header is honoured where the Customer (controller) has opted into our
respectDntSDK option. By default, DNT is informational only because most modern browsers no longer send it, and the W3C deprecated the standard in 2019.
12. Security
Our security commitments are described in detail in our Security Overview. Summary:
- Encryption at rest: AES-256 (Google Cloud–managed keys).
- Encryption in transit: TLS 1.2 minimum, TLS 1.3 preferred.
- Access controls: role-based access, MFA required for all admin access.
- Audit logs: every admin action against customer records is logged and immutable for 7 years.
- Incident response: 24 hours initial disclosure from confirmation of incident to controller Customers, 72 hours preliminary report, full RCA within 14 days.
- Vulnerability disclosure: [email protected], with safe harbour for good-faith researchers as described in the Security Overview.
- SOC 2 Type II: audit period commencing Q1 2027, report available Q3 2027 (committed roadmap; until then, customers requiring SOC 2 as a prerequisite to purchase are notified at sign-up).
13. Changes to this policy
We will amend this policy when our practices change, when sub-processors change, when applicable laws change, or when an enforcement authority issues guidance that warrants a clarification. Material changes are communicated to registered Customers by email at least 30 days before they take effect, and the effective date at the top of this document is updated. Non-material changes (typographical corrections, clarifying examples) are published without separate notice; the change history is maintained in our public repository.
14. Contact & complaints
For privacy questions, data subject rights requests, or to designate an authorised agent: [email protected].
You also have the right to lodge a complaint with the supervisory authority in your jurisdiction. Examples:
- EU: the data protection authority in the Member State of your habitual residence (one-stop-shop principle, GDPR Art. 56).
- United Kingdom: Information Commissioner's Office (ICO).
- South Africa: Information Regulator.
- California: California Attorney General or California Privacy Protection Agency.
- Other jurisdictions: see the list at DataGuidance.