The Email Security Report Every CISO Should Read, And the Questions It Should Inspire

A new report from SACR analyst Anna Perrone on the state of email security in 2026 is a very thoughtful market analysis. It challenges organizations to stop treating “email security” as a content-filtering problem, and to start treating it as an identity-graph problem with auditable evidence behind it.

This is an important and long overdue reframe.

Not only do we agree with the report's core thesis. We agree with its architecture map, its vendor assessment methodology, and its guidance to CISOs. That said, we want to leverage Anna’s report as an opportunity to pose an additional and critical question: What should email security look like when you are trying to protect BOTH, the inbox from external threats – and the outbox via which sensitive data is constantly being shared with others outside of the domain?

The Questions Every CISO Should Be Asking

“For CISOs, security architects, and senior practitioners, the practical question is not whether the secure email gateway is dead or whether ICES replaces it. The better question is what each layer uniquely contributes. Does it prevent delivery? Does it understand the communication context? Does it produce evidence? Does it reduce blast radius? Does it remediate across mailboxes, shared folders, OAuth grants, mailbox rules, and collaboration surfaces? Does it integrate into the systems where security operations teams already work?"

To this list of questions, we would add several more, including:

Does it protect the data after it leaves your environment? A phishing attack that succeeds in stealing a sensitive document does not stop being a security problem once the document has been exfiltrated. The question of what happens to regulated, confidential, or operationally sensitive data once it crosses organizational boundaries is inseparable from the email security problem, because email is how most of that data is shared externally.

Does it give senders meaningful control over what they share? The ability to expire access to a document, revoke a file-share after the relationship changes, limit whether a recipient can forward, print, or copy sensitive material are not exotic. They are the natural extension of governance into the communication workflow. Every CISO who has dealt with a terminated vendor relationship, a regulatory hold, or a data-minimization requirement knows that the answer to "can we get that data back?" is almost always "no." But, with the right holistic view of email security, the answer can always be “yes”.

Does it enable secure sharing without friction, or does it just add barriers? The history of outbound email security has often been a history of restriction. DLP systems that block. Encryption gateways that quarantine. Governance policies that create workarounds. The right standard is not "does it prevent unauthorized sharing"; it is "does it make authorized, governed sharing easier while making unauthorized sharing harder?" Data has to move. The organizations that get this right do not stop their data from moving; they make sure governance travels with it.

Does it produce audit trails that survive the perimeter? The SACR report correctly identifies auditability as a procurement requirement for the inbox. The same requirement applies to everything that leaves the inbox. Regulators, cyber insurers, and legal teams increasingly need to demonstrate not just what was blocked, but what was shared, with whom, when, and under what access conditions; including after that data was in someone else's environment. Audit trails that stop at the send button are incomplete audit trails.

Does it treat the outbox as seriously as the inbox? This is the summary question. The report documents years of innovation in inbound threat protection, and the progress is real and valuable. Outbound data governance (namely persistent encryption, attribute-based access control, object-level policy enforcement, revocation and expiry rights) has advanced significantly as well. But in most organizations, these capabilities are not yet integrated into the same program, evaluated against the same criteria, or held to the same standards of evidence and auditability. They should be.

Where Virtru Fits in This Framework

We build data-centric security on open standards, specifically the Trusted Data Format (TDF), an open specification that embeds policy and cryptographic access controls directly in the data object. The principle is straightforward: protection should travel with the data, not depend on the security of whatever environment the data happens to be passing through.

This is not a competing answer to the threat model the SACR report describes. It is a complement to it. The identity-graph problem the report identifies as the core of modern email security is exactly the problem TDF is designed to address at the data layer. When a document is protected with TDF, access decisions are made in real time, based on the identity and attributes of the person requesting access, regardless of where the document lives. The same attribute-based access control logic that governs access within your environment governs access when the document has been emailed to a partner, uploaded to a shared workspace, or processed by an AI agent.

The SACR report correctly notes that email security is converging with identity, data security, and security operations. TDF and the broader Virtru platform live at that convergence point — connecting the identity context with the object-level controls needed to govern data once it is in motion.

The report makes a strong case that explainability and evidence generation are becoming procurement requirements for inbound detection. The same logic applies to outbound governance: organizations need to demonstrate not just that they blocked a phishing email, but that the sensitive data they shared externally was accessed only by authorized identities, under authorized conditions, with a complete and verifiable record of every access event. That kind of evidence is built into TDF at the protocol level.

Open standards matter here too. The SACR report's observation that no single architecture wins the market is as true for data governance as it is for inbox protection. The reason TDF can function as an interoperability layer — allowing governed sharing across organizations with different email security stacks, identity providers, and cloud platforms — is that it is an open standard, not a proprietary container. Organizations that build outbound governance on proprietary platforms accumulate dependency. Organizations that build on open standards accumulate leverage.

Conclusion

The SACR report correctly identifies the convergence of email, identity, and data security as the defining trend of the next several years. It correctly maps the architectural landscape as multidimensional, with each layer contributing something distinct. And it correctly shifts the evaluation criterion from detection efficacy to operational outcomes: evidence, integration, remediation depth, blast-radius reduction.

These very valid arguments apply not only to the inbox, but also to the outbox. The same framework that asks "what does each inbound security layer uniquely contribute?" should ask the same question of outbound data governance. Does it protect data after it leaves your environment? Does it give senders meaningful control? Does it make governed sharing easier, not just unauthorized sharing harder? Does it produce audit trails that survive the perimeter?

Virtru builds persistent data protection on the Trusted Data Format (TDF), an open standard for embedding policy and cryptographic access controls directly in data objects across email, files, and collaboration platforms. The same identity-graph logic that the SACR report identifies as essential for inbox protection is what Virtru uses to govern data wherever it travels.