How an assessment is run, and how the data it produces is handled

The properties that matter most about running an automated assessment against somebody's production site are the ones a reader can verify. These are set out in full on the methodology page and enforced in the fetch layer rather than described in it:

Read-only

Only GET, HEAD and OPTIONS are sent. The allowlist is in the HTTP client, so a new check cannot widen it without changing that one list.

No credentials, ever

No account is signed in to, no token is supplied, no session cookie is stored or replayed. Anything behind a login is not assessed.

Bounded

A fixed per-host request budget, a crawl depth and page ceiling, and a wall-clock deadline. When a bound is reached the run stops and the report states which parts of the surface were not reached.

Public addresses only

Resolved addresses are classified before connecting; private, loopback, link-local, reserved and unique-local answers are refused, a host that resolves to any private address is refused, and the connected peer is re-validated afterwards.

None of this makes an assessment invisible. It makes requests, they appear in logs, and a provider may alert. That is stated on the methodology page too, because a page that only mentioned the reassuring half would not be worth reading.

This section summarises the Privacy Policy, which is the binding document and was last revised in September 2026. The summary exists so a reader does not have to read a policy to answer a procurement question; where the two differ, the policy governs.

What an assessment reads

Publicly reachable and externally observable information from the target — DNS records, mail configuration, TLS information, response headers, cookies, exposed technologies, subdomains, endpoints, files and related signals. Public information occasionally contains personal data, such as contact details in public records; it is processed only as reasonably necessary to perform the assessment.

Who can see a report

Only the account that commissioned the assessment, and any users authorised on it. Reports are not published, sold, or made searchable. Reports are not emailed to the target's owner.

Search engines

Every account-, agent- and token-scoped route sends X-Robots-Tag: noindex and carries a <meta name="robots"> directive, including shared report links. None of them appears in the sitemap. robots.txt is not used as access control and does not enumerate private paths; access is controlled by authentication.

Share links

A share link is a capability: an unguessable token, expiring on its own shorter clock than a verification link, revocable, and never indexed.

Third parties and AI

Assessment data is processed on infrastructure controlled by or operated for Soryvex, and is not sent to third-party AI providers for model training. Personal information is not sold and is not shared for cross-context behavioural advertising. Sub-processors are listed in the Privacy Policy.

Retention

Assessment data and reports are retained while an account is active and for a reasonable period afterwards. Technical and security logs are retained for a limited period, longer where needed to investigate an incident. Deletion, de-identification and backup rotation are described in the Privacy Policy.

The public pages of this site are static-ish server-rendered HTML with no third-party analytics, no advertising scripts and no cross-site tracking. Two cookies exist and both are strictly functional: the session cookie that keeps you signed in, and a CSRF token that protects state-changing requests. Both are HttpOnly and SameSite-restricted. Consent is collected only for what is actually optional.

The site sends a Content-Security-Policy with no unsafe-inline for scripts, a per-request nonce for the scripts it does serve, Strict-Transport-Security with a two-year max-age and preload, framing denied, and a referrer policy that does not leak paths.

It publishes an RFC 9116 /.well-known/security.txt with a monitored contact address. That file is the fastest route to reach us.

Email [email protected]. That address is also in /.well-known/security.txt and on the contact page.

Useful to include: what you found, how to reproduce it, which part of the product it affects, and how you can be reached. We commit to acknowledging a report and we publish the acknowledgement deadline in the Expires field of the security.txt file, which is the thing that makes that commitment checkable rather than decorative.

Please do not run an automated assessment against our own infrastructure as a way of testing this. That is what the example report is for: it is a real assessment of a domain we own, published in full, and it is the intended way to see what the output looks like.

If you need a security questionnaire answered, a sub-processor list, a data processing agreement, a penetration test report or a compliance attestation: ask. Some of those documents exist and some do not, and you will get a straight answer either way rather than a page that implies everything is in order.

The Terms of Service are the binding version of everything summarised here, and they state the same boundaries: what a report is not, who is responsible for authorising an assessment, and what the liability limits are.