Microsoft 365 Copilot connector permissions need a pre-launch evidence pack for UK SMEs

Tools & Technical Tutorials

16 June 2026 | By Ashley Marshall

Copilot connectors look like a search upgrade until the first finance file appears in the wrong answer. The fix is not panic. It is evidence before launch.

Why connectors change the permission question

Microsoft 365 Copilot is often introduced as a productivity layer on top of email, Teams, SharePoint and Office files. That description is true, but incomplete once connectors enter the picture. Microsoft says Copilot can reference third-party tools and services through Microsoft Graph connectors or agents, and that connector data can be returned in Copilot responses when the user has permission to access it. The practical issue for UK SMEs is therefore not whether Copilot is allowed to read everything. The practical issue is whether your permission model already represents what the business actually intends.

Microsoft Learn describes Copilot connectors as a way to sync external data into Microsoft 365. Each item includes content, metadata and an access control list, or ACL, which is used to enforce permissions. Microsoft also says there are more than 100 prebuilt connectors, including Box, Dropbox, Google Drive, Confluence, Salesforce, ServiceNow, Workday, Zendesk and Jira. That breadth is useful, but it means a small business can connect several years of operational history in a few admin sessions.

What this means in practice is simple. A connector project is not just a technical integration. It is a permission translation exercise. A ServiceNow group, a Salesforce role, a Confluence space, a network file share and a SharePoint site may all express access differently. If the mapping is wrong, Copilot may still be honouring permissions, but honouring the wrong permissions. That is why the evidence pack should start before launch, not after an awkward answer in a board meeting.

The misconception: Copilot security means no oversharing risk

The common counterargument is understandable: Microsoft 365 Copilot only shows users data they already have permission to view, so surely the risk is already controlled. Microsoft does say that Copilot surfaces organisational data only where the individual user has at least view permissions, and that prompts, responses and data accessed through Microsoft Graph are not used to train foundation large language models. Those are important controls. They do not remove the need to check whether your existing access model is too loose.

The difference is visibility. Before Copilot, a user with over-broad access still needed to know where to look, what search terms to use, which folders mattered and which legacy system held the useful context. Copilot changes the effort curve. It can summarise, connect and cite material that the user may never have found manually. For an SME with lean IT, old project folders, inherited SharePoint permissions and several cloud tools added during growth, that is where the risk sits.

Microsoft's Copilot privacy documentation is useful because it states both sides clearly. It explains the security boundary, but it also tells organisations to use permission models such as SharePoint to ensure the right users or groups have the right access. That sentence is doing a lot of work. It means the platform can respect your controls, but it cannot infer your commercial intent. If your whole company has access to a client due diligence folder, Copilot is not necessarily breaking the rule by surfacing it. The rule is the problem.

What a pre-launch evidence pack should prove

A pre-launch evidence pack is not a hundred-page governance artefact. For most UK SMEs it should be a concise set of artefacts that proves the launch decision was controlled. At minimum, it should include a connector register, a data source owner for each connector, the authentication method, the permission source of truth, excluded locations, sample ACL tests, sensitive data checks, approval notes and a rollback plan. The output should be clear enough for a director, data protection lead, IT provider and department owner to understand without reading connector code.

The connector register should name the systems being connected, such as Salesforce, ServiceNow, Jira, Confluence, SharePoint, network file shares or Zendesk. For each source, record whether the connector is synced into the Microsoft Graph index or uses a federated model where data remains in the source and is fetched in real time. Microsoft's connector documentation distinguishes those models, including federated connectors for live, dynamic or sensitive sources that should not be indexed. That choice matters for evidence because it changes where content sits, how freshness is handled and what needs monitoring.

What this means in practice is that the evidence pack becomes the launch gate. If the owner of finance cannot sign off the permissions for finance material, the finance connector does not go live. If a Confluence space has inherited broad access and no owner, it is excluded until fixed. If a custom connector expands external group membership into every item ACL, the design is challenged before it creates a maintenance burden. The point is not to slow adoption. It is to avoid pretending that a demo success is the same as a permission-safe deployment.

The UK SME risk lens is governance, not theatre

For UK SMEs, the regulatory question is rarely whether Microsoft 365 Copilot is allowed in principle. The sharper question is whether the business can demonstrate appropriate governance for the data it chooses to expose through connected systems. The ICO's AI guidance is aimed at public, private and third sector organisations, and points organisations back to UK GDPR principles when personal data is used in AI systems. The ICO also provides an AI and data protection risk toolkit for assessing risks to individual rights and freedoms. That is directly relevant where connector data includes HR files, customer tickets, sales notes, support transcripts or special category data.

The latest GOV.UK Cyber Security Breaches Survey 2025/2026 gives useful context for SME leaders. It reports that 31% of businesses were using AI, adopting it or actively considering it, but only 24% of that group had cyber security practices or processes in place to manage AI technology risks. It also reports that 30% of businesses conducted a cyber security risk assessment and that 15% reviewed risks from immediate suppliers. Those figures explain why an evidence pack is not bureaucracy. It fills a very real readiness gap.

NCSC guidance on AI and cyber security makes the same point in security language. AI systems should function as intended, remain available when needed and avoid revealing sensitive data to unauthorised parties. For a Copilot connector launch, that means the business needs evidence that permissions, source systems, suppliers and staff processes have been reviewed together. A signed evidence pack will not guarantee perfection, but it creates the record the business needs when a customer, auditor, insurer or regulator asks how the decision was made.

How to test connector permissions before users get access

Permission testing should be boring, repeatable and documented. Start with three to five realistic user personas: director, finance manager, sales user, project manager and external or temporary user if relevant. For each persona, define what they should see, what they should not see and which connected systems are in scope. Then run sample prompts and Microsoft Search queries against test content before broad rollout. The evidence pack should include screenshots, query terms, item IDs or URLs, expected results and actual results.

Microsoft Graph connector items use ACLs that represent Microsoft Entra users or groups, and Microsoft Learn notes that a deny entry takes precedence over a grant entry. It also warns against expanding external group membership directly into individual item ACLs because group membership can create a high volume of item updates. That is a technical detail with a governance consequence. If your permission model depends on local Salesforce profiles, ServiceNow groups or Confluence groups, you need a documented sync approach and a test showing that membership changes flow through correctly.

For SMEs using an IT partner or managed service provider, the test pack should be plain English. Ask for a permissions matrix, sample before-and-after tests, a list of excluded locations and evidence that company-wide sharing links or anonymous access have been reviewed. Microsoft's secure foundation guidance for Copilot recommends removing excessive or anonymous access, correcting broken inheritance and confirming site ownership for high-risk sites. Those are exactly the tests an SME can turn into a practical checklist. The result should not be a vague statement that permissions were reviewed. It should be a small bundle of proof showing which permissions were tested, who tested them and what changed before launch.

A practical launch checklist for SMEs

The evidence pack should end with a launch checklist that the business can actually use. First, confirm the purpose of each connector. If the purpose is vague, delay it. Second, identify the data owner and technical owner. Third, classify the connected content, especially HR, finance, legal, client confidential and regulated material. Fourth, map the permission source of truth. Fifth, run persona testing. Sixth, record unresolved risks and compensating controls. Seventh, set review dates, because permissions drift after launch.

Tooling can help. Microsoft Purview, sensitivity labels, Data Loss Prevention, SharePoint Advanced Management, Restricted Access Control, Entra ID access reviews and audit logs all have a role, depending on licensing and risk. SMEs do not need to buy every control on day one, but they do need to be honest about what is active, what is manual and what is not covered. If you rely on a monthly admin review because you do not have a higher tier licence, write that down and assign an owner. Unwritten controls are rarely controls.

The final launch decision should answer five director-level questions. What are we connecting? Who can see it? How do we know? What did we exclude? When will we check again? That is the heart of the evidence pack. It gives the SME a way to adopt Microsoft 365 Copilot connectors without turning the rollout into either blind optimism or a compliance theatre exercise. The right posture is pragmatic: launch where the evidence is strong, pause where it is weak, and treat connector permissions as a business control rather than an IT footnote.

Frequently Asked Questions

Is Microsoft 365 Copilot allowed to show connector data?

Yes, where a connector is approved and the user has permission to access the underlying item. The risk is usually not Copilot ignoring permissions, but existing permissions being broader than the business realises.

What is a Copilot connector evidence pack?

It is a concise launch record covering connected systems, owners, permission mappings, exclusions, test results, approvals, residual risks and review dates.

Do UK SMEs need a DPIA for Copilot connectors?

Not always, but a DPIA should be considered where connector data includes personal data at scale, sensitive data, employee monitoring implications or high risk processing under UK GDPR.

Which systems are highest risk to connect first?

HR, finance, legal, customer support, CRM notes, service desks, board papers and legacy file shares usually deserve the strictest pre-launch review.

Can sensitivity labels fix connector oversharing?

They help, especially inside Microsoft 365, but they are not a complete substitute for accurate permissions, owner review, DLP, access reviews and connector-specific testing.

Should SMEs use synced or federated connectors?

It depends on the source. Synced connectors put items into the Microsoft Graph index, while federated connectors fetch data in real time and can suit sensitive or fast-changing sources.

Who should sign off the evidence pack?

At minimum, the technical owner, business data owner and an accountable director should sign off. For personal data, involve the data protection lead or external adviser where relevant.

How often should connector permissions be reviewed?

Review high-risk connectors at least quarterly and after major changes such as restructures, new suppliers, migrations, departures or permission model changes in the source system.