You’re about to upload your team’s names and emails. 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 — and 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’s the moment the exercise exists to catch — and 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; the value itself is never written, logged, or sent anywhere. An automated test fails the build if a raw value ever survives.

Illustrative example

Encryption

In transit, at rest, and in backups

In transitEvery connection — browser to app, app to database, tracking pixel to server — is encrypted with TLS.
At restEmployee names and emails use AES-256-GCM. Each record gets its own data key, wrapped by a master key held separately from the database.
BackupsEncrypted before they leave the server, so the backup store never holds readable personal data. A full restore has been run end to end.

Tenant isolation

One customer can never see another’s data

Many companies share infrastructure, so the boundary between tenants matters most. We enforce it at the database layer with row-level security, not in application code where a missed check would leak data. Every request runs under a restricted role scoped to a single organisation; a query that tried to read another company’s rows returns nothing, even if the application above it has a bug.

Accounts & access

Who gets in, and what’s recorded

Passwords are stored only as salted bcrypt hashes (work factor 12).
Two-factor authentication (TOTP) on every account, with hashed one-time recovery codes.
Account lockout kicks in after repeated failed logins.
Admin tooling sits behind a separate allowlist. Being signed in is never enough.
Sensitive actions are audit-logged, so there’s 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 addresses on your own registered domain and blocks generic consumer providers — a technical guardrail, not just a line in the terms. The application itself is hardened throughout with standard web-security controls.

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 providers — each listed, with its purpose and region, on the pages below. We keep that list current and give notice before adding a new one.

What we don’t claim

Honest about stage

Not yet

SOC 2 — not certified
ISO 27001 — not certified

What we can point to

Every mechanism on this page
A published vulnerability-disclosure policy
A real person who answers security questions
Security questions, or found something?

Email us directly. A person who works on the product answers — not a ticketing queue. See our disclosure policy.

security@hukproof.com

Run your first simulation this afternoon.

Free for up to 100 people. No card, no consultant, no three-month onboarding.