As a consultant who is frequently given a user account and login for collaboration in a client's tenant, we need to ensure that both our own company data and also the client data is secured. My laptop is enrolled in our organisation's MAM and MDM policies, which works fine, however logging into office applications with a second corporate login allows me to synchronise all files I am given access to, with no protection applied by the client's MAM policies.

I am told this is by design that the second account's policies are not applied, however if these can not be applied, it should not allow the log-in as at the moment it is a security risk with the protection failing 'open'

Ideally the information from each organisation would be covered by the respective organisation's policies.

Hello,

we have two options to set the 'offline access' time:
- in the protection template of a label
- via PowerShell

The more restrictive option is always prioritized.

I would like to have an Advanced Setting which lets me choose which one to enforce per label.

For example:
- Label: Confidential \ All Employees (7 days offline access)
- Label: Strictly Confidential \ Custom Permissions (0 days offline access)

When I want to enforce the 0 days offline for custom permissions I need to set them via PowerShell.
But then these 0 days are also enforced for the 'Confidential \ All Employees' label.
But here I want to have the 7 days offline access.

So I would like to configure an Advanced Setting to enforce that for this label the offline access from the protection template is used and not the more restrictive one.

Best regards

When configuring a DLP policy through Security and Compliance Center (SCC), there is an option to send alert to admins when a rule match within the DLP policy. When the switch is toggled off, no related DLP alert will show up in the SCC console. When it is toggled on, the alerts show up in the console. Further, when this switch is toggled on, it requires you to put in an email address which will receive the alert. We would like to request a Design Change Request to enhance the product. Below are details of what we would like to see:
• All alerts should show up in SCC regardless of the “send an alert to admins when a rule matches” button being toggled on.
• An option to have the email address not required (so the alert only shows in the console). This is because the Admin is the same person who receives the incident report (next button you can toggle on/off). It is duplicative for them to receive both.

When a DLP policy is in place for exchange and a policy tip is displayed, the user hits send and a pop up is displayed telling the user that the email has been blocked. This blocking pop up reads “This message includes one or more recipients who aren’t authorized to receive sensitive information. Please remove those recipients and try to send the message again”. This differs from the policy tip that we are displaying. We need the ability for this pop up to be customizable based on the DLP policy the user triggers. The user experience is degraded when they receive two differing messages.

When a DLP policy is triggered and a notification is sent back to the user, the notification contains a copy of the original email. The problem with this is that the original email contains the content that triggered the DLP policy in the first place. This further propagates the sensitive information that we are trying to keep out of the environment. The best case scenario would be the sensitive information is masked or truncated prior to being sent back to the user. This scenario will still allow the user to have the context of where the sensitive information exists in their email/document etc. and to remediate appropriately with minimal user/business impact. Another option (not the best but better than current state) would be to strip out the original email in the notification all together. This option would at least stop further propagation of the sensitive data.

The customization of DLP notifications allows for the use of “tokens” or variables that provide additional information about the notification. The current tokes available provide limited information which provides little value to the user receiving the information. It would be great if the tokens could include more specific information about the actual DLP event such as:

-sender/receiver
-name of DLP policy that was triggered
-masked/truncated sensitive information (including surrounding text) that caused the DLP event to trigger

All of these would make the notification more valuable to the end user and would assist in the education and remediation process. Other DLP tools are currently able to do this with no problem.

At the base level we really need the ability to setup different policies for Teams chats vs channels. Hopefully these options would be granular enough to even specify the number of people who could see a chat or a channel. So a 1:1 chat might have a DLP policy, but a chat with more than 3 people might have a flag for example.

Or a channel in a Team with less than 10 people would have a flag, but if the chanel is available to more than 10 people then we could have a different policy.

Having options such as these would allow us to align our DLP policies with our organization policies for sensitive information.

Ideally the Team channel options would be granular enough to setup unique policies for different types of Teams and channels

The sensitivity label capability to block unmanaged devices from SharePoint/Group sites allows us to enable BYOD while containing particularly sensitive documents with compliance requirements to libraries that unmanaged devices can't access.

However, it's hard to allow this flexibility without a likewise capability on messaging platforms. 99% of our messages do not require restrictions, but due to that 1% requirement, we're faced with two bad choices. We have to block Teams and Outlook entirely from BYOD (which are primarily personal phones used for communication making it particularly poor), or ban communication of sensitive material and set up a secure third party messaging system at significant maintenance and training costs.

These issues can be very cleanly resolved by allowing the placement of sensitivity labels with the option for blocking unmanaged devices on Teams channels and individual emails.