When enterprises think about data protection, they often focus on one question: how to stop sensitive files from leaving the organization in the first place. What is often underestimated is the next risk: once a file has already been shared externally for a legitimate business reason, the risk does not end. After external delivery, the file leaves the original network, endpoint, and identity boundary and moves into partner devices, personal computers, project workspaces, and offline storage media. If that file can then be forwarded again, reopened repeatedly, or retained indefinitely, one approved external share can quickly become a second or third leak.
That is why many organizations still suffer from continued spread of sensitive content even after deploying email audit, outbound approval, or document encryption. A contract, design drawing, quotation, project file, or customer dataset may need to be shared for business reasons. But if no control remains over who can keep using it, for how long, or whether it can be invalidated after risk emerges, then the organization has solved only the first half of the problem.
Why secondary leakage becomes more likely after external sharing
The real risk is not only the first outbound action. It is the fact that once the file leaves the original control environment, the cost of further distribution drops sharply. A recipient can forward it internally, copy it to a personal machine, move it to a USB device or cloud drive, or circulate it through messaging tools. The sender may believe the job is done, while the actual usage path becomes opaque.
This is especially difficult because many external file shares are operationally justified. Contracts, drawings, design files, pricing materials, and delivery documents do need to cross organizational boundaries. The question is not simply whether the file can be sent. The question is whether the sender still retains control after it has been sent. If the file turns into an ordinary document the moment it is shared, the enterprise has little practical ability to restrict, recover, or contain it afterwards.
The real pain points enterprises face after files are shared externally
First, many enterprises can control whether a file may be sent, but not how it may be used after it is sent. Once the file reaches the outside party, there is often no technical restriction on repeated use, long-term retention, or continued redistribution.
Second, many organizations do not provide a workable compliant path for legitimate exceptions. Business teams genuinely need to send documents externally. If the only options are “fully block it” or “send a normal attachment,” users will usually default to the easier path.
Third, many enterprises have no post-send containment mechanism. By the time the organization realizes the partner relationship has ended, the recipient was wrong, the content is outdated, or the scope of exposure is too broad, it may already be unable to invalidate the shared file.
Fourth, many approval processes stop at “may this file be sent.” They do not govern how long the approval remains usable, in what format the file must be shared, or whether the file can later be recalled.
How Ping32 builds a post-share anti-proliferation control loop
To prevent secondary leakage after external sharing, governance needs to move beyond blocking outbound transfer and toward a model in which external sharing happens in a controlled form and remains controllable afterwards. Ping32 addresses this through its File Outbound Package capability in the document encryption workflow.
The key idea is not to send the original file as an ordinary attachment. Instead, the administrator defines the outbound mode first, then the user generates a controlled outbound file or outbound package, and the external recipient accesses that package under defined conditions. In higher-risk scenarios, this can be combined with approval-based outbound sharing, approval validity windows, and later outbound package recall. That turns external sharing from a one-time release into a controlled and recoverable process.
How to use Ping32 to prevent secondary leakage after sensitive files are shared
1. Enable the file outbound package policy in the console first
In the Ping32 console, go to Document Encryption -> Policy -> Advanced Settings -> File Outbound, open Parameter Settings, and choose Support File Outbound. According to the manual, administrators can define three modes here: prohibit file outbound and approval outbound, support approval outbound, or support file outbound.
This step matters because it forces the organization to define its baseline governance model before users start sharing files. Which roles may share freely, which roles must go through approval, and which sensitive data should not be sent through outbound packages at all should be clarified here first.
2. Use approval-based outbound sharing for higher-risk files instead of default free outbound
If the document involves contracts, R&D materials, customer data, pricing structures, or bidding documents, the safer choice is support approval outbound. In that mode, administrators configure an approval template, and users must submit approval before they can generate the outbound package.
The manual also indicates that an effective time window can be set after approval. That means approval does not grant open-ended permission to generate or use outbound packages forever. It allows the organization to constrain the action to a defined time window, which is important for preventing long-term reuse of approvals.
3. Have users generate controlled outbound objects instead of sending the original encrypted file
File outbound packages can be created only from encrypted files. On the client side, users can select the encrypted file and open Create Document Security -> Create File Outbound Package from the context menu. If approval outbound is enabled, they can also apply through Apply for File Outbound Package or through the tray menu under Initiate Approval -> Apply for File Outbound Package.
Ping32 supports two output forms. One is a .nsp outbound file, which is smaller in size but requires the Outbound Package Viewer. The other is a .exe outbound package, which can be opened directly by the recipient. In both cases, the important point is that what leaves the organization is no longer the ordinary original file. It is a controlled container for external use.
4. Set passwords and outbound permissions when creating the package so the first share becomes a controlled share
According to the manual, users must at least provide a title and password when creating the outbound package, and they configure outbound permissions in the permission-setting interface. This changes external sharing from handing over a file to handing over conditional access to a file.
For scenarios where later containment may be needed, the organization should also preserve the prerequisite for online verification at creation time. The manual explicitly states that recall is only possible if online verification was enabled when the outbound package was created. In practice, this means the ability to stop later misuse is decided at the moment the package is generated, not after the risk has already materialized.
5. Generate the outbound package viewer when needed so the viewing path is also controlled
If the enterprise chooses the .nsp outbound file format, it should go to Document Encryption -> Encryption Tools -> Outbound Package Viewer -> Generate in the console, create the viewer, and provide it together with the outbound file to the external recipient. The recipient imports the .nsp file and must still pass password validation before the content can be viewed.
This adds a step compared with sending a normal attachment, but it also adds governance value. It means the organization controls not only the file content, but also the way the file is accessed, instead of letting the recipient open and further distribute it through any arbitrary tool.
6. Recall the outbound package quickly when risk is discovered
If cooperation ends, personnel change, the recipient is wrong, the permission scope is too broad, or the content must be withdrawn, administrators can go to Document Encryption -> Approval Tasks -> File Outbound, locate the relevant task under All or Processed, right-click it, and choose Recall. After recall, the recipient will no longer be able to use the outbound package normally, even if the password is entered again.
This is one of the most important controls for preventing secondary leakage because it gives the organization a post-send containment option. In many enterprises, the problem is not that the first outbound share was always wrong. The problem is that once risk becomes visible, there is no way to invalidate what has already been sent. Outbound package recall directly addresses that gap.
The product value of Ping32
From a product standpoint, Ping32 solves more than the narrow problem of how to send a file externally. It turns external sharing into a process that can be approved, restricted, validated, and recalled. For security managers, that means external sharing no longer automatically equals loss of control.
For business teams, Ping32 is not just a blunt block. It provides a usable compliant path. Files can still be shared, but in the form of controlled outbound packages. Exceptions can still exist, but under approval and validity controls. If risk appears later, recall and containment remain possible. Mature outbound governance is not about blocking every file. It is about making sure that each external share is less likely to turn into uncontrolled secondary leakage.
FAQ
Q1: If the file was approved and shared legally, why can secondary leakage still happen
Because approval answers only whether the file may be sent this time. It does not automatically control who may continue using it afterwards, for how long, or whether it can be redistributed. If the shared object becomes an ordinary attachment, the enterprise loses most of its leverage over later use.
Q2: What is the essential difference between Ping32 file outbound packages and directly sending an encrypted file
The difference is that outbound packages are designed as controlled carriers for external use. According to the manual, users can generate .nsp outbound files or .exe outbound packages from encrypted files and apply passwords and outbound permissions to them. Ordinary attachments, by contrast, tend to lose controlled usage boundaries once they leave the enterprise.
Q3: Why is online verification during package creation so important
Because the manual states clearly that recalling an outbound package requires that online verification was enabled when the package was created. If that prerequisite is not preserved at creation time, the administrator may discover risk later but still have no technical way to invalidate the already shared package. That is not a minor detail. It is the difference between having a containment option and having none.
Contact
10 min 
