Privacy Policy
What SiteGuardia processes, why, for how long, and what you can ask us to do about it.
Version 2026-09-22Updated 2026-09-22
This is a working draft. It describes the system as built and has not yet been reviewed by a qualified lawyer.
This document is a working draft. It describes the system as built, and it has not yet been reviewed by a qualified lawyer. It will be before SiteGuardia operates commercially. Nothing here is legal advice.
The short version
SiteGuardia Free needs almost nothing from you. There is no account, no name, no email address, no payment details. You give us a domain; we give you a temporary report. Two days later both are gone.
Who is responsible
The operating entity for SiteGuardia is not yet established. This section will name the controller, its address and its representative before the service is offered commercially. Until then, contact details for privacy questions are published at /.well-known/security.txt.
What we process, and why
The target you enter
The domain or URL you submit, its normalised form, and a keyed fingerprint derived from it. We need this to run the check and to enforce the daily limit. The legal basis is performance of the service you requested.
Timestamps and scan state
When a check started, which modules ran, how long each took, and whether it completed. Needed to produce the report and to operate the service.
Sanitized scanner output
Findings, scores, and the safe evidence attached to publishable findings: header names, record values, protocol versions, certificate dates. This is the report.
We do not keep raw scanner output. It is processed in temporary memory-backed storage and deleted within minutes, including when a job crashes.
Your IP address
Held briefly in security logs for abuse prevention, and used to derive a rotating pseudonymous key for the per-visitor rate limit. The key is HMAC(rotating_secret, normalised_ip + utc_date), so it cannot be reversed to an address and yesterday's keys cannot be matched to today's. We do not store raw IP addresses for quota purposes. The legal basis is our legitimate interest in preventing abuse of a free service.
Your locale and your acceptance of the terms
The language you chose and the version of the Terms and the Responsible Scanning Policy you accepted, with a timestamp. We need the record of acceptance; it is the basis on which the check ran.
Operational telemetry
Counts, durations and error rates, aggregated. We do not send full target URLs to any external telemetry service.
What we do not collect
No name, no postal address, no telephone number, no identity documents, no password, no payment information, and no account. Not as a policy choice we could quietly reverse: the free tier has no place to put any of it.
We do not use browser fingerprinting. No canvas, audio or WebGL identification. Abuse controls are server-side.
Cookies
Only strictly necessary cookies, described in the Cookie Policy. No advertising cookies, no third-party analytics cookies.
How long we keep things
| What | How long | Deleted by |
|---|---|---|
| Raw scanner output | Minutes. Removed when the job finishes and when it crashes. It lives in memory-backed storage and never reaches a disk. | The worker itself |
| Sanitized report, findings, scores, modules | Reachable for 48 hours from when the scan was requested, then deleted on the next purge pass after a further hour of grace | The purge job |
| Quota counters | Deleted on the first purge pass after the UTC day they belong to has ended | The purge job |
| Abuse and security events | 21 days | The purge job |
| Administrative audit entries | 365 days | The purge job |
| Aggregate operational metrics | Retained. They are counts and timings with nothing in them that identifies a request | Not deleted |
Four things in that table used to be stated differently, and the differences were not rounding.
48 hours from request, not from completion. The expiry is set when a scan is admitted, before it has run. A scan that takes three minutes is reachable for 48 hours minus those three minutes. We have kept that behaviour and changed the wording, because the alternative was to change the behaviour to match a sentence.
Expiry and deletion are two events. At 48 hours the report address stops working and returns 410. The row is deleted by the purge pass that runs after a further hour of grace, which exists so somebody who opened their report a minute before expiry is not reading a page whose data vanishes underneath them. The purge runs on a five-minute cycle, so in the normal case deletion happens between 49 and 49.1 hours after the request. If the purge job is stopped, nothing is deleted until it runs again; the report is unreachable throughout, but unreachable is not deleted, and this page will not claim otherwise.
Quota counters. A counter row records that a registrable domain was checked on a given UTC day, and a second records the pseudonymous actor who asked. They are dropped on the first purge pass after that UTC day ends. Until recently they were kept an extra day and the job compared against the machine's local date rather than a UTC one; both are fixed.
Logs are two retentions, not a range. Abuse and security events are kept 21 days. Administrative audit entries -- a record of what an operator did -- are kept 365 days, because they are what an incident review reads. These were previously described together as "14 to 30 days", which was true of neither.
What else exists, and for how long
The table above is the data the service was designed around. These also exist, and a retention page that omits them is describing a system rather than this one.
| What | Where | How long |
|---|---|---|
| Reverse proxy access logs | The machine serving the site. Method, path, status, timing, user agent, address | Not currently trimmed by a job. To be set with the hosting decision |
| Application error logs | Same. Paths are redacted and report tokens are never written | Same |
| Database backups | Wherever the hosting provider puts them. A backup taken before a report expired contains that report | Determined by the backup schedule, which does not exist yet |
| Support correspondence | An inbox, once there is one | Determined by the mail provider and by us |
| PDF reports you downloaded | Your computer, or wherever you forwarded them | We cannot delete these. A downloaded file has left the service |
The last row is not a disclaimer, it is the most important line on this page. A report is designed to be forwarded to a developer. Once it is, expiry does nothing to the copies, and neither do we.
The first four are outstanding decisions rather than policies. They are listed because a privacy page that describes only the parts with a purge job is describing the parts that were easy.
Pseudonymisation, and what it is not
Quota and rate limiting need to recognise a repeat requester without storing who they are. What is stored is a keyed hash -- an HMAC -- of the requesting address, with a key that changes, and the address itself is not written down.
This limits abuse and it limits what a database dump reveals. It is pseudonymisation, which under the GDPR is a security measure and not anonymisation: the values still relate to individuals, whoever holds the key can compute them again, and a value can be linked to other records that share it. This page used to describe the same mechanism as impossible to reverse or relate. That overstated it, and overstating a privacy control is worse than a weaker control honestly described.
Sensitive findings
When a check finds something serious on a domain nobody has proven they own, the technical evidence is classified and dropped before anything is written to storage. It is not hidden from you; it does not exist. The database has a constraint that refuses to store a withheld finding carrying evidence, and the API response model has no field that could carry one.
What does remain is worth stating, because this page used to end here with "there is no sensitive data for us to lose", and that was true only of the part that was dropped. For 48 hours we hold: the domain that was checked, when it was checked, which checks failed, at what severity and with what confidence, the duration of each module, and a pseudonymous identifier for whoever requested it.
That set is not sensitive in the sense the GDPR uses for special categories, and it is not harmless either. It is a statement that a particular website had particular weaknesses at a particular time, and the protection it has is that it is addressed by a 256-bit token nobody can guess, is never indexed, is never in a shared cache, and is deleted on schedule.
Who else processes your data
SiteGuardia currently uses no third-party processor for the free check. If that changes, a subprocessor list will be published here with the purpose and region of each one before the change takes effect.
Scans reach the site you named, which will see the request in its own logs. That is inherent to the service.
International transfers
Where transfers occur, they will be listed with their safeguards in the subprocessor list. None apply today.
Your rights
Depending on where you are, you may have rights to access, correct, delete, restrict or object to processing of your personal data, to data portability, and to complain to a supervisory authority. Under the CCPA and CPRA, rights to know, delete, correct and to opt out of sale or sharing may apply; we do not sell or share personal information. Comparable rights exist under the LGPD and other regimes.
How to exercise one
Write to the privacy address on the Operator details page. Tell us what you are asking for and give us enough to find the record; for a report, that is the report address, because it is the only thing that identifies it.
We will acknowledge within 5 working days and answer within 30 days, or tell you within those 30 days why we need longer and how much longer. If we cannot identify you as the person the data relates to, we will say so rather than guess: for a report, holding the link is the only evidence there is, which also means anyone holding the link can ask.
If you are not satisfied, you can complain to your supervisory authority. Where we are established determines which one supervises us, and that is on the Operator details page once it is settled.
This page used to say the rights were "already satisfied by design", because there is no account and a report expires in 48 hours. That is not the same thing. Expiry runs on its own schedule for everyone and answers no request; it does not tell you what we hold, and it does not reach the backups, the proxy logs or a support inbox. A procedure is a procedure, and this is ours.
What is still outstanding. The address above is a placeholder until the operator is established, so today there is nobody at the other end of it. The deadlines above are what we are committing to, and they become real when the address does.
Children
SiteGuardia is not directed at children and we do not knowingly process their data.
Security
TLS 1.2 or higher in transit, with TLS 1.3 preferred. Report tokens stored as keyed hashes, never in plain text. The scan plane runs isolated from the database with no route to it. We do not claim any certification we do not hold.
This page used to say "disk encryption on the host". There is no final host: SiteGuardia has not been deployed anywhere permanent, so that was a claim about an environment nobody has chosen. Encryption at rest will be stated here once it is a property of a running deployment somebody can check, and not before.
Changes
This policy is versioned. Material changes will be published here with a new version and date, and the version in force when a check runs is recorded with that check.