Is PhishFence SOC 2 certified?

Not yet. SOC 2 Type 1 is targeted for 2027 once revenue and customer count justify the audit cost. We operate to SOC-2-aligned controls today (least-privilege access, encryption in transit and at rest, audit logging, incident response runbook) but do not hold a formal attestation.

Has PhishFence had a third-party penetration test?

Not yet. A formal third-party penetration test is targeted for Q4 2026. The application is reviewed continuously by the founder and runs automated security scanning in CI.

Does PhishFence support TOTP or SSO?

Not yet. Authentication today is email/password (10-character minimum with complexity and common-password blocklist), magic-link login, Google OAuth login, email verification on signup, and password reset. TOTP/2FA is planned for the next quarter; SSO (SAML / OIDC) will be added when the first enterprise customer requires it.

Can users delete their PhishFence account?

Yes. Account deletion is a self-service action from Settings. Deletion wipes the account, monitored domains, alert configurations, alert history, screenshots, alert events, phishing reports, API tokens, email verifications, password resets, and team memberships. Audit log entries are retained but their user_id is nulled. If a Stripe subscription is active, it is canceled before user deletion.

Does PhishFence store the content of my emails?

No. PhishFence does not store message bodies or customer email contents. DMARC processing operates on aggregate reports (RUA) only; forensic reports (RUF) are not stored unless the customer opts in. Payment card data is handled by Stripe; PhishFence never sees it.

Security at PhishFence

Data we hold — and data we don't

We store	We do not store
· Customer email address (account identifier) · Bcrypt-hashed password (cost 12) · Monitored domain names · Lookalike scan results & risk scores · DMARC aggregate reports (RUA) · Screenshots of suspect domains · Alert configurations & notification routing · API token hashes (keyed BLAKE2b, plaintext shown once at creation) · Audit log of security-relevant events · Billing metadata via Stripe (subscription IDs, plan)	· Message bodies or customer email contents · End-user PII beyond what's required for the account · DMARC forensic reports (RUF) — opt-in only · Payment card numbers (handled by Stripe) · Plaintext passwords · Plaintext API tokens after creation · Browser cookies for third-party advertising · Cross-site tracking pixels

We store

We do not store

· Customer email address (account identifier)
· Bcrypt-hashed password (cost 12)
· Monitored domain names
· Lookalike scan results & risk scores
· DMARC aggregate reports (RUA)
· Screenshots of suspect domains
· Alert configurations & notification routing
· API token hashes (keyed BLAKE2b, plaintext shown once at creation)
· Audit log of security-relevant events
· Billing metadata via Stripe (subscription IDs, plan)

· Message bodies or customer email contents
· End-user PII beyond what's required for the account
· DMARC forensic reports (RUF) — opt-in only
· Payment card numbers (handled by Stripe)
· Plaintext passwords
· Plaintext API tokens after creation
· Browser cookies for third-party advertising
· Cross-site tracking pixels

Encryption

At rest	PostgreSQL on Google Cloud SQL with disk encryption enabled (production). SQLite for local development only. Passwords bcrypt-hashed (cost 12). API tokens stored as keyed BLAKE2b hashes — plaintext is shown to the user once at creation and never persisted.
In transit	TLS 1.2 or higher on every external endpoint. HSTS enforced with `max-age=31536000; includeSubDomains; preload`. HTTP requests upgraded via `upgrade-insecure-requests` CSP directive.
Inbound mail	MTA-STS published at `mta-sts.phishfence.io` in enforce mode — senders refuse to deliver mail to phishfence.io over non-TLS.
Secrets	Stored as environment variables provisioned by Google Cloud Run from Secret Manager. Never committed to source control. The JWT signing key, Stripe secret key, Resend API key, and database URL are all managed this way.

Authentication

Method	Status	Notes
Email + password	Live	10-character minimum, requires letter + number + special char, blocklist of common passwords. Bcrypt hashed.
Magic-link login	Live	Single-use token, 15-minute expiry.
Google OAuth login	Live	OIDC; standard Google sign-in.
Email verification on signup	Live	Required before sensitive actions.
Password reset	Live	Email-delivered single-use token. Token reuse and brute force rate-limited per IP and per email.
Session tokens	Live	JWT in HttpOnly Secure SameSite=Lax cookie, 2-day rolling lifetime. Bumping the user's password invalidates all prior tokens.
API tokens	Live	Keyed BLAKE2b hashed at rest, rate-limited to 60 req/min per token, max 10 tokens per user.
TOTP / 2FA	Planned Q3 2026	RFC 6238 TOTP. Recovery codes generated at enrollment.
SSO (SAML / OIDC)	On request	Will be added when the first enterprise customer requires it. Talk to us.
Hardware keys (WebAuthn / passkeys)	Backlog	Backlogged; not currently scheduled.

Authorization & tenant isolation

· Every dashboard and API endpoint scopes queries by the authenticated user's user_id — cross-tenant data exposure would require a deliberate SQL injection on top of an auth bypass.
· CSRF tokens enforced on every state-changing request (POST, PATCH, DELETE) via a dedicated middleware.
· Rate limiting on auth endpoints (10/min per IP) and on the public domain checker (3/hour per IP).
· Admin endpoints gated by an is_admin flag set out-of-band — not "first user wins".
· Team-based features (multi-user accounts) enforce both team membership and per-feature plan gates before granting access.

Application security

Content-Security-Policy	Strict CSP with `default-src 'self'`, no `unsafe-inline` on `script-src`, `frame-ancestors 'none'`, and `object-src 'none'`.
Clickjacking	`X-Frame-Options: DENY` in addition to the CSP `frame-ancestors`.
MIME sniffing	`X-Content-Type-Options: nosniff`.
Referrer policy	`strict-origin-when-cross-origin`.
Permissions policy	Camera, microphone, geolocation, payment, and other powerful APIs all blocked at the browser level.
Output encoding	Jinja2 autoescape enforced. User-supplied content rendered via standard template variables, never `\|safe`.
Input validation	Pydantic models on every API endpoint, server-side validation on every form. Domain inputs canonicalized and length-capped before storage.
Web application firewall	Application-level WAF middleware that bans IPs hitting common attack signatures (path traversal, SQLi probes, scanner UAs).
Prompt injection	LLM-backed features (DMARC analysis assistant) treat all outputs as untrusted content. Generated text is rendered, never executed, never used as a tool call.
Dependencies	Pinned versions in `requirements.txt`. Reviewed for known CVEs prior to deploy.

Operational security

· Hosting: Google Cloud Run for the web tier; Cloud SQL (PostgreSQL) for the data tier; Cloud Run Jobs for scanning workloads; Cloud Scheduler for orchestration. US region.
· Backups: Automated Cloud SQL backups with 30-day retention. Point-in-time recovery enabled.
· Error monitoring: Sentry. Personally identifiable fields are scrubbed before transmission; message bodies and customer email contents are never sent.
· Email sending: Resend (transactional only: account verification, password reset, alert notifications). DMARC enforced on phishfence.io's sending domain.
· Logs: Structured JSON logs to Google Cloud Logging; standard 30-day retention. Audit log of security-sensitive actions retained 90 days at minimum.
· Deploys: All deploys go through Cloud Build with automated tests, type checks, and security scans. Production deploys are gated behind manual approval.

Incident response

· Affected customers will be notified within 72 hours of confirmed incident affecting their data, mirroring the GDPR Article 33 timeline.
· Notification goes to the email address of record on the affected account, plus a public post-mortem if the incident is wide-scope.
· Detection inputs include Sentry alerts, Cloud Logging metrics, abuse signals from the WAF, and customer reports to security@phishfence.io.
· The status page at status.phishfence.io is the canonical communication surface for ongoing incidents. (Status page is being stood up; if you reach it before it's live, please email support@phishfence.io.)

Account & data deletion

Account deletion is a self-service action from Settings → Delete account. Confirmation requires re-typing your account email. On confirmation, in a single database transaction we:

Cancel any active Stripe subscription so billing stops immediately.
Delete monitored domains and every alert, alert event, screenshot, and phishing report attached to them.
Delete pending email verifications, password resets, feedback, API tokens, and team memberships.
Null out the user_id on retained audit-log entries (we keep the event records so a forensic trail survives the deletion).
Hard-delete the user row itself.

Sentry sweeps any cached error context for the deleted user on its 30-day rolling window. Backups containing your data age out per the 30-day backup retention.

Owners of teams with active members must transfer ownership or dissolve the team before deletion can proceed.

What we don't have yet

We'd rather you ask once and get the truth than discover it later in your security questionnaire. Here's what we're missing today and when we expect to close each gap.

Control	Status & plan
SOC 2 Type 1	Not yet. Targeted for 2027 once revenue justifies the audit cost (~$15–25K plus ongoing). We operate to SOC-2-aligned controls today but do not hold a formal attestation.
SOC 2 Type 2	Not yet. Follows Type 1 by the standard 6-month observation period.
Third-party penetration test	Not yet. Targeted for Q4 2026. We'll publish the executive summary; the full report goes out under NDA.
HIPAA / BAA	Not supported. PhishFence is not designed for protected health information; do not store PHI in monitored-domain notes or alert configurations.
FedRAMP	Not planned. PhishFence is not certified for US Federal Government use.
ISO 27001	Not yet. Following SOC 2.
GDPR formal certification	We operate to GDPR-aligned principles today (data deletion implemented, sub-processors disclosed, EU-resident customers treated as data subjects) but do not hold a formal certification.
Public bug bounty program	Not yet. We accept vulnerability reports via security@phishfence.io and the security.txt contact. Responsible disclosure welcomed; a formal program with rewards is planned post-pen-test.

Report a vulnerability

Send vulnerability reports to security@phishfence.io. Our coordinates are also published per RFC 9116 at /.well-known/security.txt.

Please include reproduction steps, the affected endpoint or URL, and any proof-of-concept payload. We respond within one business day and aim to issue an initial fix or mitigation within 7 days for high-severity issues. We won't pursue legal action against researchers who follow standard responsible-disclosure norms.

Security is the product. Here's how we run it on ourselves.