Security

Version 1.1 · Last updated 2 October 2026

GuardMyMark is built and run by one person. We don't have a security team or a SOC 2 report, so this page explains plainly what we do to protect your data, and what we don't do.

Contents

1. Where your data lives
2. Encryption
3. Access
4. How we build and run the product
5. Backups and deletion
6. Product-specific measures
7. What we don't have (yet)
8. Reporting a vulnerability

1. Where your data lives

The application and database run on servers rented from Hetzner in Germany (EU), in ISO 27001-certified data centres. Cloudflare sits in front of the site for DNS, TLS and protection against attacks. Other services that receive data are listed on the Subprocessors page.

2. Encryption

• All traffic uses HTTPS (TLS 1.2 or newer), with HSTS.
• Disks and database backups are encrypted.
• Where the product stores credentials for a system you connect to it, they are encrypted again inside the database (libsodium sealed boxes) with a key held separately from the database, decrypted only in memory when a job needs them, never shown back in full and never written to logs. Section 6 says whether GuardMyMark holds any such credential at all.

3. Access

• Only the founder can access production systems, using SSH keys and two-factor authentication on every admin account (hosting, DNS, source code, email, payments).
• Automated deployments use a separate key with limited rights.
• We look at your data only when needed to support you, fix a problem you reported, or investigate abuse or a security issue.
• Sign-in uses email and password or Google. Passwords are stored only as salted, slow hashes (never in plain text), and we never see them.

4. How we build and run the product

• Every database query is scoped to your organisation, and automated tests check that one customer can't see another's data.
• Dependencies are kept up to date and scanned for known vulnerabilities.
• Staging and production are separate; staging never contains production personal data.
• Errors and logs are kept on our own server for 30 days, and we scrub personal data (request bodies, tokens) from error reports.
• Uptime is monitored every minute and alerts go to the founder.
• We follow a written incident procedure. If a breach affects your personal data, we will notify you within 48 hours of becoming aware of it (see the DPA).

5. Backups and deletion

• The database is backed up nightly and backups are kept for 60 days. We test restores regularly.
• When you delete data or close your account, it is deleted from the live system within 30 days and from backups as they expire.

6. Product-specific measures

• There is nothing of yours to steal from us but your watch list. GuardMyMark connects to no system of yours, so it holds no API key, token or password of yours — only the marks you asked us to watch and the public register records that scored against them. Payment details never reach us: Creem takes the payment on its own pages.
• One customer cannot read another's watch list. Every read of a watch, a hit or a deadline is scoped to your workspace, and automated tests assert that a request naming another workspace's row gets nothing rather than somebody else's data.
• Links that carry their own authority are scoped to one thing. The shared free-check report, the calendar feed and the links in a weekly notice are authorised by a signed token in the URL instead of a login, because they are opened from a mail client or a calendar app. A notice token covers one filing or the notice on/off switch; a feed token covers one person's dates. Rotating the signing key invalidates every outstanding link at once. Treat these URLs as credentials, and tell us if one leaks.
• The free check is rate-limited and challenged. It is the one public endpoint worth scraping, so it is behind a Cloudflare Turnstile check and a per-address limit, and it queries only our own index — it makes no outbound request on your behalf.
• The register ingest is replayable and watched. Each day's raw register file is retained for 30 days so a parser fix can be replayed, and a day whose record count is far from the trailing average raises an alert rather than passing silently. A missed filing is the failure that costs you a deadline, so we would rather be told about a quiet day than not hear about an empty one.
• The borderline comparison is the only place your content leaves our servers, and it carries two mark texts and their classes — no identifier of you (see Privacy, section 4.3).

7. What we don't have (yet)

• No SOC 2 or ISO 27001 certification of our own (our hosting provider is certified).
• No 24/7 on-call team: alerts reach one person, so outside business hours in Central/Eastern Europe responses can be slower.
• No bug bounty with payouts, but we are grateful for reports (see below) and will credit you if you like.

If your organisation needs a security questionnaire answered, email support@guardmymark.com.

8. Reporting a vulnerability

Email security@guardmymark.com with details and steps to reproduce. Please give us reasonable time to fix the issue before disclosing it, don't access or change other people's data, and don't run tests that degrade the service (no load or denial-of-service testing). We won't take legal action against good-faith research that follows these rules. We aim to acknowledge reports within 3 business days. A machine-readable contact is at /.well-known/security.txt.