SPO Admin Rights & DLP [Updated|Resolved]
Update: You can sidestep the Compliance Center GUI inconsistencies below, by using the Set-DlpCompliancePolicy cmdlet. I have confirmed that you can successfully run, without site-admin permissions, a command like this:
Set-DlpCompliancePolicy -Identity "SPO ABA and CCN Policy" -AddSharePointLocation "https://contoso.sharepoint.com/Procurement","https://contoso.sharepoint.com/" -Mode TestWithNotifications
There are additional options for the -Mode parameter, as well as options to remove SPO locations, and add & remove OneDrive locations.
One weird wrinkle in the framework is apparent if you review your added locations in the DLP policy GUI: you can remove the locations from the policy, even though you wouldn't have been able to add them via the GUI.
Another is that a site's members or owners can add a site to a DLP policy. This provides a workaround to using PowerShell, if you prefer the GUI: just add yourself or your DLP manager as a site member, as each SPO site is created. That's still not a least-privilege solution, though it doesn't pile on admin rights unnecessarily.
I have an open case with Microsoft about an unexpected wrinkle in O365 DLP. SharePoint Online locations (sites) based on some of the available templates can't be added to a DLP policy unless the person setting the policy is an administrator for that site. Here's how it breaks out as of this writing:
I can add sites which use these templates:
Team site (classic experience)
Project web app site
I cannot add sites which use these templates:
Team site (no O365 Group)
If the members of your DLP team aren't also Global or SPO admins already, this is a hard pill to swallow. Granting site-admin permissions across the board runs afoul of both the least-privilege principle and the separation of admin duties. Think about it in Exchange terms: if your DLP team had to have "Full Access" mailbox permissions simply to include (all) mailboxes in a policy, you'd be sounding the alarm.
In my testing, OneDrive for Business locations don't require the elevated permissions.
I'll keep you posted as Microsoft addresses the issue. I suspect that this will require a significant change within the O365 framework, and will take a while for them to work out a solution.