1. Our approach
Your contact list and your patients’ booking requests are some of your practice’s most valuable and most sensitive data. We design ModularMail to hold as little as it needs, keep each practice’s data separate, and protect it at every step. This page describes what we do. It is a description of our practices, not a certification: we do not claim an audit standard we have not been assessed against.
2. Protecting data
- Encryption in transit. All traffic to the website, app and booking pages uses HTTPS.
- Encryption at rest. Our database and file storage provider encrypts stored data. Credentials for the email delivery accounts we manage for you are additionally encrypted by us before they are stored.
- Passwords. We never store your password in readable form. Sign-in is handled by our authentication provider, which stores only a salted hash.
- Payments. Payments are handled by Stripe. Card numbers never touch our servers.
- Data minimisation. We hold what we need to deliver your email and booking requests. We do not hold clinical records, and the Service does not connect to your practice management system today.
- No patient data to AI. We do not send contact lists or patient details to our AI provider. Names are merged into emails when they are sent.
3. Keeping practices apart
Every practice’s data is tied to its own account and protected by row-level security in the database, so one practice cannot read another’s contacts, campaigns or booking requests, even through a fault in the application. Privileged keys are used only on our servers, never in your browser, and are kept out of our code.
4. Access and operations
- Least access. Only people who need production data to do their job can reach it, and destructive database changes need explicit sign-off before they are run.
- Signed internal calls. Our background workers and integrations verify a signature on every incoming call, and unsigned calls are refused.
- Secrets management. Keys and credentials are held in our hosting provider’s secret store, not in source code.
- Provider vetting. We use established providers (see sub-processors), and have written data protection terms with each.
5. Booking pages and patient submissions
- Each email’s booking page has a random identifier that cannot be guessed, and a practice’s own booking link also needs a secret key.
- Links in emails carry no personal information: no names or email addresses in web addresses.
- Submissions are rate-limited and screened for bots, and booking pages are kept out of search engines.
- The practice is told about a new request by email. We pass on only what the patient entered.
6. Protecting your sending reputation
A pre-send check blocks emails that are missing essentials (such as the unsubscribe link and sender details), contain link shorteners, or would be clipped by mailbox providers. Unsubscribes, bounces and complaints are suppressed automatically so they are never emailed again, and sending is monitored so that a problem on one account does not affect others.
7. If something goes wrong
We investigate security events promptly. If we confirm a personal data breach affecting your data, we will tell you without undue delay and within 72 hours, explain what happened and what we are doing about it, and help you meet any duty you have to notify patients or regulators.
8. Reporting a vulnerability
If you think you have found a security problem, please tell us at support@modularmail.io. Give us a reasonable time to fix it before you share it, do not access or change other people’s data, and do not disrupt the Service. We will acknowledge your report, keep you informed and not take action against anyone acting in good faith.
9. What you can do
- Use a strong, unique password and keep it private.
- Tell us straight away if you think your account has been accessed by someone else.
- Only upload the contact details you need. Never upload clinical information.