Trust: compliance, subprocessors and the DPA

This is the page a security or legal review asks for. It states what Spaw is certified for, which is nothing, and then everything it does instead: who processes what and where, a data processing addendum you can accept without a negotiation, the answers to the questions on a standard questionnaire, and where to send a vulnerability. /security is its companion and covers what each of the six lookups stores; this page covers the company around them.

Certifications, plainly

Spaw holds no security certification. No SOC 2 Type I or Type II. No ISO 27001. No HIPAA attestation, no PCI DSS attestation, no CSA STAR entry. No independent penetration test has been performed, so there is no report to send and no summary to quote. Nobody has audited this service, and no statement on this page has been reviewed by anyone but the people who wrote the code it describes.

If your process requires a SOC 2 Type II report before a supplier can be approved, say so at the start of the conversation and we will both save the week. The report does not exist and cannot be produced quickly — a Type II observation window is months long — so an approval that depends on one is an approval Spaw will fail.

What there is instead is evidence rather than assurance, and it is all published without asking:

• /status publishes, live and unauthenticated, the state of every component behind an answer, ninety days of measured availability with its limits spelled out, the age and version of every dataset an answer is read from, and per-endpoint latency. GET /api/v1/status/data returns the same as JSON, so you can watch it from your own monitoring instead of trusting a page.
• /incidents is the written history: what broke, what it meant for callers, what was billed, what changed afterwards. Written by a person after the fact, with an Atom feed.
• /openapi.yaml is the contract itself, not a description of one. A test fails the build if a route exists the document does not describe, or the reverse.
• /security states, one product at a time, what is stored, for how long, what leaves this server and what never does.
• This page's questionnaire section answers the specific questions rather than pointing at a badge.

An audited competitor is telling you an auditor checked their controls once. This page is telling you what the controls are. Those are different things and we are not going to pretend they are the same one.

Who is responsible for what

For the data your account holds — your name, your email address, your keys, your billing record — Spaw is the controller.

For the identifiers you send to be verified — other people's email addresses, phone numbers, IP addresses and postal addresses — you are the controller and Spaw is the processor. You decide which identifiers to check and why; Spaw answers the question and keeps what the retention section of /security says it keeps, for as long as it says. The data processing addendum below is the contract for that relationship.

There is one part of the service where Spaw acts on its own account, and it is named here because a questionnaire will not think to ask. Abuse outcomes reported about a phone number or an IP address are counted across accounts: once at least three separate accounts report abuse for the same value inside thirty days, that value's risk score rises for everybody. What crosses accounts is the count of accounts and nothing else — never a report, never who filed it, and for an IP address never the address, which is stored only as a salted hash. That count is Spaw's own processing, about a person who never signed up here, which is exactly why the erasure route below exists and why it is self-serve.

Email outcomes are pooled only as a per-domain bounce ratio, and only once a domain has at least five of them; below that the domain says nothing, so one report can never move a verdict. Postal address outcomes are never pooled at all, deliberately and permanently: an IP address is a network endpoint and a phone number is a handset, but a postal address is where somebody lives, and a shared "post fails here" database would be a database about residences.

Subprocessors

By role, and by what each one can actually see. Spaw does not publish the names of its suppliers on this page — a supplier list on a marketing site is a target list, and one of these roles is a data source under a contract that forbids it — but the named list, with the legal entities and the contracts, goes to a customer or a prospective customer who asks at [email protected].

Three things are deliberately absent from that table.

File storage. Bulk job inputs and results, support requests and erasure records are written to the application server's own disk, not to a third-party object store. There is no storage subprocessor to name.

Every dataset behind a phone, address, IP or business answer. Those are downloaded and queried here, so no third party is in the request path and nothing you send reaches them. They are suppliers of data, not processors of yours; each one, with its licence, is listed on /about and named again in the sources block of every response.

Two licensed partners that are not configured. A live carrier check on a phone number and a deliverability check on a postal address would each send the value to a licensed partner. Neither is switched on, so neither exists as a subprocessor today, and the response says the check did not run rather than guessing. If one is ever configured this table gains a row before it goes live.

And one thing about the table rather than in it: a new subprocessor, or a change of role for an existing one, is published here and in the changelog before it starts processing. Ask at [email protected] to be told directly rather than having to watch a page.

Data processing addendum

This is Spaw's standing DPA. It applies to every account without being signed, and it is offered here rather than on request because a document that takes a week to obtain is not a control, it is a delay. If your legal team needs it as a countersigned document, or needs standard contractual clauses executed against a named entity, write to [email protected]; an attachable copy of this page is at /trust.md.

1. Subject matter and roles. Spaw processes personal data on your instructions for the sole purpose of answering the verification queries you send, and for no other purpose. You are the controller of that data; Spaw is the processor. Where Spaw processes your own account data, Spaw is the controller of that.

2. Duration. For as long as your account is open, plus the retention windows published on /security. Those windows are not one number, and it would be convenient but wrong to say they were: thirty days for the email lookup history, every bulk run's uploaded list and result file, and the request log; one hundred and eighty days for the outcomes you report; seven days for the repeat marker. Two stores exist to be read back later and so are held until you say otherwise — a suppression entry until you remove it, and a monitored list until you delete it or three hundred and sixty-five days after its last run, whichever comes first.

3. Categories of data and data subjects. Whatever you choose to send: email addresses, domains, phone numbers, IP addresses, postal addresses and business identifiers, belonging to whoever you have a reason to verify — your customers, your applicants, your suppliers. Nothing else is asked for: no endpoint takes a date of birth, a national identity number or a payment instrument, and a business answer deliberately carries no registered address, because a registered address is very often a home address.

4. Instructions. Spaw processes the data only as documented in the API reference and on this site. If Spaw is ever required by law to process it otherwise, you will be told before it happens unless the law forbids telling you.

5. Confidentiality. Everybody with access to production data is bound to keep it confidential.

6. Security measures. Those described in the questionnaire section below, which is a statement of what is in place today rather than a list of aspirations. Measures may change, but not downward: a measure is not removed without an equivalent replacing it.

7. Subprocessors. Those in the table above, engaged under written terms no weaker than these. A new one is published before it starts processing, and you may object; if the objection cannot be resolved you may close your account, which you can do yourself from the settings page at any time. There is no published refund policy and this addendum does not invent one.

8. Data subject rights. Spaw will help you meet a request you receive, and answers a request made directly to Spaw about data it holds — see the section below. Erasure of an email address you sent is available to the person it is about, self-serve and without going through you, because a mailed confirmation proves control of that one identifier. For a phone number, a postal address or an IP address they write to support and a person checks first; there is no way to prove control of those over the web, and a form that pretended otherwise would be a way to erase somebody else's data.

9. Personal data breach. Spaw will notify you without undue delay, and within 72 hours of becoming aware, of any breach affecting your data, with what is known at the time rather than waiting for a complete picture. The incident log carries the public account afterwards.

10. Audit. Spaw will answer questions in writing, in the detail on this page or more. There is no audit report to send, and a site visit is not something a service this size can host; a questionnaire, a call, and specific answers to specific questions are what is on offer.

11. Deletion and return. Deleting your account removes it and everything attached to it — keys, history, jobs, monitors, suppression lists, feedback and the uploaded and generated files of every bulk run — and cancels any live subscription. Two things deliberately outlive it, both named on the privacy policy: a support request you sent, which is a message to a person filed against the reply-to address you gave rather than against the account and ages out on its own one-hundred-and-eighty-day window, and a one-way salted hash of the address that claimed the new-account credit bonus, kept so the bonus cannot be claimed twice by closing an account and opening another. Your history and suppression list export as CSV from the dashboard at any time, before or instead.

12. International transfers. Where personal data is transferred outside the UK or the EEA it is done under the standard contractual clauses or another mechanism recognised by the exporting jurisdiction. The specific mechanism per subprocessor is stated in the named list available on request.

13. Liability and precedence. This addendum forms part of the terms of service and prevails over them on the handling of personal data.

Security questionnaire answers

The questions a review actually asks, answered specifically. An answer that says "not published here yet" means nobody has written the fact down, not that it is being withheld — ask and you get it.

Is data encrypted in transit? Yes. All traffic to spaw.co, including the API, the dashboard, the form widget and the MCP server, is HTTPS; plain HTTP is redirected. The one outbound connection that is not HTTPS is the SMTP mailbox handshake itself, which speaks the protocol the receiving mail server speaks and ends before any message data is transmitted.

Is data encrypted at rest? Partly, and here is exactly which parts, because "encrypted at rest" is the answer people give when they mean full-disk encryption and nothing else. Passwords are stored as bcrypt hashes. Secret API keys are stored as hashes and shown once at creation — Spaw cannot display one again, and cannot recover one for you. A publishable key is stored and displayed in plain text by design, because it is meant for a browser and is protected by its origin allowlist instead. A Turnstile secret held for a publishable key is stored encrypted. IP addresses in outcome reports are stored only as a salted SHA-256 and never as the address. The address that claimed the new-account credit bonus is kept as a one-way hash so the bonus cannot be claimed twice, and cannot be read back. Everything else in the database — including the thirty-day email lookup history and the suppression lists — is stored as written, so the answer for those is the storage-layer encryption of the hosting platform and the access controls below, not application-level ciphertext.

Who can reach production data? Only accounts whose email address appears in the deployment's own operator allowlist, which is configuration on the server and not a role anyone can be granted through the interface. There is no support impersonation feature: nobody can sign in as a customer. The admin panel writes in four places and nowhere else: the customer record itself, an adjustment to an account's credit balance (which writes a ledger entry the customer can see on their own usage page), a data-feed sync, and the erasure action described below. Everything else there is a read-only report.

How do you authenticate accounts? Password, with time-based one-time-code two-factor authentication and recovery codes, or a passkey. Every session is bound to the password it was started with, so changing a password ends the other sessions rather than leaving them signed in — which is the one thing somebody does the moment they think they have been compromised. The settings page lists every signed-in device with its address, browser and last activity, and can sign the others out.

How do you authenticate API calls? A bearer secret key, or a publishable key in the body for browser calls. No cookie ever authenticates the API, so credentialed cross-origin requests are not accepted. A secret key can be limited to any of seven scopes, to an allowlist of source addresses or CIDR ranges, and to a daily credit cap that stops a batch part-way rather than letting one request spend past it. A publishable key can only be used from the origins you list, and can require a Turnstile token per lookup.

What is logged? One row per API call: the request id, the endpoint's route name, the status, the typed error code, the credits and the time taken. Never the value that was looked up — that is a rule with a test behind it, which runs a real IP lookup and asserts the address appears nowhere in the row. Kept 30 days. Separately, one anonymous timing row per lookup request, kept a week and rolled up into a daily count before it is deleted, which is what the availability figure on /status is measured from.

Do you have monitoring and alerting? Yes, and its output is public rather than internal: /status is generated from the same snapshot the alarms read, so the page and the alarm cannot disagree about what "behind" means. Queue depth, failed jobs, stuck bulk runs and overdue monitors alarm to the operator; every dataset behind an answer is checked daily for staleness and alarms once a day per dataset until it is fixed.

How are changes to production made? Every change is gated by an automated test suite, static analysis at PHPStan level 7 and a formatter, all run before it lands. The OpenAPI document is enforced by tests against the routes, so an endpoint cannot ship undocumented.

How do you manage vulnerabilities in dependencies? Framework and library updates are applied by hand and gated by the same suite, and application code is not allowed to import a development-only dependency — a test reads the installed package list and fails the build on one. There is no commercial scanner in the pipeline, and saying otherwise would be easy and untrue.

Do you run penetration tests? No. See the certifications section: there is no report because there has been no test.

What are your backup and restore arrangements? Not published here yet. The honest position is that the schedule and the last restore test have not been written down in a form worth publishing, and a trust page is the wrong place to guess. Ask at [email protected] and you get the current arrangement in writing.

Where is data processed? See the subprocessor table, including the two rows where the region is not published here yet.

What is your incident response? An incident is worked, then written up by hand at /incidents with what was found and what changed — including what it cost callers, and including the incidents where the finding was that the measurement itself was blind. Under the DPA above, a personal data breach affecting your data is notified to you without undue delay and within 72 hours of Spaw becoming aware.

What is your availability commitment? There is none, and we would rather say so than publish a figure we cannot stand behind. What there is, is the measurement on /status, with its limits stated on the page: it counts requests that reached this server and were recorded, so it is a floor on the bad days rather than proof of a good one.

Do you use customer data to train models, or sell it? No, to both. Submitted data answers your query and is used for nothing else. Nothing here builds a shared dataset out of what you send, with the two narrow exceptions named under "who is responsible for what" above, which are counts and never values.

What is the legal entity behind the service? Not published here yet. Ask at [email protected].

Reporting a vulnerability

Send it to [email protected], or through the support form if you would rather not use mail. The machine-readable version of this section is at /.well-known/security.txt, per RFC 9116.

We acknowledge a report within five business days. That is an acknowledgement, not a fix: it means a person has read it and told you what happens next. There is no bounty programme and no payment, and we would rather tell you that up front than have you find out after the work.

What we ask: test against your own account and your own data, do not run automated scanners against the API at volume — they cost real credits and read as an attack — and give us a reasonable window before publishing. What you get: a straight answer about whether it is a real issue, what the fix is, and when it shipped, plus a named credit in the incident log if you want one.

Data-subject requests

If Spaw holds something about you and you never signed up here, the erasure form is at /privacy/data-request. It takes an email address, mails a confirmation link to it, and — when you open the link and press the button — deletes every row this service holds under that address: the lookup history entries a customer's verification left, the delivery outcomes anyone reported about it, and any suppression list it sits on. It runs immediately and shows you the count per table. Nobody is told that you asked.

The form takes an email address and nothing else on purpose. The only thing a stranger can prove over the web is that they receive mail at an address, and that proves control of exactly one identifier: their own. A form that also took a phone number would let anyone erase anyone else's number by confirming their own mailbox, which is not a data-subject right — it is a way to clear an abuse report off a number you are abusing. For a phone number, an IP address or a postal address, write to [email protected]; a person checks that you are who the data is about, and then erases it the same way.

Three things an erasure deliberately leaves alone, because a gap nobody names is worse than a gap. The erasure page lists the same three beside the form, so you see them before you press the button rather than afterwards.

1. A customer's own monitored list, and the file a customer uploaded for a bulk run. Those are that customer's records rather than ours, and quietly deleting a row out of a saved list changes their monitoring without telling them — so we tell them instead. Both are deleted on their own schedule anyway: a bulk job and its files after 30 days, a monitored list 365 days after its last run, or whenever the customer deletes it.
2. The seven-day repeat marker. A hash and a timestamp under an account's own key. It carries nothing that can be read back, and it expires inside a week by itself.
3. The one-way hash of an address that claimed the new-account credit bonus, if that address ever opened an account here. It exists so the bonus cannot be claimed twice by closing an account and opening another, it is salted rather than the address, and it is linked to nothing else.

For access, correction, restriction or objection, or for anything the form does not cover, write to [email protected]. We answer within 30 days, which is the outer limit the GDPR allows rather than a target, and normally much sooner. If your request is made to a customer of Spaw rather than to Spaw, they are the controller and Spaw will help them meet it.

If you are an account holder, your own data is self-serve: the dashboard exports your verification history and suppression list as CSV, and deleting your account from the settings page removes the account and everything attached to it. You do not need to ask anyone.