blog.frederique.harmsze.nl my world of work and user experiences

September 30, 2019

Some tips for respecting the privacy regulations in project sites

Filed under: Governance,SharePoint — Tags: , — frederique @ 22:36

Recently, I have been talking about GDPR in the context of SharePoint project sites for a construction company building houses. What practical design choices should we make for the new SharePoint template we are developing, combined with instructions to our users? Let us take a look at five of them.

In a previous post we talked about the Office 365 security and compliance GDPR dashboard, that can help us detect and manage sensitive information after it has been stored in our Office 365 tenant. But it is better to think beforehand and aim for privacy by design. We should only store and process personal data if we have a clear purpose for it. And only for the people who do need these data, for as long as they need it.

1.Don’t use personal data if you can keep it abstract

In their building projects, the houses are bought by real people, who have real personal data. In the project site, information has to be shared about the construction of the individual houses: which kitchen options should be included, what work remains to be done for that house, et cetera. However, there is no need to refer to these houses by the names of the buyers.

So we don’t list a house as the one bought by Mr and Mrs Smith, but at the house with building number 32. And we explain to all users that we avoid using personal data unless it is absolutely necessary to get the job done and we can justify sharing these personal data.

2.Put documents with personal data in a clearly marked, separate, secured library

We do have some cases where some project team members do need to see personal data in order to do their jobs, like commercial team members who need to talk to the house owners and renovation architects who need to see photos of the original rooms the may display personal belongings.

So we have a separate document library for the house owner documents, which is clearly marked as such. That library is listed in the site menu under the heading ‘Sensitive’. And only the project team members who need to use these data have permission to enter the library. We explain to our users where they have to store and find these documents, and that if they don’t see the library, they do not have permission to open it.

3.Only share the personal details that are needed, nothing else

We have a secured list of the contact details of the owners of the houses that are being built, so that project members who need to get in touch with these people know how to reach them. In the past, that list also included fields to share information about the spouses, children, hobbies, et cetera. Somebody got inspired by customer relationship management and got carried away… That information is quite irrelevant for the construction job.

So we trimmed down the list in our site template, to contain only the fields relevant for the job. This way, our users understand that they should not include other personal data.

4.Only allow individuals to access personal data. Not AD-groups

In parts of their project sites, all employees in the business unit or even all employees in the company can see the information. For example, the basic project information is visible to all, for transparency in the organization. For these “high visibility” lists and libraries, access is managed by way of AD-groups that include everyone in that unit. However, you cannot easily see who is part of that “everyone group”.

So in lists and libraries that contain personal data, we do not allow security by way of AD groups. We tell the site owners that they have to add individual users to the SharePoint permission groups, to explicitly and purposefully give those people access.

5.Delete personal data no longer needed after the project

After the building project is finished, some personal data may be needed by the aftercare people. But we should not keep personal data just in case somebody may be interested in them someday…

So we remove the permissions on the personal data for the users who are no longer involved in the finished. And we delete the personal data that do not have to be kept for a clear purpose. For example, we need to keep the data of the companies involved as subcontractors, but we do not need the phone numbers of the individual people. So we keep a companies list for the project relations, but not the people contacts lists.

 

All in all, we are baking some privacy measures into our SharePoint template for construction projects. We are giving the site owners and end users specific instructions. And we are creating awareness, that we need to be careful with personal data.

February 28, 2019

Office 365 security and compliance GDPR dashboard – Yes please

Filed under: Governance,Office365 — Tags: , — frederique @ 23:57

These days, our project managers and site owners are aware that they have to be very careful to store no personal data, except data that are necessary to do the job, only accessible to the people who need to use it, only for the time they are needed, only for the purpose for which they were gathered. But are we sure that there were no personal data hidden somewhere in SharePoint 2007, dating from more than a decade ago, that we now risk exposing SharePoint Online after migration? Let us MAKE sure!

I am working on a project for a construction company that has been using SharePoint for ages. They have over 8.000 SharePoint sites for our Operating Company alone, most of them SharePoint 2007 sites. Currently, we are migrating these old sites to SharePoint Online, as “archive sites”, as part of our transition to Office 365. So we see a lot of old stuff passing by…

  • We want to make sure we keep all information that is still relevant for the company, such as construction details on the buildings they constructed, information needed for maintenance and guarantees.
  • But we also want to make sure that we do not have personal data that we are not allowed to have according to the privacy rules, GDPR (General Data Protection Regulation).

I am not worried about the remains in SharePoint 2007; those servers will be decommissioned and emptied soon. What I want to know: are compliant in our Office 365 environment, including SharePoint Online, where we are migrating all of that old information. The advantage of asking that question, is that we can use the modern tooling offered by Office 365 itself to check!

Tools in Office 365: GDPR dashboard and toolbox

Recently, I made our privacy officer very happy by showing him the GDPR Dashboard in the Office 365 security & compliance center. It is part of the admin toolbox which we already have in our tenant. So let’s comfigure it and use it to our advantage.

Security & Compliance center: GDPR dashboard

Security & Compliance center: GDPR dashboard (in a demo tenant, nothing going on…)

It took me a moment to find it, because I was looking in the Microsoft 365 admin center. You need to go to a different url: https://protection.office.com/ (at least, in the admin center of my tenant I see no link at this time)

And this dashboard comes with a toolbox:

GDPR toolbox

GDPR toolbox

Discover
Identify what personal data in your org is related to GDPR.
• Import data: Bring data into Office 365 to help safeguard it for GDPR.
• Find personal data: Use content search to find and export personal data to help facilitate compliance in your org.

Govern
Manage how personal data is classified, used, and accessed.
• Auto-apply labels: Automatically classify content containing personal data to help ensure it’s retained as needed.
• Create a disposition label: Trigger disposition reviews so you can decide if personal data should be deleted when it reaches a certain age.
• Use Compliance Manager: Access your org’s compliance posture for GDPR and get recommended actions for improvement.

Protect
Establish security policies to prevent, detect, and respond to cyberthreats.
• Create a data loss prevention (DLP) policy: Detect content containing personal data to help ensure it’s protected.
• Apply cyberthreat policies: Protect your users from cyberattacks like phishing, malware, malicious links, and more.

Monitor & respond
Track label usage, stay on top of data breaches, and respond to data subject requests (DSRs) and legal investigations.
• Respond to DSRs: Create DSR cases to find and export Office 365 data related to a data subject request.
• Respond to legal investigations: Use eDiscovery cases to respond to legal investigations.
• Review and explore label usage: Get insights into how labels are being used and take action if needed.
• Set up alert policies: Track and get notified about user and admin activities related to GDPR.
• View reports: Drill down on activity related to policy matches, threat detections, and more.
• Visit Service Assurance: Learn how Microsoft helps meet the security, privacy, and compliance needs of your org.

Data Loss Prevention Policy for GDPR

One of the items in the GDRP toolkit is to create a DLP (Data Loss Prevention) Policy to detect content containing personal data. You can create one starting from the shortcut in the GDPR toolbox or from the DLP section of the security & compliance center.

Data Loss Prevention policy: GDPR

Data Loss Prevention policy: GDPR

This will detect personal information in our environment:

  • EU Debit Card Number
  • EU Driver’s License Number
  • EU National Identification Number
  • EU Passport Number
  • EU Social Security Number (SSN) or Equivalent ID
  • EU Tax Identification Number (TIN)

You can select where it should apply. I want it to protect all content in all locations Office 365, including Exchange email and OneDrive and SharePoint documents (Hey, not SharePoint lists? And how about Yammer Groups, Teams conversations? Maybe it is assumed that nobody would put, for instance, a passport number in there. I have seen scans of passports in SharePoint documents and in email attachments, before they were removed as soon as possible…).

GDPR Policy: select the locations it should protect

GDPR Policy: select the locations it should protect

But for a test it is more practical to limit its scope and choose specifc locations.

GDPR policy limited to one test site collecton

GDPR policy limited to one test site collecton

You can customize what it should detect, for example: content shared with outsiders or only insiders?

GDPR Policy: tweak the details of what it should detect

GDPR Policy: tweak the details of what it should detect

And then what action should it take if it detects personal data? For example, email a report to the person who set the policy, the global admin, some specific mail address.

GDPR Policy: what action should it take with what it has detected?

GDPR Policy: what action should it take with what it has detected?

As a result, you get reports like these, in a csv file:

GDPR policy: report from demo tenant, converted from csv to columns to make it more readable

GDPR policy: report from demo tenant, converted from csv to columns to make it more readable

 

Ok, to be honest, in our first test it did not seem to detect any of our own examples of personal information we added in a SharePoint testsite, while it found a lot of false positive. But still, it looks very useful, once we get it to work properly.

Powered by WordPress