---

author: Wellforce IT Editorial Team author_credentials: Microsoft 365 administration, nonprofit IT consulting, and data security advisory schema_types: [Article, FAQPage, HowTo] date: 2026-04-18

Security in SharePoint: The Audit Sequence That Actually Closes Your Configuration Gaps

The question “is SharePoint secure?” shows up in every security review we participate in. It’s the wrong question — but it points to a real problem. The platform itself runs on Microsoft’s enterprise-grade infrastructure, inherits Azure Active Directory (now Microsoft Entra ID) identity controls, and encrypts data at rest and in transit. The breaches that make headlines don’t happen because SharePoint failed. They happen because someone left external sharing wide open, never applied sensitivity labels, or granted site-owner permissions to 40 people who didn’t need them.

This piece walks through the specific order an M365 admin should audit and harden SharePoint — not in the abstract, but setting by setting, in the sequence that closes the highest-risk gaps first.

AEO Definitive Answer: Is SharePoint Secure?

SharePoint is secure at the infrastructure level: Microsoft encrypts data at rest and in transit, enforces Entra ID authentication, and maintains compliance certifications across major frameworks. However, most SharePoint security incidents stem from misconfigured tenant settings — especially overly permissive external sharing, default site permissions, and absent data loss prevention policies. The platform is secure; the defaults organizations leave untouched are not.

SharePoint’s Built-In Security vs. Your Configuration Gaps

Microsoft’s own documentation frames SharePoint’s security model around what it calls “enterprise-grade security and compliance capabilities that leverage Microsoft’s comprehensive data governance framework” (SharePoint Embedded Security Features Q&A, Microsoft Tech Community). That’s accurate. Out of the box, SharePoint provides:

• Encryption: AES 256-bit encryption at rest, TLS 1.2+ in transit.
• Identity management: Every access request routes through Microsoft Entra ID (formerly Azure AD), which supports conditional access, multi-factor authentication, and risk-based sign-in policies.
• Compliance scope: SharePoint Online falls under Microsoft’s SOC 2 Type II, ISO 27001, HIPAA BAA, and FedRAMP certifications.

None of that matters if your tenant-level sharing policy is set to “Anyone with the link” and your site collection administrators haven’t been reviewed since 2022.

The gap isn’t the platform. It’s the distance between what Microsoft makes possible and what your organization has actually configured. According to 365TUNE’s 2026 guide to critical M365 security settings, a significant number of tenants still run with default sharing and permission configurations that expose data to unintended audiences. The guide specifically flags SharePoint external sharing and guest access policies as settings admins must actively tighten — they are not secure by default in the way most organizations assume.

This is the unspoken objection behind every “is SharePoint secure” search. People aren’t questioning Microsoft’s encryption. They’re reacting to an experience — a shared link that went to the wrong person, a site that somehow became accessible to everyone in the org, a board document folder that a departing employee could still reach three months after leaving. Those are configuration failures, not platform failures.

The SharePoint Security Audit Sequence (Step-by-Step)

The order matters here. Admins who start with DLP policies before fixing external sharing are building controls on a foundation that’s already leaking. Here’s the sequence we use, and why each step depends on the one before it.

Step 1: Lock Down External Sharing (Tenant Level, Then Site Level)

External sharing is the single highest-risk setting in SharePoint Online. It controls whether users can share files and folders with people outside your organization — and at what level of authentication those external users are required to have.

Start at SharePoint admin center → Policies → Sharing. The tenant-level setting acts as a ceiling: individual sites can be more restrictive but never less restrictive than the tenant default.

Your options, from most to least restrictive:

1. Only people in your organization — no external sharing at all.
2. Existing guests — only people already in your Entra ID directory as guest accounts.
3. New and existing guests — external users must authenticate with a Microsoft account or by redeeming an invitation.
4. Anyone — generates anonymous links. No authentication required.

For most organizations, the correct tenant-level setting is New and existing guests. This is especially important given that, as Microsoft’s documentation confirms, starting May 2026, SharePoint and OneDrive integration with Microsoft Entra B2B will be enabled for all tenants regardless of previous settings. This means external guest access will route through Entra B2B by default — a security improvement, but one that still requires you to set the scope of sharing correctly at the tenant and site level.

We’ll cover external sharing in more detail in the next section, because it’s the single most common misconfiguration we encounter.

Step 2: Audit Site Permissions and Ownership

Once sharing scope is set, review who has access to what internally. Navigate to each active site collection and review:

• Site owners: These users can change permissions, delete content, and manage site settings. Limit to 2-3 people per site.
• Members vs. Visitors: Members can edit; Visitors can only view. Many organizations have dozens of members who should be visitors.
• Microsoft 365 Group membership: If the site is group-connected, its membership is controlled by the associated M365 group. Check group owners and members in the Entra admin center.

EPC Group’s 2026 SharePoint governance guide specifically recommends managing permissions through Entra ID security groups rather than adding individual users to site permission levels. This is sound advice — it makes access reviewable, auditable, and revocable at scale.

Step 3: Apply Sensitivity Labels

With permissions cleaned up, apply Microsoft Purview sensitivity labels to classify content. Labels can enforce encryption, watermarking, and access restrictions that travel with the document — even if it’s downloaded or shared outside SharePoint.

Configure labels in Microsoft Purview compliance portal → Information protection → Labels. Define your taxonomy (e.g., Public, Internal, Confidential, Highly Confidential), then publish label policies that auto-apply or prompt users to label documents at creation.

Labels must come before DLP policies because DLP rules reference labels as conditions. You can’t write a policy that blocks external sharing of “Confidential” documents if you haven’t defined what “Confidential” means in your label taxonomy.

Step 4: Configure DLP Policies

With labels in place, build Data Loss Prevention policies in Microsoft Purview → Data loss prevention → Policies. Target SharePoint Online (and OneDrive, since they share a backend) with rules like:

• Block external sharing of any document labeled “Highly Confidential.”
• Notify the compliance team when a document containing Social Security numbers is shared with anyone outside the organization.
• Warn users (with override option) when sharing “Confidential” documents externally.

DLP policies are only as good as your label taxonomy. This is why the sequence matters.

Step 5: Set Up Access Reviews

Microsoft Entra ID Governance includes access reviews that can automatically prompt site owners to verify whether current members and guests still need access. Configure these in Entra admin center → Identity Governance → Access reviews.

Set a quarterly cadence for high-sensitivity sites (finance, HR, board documents) and semi-annual for general collaboration sites. Reviewers who don’t respond within the review period should trigger automatic removal — this is configurable in the review settings.

Step 6: Enable and Monitor Audit Logs

Finally, turn on unified audit logging (it should be on by default, but verify in Microsoft Purview → Audit) and establish a monitoring routine. More on which specific logs to review in the monitoring section below.

External Sharing: The #1 Misconfiguration and How to Fix It

External sharing deserves its own section because it’s where the most damage happens. Here’s what we see repeatedly across mid-market organizations and nonprofits:

The pattern: An organization migrates to SharePoint Online. During the migration, external sharing is set to “Anyone” at the tenant level to avoid disrupting existing workflows with external partners. The migration finishes. Nobody changes the setting back. Two years later, any user in the organization can generate an anonymous link to any document in any site — no authentication, no expiration, no audit trail.

The fix is straightforward but requires coordination:

1. Set the tenant-level sharing to “New and existing guests.”
2. For sites that genuinely need broader sharing (e.g., a public-facing resource library), set the site-level policy to match — but keep these exceptions documented and reviewed quarterly.
3. Enable link expiration for guest access links. Thirty days is reasonable for project-based sharing; seven days for sensitive content.
4. Require guests to re-authenticate every 30 days via conditional access policies in Entra ID.

The Entra B2B integration rollout (Microsoft Learn documentation) strengthens this by ensuring external users are represented as guest objects in your directory — making them visible in access reviews, auditable in logs, and subject to conditional access policies. But the integration doesn’t restrict sharing scope for you. That’s still a manual configuration decision.

Sensitivity Labels and DLP Policies: Setting Them Up in the Right Order

A common mistake: organizations deploy DLP policies first, writing rules based on sensitive information types (credit card numbers, Social Security numbers, etc.) without ever implementing sensitivity labels. This creates a system that can catch some data leakage through pattern matching but can’t enforce protections based on the classification of a document.

The correct order:

Labels first. Define your sensitivity label taxonomy. Keep it to four or five levels — more granularity creates confusion without proportional security benefit. Publish the labels and give users two to four weeks to begin applying them. Use auto-labeling policies to catch content that matches known patterns (e.g., any document containing more than five instances of a Social Security number pattern gets auto-labeled “Confidential”).

DLP second. Once labels are in use, build DLP policies that reference them. This gives you two layers of detection: content-based (pattern matching) and classification-based (label-driven). A DLP policy that says “block external sharing of any document labeled Highly Confidential OR any document containing 10+ credit card numbers” is significantly more effective than either condition alone.

Why this order matters for SharePoint specifically: SharePoint’s integration with Microsoft Purview means that sensitivity labels applied to a SharePoint site can enforce a site-level sharing restriction automatically. A site labeled “Highly Confidential” can be configured to block all external sharing at the site level, regardless of the tenant-level policy. This is container-level labeling, and it’s one of the most powerful — and underused — controls available. Microsoft’s own security feature documentation (SharePoint Embedded Security Q&A) highlights how labeling integrates with the broader data governance framework to enforce protections automatically.

SharePoint Security for Nonprofits: Grant Documents, Board Files, Donor Data

Nonprofits face a specific version of the SharePoint security problem. They handle sensitive data — donor records, grant applications with financial details, board meeting minutes with strategic and personnel information — but often operate without dedicated security staff.

The audit sequence above applies directly, but with these priorities:

Donor data sites should have external sharing set to “Only people in your organization” at the site level. There’s rarely a legitimate reason to share donor records externally, and the cost of a breach — reputational damage, loss of donor trust, potential regulatory exposure under state data breach notification laws — is disproportionate to the size of the organization.

Board document libraries should use sensitivity labels set to “Highly Confidential” with container-level enforcement. Board members who are external (not employees) should be provisioned as Entra B2B guests with conditional access policies requiring MFA and compliant devices.

Grant document collaboration is where external sharing gets tricky. Grant applications often require collaboration with partner organizations. Use site-level sharing set to “New and existing guests,” combined with link expiration (30 days) and access reviews at the end of each grant cycle. This is a case where the broader strategic decisions about IT configuration intersect with organizational governance — the kind of question an IT advisory engagement can help clarify before defaults become liabilities.

Ongoing Monitoring: The Three Audit Logs Worth Reviewing Monthly

Hardening settings is a point-in-time activity. Maintaining a secure SharePoint environment requires ongoing monitoring. Not every log is worth your time. These three are:

1. Sharing Activity Report (SharePoint Admin Center → Reports → Sharing)

This shows who shared what, with whom, and when. Filter for external sharing events. Look for: anonymous links created for documents in sensitive sites, sharing events from users who don’t typically share externally, and any sharing to personal email domains (gmail.com, yahoo.com) rather than organizational domains.

2. External User Activity (Microsoft Purview → Audit → Search)

Run a monthly audit log search filtered to activities by external/guest users. Sort by volume. A guest user who accessed three documents during a project is normal. A guest user who downloaded 200 documents across six sites in a single day is not. This log also reveals guest accounts that remain active long after the collaboration that created them has ended — a direct input to your quarterly access reviews.

3. DLP Policy Matches (Microsoft Purview → Data Loss Prevention → Activity Explorer)

Review which DLP policies are triggering, how often, and whether users are overriding them. A high override rate on a specific policy means one of two things: the policy is too broad and needs tuning, or users are routinely circumventing a control that exists for good reason. Either scenario requires attention.

These three logs, reviewed monthly, give you a working picture of how SharePoint is actually being used versus how you’ve configured it to be used. The delta between those two things is your real risk surface.

FAQ Block

Is SharePoint secure?

Yes. SharePoint Online runs on Microsoft’s Azure infrastructure with AES 256-bit encryption at rest, TLS 1.2+ in transit, and authentication through Microsoft Entra ID. It holds SOC 2 Type II, ISO 27001, and FedRAMP certifications. The security risk in most organizations comes from misconfigured tenant settings — not the platform itself.

What are SharePoint security best practices?

Audit and harden settings in this order: restrict external sharing at the tenant level, clean up site permissions, apply sensitivity labels, configure DLP policies, schedule access reviews, and monitor audit logs monthly. The sequence matters because later controls depend on earlier ones (e.g., DLP policies reference sensitivity labels). EPC Group’s 2026 governance guide recommends managing permissions through security groups rather than individual user assignments for scalability.

How do I secure SharePoint for external sharing?

Set the tenant-level sharing policy to “New and existing guests” (not “Anyone”). At the site level, restrict further based on content sensitivity. Enable link expiration (7-30 days depending on sensitivity), require guest re-authentication every 30 days via conditional access, and run quarterly access reviews to remove stale guest accounts. With Entra B2B integration becoming default for all tenants in May 2026, external users will be represented as directory guest objects — making them auditable and subject to your conditional access policies.

How secure is SharePoint compared to other file-sharing platforms?

SharePoint Online benefits from Microsoft’s scale of investment in infrastructure security — the same infrastructure that supports Azure, Teams, and Microsoft 365. The differentiator isn’t the platform comparison; it’s the configuration comparison. A well-configured SharePoint tenant with proper labels, DLP, and access reviews is significantly more secure than any platform — including SharePoint itself — left at default settings.

Do I need a third-party tool to secure SharePoint?

For most small and mid-market organizations, no. Microsoft Purview (included in many M365 E3/E5 and Business Premium licenses) provides sensitivity labels, DLP, audit logging, and access reviews natively. Third-party tools add value for organizations that need cross-platform DLP, advanced analytics, or integrations with non-Microsoft systems — but the native toolset covers the six-step audit sequence described above without additional licensing for many plans.

---

The actionable takeaway: Open your SharePoint admin center and check your tenant-level sharing setting right now. If it says “Anyone,” you have an anonymous-link exposure that no amount of DLP policy or user training will fully compensate for. Fix that first. Then work through the rest of the sequence. The platform is built to be secure — but only if you configure it that way.