What a SharePoint compliance audit actually checks

If you are the SharePoint admin or the compliance lead at a finance, healthcare, or government tenant, this is the audit-prep companion to our launch post. There we named the four slow-burning issues that age any M365 hub — reachability, freshness, accessibility, config drift — and argued that they are a compliance surface rather than an IT surface. Here we walk through the five findings a SharePoint compliance audit typically flags, the evidence an auditor actually wants to see, and how Wardwell's weekly scan produces that same evidence on a cadence instead of a fire drill.

Most teams walk into a SOC 2, HIPAA, FedRAMP, PCI, or internal audit thinking the question is is the tenant configured correctly?. It is not. The auditor's question is do you have evidence that it has remained configured correctly since the last review? A snapshot from launch day does not answer that question. A weekly digest with a paper trail does.

What the auditor is actually looking for

A SharePoint compliance audit is not a configuration review. It is an evidence review. The auditor is not asking do you have a label policy? They are asking can you show me that, as of last Tuesday, this hub was inside the approved baseline? — and that the same question was answerable yes a month ago, three months ago, and six months ago.

The implication is structural. Compliance over a SharePoint hub is not a project. It is a recurring check whose output is the audit evidence packet. The teams that pass cleanly are the teams that already have a cadence. The teams that scramble are the ones whose last evidence is the slide deck from twelve months ago.

The five findings we see surface most often

In our field work we see the same five findings surface in over 90% of SharePoint compliance audits. They map cleanly onto the four slow-burning issues from the launch post, with one addition — patch posture — that becomes its own finding once an auditor opens the security controls binder.

1. Broken internal links

Reachability is the auditor's first stop. They will pull a sample of pages from the hub and ask whether the navigation, the embedded links, and the references inside policy documents still resolve. They will not care that a link worked on launch day; they care that it works now, and that you can show them the date you checked.

Wardwell's weekly crawl visits every page on the hub, resolves every internal link, and flags the ones whose targets now 404 or redirect. The digest is the receipt: ten pages, four broken links, the date of the check, and the diff since the previous week.

2. Missing alt text and WCAG regressions

Accessibility is the second stop, and the one with the longest audit-tail. A VPAT 2.4 from launch day does not satisfy a regression-finding. The auditor wants per-page evidence that, as of the period under review, the WCAG 2.1 AA trail was intact — alt text populated, headings in order, contrast met, form labels present.

Wardwell's accessibility scan exports per-page evidence on the same weekly cadence. The resulting CSV maps cleanly onto the VPAT fields the auditor is checking against, so the evidence packet is a single file rather than a switch between a tool, a spreadsheet, and a PDF.

3. Ungoverned external sharing

This is the finding that turns a SharePoint audit into a SharePoint audit rather than an IT one. Guest links with the wrong scope, "Anyone" links on documents that should have been policy-gated, anonymous access to a folder that holds a personnel file — these are the surface that actually trips a HIPAA, PCI, or SOC 2 control. Not the IT helpdesk.

Wardwell's config-drift diff runs against the baseline that was approved at the last security review. Anything off-baseline is a config ticket, dated, with the previous value, the current value, and when the drift started. The auditor's external-sharing finding closes against the same receipt.

4. Stale policy and ownership records

Stale content in a SharePoint hub is rarely an authoring problem; it is an ownership problem. The page still renders. The navigation still points to it. The owner moved on six months ago, and the email alias on the Owner site column no longer resolves to a real person.

The auditor wants the Last reviewed date and an Owner id that still resolves. Wardwell's freshness scan pulls both fields, on the same weekly cadence, and surfaces the pages whose owner no longer exists in the directory or whose Last reviewed date is past the policy threshold.

5. Missing security patch evidence

The fifth finding is the one that surprises SharePoint admins the most and the one auditors are increasingly strict about. The security controls binder promises that SharePoint Online, Windows, and Office receive patches on a defined cadence. The auditor wants proof that the tenant received those updates on the cadence the policy promises, over the period under review.

Wardwell's patch-posture scan reads the relevant admin signals on the same weekly cadence and rolls them up into the digest. The receipt shows the patches applied, the date, and the cadence-implied deadline — exactly the format the auditor's checklist expects.

What "audit-ready" actually means

Compliance readiness, on a SharePoint hub, is a weekly property, not a launch-day property. It is the state in which, on any given Tuesday, there is a digest in the compliance lead's inbox whose date matches the date the auditor's checklist will ask about. It is the diff between passing an audit and being audit-ready.

Three weeks of evidence on the same cadence is what closes a clean audit. One quarter is what resets the relationship between the SharePoint team and the security team from fire drill to running on a schedule.

Three weeks of evidence is enough

A useful pattern for a tenant that has not yet built the cadence:

1. Pick the audit-targeted hub. Not the whole tenant. One hub, the

one the audit team keeps asking about. That is the baseline.

1. Run the four scans + patch posture. Broken links, stale content,

WCAG, config drift, and the patch-posture roll-up. Capture the baseline output as the receipt for week one.

1. Turn the digests into the evidence packet. The weekly digest is

the audit evidence packet. The format is the same each week: date, scope, findings, drift, posture.

1. Hand it to the auditor. The evidence packet for the period under

review is the file you already produced that week. No reformatting.

Where Wardwell fits

We built Wardwell for the SharePoint admin who already knows the four slow-burning issues from the launch post and wants the same continuous monitoring for the hub that they already have for endpoint and identity. Read-only Microsoft Graph scope, six permissions, never broader. Broken- link crawl, freshness queue, WCAG 2.1 AA evidence, config-drift diff, and patch-posture roll-up — end to end, on a weekly cadence, with a weekly digest that is the same format your auditor will want.

If you want to see it on a tenant of your own, run a one-shot scan at the /scan page — sign in with Microsoft, point us at one site, and the first digest lands in your inbox the following Monday.