SharePoint Compliance: HIPAA, SOX & FedRAMP Guide

SharePoint Compliance in Regulated Industries

Compliance is not a feature you turn on — it is an architecture you build. SharePoint Online provides the tools, but your organization must configure, monitor, and maintain them to satisfy regulatory requirements. The gap between what SharePoint can do and what your auditors will accept is where most compliance failures occur.

SharePoint architecture diagram showing hub sites, team sites, and content structure — Enterprise SharePoint architecture with hub sites and connected team sites

In our 25+ years managing enterprise SharePoint for Fortune 500 companies in healthcare, financial services, and government, we have guided organizations through HIPAA audits, SOX assessments, and FedRAMP authorization processes. This guide covers the specific SharePoint configurations required for each framework and the common gaps that auditors flag.

---

HIPAA Compliance in SharePoint

What HIPAA Requires for SharePoint

The Health Insurance Portability and Accountability Act requires covered entities and business associates to implement administrative, physical, and technical safeguards for protected health information (PHI). When PHI is stored or processed in SharePoint, the following technical safeguards apply:

Access control (§164.312(a)):

Unique user identification — every user has a unique Azure AD account
Emergency access procedure — break-glass accounts documented and tested
Automatic logoff — session timeouts configured in conditional access
Encryption and decryption — data encrypted at rest and in transit

Audit controls (§164.312(b)):

Record and examine activity in systems containing PHI
SharePoint unified audit logs must be enabled and retained

Integrity controls (§164.312(c)):

Protect PHI from improper alteration or destruction
Version history, check-out controls, and information barriers

Transmission security (§164.312(e)):

Guard against unauthorized access during transmission
TLS 1.2+ for all SharePoint Online connections (enforced by Microsoft)

SharePoint HIPAA Configuration Checklist

Step 1: Business Associate Agreement

Microsoft provides a BAA as part of the Microsoft 365 DPA. Verify your organization has executed the BAA through the Microsoft Service Trust Portal. Without a BAA, storing PHI in SharePoint is a HIPAA violation regardless of your technical controls.

Step 2: Sensitivity Labels for PHI

Create a sensitivity label named "Protected Health Information" or "PHI" with the following settings:

Encryption: Encrypt content, restrict access to specific groups
Content marking: Header and footer indicating "Contains PHI - HIPAA Protected"
Auto-labeling: Detect health-related sensitive information types (SSN, medical record numbers, diagnosis codes)
Access: Restricted to healthcare-role security groups only

Step 3: Data Loss Prevention Policies

| DLP Policy | Trigger | Action |

|-----------|---------|--------|

| PHI External Sharing Block | PHI sensitivity label + external sharing | Block sharing, notify compliance |

| PHI Bulk Download Alert | >10 PHI files downloaded in 1 hour | Alert security team, block if repeat |

| PHI Email Attachment | PHI file attached to email to external recipient | Block send, notify sender |

| PHI Unprotected Detection | Health info types detected without PHI label | Apply label automatically, notify owner |

Step 4: Audit Log Configuration

Enable unified audit logging in Microsoft Purview
Configure audit log retention for 7 years (HIPAA requires 6 years, plus 1 year buffer)
Create alerts for: PHI file access by non-healthcare users, permission changes on PHI sites, external sharing attempts on PHI content
Export audit logs to your SIEM for real-time monitoring and incident response

Step 5: Access Controls for PHI Sites

Create dedicated SharePoint sites for PHI content — do not mix PHI with general content
Restrict site membership to healthcare-role security groups
Require multi-factor authentication for all PHI site access via conditional access policy
Block access from unmanaged devices (personal phones, home computers without Intune enrollment)
Disable external sharing on all PHI sites

Step 6: Incident Response Procedures

Document procedures for PHI breach notification (60-day requirement under HIPAA)
Configure Microsoft Purview Insider Risk Management to detect anomalous PHI access
Test incident response procedures quarterly
Maintain a breach notification log accessible to compliance and legal teams

---

SOX Compliance in SharePoint

What SOX Requires for SharePoint

The Sarbanes-Oxley Act applies to publicly traded companies and requires internal controls over financial reporting. When financial data, reports, or supporting documents are stored in SharePoint, SOX Section 404 controls must be implemented.

Key SOX requirements for SharePoint:

Access to financial data is restricted to authorized personnel only
Changes to financial documents are tracked and auditable
Financial records are retained for required periods (7 years minimum)
Segregation of duties is enforced for financial workflows

SharePoint SOX Configuration

Financial content isolation:

Create dedicated site collections for SOX-scoped financial content
Restrict access to finance team security groups and authorized auditors
Implement information barriers to prevent cross-department access
Use sensitivity labels to mark SOX-scoped content

Change tracking and audit trails:

| Control | SharePoint Configuration | SOX Requirement |

|---------|------------------------|-----------------|

| Document changes | Major versioning with 100+ version limit | Change tracking |

| Access logging | Unified audit log with 7-year retention | Audit trail |

| Permission changes | Audit alerts on group membership changes | Access control |

| Approval workflows | Power Automate with sequential approval | Segregation of duties |

| Record integrity | Compliance hold on financial records | Record retention |

Segregation of duties:

Financial document creators cannot approve their own documents
Implement multi-stage approval workflows in Power Automate
Use separate security groups for preparers, reviewers, and approvers
Document the segregation of duties matrix and map it to SharePoint group assignments

Retention and preservation:

Configure 7-year retention policy for all SOX-scoped content
Apply compliance holds during audit periods
Disable user deletion of records in SOX-scoped libraries (remove Delete permission from Contributors)
Archive completed financial periods to read-only sites

SOX audit preparation:

Export permission reports for all SOX-scoped sites before audit
Generate version history reports for key financial documents
Provide audit log extracts for the audit period
Document all access control changes during the audit period with business justification

---

FedRAMP Compliance in SharePoint

FedRAMP Authorization Levels

The Federal Risk and Authorization Management Program applies to cloud services used by federal agencies. SharePoint Online is available at multiple FedRAMP authorization levels:

|------------|---------------|--------------------|-----------------------|

GCC and GCC High Considerations

If your organization requires FedRAMP High authorization, you must use SharePoint Online in GCC High. Key differences from commercial SharePoint Online:

Feature limitations in GCC High:

Some third-party integrations are not available
Certain Power Platform connectors are restricted
Some advanced Copilot features may have delayed availability
App catalog submissions require additional review
External sharing is more restricted by default

Additional security controls:

All data stored within the United States
Personnel with access to data are US persons only
Background checks required for all Microsoft personnel with data access
Encryption keys managed by Microsoft with customer-controlled option (Customer Key)

FedRAMP-Specific SharePoint Configurations

NIST 800-53 controls mapped to SharePoint:

| NIST Control | SharePoint Implementation |

|-------------|--------------------------|

| AC-2 Account Management | Azure AD user lifecycle, access reviews |

| AC-3 Access Enforcement | SharePoint permissions, conditional access |

| AC-6 Least Privilege | Role-based groups, minimal Full Control |

| AU-2 Audit Events | Unified audit log, all events enabled |

| AU-6 Audit Review | Automated alerts, SIEM integration |

| CM-7 Least Functionality | Disable unused features, restrict app catalog |

| IA-2 Identification | Azure AD MFA, certificate-based auth |

| SC-8 Transmission Confidentiality | TLS 1.2+ (enforced by default) |

| SC-28 Protection of Information at Rest | BitLocker + per-file encryption |

Continuous monitoring:

Configure Microsoft Defender for Cloud Apps for continuous monitoring of SharePoint activity
Integrate SharePoint audit logs with your FedRAMP-authorized SIEM
Run monthly vulnerability assessments on custom SPFx solutions
Conduct quarterly access reviews for all FedRAMP-scoped sites
Document and remediate findings within NIST-defined timeframes

---

Cross-Framework Compliance Controls

Controls That Satisfy Multiple Frameworks

Several SharePoint configurations satisfy requirements across HIPAA, SOX, and FedRAMP simultaneously:

Unified audit logging:

Enable for all SharePoint activities
Retain for 7+ years (satisfies HIPAA 6-year, SOX 7-year, and FedRAMP audit requirements)
Export to SIEM for real-time monitoring
Create alerts for high-risk activities

Sensitivity labels:

Create labels aligned with data classification (Public, Internal, Confidential, Highly Confidential, Regulated)
Apply regulatory-specific sub-labels (PHI, Financial, CUI)
Configure auto-labeling for sensitive information types
Enforce encryption and access restrictions based on labels

Conditional access policies:

Require MFA for all regulated content access
Block unmanaged devices from accessing regulated sites
Enforce location-based restrictions for FedRAMP (US-only access for CUI)
Configure session controls to prevent download of regulated content on personal devices

Data loss prevention:

Create DLP policies for each regulatory framework
Stack policies so content matching multiple frameworks triggers the most restrictive action
Monitor DLP incident reports weekly and tune false positive rates
Document DLP policy exceptions with business justification and time limits

---

Compliance Monitoring Dashboard

Build a compliance monitoring dashboard using Power BI connected to Microsoft Purview and SharePoint admin APIs:

Dashboard metrics:

| Metric | Target | Data Source |

|--------|--------|-------------|

| Sites with correct sensitivity labels | 100% | SharePoint Admin API |

| DLP incidents (weekly) | Decreasing trend | Microsoft Purview |

| Access review completion rate | 100% | Azure AD Access Reviews |

| Audit log coverage | 100% of regulated sites | Unified Audit Log |

| External sharing on regulated sites | Zero | SharePoint Admin Center |

| MFA enforcement rate | 100% | Conditional Access reports |

| Retention policy compliance | 100% | Microsoft Purview |

For compliance implementation and audit preparation, our [SharePoint consulting team](/services/sharepoint-consulting) has experience with HIPAA, SOX, and FedRAMP assessments. [Contact us](/contact) for a compliance readiness evaluation.

---

Frequently Asked Questions

Does Microsoft's FedRAMP authorization cover my organization?

Microsoft's FedRAMP authorization covers the Microsoft 365 platform. Your organization must still implement customer-responsible controls (access management, data classification, monitoring, incident response). The shared responsibility model means Microsoft secures the platform, and you secure your configuration and data within it.

Can I store PHI in standard SharePoint Online (not GCC)?

Yes. Microsoft signs a BAA for standard commercial Microsoft 365, and SharePoint Online meets HIPAA technical safeguard requirements. GCC is required for government agencies, not for healthcare organizations. However, you must configure all HIPAA controls yourself — the platform provides the capabilities but does not enforce them by default.

How do I prepare for a SOX audit of SharePoint content?

Start preparation 60 days before the audit period. Generate permission reports for all SOX-scoped sites, export audit logs for the review period, document all permission changes with business justification, verify retention policies are applied correctly, and test that segregation of duties controls are functioning. Have a designated contact available to answer auditor questions about SharePoint controls in real-time.

What is the difference between retention policies and retention labels?

Retention policies apply broadly to locations (all SharePoint sites, specific sites). Retention labels apply to individual documents and are more granular. Use retention policies for baseline retention across the organization. Use retention labels for regulatory-specific retention that needs document-level precision (e.g., label a specific contract for 10-year retention while the library default is 7 years).

How do I handle a compliance incident in SharePoint?

Follow your incident response plan. Immediately: (1) Preserve evidence by placing a compliance hold on affected content. (2) Identify scope by reviewing audit logs for the affected time period. (3) Contain by restricting access to affected sites. (4) Investigate root cause. (5) Notify as required by regulation (HIPAA: 60 days, GDPR: 72 hours). (6) Remediate the control gap. (7) Document the incident and remediation for audit evidence.

Do I need a separate SharePoint environment for each compliance framework?

No. You can manage multiple compliance frameworks in a single SharePoint Online tenant using sensitivity labels, DLP policies, and site-level access controls. Create separate sites for content with different regulatory requirements, but they can coexist in the same tenant. The exception is FedRAMP High, which requires GCC High — a physically separate environment.