What becomes discoverable needs the right access rules.

Prioritise repositories by data risk

Start with personnel records, financial information, customer contracts and internal calculations. For each site, record an owner, legitimate users and the main sharing routes. Pay particular attention to broad groups and old project memberships. The task is not to lock down as many folders as possible, but to distinguish intended collaboration from unintended access.

Discoverability is not the same as permission

Microsoft describes Restricted Content Discovery as selective assistance during content and permission reviews. Restricted SharePoint Search is explicitly not a security boundary and does not change site permissions. Neither should therefore be presented as blanket protection against data access. Each temporarily restricted area needs an owner and a date for completing the underlying permissions review.

Example: separate sales material from internal costing

A sales team needs approved service descriptions and customer proposals, but not confidential personnel costs. Assign these sources clear owners and groups. Test the same research request as a salesperson and an authorised manager. Include both a legitimate proposal question and a direct request for protected cost calculations. Document the expected boundary before testing.

Test exceptions and changes too

Check inherited permissions, individual shares and removal from a project group. Repeat the relevant search after a permission change, allowing for documented update delays. A missing result may also indicate an incomplete knowledge base. Every test therefore needs positive cases that must keep working and negative cases that must remain excluded.

Working template: a role and source matrix

Use user roles as rows and concrete sources as columns in your test matrix. Mark each combination “allowed”, “not allowed” or “unresolved”. Link every combination to a typical question and expected result. This lets you retest permission changes precisely. Use controlled test accounts and suitable test content; do not widen access to sensitive documents for a more convenient demonstration.

• Positive test: the authorised role receives an evidenced answer.
• Negative test: the unauthorised role receives no protected details.

Make permission maintenance an ongoing process

A cleaned-up repository will not stay that way without ownership. Connect project closure, role changes and new sensitive content to renewed sharing reviews. The AI System Check can prioritise critical data paths; subsequent implementation records changes, test results and remaining issues. This provides a concrete rollout basis rather than an unverifiable statement that Copilot is now “secure”.