Trust
Security, data handling and the paperwork
We build intake automation for clinics, brokers and logistics operators, which means we handle enquiries containing health details, policy numbers and customer contact data. This page is what we would send your compliance officer, written before they ask rather than after.
Agreements we sign
All four are routine for us and none of them require an escalation or a special case. Ask at the point it matters and it gets signed.
Mutual NDA
Signed before any discovery call that needs one, including the first. You do not have to describe your problem to us before we are bound.
Data Processing Agreement (GDPR)
Where we process personal data of people in the EU or UK, we sign a DPA naming us as processor, listing subprocessors, and committing to assist with data subject requests and breach notification within the statutory window.
Business Associate Agreement (HIPAA)
Where a build or a support engagement means we could access protected health information, we sign a BAA with you. We also require one from every vendor in the chain that touches PHI, which is why some model and messaging providers are excluded from healthcare projects by default.
IP assignment in the master agreement
Work product is yours on payment: source code, infrastructure, prompts, evaluation sets and documentation. There is no retained licence and no proprietary runtime you have to keep paying for.
Where your data lives
Data residency is decided at the start of the project, not discovered at the end of it.
You choose the region
Application and database hosting is pinned to the region you require — EU (Frankfurt or Dublin), UK, US, or the Gulf. For regulated work we default to the region your regulator expects rather than the cheapest one.
Encrypted in transit and at rest
TLS 1.2 or higher on every connection, including between our services and yours. Storage-level encryption on databases, object storage and backups.
We hold as little as possible
We do not store payment card details at any point; card data goes directly to Stripe and we keep only the token. We do not copy production databases onto developer machines, and we use redacted or synthetic data in development and testing.
Retention is a setting, not an accident
Transcripts, recordings and audit logs are kept for the period your compliance officer specifies and deleted on schedule. If you need a shorter window than our default, it is a configuration change rather than a negotiation.
Who can reach it
Most real incidents at a vendor this size are access problems rather than exotic attacks, so this is where we spend the effort.
Least privilege, by named person
Access to a client's systems is granted per engineer for the duration of the work, not to the company at large. We can give you the list of who holds what at any point.
MFA everywhere, no shared logins
Multi-factor authentication is mandatory on every account that touches client infrastructure, and credentials are held in a managed password manager rather than in chat, tickets or documents.
Offboarding within one business day
When someone leaves the project or the company, their access is revoked and any shared secrets they held are rotated. You are told when this happens on your project.
Everything privileged is logged
Administrative actions and access to sensitive records are written to an audit log you can read, which is also what makes the HIPAA minimum-necessary principle demonstrable rather than assumed.
How we handle AI and your data
This is the question we get most often, and the honest answer has a few sharp edges worth stating plainly.
Your data is not used to train anyone's model
We use model providers on business or enterprise terms where training on submitted data is contractually excluded, and we verify that term for each provider before a project starts. Consumer AI subscriptions are not used on client work.
Model providers are subprocessors, and are named
If a model provider sees your data, it appears in your DPA as a subprocessor with its own region and terms. You are told before we add one, not afterwards.
The model never invents a fact about your business
Prices, availability, order status and policy answers come from a function call against your system of record. The model chooses which question to ask; it does not answer from memory. That is a security property as much as a quality one.
Some things are routed to a human by design
Complaints, clinical questions, coverage and claim decisions, and anything a wrong answer makes into a liability, are escalated rather than answered. The boundary is written into the build and tested, not left to the model's judgement.
Engineering practices
The unglamorous habits that prevent most of the problems.
Separate environments, separate credentials
Development, staging and production are isolated with their own secrets. Production access is limited to the engineers who need it for the work in hand.
Secrets never enter the repository
Configuration is injected at deploy time. Repositories are scanned for committed credentials, and any exposed secret is rotated rather than deleted from history and forgotten.
Dependencies are watched
Automated vulnerability alerts on dependencies, patched on a schedule for routine issues and immediately for anything actively exploited.
Code review before production
Changes are reviewed by a second engineer before they reach a production branch. For regulated projects, the review trail is retained.
If something goes wrong
No vendor can promise nothing will ever happen. What we can commit to is how fast you find out and what you get.
You are told within 24 hours
If we become aware of a breach affecting your data, you hear from us within 24 hours of confirming it — ahead of the 72-hour GDPR notification window, so you still have time to act.
You get the facts, not reassurance
What happened, what data was involved, what we have done, and what we recommend you do. In writing, including a timeline.
A written post-incident review
Within ten working days: root cause, what changed as a result, and what we would do differently. Shared with you whether or not you ask.
Subprocessors
Listed by role rather than as a fixed vendor list, because the set varies by project. Your DPA carries the exact list for your engagement, and we tell you before adding one.
| Category | Typically | What it sees |
|---|---|---|
| Application & database hosting | Vercel, AWS, or your own cloud account | Application data, in the region you specify |
| Messaging & telephony | Meta (WhatsApp Business Platform), Twilio | Message content, phone numbers, delivery metadata |
| Language models | OpenAI, Anthropic — business terms, training excluded | Enquiry text, and only the record fields a given task needs |
| Transactional email | Google Workspace / Gmail, or your existing provider | Recipient address and message content |
| Error monitoring | Sentry or equivalent, with PII scrubbing enabled | Stack traces and request metadata, personal data redacted |
| Payments | Stripe | Handled directly by Stripe — we store a token, never card details |
Questions procurement asks
Answered before you ask
If yours isn't here, send it over — we answer security questionnaires in writing within five business days.
No, and we will not imply that we are. Both are meaningful for enterprise vendors and neither is something a team of our size holds without it being the main thing we sell. What we offer instead is specific: named agreements we sign, a written answer to your security questionnaire, data residency in the region you require, and a subprocessor list per project. If your procurement process makes a certification mandatory, tell us early and we will say so rather than spending your time.