Currently the system blindly applies an “[External]” tag to an email subject and a notification in the message body. If the email is forwarded or replied to only internal email addresses, the message is again tagged as external, repetitively causing tagged to be applied, resulting a perpetual situation like this with the subject:
 
[External] RE: [External] RE: [External] Message Subject

This is for a message that was originally from an external source that got replied to internally multiple times. At this point it is an internal email, but an "[External]" tag is incorrectly applied. The best way to defeat security is with false positives, causing people and systems to ignore alarms, even when they're real.

The sender can remove the tag, but it causes Outlook to see it as a separate message thread.

The corrective action is to have the system intelligently apply External tagging and notification, preventing it from being incorrectly and perpetually being reapplied and Outlook maintaining correct message threading.

The current maximum instance count for Exact Data Matching is 100. I understand this is for performance reasons, and this makes sense. This is also a setting that cannot be changed.

In the healthcare industry we need to send secure encrypted emails of medical record numbers and social security numbers to many insurance companies and authorized healthcare business associates. Many insurance companies require the format to me in an email, and they prevent the use of other technologies like OneDrive.

We have a policy with our previous DLP system (Symantec/Vontu) which allows more than 100 instances per email, but we will never allow more than 499 per regulatory concerns, even if the user is authorized to send sensitive data outside of the organization.

We need to recreate this rule. I feel it is important to give more flexibility based on authorized user's role. 100 instance works on probably 99.9% of all emails out there, but I need to find a way to deal with the .1% who send out most critical data and keep our business safely and efficiently running.

Office 365 deals in data yet it is missing a vital function, data redaction. Most issues would never rear their ugly head if content was redacted. DLP can force content to not be downloaded among other functions, but there needs to be an action of redacting. Auto redact the content in question as an "action" that can take place in the system. If you have started adding this to Discovery holds, this needs to be a preventative in DLP. "Companies" know their system of record and where data is to be placed. "Users" usually have issues applying this,---this is where DLP needs to help further.

DLP is supposed to be a set of tools and processes used to ensure that sensitive data is not lost, misused, or accessed by unauthorized users.

What is redaction? It allows content to be blacked out/blocked within the document/item but the rest of the document stays intact. Many, many times a user will need for example, a social security number on a document to do one job function, when they are done, it should be removed before the document is saved in another area as they no longer need the info. This is such a common function and reason why data gets placed in the wrong place, because users don't have a way to remove the items from the document they still want to reference (but without the sensitive content).

I think this also needs to tie into redaction in Office so a user can do so before they save the content into the system or space. I will be adding a separate request in user-voice for that in the proper area.

We have noticed that when we make changes to a policy, it goes back and rescans everything in the location that the policy is applied to. Those rescans/re-indexes seem to create alerts in the tool as well as send admin alerts. This creates unnecessary overhead, confusion for the end user, and skews the metrics we collect.

We would like to see the product changed to be able to have a choice to rescan/re-index when policy is changed. Perhaps there could be a checkbox on the final page before saving changes that asks the user if they would like to rescan the environment with the newly updated policy. This functionality exists in MCAS file policies today and we would like to see in unified DLP policies as well.

In general i like the update which you have rolled out for DLP.

But while creating policy rules i see that the conditions are applied only in AND boolean logic. It would be better if we have the flexibility with OR condition as well. Because without this option, i see that we need to create multiple rules to achieve things that we need.

For an Example:

Say if sender is abc@abc.com, He/She sends a document to someone who is outside the organization. Assume that i use a Label "Confidential" which will be stored in document properties and i can detect with the condition. But if i also want to detect if the Label "Confidential" is referenced in the document as a footer, i wont be able to put that logic with the current available options for which i need to create a separate rule. If there would have been an OR boolean login. This can be achieved in one rule instead of two rules.

In the exception section, i also see only AND boolean logic available which again creates a roadblock, if i want to add multiple exception via different available conditions.

Even thought the description says that the exception says this rule will not be applied to any of these. Just because of AND logic, i think that it needs to satisfy all the conditions below to get the exception working.

For an Example:

I dont want to apply this rule if a sender is someone who is in C Level (CLevelGuy@abc.com) and also if there are some approved Outside recipients who can receive this document. Now to achieve this, i need two separate rules, which would have been possible with a simple one rule if we have OR boolean logic option

Whilst I'm fine with users utilising Teams on their home machines for necessary video-conferencing (as we primarily use a VDI environment, which has issues with webcam quality due to the passthrough) I don't want them able to download files to their machines instead of accessing them within the secure Teams window. This functionality is already in the browser-only instance of Teams at teams.microsoft.com . Implementing Company Portal is simply not feasible when users are all working remotely, and for guest users already abiding by other Company Portal restrictions from other organisations this will them mean they can't use our Teams app at all.