Security & Trust

Last updated: 12 October 2026

SYNCDATE is operated by DUMA DIGITAL SOLUTIONS S.R.L. (Romania), an EU company. This page explains how we handle your data — the access we request, how we protect it, where it lives, and how it is retained and deleted.

How SYNCDATE handles your data

What SYNCDATE does. SYNCDATE keeps calendars in sync. It reads events from calendars you connect, applies your sync rules, and writes to the calendars you choose. It does not read email, files, contacts, or anything beyond calendars.

Privacy by default. New syncs copy events as Busy. A two-way Mirror between calendars you own keeps the real titles. You can change either before you start. For teams projecting availability to clients, that means event titles, descriptions, and attendees stay off the client calendar unless you change it; the client calendar only learns that a time slot is taken.

Access and scopes

SYNCDATE requests calendar scopes only, plus basic sign-in identity:

Google: openid, email, profile, calendar.readonly (read), and calendar.events (create/update/delete events). No Gmail, Drive, Contacts, or Directory scopes are requested.
Microsoft (Entra ID / Outlook): Sign-in requests openid, email, profile, offline_access, User.Read (basic profile), and Calendars.ReadWrite (read/write your calendars). When you connect another Outlook account or change an account on the Accounts page, SYNCDATE lets you choose: Calendars.Read for your own calendars read-only; Calendars.ReadWrite for your own calendars editable; Calendars.Read.Shared for your own and shared calendars read-only; Calendars.ReadWrite plus Calendars.Read.Shared for your own calendars editable and shared calendars read-only; or Calendars.ReadWrite.Shared for your own and shared calendars editable. Microsoft’s sharing rights still determine whether each shared calendar can be edited. A narrower later request does not revoke a previously granted Microsoft permission; SYNCDATE enforces the selected read-only setting. No Mail, Files, or Directory permissions are requested.

offline_access (Microsoft) and access_type=offline (Google) let SYNCDATE keep syncing in the background without you re-signing-in each time. You can disconnect an account at any time; disconnecting revokes SYNCDATE’s stored access and refresh tokens.

Encryption

Credential security. OAuth tokens are encrypted at rest with AES-256-GCM. SYNCDATE never sees or stores your calendar account password — access is via OAuth grants you can revoke from your provider’s security settings at any time.

Encryption in transit. All traffic is encrypted with TLS, including traffic between our edge (Cloudflare) and origin, which runs in Cloudflare Full (Strict) mode.

Where your data lives

The application and databases are hosted with Hetzner in EU data centres (Germany and Finland), operating under an ISO/IEC 27001:2022 certified information-security management system.

Off-site database backups and write-ahead-log archives are held in private Hetzner Object Storage in the EU. pgBackRest encrypts these recovery objects client-side using AES-256-CBC before upload; the encryption key is kept in protected production configuration and is never stored with the backup objects. Uploads use TLS on port 443 with certificate verification enabled. Recovery objects are retained only for the operational recovery window and no longer than 90 days.

For the full list of subprocessors, their purposes, locations, and transfer mechanisms, see /subprocessors.

Data retention and deletion

Account and connection data are retained while your account is active. Operational logs (including sync logs and MCP tool-call audit logs) are retained for a limited period, typically up to 90 days.

Deleting your account removes your records from our production systems (a PII-free audit tombstone may be retained). Any copy in off-site backups is removed as those backups expire, currently within 90 days. Synced copies already written into third-party calendars live in those calendar accounts and are removed there, not by us.

Infrastructure and operational practices

Our hosting provider, Hetzner, operates its EU data centres under an ISO/IEC 27001:2022 certified information-security management system. The network is protected by Cloudflare (DDoS/WAF), and the origin firewall is restricted to the ports required to serve the application, with web traffic limited to Cloudflare. Encrypted full database backups run daily, with continuous write-ahead-log archiving for point-in-time recovery.

We use structured audit logging with correlation IDs, and we keep production and development environments separated with different encryption and session keys, so development cannot read production data. Production access follows the principle of least privilege and is secured with SSH keys.

Compliance posture

GDPR. SYNCDATE is operated by DUMA DIGITAL SOLUTIONS S.R.L. (Romania), an EU company. A self-serve Data Processing Agreement is available, and the current subprocessor list is published on this site.

Certifications. The infrastructure layer runs in Hetzner’s ISO/IEC 27001:2022 certified EU data centres. SYNCDATE itself is not currently SOC 2 or application-layer ISO 27001 certified. We are happy to complete your security questionnaire.

This section is for an IT administrator who is asked to approve SYNCDATE in an organization’s tenant — for example, when a consultant connects a client-provisioned calendar account.

A member of your team uses SYNCDATE to project their availability into the calendar your organization provisioned for them, so scheduling works without manual copying.

Permissions requested (Microsoft): Sign-in uses User.Read and Calendars.ReadWrite, plus openid, email, profile, and offline_access. For added Outlook accounts and account permission changes, the user chooses one calendar profile before Microsoft authorization: Calendars.Read, Calendars.ReadWrite, Calendars.Read.Shared, Calendars.ReadWrite plus Calendars.Read.Shared, or Calendars.ReadWrite.Shared. These are delegated permissions for calendars the signed-in user can access. SYNCDATE blocks writes on its read-only profiles, including when Microsoft retains an older broader grant. No Directory, Mail, or Files permissions and no application (app-only) permissions are requested.
Permissions requested (Google): calendar.readonly and calendar.events, plus openid, email, and profile. No Gmail, Drive, Contacts, or Directory scopes.
What flows into your tenant: availability blocks (“Busy”) on that user’s own calendar whenever any calendar in the sync is not fully theirs — no event titles, bodies, or attendees from outside your tenant, unless the user explicitly enables detail copying. A two-way mirror between calendars the user fully owns keeps titles unless the user switches that off.
What flows out of your tenant: by default, nothing beyond what the user configures. If the user enables a sync direction out of the tenant, events on their tenant calendar can sync to their other calendars, as they configure.
Data handling: tokens encrypted at rest (AES-256-GCM); primary processing in EU data centres (Hetzner, Germany/Finland, ISO/IEC 27001:2022); a small number of US-based subprocessors covered by SCCs and the EU–US Data Privacy Framework (see the subprocessor list); a GDPR DPA and subprocessor list are published. Access is revocable at any time from your tenant — revoking the app’s grant immediately cuts SYNCDATE’s access.
Scope of trust: the app uses per-user delegated consent for the user’s calendars and calendars others shared with that user when they opt in.

Questions: support@syncdate.app.