Platform / Security
How Proxy looks after your customers' data.
Proxy holds your customers' documents, sends messages in your name and records what was done. Here is where that data lives, who can reach it, how long it is kept, and who else processes it, in plain English first and in technical detail after.
- Files stored
- Amazon Web Services, London
- At rest
- Encrypted with AES-256
- Certification
- None held at present
In plain English.
The questions a supplier review asks, answered as they are today. Anything not yet available says so.
Where customer data is stored
Customer files, including signed documents, uploads and call recordings, are stored in Amazon Web Services in London (the eu-west-2 region). Every organisation uses the same region.
Document reading runs in the same AWS region. Other providers that handle data to deliver a product are listed under "Who else processes data" below.
Encryption
Every file is encrypted at rest with AES-256. Particularly sensitive settings, such as calendar connections, webhook secrets and the credentials Proxy uses to reach your systems, are encrypted again in the database, and passwords are stored only as hashes.
Connections to Proxy use HTTPS; a plain HTTP request is redirected to it.
Your data is kept apart from every other organisation
Every record belongs to exactly one organisation, and Proxy checks that at three separate points before anything is shown or changed. Asking for another organisation's record gets the same answer as asking for one that does not exist.
Who in your team can do what
People are given a role: Owner, Admin, Manager, User or Read only, or a role you build yourself from permissions for each product. Nobody can give themselves more access than their own role, and an organisation always keeps an owner.
Two-factor sign-in and single sign-on are not available yet.
A record of who did what
Changes are recorded with who made them and when, and those records cannot be edited or deleted afterwards. Each signing request shows its full history, and the message log can be exported.
How long things are kept, and deletion
A deleted file disappears at once and can be restored for 30 days, after which it is removed permanently. Signed documents and their certificates are kept for seven years by default. Call recordings are kept for a year by default, and you can set anything from seven days to seven years. Document-check results are kept for 90 days.
What happens to your data when an account closes is set out in your agreement.
Who else processes data
Proxy uses a small number of providers to deliver its products. The current list, with what each processes, is part of your data processing terms, which also say how you are told about changes.
Certification
Proxy does not currently hold ISO 27001, SOC 2 or Cyber Essentials certification. If that changes, this page will say which, and from when.
Who else processes data.
The providers Proxy uses to deliver its products, and what each one does. Your data processing terms carry the authoritative list.
| Provider | What it does | Used by |
|---|---|---|
| Amazon Web Services | File storage in London, and reading documents | All, Verify |
| Anthropic | The AI model behind document checks | Verify |
| Twilio | Sending and receiving text messages, and phone calls | Comms, Voice |
| SendGrid | Sending email | Comms |
| Stripe | Card payments for credit | Billing |
| Cloudflare | Serving your own signing and booking domains | Sign, Booking |
| Reading busy times from a connected Google Calendar | Booking, if staff connect one |
Technical detail.
For the person reviewing how it is built: how each control is enforced, and what a record looks like.
Isolation is structural
Every record belongs to one organisation. A request carrying another organisation's identifier is refused while the route is still being resolved, before a line of application code runs.
The answer is 404, not 403, because a 403 would confirm the record exists.
A scope narrows. It never grants
An integration holds scopes, and its effective permission is the intersection of those scopes with what its owner can already do. A credential cannot be configured into an authority nobody has.
Entitlement is asked separately, on every request, from the scope itself.
Three credentials, three jobs
A publishable key identifies your integration in a browser and reads nothing. A secret key works server to server. A client session is minted by your backend for one capability, one resource and a few minutes.
Credentials never appear in logs, exception messages or webhook payloads.
Every mutation has a named actor
The actor is not optional and not derived. It is written to the audit trail and onto the record itself, so the question "who did this, and when" has an answer that does not depend on log retention.
The same authorisation model serves the API and the web interface.
Encrypted in transit and at rest
Transport is TLS with no plaintext fallback. Objects are encrypted at rest by the storage provider, and signing traffic runs on its own host with cross-origin access closed rather than configured.
Allowed origins are an allowlist per integration, not a wildcard.
Retention is yours to set
Retention is explicit per kind of record rather than inferred from use. Deleting a file makes it inaccessible at once and stays reversible for a defined window, 30 days by default, and then it does not.
Every size and lifecycle change is a ledger event, not a recalculated total.
You can see what you spent
Each metered operation writes a usage record with the operation key, the quantity, the billing unit and the cost. Free operations are recorded in full rather than dropped, so the count is always there.
Usage is readable without buying anything: nobody is charged to see a bill.
Delivery is a record, not a hope
Webhook events carry a status through pending, processed, failed or ignored. Retries are recorded. A signature is validated server-side and the verdict is kept with the signature.
A replayed request answers 200 with Idempotency-Replayed: true.
What the platform records, and an example audit response
GET /api/v1/audit?resource=01k5m7z4…
{
"data": [
{
"event": "storage.object.created",
"resource": "01k5m7z4h9c1e8ptw2yb3rkq5d",
"actor": { "type": "integration", "name": "Claims portal" },
"recorded_at": "2026-08-14T09:40:58+00:00"
},
{
"event": "processor.job.completed",
"resource": "01k5m8f2r7q0x3v9tzcd4npb6h",
"usage": { "operation": "ocr.document", "quantity": 1, "status": "charged" },
"recorded_at": "2026-08-14T09:41:07+00:00"
}
]
}The actor is on the record, not only in a log line. A usage record carries the operation, the quantity and whether it was charged.
Audit trail
What happened, to which record, who did it, and when.
On every mutation, by every service.
Usage ledger
Each chargeable action, how many, what it cost, and whether it was charged.
On every metered operation, charged or free.
Delivery record
Whether each message and notification arrived, and every attempt to send it.
On every message sent and every webhook attempted.
Signature validation
A check of every signature, kept with the signature it belongs to.
On every signature submitted for capture.
Ask for more security information
Send your security questionnaire, or ask for the data processing terms and the current provider list, through the request form. A person reads it and replies by email, usually within two working days.
Report a vulnerability
Use the same form, say that it is a security report, and give enough detail to reproduce it. We will confirm receipt, and we will not pursue anybody who reports in good faith and does not access other organisations' data.
Send us your security questionnaire.
We would rather answer your specific questions than publish a short list of comfortable ones. Ask for the data processing terms and the provider list at the same time.
- Files
- Stored in London, encrypted at rest
- Separation
- Checked at three points on every request
- Not yet available
- Two-factor sign-in, single sign-on