AnonymousSign in
Start from a neutral baseline and add what matters to you. Criteria are labeled by source — the platform baseline is architecture-neutral; buyer-contributed criteria are shown separately.
This evaluation is stored in your browser only. We cannot see it, and it is not tied to any account. Save it to a link or create an account to keep it across devices — you can export it at any time either way.
Signing up adds sharing with your team, sending this as an RFP to vendors, and private document sharing. Nothing above is taken away, and nothing here is sent anywhere until you choose to.
Look for a clear fallback story for recipients without S/MIME/PGP set up (most external recipients) — a product that only works cleanly between two configured clients has limited real-world reach.
Manual per-email encryption decisions get skipped under time pressure; look for reliable automatic policy triggers with a real accuracy figure on content detection.
Fully end-to-end (no recovery) conflicts with many compliance regimes requiring organizational access to business records — look for the vendor being explicit about this tradeoff, not glossing over it.
Recipient friction is the biggest real-world adoption barrier for email encryption; look for a low-friction default (e.g., one-click portal access) rather than assuming recipients will install software.
No buyer-contributed criteria yet
Verified buyers can suggest criteria (anonymized before pooling).
Encrypted email that becomes unsearchable breaks e-discovery/compliance archiving — look for an explicit answer on how archived encrypted mail stays discoverable under legal hold.
A solution that only works well on desktop Outlook misses a large share of real email usage — look for genuine mobile parity.
Look for either native DLP or a real integration handoff — encryption alone doesn't prevent sending sensitive data to the wrong recipient, only concealing it in transit.
Look for exportable, regulation-mapped audit logs, not just a raw send log requiring manual interpretation for a compliance review.
Look for transparent, tier-differentiated pricing that's explicit about which capabilities are gated behind a premium tier rather than included in the base product.
A compromise of the encryption system itself would be a severe incident given its role protecting sensitive communications — ask for a specific, tested incident-response process, not a generic reassurance.
Insist on the real audit report — a compliance-badge claim without the underlying report is insufficient evidence for a product handling this level of sensitive communication.
Look for a clear answer on this integration boundary; redundant, disconnected content-inspection between the encryption product and the existing email security stack creates real policy-management complexity.
Cross-border strong-encryption regulation genuinely varies by country — a vendor operating internationally should have a specific answer on how jurisdiction-specific requirements are handled, not assume one global policy suffices.
Ask for a specific size-limit figure and what happens when it's exceeded — a low limit that forces users to a separate insecure transfer channel undermines the whole point of the encryption product.
Trend-over-time reporting is a distinct capability from real-time delivery logs — confirm this exists as a maintained, exportable report.
An encryption-vendor outage that fully blocks sending/receiving encrypted mail is a severe availability failure mode for organizations that rely on it for regulated communication — ask for a specific continuity mechanism, not just an uptime SLA number.