Security & sub-processors

This page is written to answer a security review without a call. Everything here applies to every account. If your team has a question it does not answer, write to security@prooftell.com and we will answer it, and add the answer here. To keep a copy, print this page or save it as a PDF.

Hosting

European Union

Belgium, on Google Cloud

Single lookups

Not stored

Processed and returned

Assessments

90 days

Your setting, from 0 to 365

Uploaded files

30 days

Or until you delete them

What we hold, and for how long

ProofTell takes a phone number, an email address or an IP address, checks it, and hands back what it found. It is built so that most of that leaves nothing behind, and so that what is kept is kept for a period you choose.

• Single lookups are not stored. A value sent to /v1/phone, /v1/email or/v1/ip is processed and returned in the response. It is not written to any database.
• Assessments are stored for a period you set. A call to /v1/assess is stored with its inputs, score, verdict, reasons and the result of each check, so that your team can review and explain it. The default is 90 days. An owner or an admin can set it from 0 to 365 days; at 0, assessments are not stored at all. Deletion at the end of the period is automatic, performed by the database itself.
• Uploaded files are deleted after 30 days. The upload, the working data and the result file are removed 30 days after upload by a rule on the storage bucket, not by a job that could fail to run. You can delete a file sooner from the dashboard or the API; deletion removes the stored objects at once.
• The values you submit stay out of our logs. They travel in the body of the request, never in its address, and our application logs and error messages do not contain them. Operational logs record the time, path, status and duration of a request and the address of the calling system, and are kept for 30 days.
• Usage and billing records contain no submitted values. They are counts and amounts, per signal and per organization.
• Sandbox calls touch nothing real. A pt_test_ key returns simulated results; no source is queried.

The contractual version of all of this is in the data processing agreement, Annex I.

Where it is processed

The API, the database and file storage run in Belgium (Google Cloud region europe-west1), in the European Union. The data you submit is not copied to another region.

• Phone numbers are checked by Veriphone, a service we operate ourselves in the same cloud region, against its own reference data. The number does not leave our systems.
• IP addresses are looked up in datasets loaded in the memory of our own servers. The address is never sent to a third party.
• Email addresses are the one exception, and it is in the nature of the check. Whether a mailbox exists can only be learned by asking the mail server responsible for it. The request carries the address and nothing else: no account identifier, no file, no other field. It is made by Verimail, our email verification sub-processor, through verification servers in several countries inside and outside the EU and the UK, because mail providers answer differently depending on where a request comes from. No message is sent to the address.

ProofTell is operated by Epic Grove Ltd, a company registered in England and Wales (company number 17285617). Transfer mechanisms are set out in clause 10 of the DPA.

Sub-processors

These are the companies that process the data you submit for checking. There are two.

The list is short because sub-processors are legal entities, not products: our whole infrastructure sits behind one company, and the phone check is a service we run ourselves.

The services we use to run our own business (card payments, sign-in, the delivery of service emails) never receive a value you submit for checking, an uploaded file or a result. They handle our relationship with you as a customer, which makes us the controller for that data rather than your processor, so they are named in the privacy policy rather than here.

We give 30 days’ notice before adding or replacing a sub-processor, and you may object. To be notified, email privacy@prooftell.com and ask to be added to the list.

Security measures

• Encryption in transit. TLS on every endpoint.
• Encryption at rest. AES-256 with Google-managed keys, for the database and file storage.
• API keys. A key is shown once, when it is created. We store only its SHA-256 hash, so a key cannot be read back from our systems, by you or by us. Keys can be revoked at any time, and live and sandbox keys are separate.
• Tenant isolation. Each organization’s data lives under its own path in the database and in file storage, and is reached only through a handle scoped to that organization. Isolation is structural: there is no shared table with a filter to forget.
• Access control. Four roles in the dashboard (owner, admin, developer, analyst), each a fixed set of capabilities, checked on every request against the verified identity of the caller. People join an organization by invitation only, matched on their verified sign-in email.
• No direct database access. The dashboard and the API are the only ways in. Browsers and client applications cannot reach the database; its rules deny everything.
• Files. Large uploads go straight to storage through a single-use signed link, and results are downloaded through links that expire after 15 minutes.
• Administrative access. Access to production is restricted through our cloud provider’s identity and access management to the people who operate the service. Secrets are held in a managed secret store, never in source code or in the database.
• Releases. Production only ever receives a build that has passed its automated tests and a check after deployment, and a release can be rolled back to the previous one.
• Resilience. Google Cloud managed infrastructure; the database and file storage are replicated across several zones of the region.
• Vulnerability management. Dependencies are updated as part of the regular release process.
• Breach notification. Without undue delay, and within 72 hours of becoming aware of a breach that affects your data (DPA, clause 7).

What we don’t have

We would rather you learn this here than three weeks into a procurement process.

• No SOC 2, ISO 27001 or equivalent certification. We do not hold one today and we will not claim otherwise. Clause 9.3 of the DPA lets us satisfy an audit request with our security documentation and a completed questionnaire instead.
• No single sign-on on the dashboard, and no enforced multi-factor authentication. Sign-in is by Google account or by email and password with a verified address. Our identity platform supports SAML and OIDC per organization; if either is a requirement, tell us.
• No customer-managed encryption keys, and no choice of region beyond the EU location above.
• No availability commitment on the published terms. A service level agreement comes with anenterprise agreement.
• No paid bug bounty.

If any of these is a hard requirement, tell us before you spend time on an evaluation.

Reporting a vulnerability

Email security@prooftell.com with enough detail to reproduce the issue. We will acknowledge within two business days. Please give us a reasonable opportunity to fix an issue before disclosing it publicly, and do not access data that is not yours while testing.

Documents

• Data processing agreement: pre-signed, no signature required from us
• GDPR: the two roles we play, and what is yours to decide
• Privacy policy
• Terms of service
• Enterprise agreement: if your policy requires a signed MSA, an SLA or a negotiated DPA