This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Data control not allowing save to USB device from application

Is this restriction a known issue or by design? I've set up a rule to ask users to authorise save to removeable storage and e-mail attachment of a document when it contains "surname firstname and fft" i.e. personally identifiable information of pupils. It works great, except that any document now saved directly to removable storage from an application is blocked. It appears from the knowledgebase that this is known about. Is there a workaround? To get users to save to the PC/network first and then copy to a USB device is going to get me shot!

:721


This thread was automatically locked due to age.
Parents
  • Hi,

    Christian is correct - this behavior is by design. We're intercepting files via Windows Explorer to ensure that data is inspected before it touches the removable storage drive (obviously quite important from a compliance perspective). To ensure that files copies go through Windows Explorer, and can therefore be intercepted, we block direct saves from applications when a "request user authorization" or "block" action is selected for the data control rule. If a monitor only action is selected such transfers are not blocked. A notification message is shown to inform the user to save the file locally and transfer using Windows Explorer. Hope this helps - great to see Data Control being used to detect PII within your organization.

    Best Regards,

    John

    :751
  • I realize this thread is 5 years old, but I have this same question in to support right now. Has anything changed in the last 5 years. Is Windows Explorer still the crucial middle-man?
  • Hello Adam,

    Windows Explorer still the crucial middle-man?
    I'm just a customer so this is not an official explanation. In short the rationale is: In order to make a decision the final document must be available to the DLP software. In case of a save from application this is only true after the document has been written. At this point DLP can only delete the file but might not be able to inform the application of this fact. To the user the save has succeeded but the file isn't there - an unacceptable situation. Explorer is "universally" available, it's possible to determine what it's up to and furthermore the source is on hand for inspection.

    Christian

Reply
  • Hello Adam,

    Windows Explorer still the crucial middle-man?
    I'm just a customer so this is not an official explanation. In short the rationale is: In order to make a decision the final document must be available to the DLP software. In case of a save from application this is only true after the document has been written. At this point DLP can only delete the file but might not be able to inform the application of this fact. To the user the save has succeeded but the file isn't there - an unacceptable situation. Explorer is "universally" available, it's possible to determine what it's up to and furthermore the source is on hand for inspection.

    Christian

Children
No Data