Security at BidHound

01Where your data lives

BidHound runs on a dedicated virtual server hosted by Hetzner Online GmbH in Helsinki, Finland. Finland is part of the European Economic Area, which the UK government formally recognises under UK GDPR as offering the same level of data protection as UK law. Your account data, company profile, pipeline, and every tender you interact with are stored in a single SQLite database on that server.

We do not replicate your data to analytics warehouses, marketing platforms, or third-party data lakes. The only copies of your data that exist outside the primary database are nightly encrypted backups (see Section 5) and short-term server logs (see our Privacy Policy, Section 9).

Some processing steps involve trusted third-party services based outside the EEA. We list every one of them in Section 7 below, with the purpose of each transfer.

02How we protect your account

The single highest-impact security event for any SaaS product is account takeover. We've layered several defences specifically against it.

2.1  Passwords

Passwords are never stored in plaintext or reversibly encrypted. We hash them with bcrypt at cost factor 12 — the current industry standard for password-at-rest protection. Bcrypt is deliberately slow: even an attacker with direct file access to the hashed password column would need enormous compute to guess a single well-chosen password.

We enforce an 8-character minimum. Stronger password rules (length, common-password blocklist, zxcvbn strength meter) are on the roadmap — see Section 8.

2.2  Brute-force protection

Every login attempt goes through two rate-limiters before your password is even checked:

• Per-account lockout: five failed attempts in fifteen minutes triggers a fifteen-minute lockout on that specific email address. Even the correct password will be refused while the lockout is active.
• Per-IP rate-limit: no IP address can make more than twenty login attempts per hour, regardless of which accounts they target.

Both apply independently to the signup endpoint too, where we also block disposable-email providers, normalise Gmail-style aliases, and log originating IP and browser for every signup.

2.3  Sessions

When you log in, we issue a signed JSON Web Token and set it as an HttpOnly cookie — so it's not readable by JavaScript — with SameSite=Lax and the Secure flag (over HTTPS). Sessions expire automatically after a period of inactivity.

03How we protect your data in the browser

Every page BidHound serves sets a strict set of defensive HTTP headers. They're invisible to you but dramatically reduce the damage a compromised third party could do.

All of these can be inspected directly — open your browser's dev tools, go to the Network tab, and check the response headers on any BidHound page.

04How we protect your data at rest

The production database lives on a server accessible only via key-based SSH from a small number of authorised devices — password SSH is disabled entirely. The hosting provider manages the physical infrastructure in a secure data centre with ISO 27001 certification.

Within the application, every API endpoint that reads or modifies your data checks that the request's session belongs to the account that owns the data. A bug here would be a serious issue, so we've hunted for them systematically — several historical issues of this shape were found and closed during pre-launch auditing, and we continue to review.

Encryption of the database file itself (using SQLCipher) is on the roadmap — see Section 8.

05Backups

The database is backed up every night at 03:00 UTC. Each backup is:

1. Captured using SQLite's atomic .backup command (safe to run against the live database, no locks taken);
2. Integrity-checked with PRAGMA integrity_check;
3. Compressed with gzip;
4. Encrypted with AES-256-CBC, using a key derived via PBKDF2 with 100,000 iterations. The encryption key lives in a file on the server readable only by the application user (file mode 0600), and a copy is held in an off-server password manager so backups remain recoverable if the server itself is ever lost.
5. Retained for seven days, then automatically deleted.

A restore helper is tested as part of our smoke suite: we decrypt the latest backup, decompress it, and verify SQLite integrity on every security deploy. Hetzner additionally runs their own full-disk snapshot backups of the VM on a seven-day rolling window, independent of ours.

06Payments

We do not see, store, or log your payment card. Subscriptions are handled end-to-end by Stripe, which is certified PCI DSS Level 1 — the highest level of payment-industry security certification. You enter your card directly into Stripe's hosted checkout; we receive only a token that lets us ask Stripe to charge the card on renewal.

If you want to update or delete your payment method, you do it from the Settings page in your BidHound account, which hands you off to Stripe's billing portal for the change.

07AI and sub-processors

BidHound uses a small, deliberate set of external services. Every one appears here, and this list is kept in sync with our Privacy Policy.

A few points worth calling out directly:

• Anthropic does not use your data to train its models. Their commercial API terms explicitly exclude training on customer inputs. When BidHound classifies a new tender, we send the public tender text (not your private profile) to Anthropic; when you ask BidHound to enrich your company profile, the text you provide is sent and the structured result is returned.
• Your data is never shared between customer accounts. Tender scoring and pipeline data are scoped to your user ID at every database read.
• We do not sell your data. Not to data brokers, not to AI training pipelines, not to anyone.

The Contracts Finder, Find a Tender, and Companies House APIs operated by UK government agencies are public data sources. We fetch public notices and company records from them; we never send them any personal data about you.

08On our roadmap

We'd rather tell you what's not yet in place than pretend the list is complete. These items are planned — some are in active development, others are deliberately scheduled for once we've hit customer milestones.

8.1  Two-factor authentication

Optional TOTP-based two-factor authentication (using an app like Authy, 1Password, or Google Authenticator). Today, a strong password plus brute-force protection is your account's defence. Adding a second factor will make takeover materially harder even if a password is compromised elsewhere.

8.2  Database-file encryption at rest

Today the database file itself is plaintext on disk; nightly backups are encrypted. Moving the live database to SQLCipher would mean the file would only be readable with a key loaded at process startup — useful belt-and-braces if the hosting provider's physical controls ever failed.

8.3  Cyber Essentials certification

Cyber Essentials is a UK-government-backed security certification scheme. Many public-sector procurements require their suppliers' suppliers to hold it. We plan to apply for it once we've passed our first revenue milestones — it's a tangible trust signal for the public-sector-adjacent buyers BidHound users sell to.

8.4  Session revocation on password change

If you change your password, we currently rely on the natural expiry of any other active session. A follow-up change will actively invalidate all other sessions the moment you change your password, closing the window between compromise and remediation.

8.5  Audit log

A dedicated, append-only log of security-relevant events (login, logout, password change, email change, data export, account deletion) separate from our operational logs. Useful both for incident response and for giving you a record of what's happened on your own account.

8.6  Formal incident-response runbook

Documented procedures for the first 2 hours after a suspected incident, ICO notification within 72 hours, and customer notification. The obligations exist today; writing them down makes us faster and sharper under pressure.

09Reporting a vulnerability

If you spot a security problem — in BidHound, in one of our third-party dependencies, or in the way we've built any of this — we'd genuinely like to hear about it. Email security@bidhound.co.uk with any details you're comfortable sharing. We'll acknowledge within two UK working days and keep you updated as we investigate.

Please give us reasonable time to fix an issue before disclosing publicly. We won't take legal action against researchers who act in good faith, don't exfiltrate user data, and don't disrupt the service.

10Related policies

11Contact

For security questions or to report a vulnerability, email security@bidhound.co.uk. For general privacy or account queries, email phil@bidhound.co.uk.