Compliance scanning is only half the equation. Identifying that a control is failing tells you what is wrong. Fixing it tells you what is right. Yet in most organizations, the gap between detection and remediation is measured in weeks, not minutes. Every day a failing control remains unremediated is a day of exposure, a day closer to audit, and a day of accumulated risk that compounds across the environment.
The Challenge: The Remediation Bottleneck
Internal benchmarking across enterprise environments reveals a striking contrast. Manual remediation of M365 compliance findings averages 38 days from detection to verified resolution. That timeline includes ticket creation, assignment, knowledge transfer, portal navigation, configuration change, verification, evidence collection, and status reporting. Each step introduces delay, and any step can stall the entire process.
The problem is compounded by the breadth of M365 compliance. A single CIS Benchmark scan may reveal 40 or more failing controls spanning Exchange Online, SharePoint, Defender, Entra ID, Power BI, and Purview. Each service has its own admin portal, its own PowerShell module, and its own configuration syntax. A technician remediating Exchange findings may have no experience with Purview or Power BI, creating knowledge silos that further slow the process.
The Two-Runbook Architecture
Automated remediation for M365 requires navigating a significant technical constraint: Exchange Online cmdlets only run under PowerShell 5.1, while modern Graph API operations perform best under PowerShell 7.2. A single-runtime approach forces compromises. The two-runbook architecture eliminates those compromises entirely.
The primary runbook runs on PowerShell 7.2 and handles all Graph API-based remediations directly: Entra ID policies, Defender settings, SharePoint configurations, and Power BI tenant settings. When it encounters a script that requires Exchange Online cmdlets, it automatically detects the dependency by scanning the script content for EXO-specific patterns and delegates execution to the companion PS 5.1 runbook. The companion executes the EXO-dependent script, captures the result, and returns status to the primary runbook, which reports back to the platform.
Automation does not mean uncontrolled. Every remediation script is versioned, reviewed, and requires explicit user confirmation before execution. The speed comes from eliminating manual portal navigation, not from bypassing change control.
Coverage: 52 Scripts Across 7 Product Areas
Comprehensive remediation requires broad coverage. The current library includes 52 pre-built remediation scripts spanning the major M365 product areas:
- Microsoft Defender (11 scripts) -- Safe Links, Safe Attachments, DKIM, SPF, spam and connection filters
- Exchange Online (6 scripts) -- mailbox auditing, modern auth, MailTips, SMTP AUTH, audit actions
- SharePoint Online (5 scripts) -- external sharing, guest resharing, infected file downloads, sync controls
- Entra ID (9 scripts) -- idle timeout, app registration, tenant creation, SSPR, guest invitations
- Power BI (2 scripts) -- publish to web, resource key authentication
- Purview (1 script) -- retention policies
- SCUBA Framework (17 scripts) -- preset security policies, Safe Links, DMARC, alerts, sharing, audit
Each script follows a consistent convention: accept parameters, execute the configuration change, verify the result, and return a structured response with success/failure status, a human-readable message, and technical details for audit logging.
Safety Model: Confirmation Before Execution
Speed must never come at the expense of safety. Automated remediation operates within a deliberate safety model:
- Explicit confirmation -- every remediation requires user confirmation via a modal dialog before execution begins
- Parameter review -- scripts that accept parameters display them for review before execution
- Org-level enablement -- remediation must be explicitly enabled per organization in settings
- Admin-only access -- only Admin role and above can trigger remediations
- Status polling -- the platform polls for completion status with a hard 10-minute timeout
- Audit trail -- every remediation trigger, execution, and result is logged in the activity audit
Webhook Integration
For organizations with existing ITSM or change management workflows, webhook integration allows remediation events to trigger downstream processes. When a remediation is triggered, an HMAC-signed webhook payload is sent to the configured endpoint, enabling integration with ServiceNow, Jira, or custom orchestration systems. The webhook includes the control ID, script name, trigger user, and organization context.
How TATER Helps
TATER provides one-click remediation directly from the unified control detail view. When a control is failing and a remediation script exists, a remediation button appears on the control card. Clicking it opens a confirmation modal with parameter review, then triggers the two-runbook pipeline. The platform polls for status updates with visual progress indicators and reports success or failure with detailed results. The remediation catalog maps unified control IDs to legacy catalog entries via variation linkage, ensuring that remediations are correctly targeted regardless of how the control is referenced. Webhook integration, SIEM event forwarding, and full audit trail logging ensure that automated remediations are fully traceable and integrate with your existing change management processes.
