What actually counts as an NDA breach by email, and the four ways it happens

Most NDA breaches are not dramatic. No one steals a document. Someone replies-all, or CCs a vendor on the wrong thread, and confidential information that was contractually protected is now in an inbox it was never meant to reach. The NDA was signed months ago, filed, and forgotten, and the breach happens on autopilot.

Here is what actually counts as a breach by email, and the four ways it happens in practice.

The four ways

1. Confidential information to a recipient with no NDA. The most common case. An external partner, a prospective vendor, or a new contact is on the thread, and the message contains information covered by a confidentiality obligation. They never signed anything that covers it. The disclosure itself is the breach.

2. To a signed party, but outside the scope. A recipient did sign an NDA, but it covers a specific project or category. The email shares something outside that scope: another client’s data, a different deal, information beyond the stated purpose. A signature is not a blanket clearance.

3. One recipient too far on a forward or CC. The original thread was clean. Then it is forwarded, and the new chain includes someone who should not see the earlier content. The breach is created by the act of forwarding, and the sender often never rereads what is now attached below.

4. Disclosing the existence or terms of a deal that is itself confidential. Sometimes the protected fact is not technical data, it is the relationship: that two parties are in talks, the price, or the status. Mentioning “we are close to signing with them” to an outside contact can breach a confidentiality term even when no document moves.

A recipient-level checklist

The pattern across all four is that the risk lives in the recipient, not only the content. Three questions before send:

• Who is on this thread, across To, Cc, and Bcc, including anyone added by a forward?
• Is each external recipient covered by a signed NDA for this kind of information?
• Is what I am sharing inside the scope of that NDA’s stated purpose?

A team that cannot answer these at the moment of sending is relying on memory, and memory is where NDA breaches come from.

Where a pre-send check fits

This is the exact problem a recipient-aware pre-send check is built for. The relationship between a sender, a recipient, and a signed NDA is something software can evaluate in the compose window: it maps the recipients against the firm’s signed NDAs and warns when confidential information is heading to a party who is not covered, before the message leaves. VerbaPulse calls this NDA Guard. It reads the recipients, not the stored message, so the check happens without building a content archive of its own.

The takeaway

An NDA only protects you if it is checked at the moment of disclosure, which is the one moment it is usually not checked. Map your confidential-data flows to the recipients who receive them, and put the check where the breach actually happens: in the draft, before send.