Security and data handling

Last updated: 13 August 2026

This page describes what we actually do, taken from the running code rather than from an aspirational policy. Where we do not have something, it says so plainly. If a control you need is missing here, assume we do not have it and ask.

What we can read, and how you grant it

Two optional connections let us read data you already own. Both are read-only, both are granted by you inside Google, and both are revoked by you inside Google without involving us.

  • Google Search Console, so your tracked questions can be seeded from demand people actually searched for.
  • Google Analytics, so you can see how much traffic arrives from AI assistants.

We use service-account delegation, not OAuth. That means we store no access token and no refresh token for your Google account, and there is no long-lived credential of yours in our database to leak. You add one named service-account address as a viewer on the specific property you choose. Access is limited to that property, and removing the address ends it immediately.

Neither connection can write anything. We never post, never modify a property, and never read a property you have not named.

What we store, and for how long

The measurement data is the questions you track, the answers the engines gave, and the figures derived from them.

  • Raw answer text is kept for 12 months, then removed. Every derived figure survives that removal, so your historical scores and trends stay intact. The raw text is what lets you check a citation claim rather than take it, which is why it is kept at all, and it is the most sensitive thing we hold, which is why it does not stay forever.
  • Your scores and history are kept for the life of the account, because a trend line is the product.
  • You can export everything at any time, on every plan, as CSV or JSON. There is no tier that withholds your own data from you.

Credentials we issue

  • API keys are bound to one subscription. A key carries the account it belongs to, and the export reads that binding rather than trusting a domain sent in the request. A key cannot name another customer's data, and a key issued for one purpose cannot be used as another kind of key.
  • Keys are revocable and can carry an expiry. Revocation takes effect on the next request. Keys also carry a daily request limit.
  • Sign-in and report links are short-lived. Dashboard links we email expire in three days.
  • A key in a URL is visible to anything that logs URLs. Some tools cannot send headers, so we support a key as a parameter and tell you the cost of it rather than hiding it. Use a separate key per document so you can revoke one without breaking the others.

Outbound connections

If you configure a webhook, we send events to it. Those requests are HTTPS only, signed with a shared secret so you can verify they came from us, and refused if the destination resolves to a private or internal address. Repeated failures disable the endpoint rather than retrying forever.

Event payloads carry no credential. A webhook destination is often a shared channel, so anything we send should be assumed to sit in that channel's history. Where an event points at your data, it carries the address and not the key.

Publication is off by default

Nothing about your measurement is public unless you switch it on. The embeddable score card and the emailed export are both opt-in and both start off. Signing up is not consent to publish anything, and a shared client report shows only what that switch allows.

What we do not have

Stated because a security page that lists only strengths is not useful to somebody doing diligence.

  • No SOC 2, ISO 27001 or equivalent certification. We have not been audited against one and do not claim to have been.
  • No third-party penetration test to publish.
  • No signed DPA yet. One is being prepared with legal review; until it exists we will not pretend otherwise.
  • No contractual uptime commitment beyond what our terms already state.
  • No single sign-on or SCIM. Access is by emailed sign-in link.

If any of these is a blocker for your organisation, say so before you buy rather than after. We would rather lose the deal than describe a control we do not operate.

Reporting a problem

Email hello@searchscore.io with anything that looks like a security issue. We would rather hear about it early and awkwardly than late and politely. If you are unsure whether something counts, send it anyway.