Data compliance

1. Scope and roles

This page describes how SyncYak protects the data that passes through SyncYak: CRM, Mail, Parse, Cloud Logging and Tunnel, the dashboard and the APIs. It is written for customers and for the auditors and security reviewers who assess us on their behalf.

For the leads, emails, records, logs and traffic customers send through SyncYak, the customer is the controller and we are the processor: we process that data only to provide the service the customer configured. For account and billing details, we are the controller. The Privacy Policy lists what we collect and why; the Terms of Service set out the processing terms.

2. Controls at a glance

3. Data in transit

Every connection that carries customer data is encrypted:

• Browsers and API clients to SyncYak. Only HTTPS, with TLS 1.2 or newer and certificates from Let’s Encrypt that renew automatically. Plain HTTP requests are redirected, and browsers are told to use HTTPS only (HTTP Strict Transport Security, one year, all subdomains).
• Between SyncYak’s servers. Servers talk to each other over TLS, and each request is also signed with a shared secret and a timestamp, so one server only accepts instructions from another member of the cluster and refuses a recorded request replayed more than two minutes later.
• To our database. Application servers connect to the database over TLS and verify its certificate against SyncYak’s own certificate authority. The database accepts connections only from SyncYak’s servers; it is not reachable from the internet.
• To the services customers connect. CRMs, Google Sheets and webhooks are reached over HTTPS; mailboxes over IMAP and SMTP with TLS 1.2 or newer. Webhooks we send are signed (HMAC-SHA256) so the receiver can check they came from SyncYak and were not altered.
• The tunnel agent. The syncyak command-line tool connects to SyncYak over TLS; the public side of every tunnel is served over HTTPS.

4. Data at rest

• Where it lives. Account, team and billing records are kept in SyncYak’s central database. The data each product processes for an account is kept in that account’s own store on the server assigned to it, apart from every other account’s.
• Secrets are encrypted. The passwords, API keys and OAuth tokens customers give us to reach their CRMs, mailboxes and databases, and our own integration secrets, are encrypted with AES-256-GCM before they are stored. The key is kept outside the database, so a copy of the database alone does not reveal them, and every encrypted value is tied to the record it belongs to, so it cannot be moved to another record and decrypted there.
• Passwords and tokens are not stored. Account passwords are kept only as bcrypt hashes. Sign-in sessions, API keys, invitations and password-reset links are kept only as SHA-256 hashes, so the values that grant access never sit in the database.
• Card details never reach us. Payments are handled by Stripe; we keep a reference to the customer in Stripe, never card numbers.
• Backups. The central database is backed up every night to a location only server administrators can read, and each backup is deleted after 14 days.

5. Who can access data

Customers and their teams

• Each team member has a role (owner, admin, developer, billing or viewer) that limits what they can see and change, and access can be limited to some products.
• API keys can be limited to one product and revoked at any time.
• Two-factor sign-in with an authenticator app is available to every user. Repeated wrong passwords lock sign-in for ten minutes, and sign-in takes the same time whether or not an address has an account, so the form cannot be used to discover customers.
• The sign-in cookie cannot be read by scripts, is sent only over HTTPS and not with requests started by other sites; requests that change data from other websites are refused.
• Every sensitive action in an account (sign-ins, key changes, member and plan changes) is recorded in its audit log.

SyncYak staff

• Production access is limited to the operators who run the service. The operator console is invisible to everyone else, and every operator action is recorded with who did it and when.
• We access a customer’s data only to provide the service, to answer a support request they made, or when the law requires it.
• The SyncYak service runs as an unprivileged system user with a restricted view of the server.

6. Application safeguards

• Outbound connections are checked. When a customer gives us an address to call (a webhook, a CRM, a database, a mail server), we refuse private, internal and cloud-metadata addresses, checked again at the moment of connecting, so the feature cannot be turned against our own network.
• Secrets stay out of logs. Links that carry a secret, such as webhook and invitation links, are masked before requests are logged.
• Browser protections. Pages are sent with headers that prevent framing by other sites, content-type guessing and leaking full addresses to other sites.
• Abuse limits. Sign-up, sign-in, password resets and the contact form are rate limited, and request sizes are bounded.
• Change control. Every change runs through automated tests before release, and releases are rolled out one server at a time.

7. Retention and deletion

Each product keeps customer data for the retention period of the customer’s plan, then deletes it automatically; the periods are listed in the Privacy Policy. Customers can delete their data at any time while the account is open.

When an account is closed, its paid plans are cancelled at once and its data is kept for 30 days in case the closing was a mistake. After that, it is permanently deleted from every server, and it leaves the backups as they expire, within a further 14 days.

8. Sub-processors

We use a small number of providers to run SyncYak: Stripe for payments, Cloudflare for DNS and network protection, an email delivery provider for service emails, and Google only when a customer connects a Google Sheet. The Privacy Policy describes each one.

9. Incident response

If we learn of a security incident affecting customer data, we contain it, investigate what happened and tell the affected customers without undue delay: what data was involved, what we have done and what they should do. This lets customers meet their own obligations, such as the 72-hour notice the GDPR requires of controllers. To report a vulnerability, write to [email protected] with “Security” in the subject.

10. Agreements and questionnaires

We sign data processing agreements, including the European Commission’s standard contractual clauses where data leaves the EU or UK, and we answer security questionnaires. Write to [email protected] with your company’s legal name and what your review needs.