Concepts

How VerifiedApp scans without touching your data (GDPR by design)

A scanner is a position of trust

When you let a tool scan your site, you are trusting it to behave. A careless scanner could hammer services it should not touch, probe systems that are not yours, or store sensitive values it stumbled on. We designed VerifiedApp the other way around — with firm boundaries baked in, because a security product that is loose with data is a contradiction. Here is exactly what those boundaries are.

We scan only your own domain

The scan stays on the domain you give us. It crawls your public pages, scripts and the files attackers probe — all on your host. It does not wander onto other domains, and crucially it does not actively test third-party services your site happens to reference. If your site mentions a cloud storage bucket, a database host or another provider, we do not go poke at those endpoints to see what they do. That kind of active third-party probing is exactly what a privacy-respecting scanner should not do, so we do not.

We never store the plaintext of a secret

When the scan detects something that looks like a secret — an exposed key, a token — it has to record that it found one so the report can flag it. But it does not keep the live value. We store a masked form (enough to recognize and locate it) and a hash, never the plaintext. That means our database is not a honeypot of your credentials, and a finding in your report cannot itself become a leak.

We read, we do not change

The scan is read-only. It requests pages and inspects responses, like any visitor — it does not submit forms with hostile input, modify data, or try to break things. The goal is to see what is exposed from the outside, not to attack your site.

Why this matters beyond compliance

GDPR and similar regimes care about data minimization and staying within scope, and these boundaries map onto that directly: we collect only what the scan needs, only from where we are authorized, and we do not retain sensitive plaintext. But honestly, it is also just how a trustworthy tool should behave. The companies that use VerifiedApp are putting our badge in front of their customers — that only works if we are clearly disciplined about data ourselves.

Built for B2B, where this is non-negotiable

Our customers are businesses that have to answer to their own customers and regulators. A scanner that respected no boundaries would be unusable for them, and would undermine the trust the badge is meant to build. So privacy-by-design is not a feature we bolted on — it is a constraint the product was shaped around.

Questions about scanning your stack?

If you need to understand exactly how a scan would treat your environment — what it touches, what it stores, how it fits your compliance needs — we are happy to walk through it. Talk to us about scanning your site.

Related reading

FAQ

Does VerifiedApp scan third-party services my site uses?
No. The scan stays on your own public domain. If your site references a cloud bucket, database host or other provider, we do not actively probe those endpoints — that kind of third-party probing is exactly what a privacy-respecting scanner should avoid.
What happens to secrets the scan finds?
We record that a secret was found so the report can flag it, but we store only a masked form and a hash — never the plaintext value. Your credentials do not sit in our database, and a finding cannot itself become a leak.
Is the scan safe to run on a production site?
Yes. It is read-only — it requests pages and inspects responses like an ordinary visitor, without submitting hostile input or changing data. It observes what is exposed from the outside rather than attacking your site.