If you’re in the process of rolling out Copilot within your organisation, there’s a good chance you’re going to be asked how to ensure your users don’t access things using Copilot that they shouldn’t.
The Challenge
Let’s face it. No org wants to end up on the front page of the News because an employee discovered something they shouldn’t and then leaked it to the media.
Ok, that may be a little far fetched, but there’s a good chance your security team is going to want clear answers on how to ensure there’s no data leakage with Copilot – especially if they have battle scars from a botched Delve implementation.
We already know that Copilot honours a users current permissions – so if they can’t access certain docs or data today, they won’t be able to with Copilot either.
So, how do we go about figuring out who has access to what, and if those current permissions are set correctly?
Don’t Alarm Unnecessarily
Firstly, there’s a good chance your SharePoint and OneDrive permissions are already good. Most data within M365 today is probably safe for the vast majority of your users. Only specific places like HR or Finance would need to be locked down – and there’s a good chance those sites already have their permissions set correctly.
This means that when a user enters a question and Copilot utilises the Graph to apply context to “ground” the question with known data like documents, emails, and meeting info, it’ll only pull data from locations where the user currently has access to today.
Remember That IT Doesn’t Own The Content
Although Copilot is typically enabled by IT, they aren’t normally the owners of documents and data stored within M365.
IT can generate a report showing who has access to what data across the org, but they aren’t going to be able to act on that report because they aren’t going to typically know who should have access to what.
Rather than asking IT to attempt to work through SharePoint permissions, it’s much better to get the business involved and put the onus back on SharePoint site owners via Access Reviews in Azure. You can utilise access reviews to ask each site owner to verify its members. This puts the onus on them to make the decision of who should have access to the content in the site they manage.
Of course, this is going to rely on each site having an owner. I always recommend each site has at least two owners where possible.
Targeting Key Critical Sites
Once you have your access reviews in place for the majority of your SharePoint Sites, you can then divert your attention to your known critical sites that you want to check manually – things like HR, Finance, Accounts, Sales, and C-Level Sites. You’ll probably have a list of these in your head. You can easily verify permissions on these sites by jumping into the SharePoint admin center, opening each sites permissions and checking memberships.
Utilise Labels
If you’re not already using labels within your M365 tenant, consider enabling and using them. Labels let you either manually or automatically (if you have E5 licensing) tag documents and data and then lock down access.
Labels are used to classify data – such as data that’s confidential, or sensitive in nature and to encrypt and control access to that data, or prevent it from being shared externally.
If you apply a label to a document that encrypts that document, only those users that are given permission can access that document – even via Copilot.
Utilising Your Pilot
Once you’ve set your SharePoint site permissions and labels, you’re going to want to test them.
Part of your pilot should involve “pen-testing”. Have your small group of trusted pilot users ask Copilot some challenging questions. Things like “What does the CEO earn?” “How many times has Karen in accounts been written up?” “Give me performance data on John”.
Use the time during the pilot to find the holes in your security, and then work out how to plug them using a mixture of SharePoint permissions and labels (either automatic or manual labels) before you go into full production rollout.
Utilising Available Reports
Report-wise, there’s a few available today.
I’ve written a blog about how to utilise PowerShell to find all SharePoint sites with “Everyone except external users” permissions: https://blog.chiffers.com/2023/11/01/microsoft-copilot-how-to-disable-everyone-access-to-sharepoint-sites/
You can also utilise the reports that are available today within the M365 admin centre to locate files that have been shared in the last 30 days. You’ll find these under Sharepoint Admin > Reports > Data Access Governance.
Final Thoughts
With a little bit of prep, and a successful pilot you too can successfully adopt and enable Copilot within your org!
