Looking across the common failure patterns, there's a single theme: legacy script patterns that nobody had revisited in years. The solutions that broke were rarely recently built, they were older integrations, older web parts, scripts embedded when SharePoint was configured years ago and then forgotten.

CSP enforcement didn't create new problems; it surfaced old ones. That's actually the point. The report-only window from late 2025 through 28 February was designed exactly for this: a chance to audit before enforcement hit. Teams that used that window had nothing to worry about on 1 March. Teams that didn't are doing triage now.

When Microsoft announced SharePoint Online's Content Security Policy enforcement in early 2026, they included a lifeline for organisations that needed more time: a Set-SPOTenant -DelayContentSecurityPolicyEnforcement $true flag that pushed enforcement from 1 March to 1 June 2026. If your IT team enabled that flag, you bought yourself 90 days.

Those 90 days are now running out.

The purpose of the delay was to give organisations time to audit their environments, fix non-compliant scripts, and test changes, not to skip preparation entirely. If you haven't started yet, this post is your starting gun.

The pattern we've seen with 1 March enforcement is that the teams who struggled were the ones who started late. Trusted Script Source changes can take up to 24 hours to propagate across a tenant. If you're making changes on 30 May and something doesn't propagate in time, you have no margin for error.

Eight weeks sounds like plenty of time. In practice, the audit usually surfaces more than expected, vendor responses take longer than expected, and internal sign-off processes take time. Start now.

If your SharePoint environment includes solutions from third-party vendors, analytics tools, chatbots, form builders, or similar, those vendors may need to update their products to be CSP-compliant. Reach out to them with the specific violation URLs from your Purview audit and ask for a compliance timeline.

In the meantime, you can temporarily register their script sources as trusted, but the long-term fix needs to come from their end if their solutions use inline scripting patterns.

There's a version of this conversation that happens after an incident. After a breach. After data has been exfiltrated, or systems have been locked down by ransomware, or a client calls asking why their data appeared somewhere it shouldn't.

That conversation is expensive. Remediation is expensive. Reputational damage is expensive. Regulatory exposure (especially under POPIA) can be very expensive.

A penetration test, run proactively, finds the same problems before they become incidents. It's the difference between fixing a lock and explaining to your clients why their data is gone.

We've seen it go both ways. Businesses that test regularly catch things early and fix them quietly. Businesses that don't, often find out the hard way — and at the worst possible time.

Six months ago, your Microsoft 365 security configuration looked solid. You enabled MFA for users, configured Conditional Access policies, and deployed DLP rules. Your Secure Score reflected strong security practices.

Today, without any deliberate changes to weaken security, you notice gaps. Some users have Conditional Access exclusions that were meant to be temporary. DLP policies don't cover recently created SharePoint sites. Your Secure Score has dropped slightly, and the recommended actions list has grown.

This is configuration drift—the gradual deviation of your security settings from their intended state. It doesn't announce itself with alerts or audit findings. Instead, small changes accumulate over time, creating gaps in your security posture that may only become apparent during audits or security assessments.

Configuration drift is going to happen—no matter what you do. It stems from normal business activities:

Each scenario represents drift from intended security baselines. Individually, they seem manageable. Collectively, they represent systematic security degradation.

The instinctive response to configuration drift is increased vigilance: review configurations more frequently, document changes more carefully, audit security settings regularly.

Manual management is impossible at enterprise scale for fundamental reasons. Consider the scope:

• Hundreds or thousands of user accounts with individual settings and permissions
• Dozens of security policies across multiple workloads
• Thousands of SharePoint sites with individual permission configurations
• Hundreds of applications with varying permission grants
• Multiple administrators making legitimate changes daily
• Over 5,000 specific manual configurations across Microsoft 365 services

Manual review of this environment is:

Time-consuming: Comprehensive drift detection requires reviewing thousands of configuration points across multiple admin centers.

Error-prone: Even diligent administrators miss subtle changes and can't catch all deviations across the entire environment.

Reactive: You discover drift after it's already occurred and potentially created risk.

Unsustainable: IT teams don't have capacity for continuous manual monitoring alongside their other responsibilities.

Organizations relying on manual drift detection inevitably discover configuration gaps during audits or security assessments, when addressing them becomes more difficult and time-consuming.

When your configuration drifts from Microsoft's security best practices, Secure Score identifies the gap and provides specific guidance. If you see recommendations like:

• "Enable MFA for all users" (but you thought you already did)
• "Restrict external sharing" (but policies have been modified)
• "Remove unused service principals" (from that app integration months ago)

These aren't just suggestions—they're indicators that your configuration has drifted from security best practices.

The History tab in Secure Score offers a weekly graph showing changes over time, making it easy to spot vulnerabilities and take immediate action. A declining Secure Score over time is a clear signal that configuration drift is degrading your security posture.

Secure Score is calculated based on the implementation of security controls across various Microsoft 365 services. Each control you implement contributes to your overall score. It tracks configuration across:

• Identity and access management: MFA implementation, Conditional Access policies, privileged access controls
• Data protection: DLP policies, encryption settings, sharing configurations
• Threat protection: Anti-phishing policies, anti-malware settings, Safe Links and Safe Attachments
• Device management: Compliance policies, app protection policies
• Infrastructure security: Audit logging, threat policies, security defaults

The score is continuously updated based on your configurations and user behaviors, so frequent checks ensure you are aware of new recommendations and potential risks.

Secure Score provides visibility into configuration drift and identifies where your settings deviate from best practices. Configuration analyzer in Microsoft Defender for Office 365 provides drift analysis and allows you to track policy changes over time, specifically for threat policies.

However, visibility alone doesn't improve security. The challenge many organizations face is moving from Secure Score recommendations to systematic security improvement. You need to:

1. Prioritize recommendations: Focus on implementing recommendations with the highest score impact first, as these actions typically offer the most significant improvement in security.
2. Assess business impact: Understand how configuration changes will affect user workflows and business operations before implementation.
3. Test changes safely: Implement changes in a controlled way to avoid disrupting users or breaking critical business processes.
4. Document your baseline: Establish clear documentation of your intended security configuration so you can monitor ongoing drift.
5. Maintain improvements: Setting up Secure Score recommendations is just the beginning—monitoring changes is what truly matters. You need processes for maintaining your improved score over time.

Relying solely on Secure Score recommendations is not ideal, as several other critical security practices are not part of the Secure Score but are equally essential. A comprehensive approach addresses both Secure Score recommendations and additional security practices specific to your organization.

Auditors increasingly recognize configuration drift as a fundamental security control weakness. If you can't demonstrate that your Microsoft 365 environment maintains its security baseline over time, you can't prove that your documented controls are actually implemented.

This creates specific audit challenges:

Point-in-Time vs. Continuous Compliance: Annual audits verify configuration at a specific moment. But compliance frameworks require continuous adherence to security controls. Configuration drift between audits represents compliance gaps that may not be detected until the next assessment cycle.

Documentation vs. Reality: Your security policies document intended configurations. Auditors want evidence that actual configuration matches documentation. Configuration drift creates gaps between documented and actual security posture.

Change Management: Compliance frameworks require documented change management processes. Configuration drift can represent undocumented or poorly documented changes that bypass formal processes, creating audit findings.

For organizations managing POPIA, UK GDPR, ISO 27001, or industry-specific compliance requirements, configuration drift isn't just a security issue—it's a compliance risk that can result in audit findings and regulatory scrutiny.

Organizations that successfully manage configuration drift share common characteristics:

They establish clear security baselines: Documented intended security configuration across all Microsoft 365 workloads, aligned with business requirements and compliance obligations. Secure Score provides the framework, but you need to document which recommendations apply to your organization and why.

They implement regular monitoring: Regular monitoring of your Microsoft Secure Score ensures you stay updated on your security posture, as the score is continuously updated based on your configurations and user behaviors. Frequent checks ensure awareness of new recommendations and potential risks.

They establish response processes: Clear workflows for investigating detected drift, determining whether changes are authorized, and remediating problematic configurations. Not all configuration changes represent problematic drift—some are legitimate adaptations to business needs.

They maintain documentation: Comprehensive records of configuration baselines, detected drift, and remediation actions provide compliance evidence and support audit preparation.

They review baselines regularly: Periodic review of security baselines ensures they remain aligned with evolving business needs, threat landscape, and compliance requirements.

Before implementing systematic drift management, assess where you stand:

□ Can you list all accounts with Conditional Access exclusions and justify each one?

□ Do you know which SharePoint sites allow external sharing and to which domains?

□ Have you reviewed service principal permissions and app registrations in the last 90 days?

□ Can you identify all users with privileged administrative roles?

□ Do you have documented baselines for your Conditional Access policies?

□ When did you last review your current Secure Score and understand why it changed?

If you answered "no" to multiple questions, you likely have configuration drift that hasn't been systematically addressed.

Many organizations get stuck between seeing their Secure Score and actually improving it. They know WHERE configuration has drifted, but struggle with HOW to remediate systematically.

Our Secure Score Implementation Guide provides a step-by-step framework for systematically improving your Microsoft 365 security posture:

✓ Prioritization framework for Secure Score recommendations based on business impact

✓ Business impact assessment templates to evaluate changes before implementation

✓ Testing and rollback procedures for safe deployment

✓ Documentation templates for compliance evidence and audit preparation

✓ Maintenance workflows for sustaining security improvements over time

"We've been able to pass cybersecurity compliance of 3 large enterprises (and counting) which the pen test was a fundamental part of,"Jade reports.

Three major enterprise clients were onboarded, with the penetration test playing a fundamental role in passing their cybersecurity compliance requirements.

Regulatory Compliance Formal certification through penetration testing addresses regulatory requirements for operating in certain industries or serving enterprise clients.

Enterprise Requirements Enterprise deals often require security compliance and proper certification before contracts can be finalized.

Sales Documentation Having security certification ready provides documentation that enterprise procurement processes require.

Operational Confidence Comprehensive testing validates existing security measures and confirms platform safety.

Removing Uncertainty Proper security validation eliminates uncertainty about platform safety, allowing teams to focus on growth.

Lelapa AI's approach to security testing and certification addressed regulatory compliance requirements and supported their enterprise client onboarding.

Three enterprise clients onboarded. Certification obtained. Regulatory requirements met.

The two-week engagement provided the certification that was a fundamental part of passing cybersecurity compliance for three large enterprises.

For technology companies serving enterprise clients: security validation and certification can address regulatory requirements and support enterprise sales processes.

Lelapa AI continues to grow across African markets, serving enterprise clients with validated security and regulatory compliance.

We're grateful to Jade Abbott and the Lelapa AI team for taking the time to share their experience and insights for this case study.

MOVEit Transfer (2023): In May 2023, the CLOP ransomware gang exploited a zero-day SQL injection vulnerability (CVE-2023-34362) in Progress Software's MOVEit Transfer application. By the end of 2023, the attack had compromised more than 2,700 organizations and exposed approximately 93.3 million personal records, with total damages estimated at $12.15 billion. High-profile victims included British Airways, the BBC, Shell, the U.S. Department of Energy, and numerous universities. This breach highlighted the critical importance of rapid vulnerability patching and the devastating consequences of zero-day exploits.

AVTECH IP Cameras (2024): In August 2024, security researchers discovered an unpatched vulnerability in AVTECH IP cameras used in critical infrastructure was being exploited to spread Mirai malware, despite the vulnerability being known since 2019. This five-year delay in addressing a known vulnerability put essential services at risk.

Office of the Comptroller of the Currency (2025): In early 2025, the U.S. OCC identified suspicious interactions between a system administrative account and internal user mailboxes—activity that had gone undetected for months, raising concerns about the agency's visibility into its systems and the effectiveness of its logging practices. This breach at a federal financial regulator highlighted how even government agencies struggle with monitoring gaps.

AT&T Breach (2022-2024): AT&T confirmed a significant data breach involving unauthorized access to its Snowflake cloud storage environment. The breach occurred between May 1, 2022, and October 31, 2022, but wasn't detected until April 2024—a detection delay of nearly two years. The breach exposed over 86 million records, including Social Security Numbers. This prolonged detection window allowed attackers extensive time to access and potentially monetize sensitive customer data.

Without effective monitoring and logging, suspicious activity can go undetected, giving attackers more time to exploit vulnerabilities and exfiltrate data.

Prevention:

• Implement centralized logging and real-time monitoring solutions
• Regularly analyze logs for anomalies
• Set up automated alerts for suspicious activity
• Establish baseline behavior to detect deviations

Pen Test Role: Pen testers attempt to bypass detection and exfiltrate data to identify gaps in monitoring systems and incident response processes.

Coinbase (2025): In May 2025, Coinbase confirmed a breach when cybercriminals bribed overseas support staff to leak sensitive customer data, including names, birthdates, email addresses, and partial Social Security numbers. Attackers used this data to orchestrate highly targeted social engineering attacks against customers. This breach highlighted the vulnerability of outsourced operations and the human element in security, demonstrating that even financial incentives can compromise insider threats.

Google Salesforce Breach (2025): In August 2025, Google confirmed a data breach from a compromised Salesforce-hosted corporate database. The hacking group ShinyHunters gained access through social engineering by impersonating IT support staff and tricking a Google employee into approving a malicious application. Even at tech giants with sophisticated security teams and trained personnel, social engineering remains remarkably effective.

Workday Breach (2025): On August 18, 2025, Workday disclosed a data breach stemming from a social engineering campaign where threat actors impersonated HR or IT staff. They contacted employees by phone or text to trick them into granting access to a third-party CRM platform. This demonstrates the evolving sophistication of social engineering tactics and the importance of verification procedures for access requests.

Humans are often the weakest link in cybersecurity. Attackers use phishing, pretexting, impersonation, and other social engineering tactics to manipulate employees into granting access.

Prevention:

• Conduct ongoing security awareness training
• Simulate phishing campaigns regularly
• Implement multi-factor authentication and verify requests for sensitive actions
• Establish clear protocols for verifying identity before granting access
• Create a culture where employees feel comfortable questioning suspicious requests

Pen Test Role: Pen testers simulate phishing attacks and social engineering scenarios to assess employee awareness and identify weak points in organizational security culture.