Privacy Policy

This distinction decides who you should contact about your data, so it comes first.

As a controller — for people who visit this site or contact us. We decide what to collect and why.

As a processor— for the data inside a customer’s connected systems. When a customer connects their CRM to Sygnal, that customer remains the controller of the personal data in it. We act on their instructions. If your details are in a customer’s CRM and you want them removed, the customer is the right party to ask; we will support them in doing it, and we will pass on any request that reaches us directly.

Sygnal reads from systems a customer explicitly connects. It is read-only: Sygnal never writes to, edits or deletes anything in a connected system.

• CRM (HubSpot, Attio) — companies, contacts (name, work email address, job title), deals and their values and stages, and logged meetings and calls.
• Event platforms (Luma) — guest name, email address, and registration and attendance timestamps for events the customer hosted.
• Advertising platforms — campaign names, spend, impressions and clicks. No personal data.
• Web analytics — visit counts grouped by channel and day. No personal data, and no individual-level browsing data.

Where a system offers scoped permissions we request read access and nothing more. Some tools authorise instead with an API key, which carries whatever permissions the customer issued it with; there the read-only limit is enforced by our own code rather than by the platform, and we recommend issuing the most restricted key the tool allows. Sygnal has no code path that writes to a connected system.

We never see or store passwords. Authorisation is handled by Nango, which holds the access tokens issued when a customer connects a system, and refreshes them. A customer can revoke access at any time from the connected system, and we retain no means of access afterwards.

Sygnal’s use and transfer of information received from Google APIs to any other app will adhere to the Google API Services User Data Policy, including the Limited Use requirements.

Concretely: data obtained through Google APIs is used only to provide the attribution reporting the customer connected Google in order to receive. It is not sold, not used for advertising, not used to train generalised artificial-intelligence models, and not transferred to anyone except the sub-processors listed below, and then only to run the service. No human reads it except where the customer has asked us to for support, where required by law, or where necessary to investigate a security incident.

Data obtained through LinkedIn’s Marketing and Community Management APIs is used only to report on the customer’s own advertising and their own organisation page. It is not sold, not combined with data from other customers, and not used for any purpose beyond the reporting the customer connected LinkedIn to receive.

• Raw provider responses — 90 days. Copies of what a connected system returned are kept so reporting can be rebuilt without re-fetching, then automatically deleted.
• Derived records— accounts, people, deals and interaction history — for as long as the customer’s account is open.
• On account closure — permanently deleted within 30 days, including from backups on their normal expiry cycle.
• A record deleted in the customer’s own system stops being reproduced by us on the next sync.

We use these sub-processors, and no others:

• Supabase — database hosting, in Frankfurt, Germany (AWS eu-central-1).
• Nango — custody and refresh of authorisation tokens.
• Vercel — application hosting.
• Inngest — scheduling of the background jobs that fetch and process data.
• Resend — delivery of the email the service sends: workspace invitations, sign-in confirmations and password resets.
• Sentry — error reporting, so faults are noticed and fixed. Hosted in the EU. Receives diagnostic detail about a failure, which can include the identifier of the signed-in user and the address of the page they were on.

We do not sell personal data, and we do not share it with advertisers or data brokers.

Data is encrypted in transit and at rest. Each customer’s data carries an organisation key, and every query the application makes is scoped to the organisation of the signed-in user through a single enforcement point in the code. Row-level security is enabled in the database as a second layer, so any access path that does not go through the application is scoped too.

Access by our staff is limited to those who need it to operate or support the service.

Our security page explains how each of these works in more detail.

Where we are the controller, you may ask us to give you a copy of your data, correct it, delete it, restrict how we use it, or object to our use of it, and to receive it in a portable form. Where we are a processor, please direct the request to the customer whose system holds your data — see “the two roles we act in” above.

You can also complain to your data protection authority. In the UK that is the Information Commissioner’s Office.

Privacy questions, and any request under the section above: admin@pion333rs.com, or by post to Dillon House, High Street, Widdington, Saffron Walden, Essex, CB11 3SB.

If we change this policy we will update the date at the top, and tell customers directly where the change materially affects how their data is handled.