A phishing simulator is only useful if it can't become the real thing.
You are about to send deceptive email to your own colleagues, from a platform that holds your directory and your sending credentials. That deserves more than a trust-badge graphic, so here is what is actually enforced, and where the boundaries sit.
What Phishtime never stores
Credentials are discarded, not encrypted
When someone submits a simulated login form, the platform records that a field was filled and what that field was called - email, password. The value is dropped before it reaches the database. There is no plaintext store to breach, no decryption key to lose, and no setting that turns capture on.
Only declared fields are recorded at all
Each landing page declares which fields it may record. Anything else posted to the submit endpoint is silently dropped, so a modified page or a curious browser extension cannot widen what gets logged.
Secrets are encrypted at rest
SMTP passwords, SSO client secrets, messaging-provider API keys and MFA seeds are AES-256-GCM encrypted with a key held outside the database, and there is a scripted rotation path for re-encrypting everything under a new key.
Events age out
Raw tracking events and audit entries are pruned on a retention schedule, so a simulation programme does not quietly accumulate a permanent behavioural record of every employee.
It can only be pointed at your own people
Tenant isolation in the database, not just the code
Row-level security
Every tenant-owned row carries its company, and database-level security policies scope every query to the company in the current session. The application connects under a restricted role, so the policies genuinely apply: a query that forgets to filter by tenant returns nothing, rather than someone else's data.
Separate paths for separate powers
Cross-tenant work - platform administration and the mail worker - runs on a distinct database role, so the ordinary request path never holds the ability to read across tenants in the first place.
Opaque tracking tokens
Each recipient gets a per-campaign token with 144 bits of entropy. Tracking URLs carry no employee identifier, no company name and nothing enumerable.
Split hosts
The admin application, the tracking endpoints and the landing pages are served from different hostnames, so a simulated page never shares an origin - or a cookie - with the console that runs your programme.
Getting into the console
Everything is on the record
Append-only audit log
Every administrative action - company created, template edited, campaign launched, SMTP tested, login set - with actor, time and source address. The log cannot be edited or deleted from the application; the database enforces it.
Scoped views
You see your own organisation's entries. Platform-operator identities are masked in tenant views, and nothing from another tenant is ever visible.
Export where you need it
CSV export for a compliance file, or the audit-log API on Enterprise to stream it into your SIEM alongside the rest of your estate.
Hosting & data residency
Phishtime runs on infrastructure in the European Union. Traffic is TLS-only, with certificates issued and renewed automatically. Current platform state - including any incident notes - is published on the status page.
We do not claim an ISO 27001 or SOC 2 certification, because we do not hold one. What we do claim is on this page, and every item is something you can ask us to demonstrate in the product.
Reporting a vulnerability
Found something? Email info@phishtime.com with enough detail to reproduce it. We will confirm receipt, keep you updated while we fix it, and credit you publicly for the find if you'd like that.
Do not test against another customer's tenant, run denial-of-service attempts, or use real third-party accounts in your testing.
Bring your security questionnaire
Sign up and open a real workspace first - most questions answer themselves once the product is in front of you. For anything it doesn't cover, talk to us directly.