What Site Guard stores, and for how long
Every table and every retention period on this page is read from the running system — the database schema, the application code and the scheduled jobs — not from a description of it.
Site Guard monitors websites. To do that it stores an account for you, a record of the sites you ask it to watch, and the findings of its nightly checks. The public pages you are reading now set no cookies at all and load nothing from anybody else.
These pages
The marketing pages at siteguard.solutions and siteguard.solutions/he/.
- No cookies. Not for analytics, not for preferences, not for anything.
- No third-party requests. No analytics, tag managers, fonts or scripts from other domains. Every asset is served from this site.
- No browser storage. The light/dark toggle changes the page and deliberately does not remember your choice, because remembering it would mean storing something.
- Server logs. Requests reaching the server are logged with the source IP address, as described below, the same as for any signed-in request.
If you have an account
What is stored, and why it has to be.
| What | Held | Why |
|---|---|---|
| Your account | Email address and a password hash (scrypt). The password itself is never stored anywhere, in any form. | To let you sign in. |
| Your sessions | A hash of the session cookie, not the cookie. A copy of the database does not let anyone use your session. | To keep you signed in for seven days. |
| Your organisation | Which organisation you belong to and your role in it. | To decide what you are allowed to see. |
| Remediation tasks | Titles and descriptions, and who created, edited or was assigned each one. These are free text and can contain whatever is typed into them. | To track the work the nightly checks raise. |
| Audit trail | Who changed what, and when. Append-only: it cannot be edited or deleted by the application. | So that a change to a security setting leaves a record. |
| Security events | Sign-ins, failed sign-ins and refusals, with the source IP address. | To detect attacks. Kept indefinitely — see the retention table. |
| Access log | One row per request: source IP, method, path, status and duration. Never the request body, and never the query string. | To investigate faults and abuse. |
| Invitations | The invited email address, in plain text, and a hash of the invite token. | An invitation names somebody who is not a user here yet. |
Two cookies are set once you sign in: a session cookie and a CSRF cookie. Both are strictly necessary to operate the console, both are __Host- prefixed, and neither is used to track you.
Sites you ask us to monitor
For each site: its address, the paths to probe, and the findings of each nightly scan.
A site may also carry an audit credential — a login you supply so the nightly render check can see your site as a signed-in visitor sees it. It is encrypted at rest with AES-256-GCM under a key held outside the database, and it is never shown back to anybody, including the administrator who entered it. No page displays it and no form is pre-filled with it.
Who else receives data
These are the only third parties the system sends anything to. The list is re-derived from the source code on every test run, so it cannot quietly fall out of date.
| Destination | What is sent | When |
|---|---|---|
| Anthropic api.anthropic.com | Redacted diagnostic findings, to write the nightly report. | Only if an API key is configured. |
| Meta graph.facebook.com | Alert text and the operator’s own WhatsApp number, for urgent alerts. | Only if WhatsApp alerting is configured. |
| Google Chrome UX Report chromeuxreport.googleapis.com | The public address of a monitored site, to fetch its published performance data. | Only if a key is configured. |
| Google Search Console searchconsole.googleapis.com | A request for your own Search Console figures, using a credential you supply. | Only if connected. |
| Google sign-in accounts.google.com, oauth2.googleapis.com | The OAuth exchange when an administrator connects a Google account. | Only when that connection is made. |
| Microsoft api.bing.com | The public address of a monitored site, to fetch its Bing Webmaster search figures for a property this account owns. | Only if a key is configured. None is. |
| Cloudflare api.cloudflare.com | A read-only check of this deployment’s own edge configuration. Nothing about a visitor, and no site data. | Only if a token is configured. None is. |
| Cloudflare www.cloudflare.com | Cloudflare’s published list of its own IP ranges, fetched hourly so the edge configuration can be checked for drift. No data is sent. | Hourly. |
| W3C validator.w3.org | The markup of a page being checked for standards conformance. That is the page’s own HTML, not anything a visitor typed. | When a conformance audit runs. |
Outbound email is sent through whichever relay the operator configures, or the local mail system if none is. Nothing is sold, and nothing is shared for advertising.
How long it is kept
Each period below is enforced by a scheduled job, not by a promise.
| Data | Kept for |
|---|---|
| Sessions | 7 days |
| Access log | 30 days |
| Diagnostic scan logs | 30 days |
| Database backups | 14 days |
| Unredeemed invitations | 7 days after they expire |
| Password reset tokens | 1 day after they expire (they expire an hour after issue) |
| Finished tasks | Per the service tier on the account |
| Audit trail and security events | Indefinitely |
The audit trail and the security events are kept indefinitely on purpose: a record of who changed a security setting, or of an attack, is worth little if it can be aged out or deleted. This means a source IP recorded in a security event outlives the account it was recorded against.
How it is protected
- Passwords are stored as scrypt hashes. There is no plaintext copy anywhere.
- Session, invite, reset and ingestion tokens are stored only as hashes.
- Integration credentials and site audit credentials are encrypted with AES-256-GCM under a key held outside the database.
- The audit trail is append-only at the database level, enforced by triggers that apply to the application’s own database role.
- Every database query is parameterised, and page output is escaped by construction rather than by remembering to escape it.
Getting your data, and deleting it
Export. An administrator of an organisation can download everything held for that organisation from the console, at /dashboard/export. Live credentials — session records and password reset tokens — are deliberately left out: putting them in a file you download and email would hand over a way into the account and tell you nothing you did not already know.
Deletion. An account and an organisation can both be erased. Erasing an organisation severs the audit rows that name it, keeping the event and removing the pointer to you, and then deletes the organisation and everything that hangs off it.
What survives erasure, stated plainly. Security events are kept, including any source IP address recorded in them. Audit rows are kept with the actor removed. This is a deliberate tension between erasure and an audit trail that cannot be rewritten, and it is recorded here rather than glossed over.
To ask for any of this, or to ask a question about it, write to [email protected].
Where this page comes from
The tables above are derived from the database schema, the application code and the scheduled jobs that enforce the retention periods. The list of third parties is re-derived from the source on every test run and fails the build if it is incomplete. If something here is wrong, it is a defect, and telling us is welcome.