Security
What DTM holds, where it lives, who can see it and how to tell us about a problem. Written for the person filling in your vendor form.
What DTM holds
Work records about named people: their Campaigns and Missions, planned and logged hours, Overhead (meetings, admin, support, leave), Notes they choose to write, and names, work email addresses and job titles. Your Organisation is the controller under UK GDPR; DTM is the processor.
No activity monitoring: no online status, no screenshots, no keystrokes. Calendar sync stores the start, end and kind of an event, never its title, attendees or description.
Where it lives
The database and the app's servers run in London. Every connection is HTTPS only, with HSTS. Data is encrypted at rest by the database host; calendar tokens are encrypted again with AES-256-GCM before they are stored.
Who can see what
Every row carries its Organisation, and Postgres row-level security keeps each Organisation's data apart, with permission checks again in the service layer. Automated tests try every action as every kind of login, through both, on every change.
Every change is written to a change log with who made it and how: themselves, a Manager covering for them, or an AI tool acting for them.
Signing in
Sign in with Google, with an emailed one-time code, or through your company's own SAML login (we connect it with your IT team). DTM stores no passwords. An Admin who proves your email domain over DNS can make your SAML login the only way in for everyone at that domain, so your company's two-factor and leaver rules apply.
Anyone can add an authenticator app as a second factor, and an Admin can require one for everyone who signs in by email code. Email codes work once and expire after 10 minutes, and repeated attempts are limited per address and per network.
An Admin can remove someone, which signs them out of every browser and AI tool at once. Anyone can sign themselves out everywhere from Settings.
AI
DTM itself sends none of your data to an AI model. A person can connect their own AI tool (such as Claude) through DTM's MCP server; it then acts as that person, with their permissions, and its changes are marked. An Admin can set AI access to On, Read-only or Off for the whole Organisation, see every connection and disconnect any of them. AI tokens work only on the MCP server, never directly against the database.
Your data, out and gone
An Admin can download everything the Organisation can see as CSV files at any time, and erase one Person and everything about them on request. Each Person can download everything about themselves, their private Notes included.
Data is kept while your Organisation is open. When an Admin closes it, everyone else loses access at once and everything is deleted 30 days later, unless an Admin reopens it first.
How it's built
Every change runs type checks, unit, database and browser tests before it ships. Dependencies are audited, code is scanned for security flaws and the whole history is scanned for leaked secrets, weekly and whenever dependencies change. Responses carry a Content Security Policy and standard security headers.
Sub-processors
| Company | What for | Where |
|---|---|---|
| Supabase | Database and sign-in | London, UK |
| Vercel | Hosting the app | Functions in London, UK; static files from a global network |
| Resend | Sending sign-in codes by email | Ireland (EU); no open or click tracking |
| Sign in with Google; read-only calendar sync if a person connects it | Google's own regions |
We tell Admins before adding one.
Found a problem?
Email security@dailyteammap.com. We reply within two working days, keep you posted until it's fixed, and won't take action against good-faith research that avoids other people's data. If a breach affects your Organisation's personal data, we tell your Admins without undue delay, so you can meet your own 72-hour duty.
Also at /.well-known/security.txt.