Privacy Management with PowerShell – Let's look at the core features of Priva!

All you need to know about Privacy Management, privacy management policies, rules, and subject rights requests.  

Why Priva?

Priva, or Privacy Management, is centered around protecting personal data and preventing leakage of that data and provides organizations with a tool to follow GDPR and other regulations regarding personal data. Administrators can use PowerShell to create, manage and document these settings as part of manual or automated processes. Priva also handles Subject Rights Requests that include data an organization may hold for an individual (or subject) and PowerShell can be used to manage these requests as well. Microsoft also designed Priva to help secure this data once identified as well as help IT make decisions on how to handle this data. People in general would like to keep their data private and if this data ends up in your tenant, using the Priva feature may help prevent its exfiltration. For the sake of this article, we will focus in Privacy Management's core features.

RBAC roles available

The following roles are available for privacy management:

• Privacy Management
• Privacy Management Administrators
• Privacy Management Analysts
• Privacy Management Investigators
• Privacy Management Viewers
• Privacy Management Contributors

Reference this Microsoft Learn article to see what these roles can do. 

Licensing

Priva is an add-on license, even if you do have an existing license plan, you will need to purchase this add-on to use it. So, for example, if you have an E1, E3 or E5 and want to use Priva, an add-on needs to be purchased.

License Reference

Trial

Microsoft also offers a trial license to get your feet wet and try the feature out. IF you don't have the license purchased, this is a great option for organizations to understand what data they have and possibly create policies for handling this data. Once that is in place, purchasing licenses will be necessary to get the most out of this feature.

Dashboard

The overview tab under the Priva feature brings up the Priva dashboard for a quick overview of your tenant and what Priva has discovered if anything.

Like most features in Microsoft 365, Priva has a series of 'cards' where information is displayed

PowerShell – Which module? 

Now that we have some of the basics out of the way, let's go ahead and explore what can be done with PowerShell. Keep in mind that Priva encompasses both Privacy Management AND Subject Rights Requests, formerly known as Data Subject Requests. Priva PowerShell is contained in the Security and Compliance Center PowerShell module, accessed with Connect-IPPSSession, whereas the Subject Rights Requests are accessed with the Microsoft Graph PowerShell module via Connect-MgGraph.

First, a quick list of the available cmdlets in the Security and Compliance Center PowerShell module:

Get-Command *priva*

Which provides these cmdlets:

Get-PrivacyDataMatchSchema                   Get-PrivacyManagementCaseAdmin

Get-PrivacyManagementComplianceCaseMember    Get-PrivacyManagementComplianceTag

Get-PrivacyManagementPolicy                  Get-PrivacyManagementRule

New-PrivacyDataMatchSchema                   New-PrivacyManagementComplianceTag

New-PrivacyManagementPolicy                  New-PrivacyManagementRule

Remove-PrivacyDataMatchSchema                Remove-PrivacyManagementCaseAdmin

Remove-PrivacyManagementComplianceCaseMember Remove-PrivacyManagementComplianceTag

Remove-PrivacyManagementPolicy               Remove-PrivacyManagementRule

Set-PrivacyDataMatchSchema                   Set-PrivacyManagementComplianceTag

Set-PrivacyManagementPolicy                  Set-PrivacyManagementRule

Policies and rules

In privacy management, we need to have policy / rule pairs to make a functioning privacy policy. 

Privacy management scenarios

• Open Access: Secure overexposed data.
• DataMinimization: Find and delete unused personal data.
• HighRiskDataTransfer: Prevent data exfiltration inside or outside your organization.
• TenantSettings: Default settings as determined by Microsoft.

Built-in privacy management policies 

First, let's look at built-in policies as they are referenced by the built-in privacy management rules.

Get-PrivacyManagementPolicy | Format-Table Name, Type, Mode, PrivacyManagementScenario, Workload

In a new environment, we would only see these default privacy policies

We can review the top default policy to see what these contain; we can run this one-liner: 

Get-PrivacyManagementPolicy 'Default data transfers' | Format-List

Review the rule and query its settings 

The privacy management policy contains little information that an administrator could use to determine the use of this policy. Instead, we need to look at the rule that this policy is applied with. The default policies are easy to connect name-wise to their corresponding rule and in this case, we review the rule Get-PrivacyManagementPolicy 'Default data transfers' and query its settings.

Built-in privacy management rules

As mentioned previously, policies are linked to rules and we can use PowerShell to get details on the rule mentioned in the policies we reviewed in the previous step. 

Get-PrivacyManagementRule 'Default data transfers'

Now, this rule is made up of a few parts, first is the rule in XML format:

Complete rule in XML format

Additionally, we have these settings in the rule: 

Settings in the rule 

We have a hashtable for the 'ContentContainsSensitiveInformation' property which is used for storing defined sensitive information types for this rule to match.

We can iteratively break down this value with these one-liners. First, what does this property store by itself:

(Get-PrivacyManagementRule 'Default data transfers').ContentContainsSensitiveInformation

Values and sub-values

We see there are some sub-values which we can then break apart as well:

(Get-PrivacyManagementRule 'Default data transfers').ContentContainsSensitiveInformation.Groups

We see there are groups of SITs stored as hashtables here as well, which we can then expand upon

To expand each of these, we can run this PowerShell one-liner:

(Get-PrivacyManagementRule 'Default data transfers').ContentContainsSensitiveInformation.Groups.sensitivetypes

Each colored rectangle represents a separate SIT that has been assigned to this privacy management rule

For this rule, there were 27 SITs defined

Where is this policy/rule combination applied? We can see from one of the previous screenshots:

Simplified view of locations where this rule is applied

Additionally, we have a Boundary Indicator property called CrossBoundaryTransfers. When reviewing this property, we see our Tenant region ('NAM' in this case and there is a destination boundary of all regions). This policy is monitoring inter-region (in Microsoft 365) traffic. 

Create a custom policy and rule set

When creating a Privacy Management policy, we need to decide on settings that will determine the focus and intent of the policy/rule set. When creating the policy itself, we need to choose locations (Exchange, OneDrive, etc) as well as which scenario (OpenAccess, DataMinimization, HighRiskDataTransfer, or TenantSettings). Additionally, adding a comment to the policy is recommended to help document intent and possibly the creation/modification date.

Example policy

In this example, we want to focus on any private data that may have been placed in OneDrive and needs to be removed at some point. 

New-PrivacyManagementPolicy -Name 'Corporate OneDrive PM Policy' -Comment 'Created 2024/4/2' -PrivacyManagementScenario DataMinimization -OneDriveLocation All

Example policy

In this second example, we focus on data that may be exposed in SharePoint as some sites are Public and could expose personal data.

New-PrivacyManagementPolicy -Name 'SharePoint Overexposure Containment Policy' -Comment 'Created 2024/2/7' -PrivacyManagementScenario OpenAccess -SharePointLocation All

Now we have additional policies in our tenant:

New policies are in the red rectangle above 

Note that there are three modes for these policies:

• Enabled,
• TestWithoutNotifications and
• TestWithNotifications with the default setting as 'Enabled'.

If this is your first time creating a policy, make sure to use TestWithNotifications to get a feel for the process.

Now that our policies are created, we can now create privacy management rules to match. In the below example, we are connecting a privacy management policy to this new privacy management rule with the following criteria: All OneDrive Sites, turning off email notifications, setting access level to all three available and looking at any data over 180 days inactive.

New-PrivacyManagementRule -Name 'Corporate OneDrive PM Rule' -PrivacyAccessLevel Public, External, Internal -Policy 'Corporate OneDrive PM Policy' -OneDriveSites All -PolicySettings "{'EmailDigestSettings': {'IsEnabled':'False'}}"  -Mode -LastModifiedThresholdInDays 180 -ContentContainsSensitiveInformation @(@{Name="U.S. Social Security Number (SSN)"},@{Name="U.S. Bank Account Number"})

Note that the PolicySetting parameter requires JSON values and that when the rule is successfully created, no feedback in PowerShell is provided.

For our next example rule, we will instead have email notifications on, URL provided for Privacy, ensure the rule is set to TestWithNotifcations, look at only Internal Access and enable it for SharePoint and OneDrive.

First, we need to change our policy from enforce to TestWithNotications:

Set-PrivacyManagementPolicy  'Corporate OneDrive PM Policy' -Mode TestWithNotifications

Next, we will create the connected rule:

Step one

Create JSON for the Policy Settings:

$PolicySettings = @{

   TrainingLink: "https://www.practicalpowershell.com/privacymanagement",

   EmailDigestSettings = @{

      IsEnabled = $true

      FrequencyType = "Weekly",

      DigestFrequencyWeeklyDay = "Monday"

   }

}| ConvertTo-Json

Step two

Then the PowerShell one-liner to make the new rule:

New-PrivacyManagementRule -Name 'Corporate OneDrive PM Rule' -PrivacyAccessLevel Internal -Policy 'Corporate OneDrive PM Policy' -OneDriveSites All -PolicySettings $PolicySettings -Mode -LastModifiedThresholdInDays 90 -ContentContainsSensitiveInformation @(@{Name="U.S. Social Security Number (SSN)"},@{Name="U.S. Bank Account Number"}) 

Now we have a privacy management rule and policy set to notify us of data that may be of a private nature, that matches two SITs over 90 days old. 

Privacy management compliance tags

These tags perform a similar task to retention tags in retention policies in that they determine what can happen to data after some time has passed. Within privacy management, these compliance tags determine what happens to data that is discovered and tagged for privacy concerns. Let's walk through the four cmdlets.

Get-Command *privacy*compliancetag

 Which provides these cmdlets:

Get-PrivacyManagementComplianceTag

New-PrivacyManagementComplianceTag

Remove-PrivacyManagementComplianceTag

Set-PrivacyManagementComplianceTag

Create a new tag

We can use PowerShell to create the privacy management compliance tags and give them pertinent information. An example of a tag created would look like this example below:

New-PrivacyManagementComplianceTag -Name 'Personal Data - Employees' -Comment 'Created by Damian' -RetentionACtion Delete -RetentionDuration 180

Now we have a tag, that when applied, will remove data after it is 180 days old.

List all privacy management compliance tags

In a greenfield environment, no privacy management compliance tags exist. However, once we create one or more, we can use PowerShell to query their settings.

Get-PrivacyManagementComplianceTag | Format-Table Name,Retention*,Comment

Listing all compliance tags in privacy management

Remove a tag

To remove a tag, we need to run the remove cmdlet like so:

Remove-PrivacyManagementComplianceTag 'Personal Data - Teams'

We will also be asked to confirm this deletion as a safeguard measure:

Remove an existing compliance tag

Change an existing tag

We can alter existing tags using PowerShell. For example, we can add or change comments, or alter retention actions / retention duration:

Set-PrivacyManagementComplianceTag 'Personal Data - Employee' -Comment 'Added by Damian on 4/16/24'

Set-PrivacyManagementComplianceTag 'Personal Data - Employee' -RetentionDuration 365

To PowerShell or not?

While PowerShell is a great tool for administrators and should be leaned on as much as possible to make day-to-day tasks easier, we might want to refrain from using it 100% of the time for more complicated tasks like privacy management. For one, not all configurable options are easily configurable. Second, not every command seems to work at this time. However, despite some of these complications, PowerShell appears to be the only place where we can create compliance tags and it is still useful for generating reports on settings, etc. Let the buyer beware in the case of Privacy Management PowerShell and use it where it works for your organization/scenario.

What's next?

Privacy Management also encompasses subject rights requests, which was formerly known as data subject requests. If you wish to get more in-depth coverage of privacy management policies, rules, and subject rights requests, please pick up a copy of Damian's PowerShell book which can be found on PracticalPowerShell.com and LeanPub.

Related links

• Try out ScriptRunner here
• "Get started with Priva" (Microsoft | Learn) 
• "Learn about Priva Subject Rights Requests" (Microsoft | Learn)
• License Reference
• ScriptRunner: Book a demo with our product experts