Privacy Policy
Last updated:
This policy explains what data Co-Signal processes, why, who else processes it on our behalf, and how you can exercise your rights over it. It applies to co-signal.com and the Co-Signal application.
What data we process
Co-Signal processes the following categories of data:
- Workspace and user identity. Your name and email address, from the sign-in provider you use to create your account, plus your workspace membership and role.
- CRM-derived account, contact and opportunity records. When you connect a CRM (Salesforce, HubSpot, or a CSV import), we ingest and store the account, contact and opportunity records you choose to connect, so we can compute overlaps with your partners.
- Encrypted CRM access tokens. The OAuth access and refresh tokens issued by your connected CRM, encrypted at rest (AES-256-GCM), so Co-Signal can keep your data in sync without storing your CRM credentials in plain text.
- Sharing rules and their audit log. The visibility level and field-level choices you set for each partner, and a log of every change made to them, including who made the change and when.
- Contact-form leads. The name, email, company and (optional) message you submit through our contact form.
- Operational logs. Standard server request and error logs generated by running the service.
Lawful basis and roles
For CRM-derived account, contact and opportunity records, your company is the data controller and Co-Signal is the data processor: you decide what to connect and what to share with a partner, and we process it under your instructions to provide the service. For your own workspace and user identity, and for the leads you submit through our contact form, Co-Signal is the data controller.
Who processes data for us
We use a small number of subprocessors, each of which is traceable to a real, currently-configured integration in our production environment. We do not use any subprocessor beyond the ones listed here.
| Subprocessor | What it processes | Purpose |
|---|---|---|
| Google Cloud Platform (Firebase) | Workspace and user identity, connected CRM account/contact/opportunity records, encrypted CRM access tokens, sharing rules and their audit log, contact-form leads, and operational logs. | Identity, application data storage, and application hosting: Firebase Authentication signs users in, Cloud Firestore stores every workspace, account, contact, opportunity, sharing rule, audit log entry and lead, and Cloud Run (via Firebase App Hosting) runs the application server. |
| DeepSeek | Candidate account identity evidence (company names, domains, and other CRM-derived matching signals) submitted for classification. No CRM access tokens are ever sent. | AI language model provider used for smart matching: fuzzy company-identity classification beyond exact domain matching. |
Some CRM integrations (Salesforce, HubSpot) and other third-party services (Slack, an email provider) exist in our codebase but are not currently enabled in production: no credentials are configured for them, so they do not process data today. If and when any of them is enabled, this policy and the table above will be updated first.
Where data is stored and processed
Our application and database run in Google Cloud's europe-west4 region (the Netherlands), inside Firestore's eur3 multi-region, matching the region recorded in our deployment runbook. Data processed by our AI subprocessor is transmitted to that provider's own infrastructure for the sole purpose of the smart-matching request being made.
Retention and deletion
We retain your data for as long as your workspace remains active. To request deletion of your workspace or any data within it, contact us through our contact page. We will confirm deletion in writing once it is complete.
Your data subject rights
Depending on where you are located, you may have the right to access, correct, delete, or export your personal data, or to object to or restrict how we process it. To exercise any of these rights, contact us and we will respond within a reasonable time.
Security practices
- CRM access tokens are encrypted at rest.
- Every sharing decision is enforced server-side, through one authorization layer every surface of the product calls through.
- Changes to sharing rules are written to an audit log.
- Every new partnership starts at the most conservative sharing default.
This policy was drafted for Co-Signal and reviewed by our team before publication. A review by a qualified legal professional is a planned post-launch item, not something that has happened yet.