How to Build an Incident Triage Workflow Across Multiple Microsoft 365 Tenants

Creating a comprehensive and well-defined incident triage workflow is essential for IT administrators, especially for those who manage a large number of devices. This allows IT staff to detect and contain incidents, such as security breaches, much more quickly and efficiently, and prevent personnel from experiencing alert fatigue.

Having an incident triage workflow also supports incident SLAs and ensures your organization is compliant with regulatory requirements. It will also improve reporting consistency for quarterly business reviews and legal compliance.

A step-by-step guide to creating an incident triage framework

The first step to creating an incident triage workflow is to define a set framework and create a JSON or CSV file where you can log the incidents you may encounter. You must pull up data from the Microsoft Graph API and see if there are alerts that need to be addressed.

In case an incident does happen, you can tag specific devices or users using the Windows Registry.

📌 Prerequisites:

• This guide applies to systems with Microsoft 365 tenants with Microsoft Defender for Office 365 and/or Microsoft 365 Defender.
• You will need to have Windows PowerShell 7 or higher installed.
• Tenant-specific account application registrations are required. If possible, you should also have a central service account to make things more efficient.
• You will need an RMM platform to manage your devices.
• Optional: It would be useful to have Logic Apps or an SIEM to help automate the escalation of high-severity incidents.

📌 Recommended deployment strategies:

Step 1: Define a cross-tenant triage framework

The first thing you have to do is to standardize the core-triage phases for all your tenants when an incident occurs. Here’s a sample triage guide:

Create a JSON template or CSV schema to log these incidents. The specific details of the template will depend on your organization’s policies and expectations.

Step 2: Use Microsoft Graph API to pull alerts from each tenant

📌 Prerequisite: Microsoft Graph should already be installed and configured for your Microsoft 365 accounts. It should have delegated or app-level API permissions.

1. Open the Start Menu and search for Windows PowerShell.
2. Right-click Windows PowerShell > Run as administrator.
3. Type this script and press Enter:

Connect-MgGraph -Scopes “SecurityEvents.Read.All”

$alerts = Get-MgSecurityAlert -All | Where-Object { $_.Status -ne “resolved” }

To filter by severity and product:

$highAADAlerts = $alerts | Where-Object { 

$_.Severity -eq “high” -and $_.ProductName -eq “Azure Active Directory Identity Protection”

$highAADAlerts | Select-Object Id, Severity, Status, ProductName, Title, CreatedDateTime}

This will pull up all the relevant alerts from Defender for your tenants, if there are any.

4. Run these queries on a scheduled loop for all your tenants and export the results to a .CSV or .JSON file so you can track the data easily. You can do these tasks using your preferred endpoint management tool.

Step 3: Tag devices or users via Registry or PowerShell for local triage

When an incident happens on a specific endpoint, administrators can create Registry keys and values to record data regarding incidents on a specific device or user profile. This information will be saved locally. To do that, follow these steps:

1. Open the Start Menu and search for Windows PowerShell.
2. Right-click Windows PowerShell > Run as administrator.
3. Deploy a script that will create the necessary Registry values to track incident data on a device.

Here’s a sample PowerShell script you can use:

New-Item -Path “HKLM:\SOFTWARE\Org\IncidentTriage” -Force

Set-ItemProperty -Path “HKLM:\SOFTWARE\Org\IncidentTriage” -Name “LastAlert” -Value “PhishingAttempt”

Set-ItemProperty -Path “HKLM:\SOFTWARE\Org\IncidentTriage” -Name “Tag” -Value “UnderInvestigation”

The name and value of the registry keys (“LastAlert,” “PhishingAttempt,” “Tag,” and “UnderInvestigation”) are dependent on the incident that you’re trying to record. Change it according to your needs.

4. To check these Registry keys and values, open Command Prompt as an administrator.
5. Type this command and press Enter:

reg query HKLM\SOFTWARE\Org\IncidentTriage

Replace the path with the path of the value you want to check.

💡 Note: You can use an RMM tool to scan your managed devices and give a report on the tag values and track each endpoint state.

Step 4: Automate response with PowerShell or conditional access

If there’s an incident involving a compromised user account, you can disable that account and invalidate all their user sessions. You can use Windows PowerShell to deploy specific responses for that incident. Here are a few sample actions they can take when an incident occurs:

📌 Prerequisite: Microsoft Graph should already be installed and configured for your Microsoft 365 accounts. It should have delegated or app-level API permissions.

1. Open the Start Menu and search for Windows PowerShell.
2. Right-click Windows PowerShell > Run as administrator.
3. To disable the compromised accounts:

Update-MgUser -UserId $user.Id -AccountEnabled $false

To invalidate sessions of the compromised account:

Invoke-MgInvalidateUserRefreshToken -UserId $user.Id

To require a user to change their password:

Update-MgUser -UserId $user.Id -ForceChangePasswordNextSignIn $true

To tag a device as quarantined using a Registry tag:

Set-ItemProperty -Path “HKLM:\SOFTWARE\Org\IncidentTriage” -Name “IsolationState” -Value “Quarantined”

Please note this must be done manually on the compromised endpoint. You can’t do it remotely because the computer should be isolated from your organization’s network.

💡 Note: Administrators can use an endpoint management tool to apply Firewall rules or disable network interfaces.

⚠️ Troubleshooting/Things to look out for

Additional considerations when building an incident response framework across multiple Microsoft 365 tenants

• Use certificate-based application registrations with short expiration dates to prevent security breaches.
• Store incident and triage logs based on tenant IDs or display names for historical audits.
• Consider integrating Logic Apps or Power Automate to help you escalate high-severity incidents.
• Consider third-party security tools via API when possible to give your organization more layers of protection and prevent security breaches.

How NinjaOne services can help with your cyber-incident triage workflow

NinjaOne can support cross-tenant incident triaging by:

• Running PowerShell scripts across specific device tags or client scopes to address the incidents
• Logging and creating reports using incident metadata
• Providing user-friendly dashboards and script audit logs across tenants to make creating business summaries and reviews easier

Strengthen security by building a comprehensive incident triage process

IT administrators can contain incidents like security breaches much more quickly and efficiently if they have an automated and comprehensive triage workflow. It also standardizes documentation and allows organizations to meet legal compliance obligations.

Related topics:

• What Is Incident Response?
• Cloud Incident Response: Best Practices in 2025
• Enhancing Efficiency Through IT Workflow Automation
• Building an Incident Response Checklist for MSP Technicians
• MSPs: 6 Keys to Surviving a Ransomware Outbreak Across Your Client Base