23 findings, one afternoon — what to fix first
Copilot readiness remediation, sequenced. Sort findings by severity and effort, the four worth doing today, three that look alarming but usually are not.
A readiness score with 23 checks behind it has a specific failure mode: everything looks urgent, so nothing gets done.
The scan is the easy part. Sequencing is where the work actually succeeds or stalls — and the right order is not "worst score first".
Sort by two things, not one
Every finding has a severity. Far fewer people ask the second question, which is how much it costs to fix. Plot the two and four groups fall out:
- High severity, low effort. Do these today. An anonymous sharing link on a finance site is a setting, not a project.
- High severity, high effort. Schedule these properly, with the owner in the room. Rebuilding a permission model is not an afternoon.
- Low severity, low effort. Batch them. They are the ones that quietly lift the score and cost nothing.
- Low severity, high effort. Write them down and leave them. This is the quadrant that eats remediation programmes.
SafeScan's findings view ranks by risk and shows the audience for each item — internal, anonymous, broken inheritance — alongside a specific action. The audience column is the one to read first, because it is the closest thing to a blast-radius indicator.
The four that are nearly always worth doing first
Anonymous links on anything sensitive
An anonymous link works for anyone who has the URL, forever, with no sign-in and no audit trail of who used it. If a finding pairs "anonymous" with a sensitive hit, that is the one to fix before lunch. Microsoft's external sharing overview covers the settings; the fix is usually per-site rather than tenant-wide.
Broken permission inheritance on a site with sensitive content
Broken inheritance is not inherently wrong — it is how deliberate exceptions are made. It becomes a problem when nobody remembers making the exception. Restoring inheritance from the parent is a small change with a large effect on how predictable the site becomes.
Guests who have outlived the project
Every guest account was added for a reason that was valid at the time. The reason expires; the account does not. Removing stale guests is low-effort, low-controversy and reduces the surface Copilot can reach on a user's behalf.
Admins without MFA
This one is not about files at all, which is why it gets missed in a conversation about Copilot and SharePoint. A privileged account without strong authentication undoes a great deal of careful permission work. Microsoft's Conditional Access overview is the place to start.
Three that look alarming and usually are not
Judgement matters as much as the ranking, and a scan that produces no false alarms is a scan that is not looking hard enough.
External sharing enabled at tenant level. For most organisations this is a deliberate business decision, not a misconfiguration. The finding is a prompt to check that it is still deliberate.
A site with hundreds of unique permissions. Sometimes this is sprawl. Sometimes it is a legal team's matter structure working exactly as designed. Ask the owner before you "fix" it.
Labels published but barely applied. Genuinely worth addressing, but it is an adoption problem, not a configuration one. Treat it as a programme, not a ticket. Microsoft's sensitivity labels documentation is the reference.
A first week that actually works
Concretely, for a tenant seeing this for the first time:
Day one, before lunch. Export the findings to Excel. Filter to critical and high. Count them. If the number is under ten, you are fixing them this week; if it is over fifty, you are picking a domain and starting there rather than working the list top to bottom.
Day one, afternoon. Clear the anonymous links on anything flagged with a sensitive hit. This is the highest ratio of risk removed to effort spent that you will get all week, and it needs nobody's approval.
Day two. Guests and dormant accounts. Pull the list, send it to the people who own those relationships, and give them a deadline rather than a question. "These twelve guests will be removed on Friday unless you tell me otherwise" gets a response; "can you review these guests" does not.
Day three. Permission exceptions on the top five sites by sensitivity. Restore inheritance where the exception has no owner and no reason anyone can state.
Day four. Rescan. Not because the work is finished, but because you want the delta while the changes are fresh and attributable. A rescan a month later tells you much less about what worked.
Day five. Write down what is left, who owns each item, and when it is due. That document, not the score, is what you take to the next meeting.
Who has to be in the room
The findings that stall are the ones an administrator cannot decide alone. Removing a guest can be a client-relationship question. Disabling a sharing link can break a live tender. Deleting a leaver's content is an HR and Legal matter, not an IT one.
Sort those out of your own queue early and route them to the person who owns the decision. A remediation plan that assumes IT can unilaterally change how a business shares information is a plan that stops in week two.
What good looks like after one pass
Not zero findings. A tenant with zero findings is either very small or not being scanned properly. What you want after the first pass is: every critical finding either fixed or explicitly accepted with a named owner, the low-effort items cleared, and the expensive ones scheduled rather than ignored.
That is a defensible position in front of an auditor, which "we ran a scan" is not.
Copilot SafeScan ranks every finding worst-first, with the audience, the exposed path, the sensitive-data hits and the specific action for each one. Export to Excel for the working list and PDF for the people who only need the summary.
Related: the PowerShell SafeScan writes for your tenant, why your score drops when nobody did anything wrong, and why readiness is a security assessment, not a licence.
