Security & data protection

You’re about to upload your team’s names and email addresses. Here’s exactly what happens to them.

HukProof runs safe, simulated social-engineering tests against your own staff, so we hold real people’s contact details. That’s a responsibility, not a footnote. This page is the specifics, the actual mechanisms, not reassurance. Everything below is something a technical reviewer on your side can verify.

Passwords
Never stored. Not even the length of the real one leaves memory
At rest
Names & emails encrypted with AES-256-GCM
Isolation
Database-enforced; one company can never read another’s rows
In transit
TLS on every connection
Backups
Encrypted daily, and a restore has actually been rehearsed

Zero retention

What we deliberately never keep

A simulation sometimes ends with an employee typing a password into a fake login page. That is the moment the exercise exists to catch, and it is also the moment a careless tool would capture a real, working credential. HukProof does not.

When a simulated login form is submitted, the server records only the name and length of each field, which is enough to prove the person entered something in the password box, and nothing more. The value itself is never written to the database, never logged, and never sent anywhere; it falls out of memory on the next line of code. This behaviour is locked in place by an automated test that fails the build if a raw value ever survives.

For an anonymous QR-code test the same is true of the email address: it is one-way hashed purely to check it against your staff list, and the raw address is discarded. We keep the answer to “is this one of your people?”, never the person’s typing.

Data protection

Encryption

  • In transit. Every connection (browser to app, app to database, tracking pixel to server) is encrypted with TLS.
  • At rest. The most sensitive fields, your employees’ names and email addresses, are encrypted with AES-256-GCM. Each record gets its own random data key, and that key is itself wrapped by a master key held separately from the database, so a copy of the database alone, without the master key, is unreadable.
  • Backups. Backups are encrypted before they leave the server, so the backup store never holds readable personal data. And the restore path isn’t theoretical: we have run a full restore end-to-end and confirmed the recovered data matched production exactly.

Tenant isolation

One customer can never see another’s data

HukProof is multi-tenant: many companies share infrastructure, so the boundary between tenants is the thing that matters most. We enforce it at the database layer with PostgreSQL row-level security, not in application code where a missed check would leak data.

Every request runs under a restricted database role scoped to a single organisation, and the tables are set to force row-level security for every query. A query that tried to read another company’s rows returns nothing. The isolation holds even if the application code above it has a bug.

Authentication

Accounts & access

  • Passwords are stored only as salted bcrypt hashes (work factor 12), never in readable form.
  • Two-factor authentication (TOTP, the standard authenticator-app kind) is available on every account, with hashed one-time recovery codes.
  • Account lockout kicks in after repeated failed logins to blunt password-guessing.
  • Administrative tooling sits behind a separate, explicit allowlist. Being signed in is never enough to reach it.
  • Sensitive actions are audit-logged so there is an attributable record of who did what.

Guardrails

The tool can only point at your own people

A simulation tool aimed at the wrong inbox is a weapon. By default, HukProof restricts every simulation to email addresses on your own registered domain and blocks generic consumer providers, so the product cannot be turned on anyone but your own workforce. It is a technical guardrail, not just a line in the terms.

The application itself is hardened with a strict Content-Security-Policy, HSTS, frame denial and MIME-sniffing protection, per-route rate limiting, and parameterised database access throughout.

Data residency

Where your data lives, and who touches it

Application data is held in a managed PostgreSQL database in the United States. The service runs on a deliberately small set of named infrastructure providers, each one listed, with its purpose and region, on our sub-processors page. We keep that list current and give notice before adding a new one.

For customers who need it, a Data Processing Agreement is available, and our Privacy Policy sets out the rights you and your employees have over the data we hold.

Honest about stage

What we don’t claim

HukProof is a young product built by a small, hands-on team, and we’d rather be precise than impressive. We are not yet SOC 2 or ISO 27001 certified, and we don’t pretend to be. What we can point to is concrete: the mechanisms on this page, a published vulnerability-disclosure policy with a good-faith safe harbour, and a real person who answers security questions.

Security questions, or found something?

Email us directly. A person who works on the product will answer, not a ticketing queue.

security@hukproof.com