Companies that will be unable to use Sentinel operational procedures on March 31, 2027

*This article is based on official Microsoft information as of July 14, 2026.

"The Microsoft Sentinel screen is changing from the Azure portal to the Microsoft Defender portal."

Hearing only this explanation might make you think that all you need to do is relearn the menu locations and operation screens.

However, the actual impact is not limited to that.

Microsoft has announced that from March 31, 2027, it will no longer support Microsoft Sentinel in the Azure portal and will transition to a model where it is used only in the Microsoft Defender portal. Organizations using the Azure portal are encouraged to begin their migration planning now. After the deadline, users accessing Microsoft Sentinel in the Azure portal will be redirected to the Defender portal.

There are 260 days remaining from July 14, 2026, until the deadline.

However, it is not enough to just switch portals in 260 days.

There are at least six areas that need to be reviewed.

┌──────────────────────────────┐
│ 1. SOC screen operations and incident response procedures │
├──────────────────────────────┤
│ 2. Data storage locations, processing locations, and retention periods │
├──────────────────────────────┤
│ 3. Sentinel and Defender XDR roles and permissions │
├──────────────────────────────┤
│ 4. Automation rules, playbooks, and ITSM integration │
├──────────────────────────────┤
│ 5. Scope of work and division of responsibility with MSSP/SOC vendors │
├──────────────────────────────┤
│ 6. Content of explanations in audit and vendor checksheets │
└──────────────────────────────┘

There are questions that IT departments, legal departments, SOC teams, and management need to consider.

Can the SOC procedures, evidence collection procedures, and scope of work in outsourcing contracts that assume the Azure portal screen be used as they are?

Conclusion: The target of the migration is not the "portal" but the "security operation model"

Do not think of this migration as merely a change in URL or screen layout.

Official Microsoft migration documentation explains that the policies applied to data storage, processing, retention, and sharing differ between the Azure portal and the Defender portal.

When using the Azure portal, Microsoft Sentinel policies are applied, but when operating Microsoft Sentinel data in the Defender portal, Microsoft Defender XDR policies are applied.

Figure 1: What is changing

[Conventional]
Azure portal
↓
Microsoft Sentinel
↓
Log Analytics workspace
↓
Sentinel-centric incident, automation, and permission management

Migration

[Future]
Microsoft Defender portal
↓
Microsoft Sentinel + Microsoft Defender XDR
↓
Unified incidents, unified entities, and unified hunting
↓
Azure RBAC + Defender XDR unified RBAC
↓
Check Sentinel policies + Defender XDR policies

Therefore, during the migration, it is necessary to check the following three points separately.

・Things that will not change
- Main items to check: Raw log storage locations, existing connectors, and the basic structure of Log Analytics

・Things that will change
- Main items to check: Incident correlation, screens, data processing, CMK, permissions, and automation

・Things to check anew
- Main items to check: Defender XDR region, unified RBAC, and primary workspace

1. What will happen on March 31, 2027

Microsoft Sentinel is generally available in the Microsoft Defender portal, including for organizations that do not have Microsoft Defender XDR or Microsoft 365 E5 licenses.

After March 31, 2027, Microsoft Sentinel support in the Azure portal will end, and it will be used exclusively in the Defender portal.

Table 1: Summary of migration deadlines

・As of July 14, 2026
- Status: Organizations using the Azure portal are recommended to begin migration planning

・Migration preparation period
- Status: Onboarding to the Defender portal, testing, revision of procedures, and training are conducted

・After March 31, 2027
- Status: Microsoft Sentinel is not supported in the Azure portal

・Users after the deadline
- Status: Redirected to the Defender portal and used only in the Defender portal

・Practical migration deadline
- Status: Verification, training, and contract adjustments must be completed before March 31, 2027

Why planning to switch on the deadline day is dangerous

The subsequent verification takes more time than the actual operation of connecting the portal.

Connect workspace
↓
Check permissions
↓
Check how incidents appear
↓
Check analytics rules and correlations
↓
Check automation rules
↓
Execute playbooks
↓
Check integration with ITSM, ServiceNow, etc.
↓
Rewrite SOC procedures
↓
Train analysts
↓
Revise division of responsibilities with contractors

For this reason, March 31, 2027, should not be considered the day to "start migration work," but rather the deadline by which revised operations must already be running stably.

2. There are parts that will not change

There is no need to cause excessive anxiety.

Even after onboarding Microsoft Sentinel to the Defender portal, the basic structure of existing data collection and telemetry flows will be maintained.

Microsoft's official documentation explains that existing data connectors will continue to operate without interruption, and there will be no changes to the underlying ingestion pipelines or data schemas of Log Analytics. The Microsoft Sentinel backend will continue to be integrated with Log Analytics.

Table 2: Items that will basically be maintained after migration

・Log Analytics workspace
　- Concept after migration: Continue to use as the foundation for raw data storage

・Existing data connectors
　- Concept after migration: Continue basic data collection

・KQL
　- Concept after migration: Existing queries can continue to be used. However, check for some table differences

・Analytics rules
　- Concept after migration: Can be created, updated, and managed in the Defender portal

・Automation rules
　- Concept after migration: Can continue to be used. However, conditions, delays, and constraints need to be checked

・Logic Apps playbooks
　- Concept after migration: Can continue to be used. However, re-check execution paths, etc.

・Azure Workbooks
　- Concept after migration: Can also be used as a primary visualization tool in the Defender portal

・Log Analytics retention settings
　- Concept after migration: Continue settings at the workspace and table level

Azure Workbooks can also continue to be used as a primary visualization and reporting tool in the Defender portal.

What is important is the point that:

Not everything needs to be recreated, but the operational results are not necessarily the same.

This is the point.

3. Is 'It's an East Japan workspace, so everything is within Japan' accurate?

This time, what legal, privacy, and audit personnel should check in particular is data residency.

There are likely many organizations that have explained it as follows in the past:

Since our company's Microsoft Sentinel uses a Log Analytics workspace in the East Japan region, all logs are stored and processed within Japan.

However, in Microsoft's current official documentation, data handled by Microsoft Sentinel is divided into the following three types.

・Raw data
　- Example: Events and logs collected from connected services and devices

・Processed data
　- Example: Incidents, alerts

・Configuration data
　- Example: Data connector settings, analytics rules, various configurations

Table 3: Organization of storage and processing locations based on official Microsoft documentation

・Storage of raw data
　- Storage/Processing location: Same region as the Log Analytics workspace associated with Microsoft Sentinel

・Processing of raw data
　- Storage/Processing location: For Europe, Israel, and China 21Vianet, it is each respective region. It is stated that for other workspaces, processing occurs in the US region.

・Processed and configuration data when not connected to the Defender portal
　- Storage/Processing location: Stored and processed based on the same logic as raw data

・Processed and configuration data after connecting to the Defender portal
　- Storage/Processing location: May be stored and processed in the Microsoft Defender XDR region

Official Microsoft documentation explains that while raw data in a Japan East Log Analytics workspace is stored in the same Japan East region, customer data in workspaces located outside of Europe, Israel, and China 21Vianet is processed in the US region.

Additionally, when Microsoft Sentinel is onboarded to the Defender portal, processed data and configuration data may be stored and processed in the Microsoft Defender XDR region.

Figure 2: Thinking about 'storage' and 'processing' separately

Factory/Server/Cloud/Microsoft 365
　　　　　　　│
　　　　　　　│ Raw logs
　　　　　　　↓
┌───────────────────────────┐
│ Log Analytics Workspace │
│ Example: Japan East │
│ │
│ Raw data storage: Same region as workspace│
└───────────────────────────┘
　　　　　　　│
　　　　　　　│ Analysis/Correlation/Incident generation
　　　　　　　↓
┌───────────────────────────┐
│ Microsoft Sentinel │
│ ・Alerts │
│ ・Incidents │
│ ・Analytics rules │
│ ・Connector settings │
└───────────────────────────┘
　　　　　　　│
　　　　　　　│ Onboard to Defender portal
　　　　　　　↓
┌───────────────────────────┐
│ Microsoft Defender XDR Region │
│ ・Processed data │
│ ・Configuration data │
│ May be stored and processed │
└───────────────────────────┘

Therefore, the question to confirm is not just,

'Where is the Log Analytics workspace located?'

It is also necessary to ask the following questions.

The following questions are also necessary.

① Where is raw data stored?
② Where is raw data processed?
③ Where are alerts and incidents stored?
④ Where are rules and connector settings processed?
⑤ Which region is the Defender XDR tenant in?
⑥ Which Microsoft services is Sentinel data shared with?

4. Check the Defender XDR region in the actual tenant

The geographic region of Microsoft Defender XDR can be checked in the following location in the Microsoft Defender portal.

Microsoft Defender portal
　　　↓
Settings
　　　↓
Microsoft Defender XDR
　　　↓
Account

Microsoft's official documentation states that after a Microsoft Defender XDR tenant is created, it cannot be moved to another region. Data for integrated services may be stored not only in the location of the original service but also in the region specified by the storage rules of the integrated service where the data is shared.

Table 4: Template for Data Location Explanation Table

・Log Analytics Workspace
　- Confirmation result: East Japan / West Japan / Other
　- Confirmation evidence: Workspace overview screen

・Sentinel raw data storage
　- Confirmation result: Same region as the workspace
　- Confirmation evidence: Microsoft official documentation

・Sentinel raw data processing
　- Confirmation result: Check regional classification in official documentation
　- Confirmation evidence: Microsoft official documentation

・Defender XDR region
　- Confirmation result: State the actual tenant display
　- Confirmation evidence: Defender XDR account screen

・Sentinel processed data
　- Confirmation result: Possibility of being processed in the XDR region
　- Confirmation evidence: Migration/location documentation

・Sentinel configuration data
　- Confirmation result: Possibility of being processed in the XDR region
　- Confirmation evidence: Migration/location documentation

・Sentinel Data Lake
　- Confirmation result: Same region as the primary workspace
　- Confirmation evidence: Data Lake settings

・External SOC/ITSM
　- Confirmation result: Storage region of the outsourced system
　- Confirmation evidence: Contract/service specifications

・Long-term storage destination
　- Confirmation result: Storage, Sentinel, external SIEM, etc.
　- Confirmation evidence: Retention settings screen

Poor explanation

Since Microsoft Sentinel is built in the East Japan region, all data is located within Japan.

Improved explanation example

Our company's Microsoft Sentinel raw data is stored in the Log Analytics workspace in the East Japan region.

On the other hand, according to official Microsoft Sentinel specifications, the location for raw data processing, processed data such as incidents and alerts, and configuration data such as analytics rules and connectors may differ from the storage location.

After onboarding Microsoft Sentinel to the Defender portal, processed data and configuration data may be stored and processed in the Microsoft Defender XDR region. Our company's Defender XDR region is [Confirmation Result].

With this phrasing,

storage
processing
raw data
processed data
configuration data

can be explained without confusion.

5. Retention periods are not uniform

Microsoft Defender XDR data is generally retained for 180 days, during which time it is visible throughout the Microsoft Defender portal.

In advanced hunting, you can typically access 30 days of data, unless you are using longer-term data via Microsoft Sentinel. Additionally, there is an exception for cases, which are not deleted.

Table 5: Checking retention periods separately

- Raw logs in Log Analytics
- Main retention setting: Based on workspace/table settings

- Sentinel Data Lake
- Main retention setting: Based on Data Lake settings

- Defender XDR data
- Main retention setting: Generally 180 days

- Defender XDR advanced hunting
- Main retention setting: Generally 30 days

- Defender XDR cases
- Main retention setting: Exception exists where they are not deleted

- Sentinel incidents
- Main retention setting: Check the portal used and integration status

- Microsoft Sentinel archive
- Main retention setting: Based on Log Analytics settings

- Logic Apps execution history
- Main retention setting: Based on Logic Apps settings

- Tickets such as ServiceNow
- Main retention setting: Based on external system settings

- Work records from SOC contractors
- Main retention setting: Based on outsourcing contracts and contractor environments

On a business partner checklist,

if you simply answer that the security log retention period is 180 days,

it is unclear which logs that 180-day period refers to.

You must specify the type of data as follows:

- Raw logs
- Alerts
- Incidents
- Advanced hunting data
- Cases
- Playbook execution history
- External tickets
- Evidence files

6. Companies using CMK need to be especially careful

Organizations using Customer Managed Keys (CMK) must also verify the scope of encryption after the migration.

According to official Microsoft documentation, if CMK is enabled before onboarding to the Defender portal, existing and new log data within the workspace will continue to be encrypted with CMK.

Sentinel content such as analytics rules and automation rules will also be encrypted with CMK.

However, it is explained that alerts and incidents after onboarding will no longer be encrypted with CMK.

Table 6: Scope of CMK application

・Existing logs in the workspace
　- After connecting to the Defender portal: CMK encryption continues

・Newly ingested logs
　- After connecting to the Defender portal: CMK encryption continues

・Analytics rules
　- After connecting to the Defender portal: CMK encryption continues

・Sentinel content such as automation rules
　- After connecting to the Defender portal: CMK encryption continues

・Alerts
　- After connecting to the Defender portal: No longer subject to CMK encryption

・Incidents
　- After connecting to the Defender portal: No longer subject to CMK encryption

・Some data within the Sentinel Data Lake
　- After connecting to the Defender portal: CMK is not fully supported; Microsoft-managed keys are used

Figure 3: 'Just because logs are CMK, doesn't mean everything is CMK'

【Log Analytics】
Raw logs
Data for analysis
　　　│
　　　└──CMK continues

【Microsoft Sentinel content】
Analytics rules
Automation rules
　　　│
　　　└──CMK continues

【Microsoft Defender XDR side】
Alerts
Incidents
　　　│
　　　└──Not subject to CMK after onboarding

If you have explained in audit responses or internal policies that:

All Sentinel data is encrypted with our company-managed encryption keys

then you need to review the content.

7. The 'incidents' viewed by the SOC will no longer be the same

In the Defender portal, incidents from Microsoft Sentinel and Microsoft Defender XDR are aggregated into a unified incident queue.

Microsoft explicitly states that SOC triage procedures will need to be updated and analysts may require retraining. In the unified queue, alerts from endpoints, identities, email, cloud, and third-party logs are correlated across products.

Figure 4: Incident management before and after migration

[Before]

Defender for Endpoint
↓
Defender XDR Incident

Microsoft Sentinel Analytics Rules
↓
Sentinel Incident

Cloud/NW/External Products
↓
Sentinel Incident

[After]

Endpoint ─┐
Identity ─┤
Email ────┤
Cloud ────┤
External Logs ─┤
Sentinel Analytics Rules ─┘
↓
Defender XDR Correlation Engine
↓
Unified Incident Queue

Consolidation makes it easier to grasp the entire attack.

On the other hand, because incidents that were previously separate are now combined into one, or incident names are changed, existing procedures and automated processes may not necessarily work as they did before.

8. Major incident specification changes due to migration

Microsoft's official migration documentation provides guidance on multiple changes regarding analytics rules, incident correlation, automation, playbooks, comments, API integration, and more.

Table 7: Major changes affecting SOC procedures

・Incident correlation
- Major impact after migration: Defender XDR's internal correlation logic controls incident unification

・Incident name
- Major impact after migration: Existing incident names may be changed due to correlation

・Provider name
- Major impact after migration: In principle, this will be Microsoft XDR in the Defender portal

・Fusion
- Major impact after migration: Fusion analytics rules in the Azure portal will be disabled and replaced by XDR correlation features

・Alert-only analytics rules
- Major impact after migration: If incident creation is disabled, they will not appear in the Defender portal

・Incident creation rules
- Major impact after migration: Microsoft security incident creation rules will be deactivated

・Manual/API created incidents
　- Main impact after migration: Some incidents created manually, via API, or by Logic Apps in Sentinel will not be synchronized to the Defender portal

・Comment editing
　- Main impact after migration: The Defender portal does not support editing existing comments

・Closed incidents
　- Main impact after migration: Incidents may not be reopened under the same conditions as before even if new alerts are added

・Automation execution
　- Main impact after migration: Delays may occur in incident synchronization or rule execution

・Manual playbooks
　- Main impact after migration: Some operations are not supported for manual execution from alerts or entities

・Hunting
　- Main impact after migration: Bookmarks cannot be used in Advanced Hunting; use the Sentinel hunting screen instead

・IdentityInfo
　- Main impact after migration: There are schema differences between Advanced Hunting and Log Analytics, requiring query verification

9. Automation based on "Incident Name" is dangerous

In the Defender portal, the Defender XDR correlation engine creates incidents and names them automatically.

For this reason, automation rules based on incident titles may not function as expected after migration.

Microsoft recommends using the analytics rule name or tags that generated the alerts within the incident, rather than basing it on the incident name.

Common traditional design

Incident name contains
"Suspicious administrator login"
　　　↓
Create emergency ticket in ServiceNow
　　　↓
Phone notification to SOC manager

Recommended review

Analytics rule ID
　　　＋
Analytics rule name
　　　＋
Tags
　　　＋
Severity
　　　＋
Target asset classification
　　　↓
Create emergency ticket in ServiceNow

Table 8 Automation Rule Checklist

・Incident title
　- Verification item: Is it being used as a condition?

・Provider name
　- Verification item: Is it hardcoded to Azure Sentinel, etc.?

・Incident provider condition
　- Verification item: Will it be affected by deprecation or changes?

・Description field
　- Verification item: Is it being used as a condition?

・Updated-by field
　- Verification: Does it correspond to the value after migration?

・Alert rule name
　- Verification: Can it still be uniquely identified after migration?

・Tags
　- Verification: Are tags that can be used for automation logic attached?

・Synchronization delay
　- Verification: Is it not based on the assumption of immediate execution?

・Playbook execution
　- Verification: From where (alert, entity, or incident) will it be executed?

・External ITSM
　- Verification: Does it support changes to URL, ID, and ProviderName?

10. Is the procedure designed assuming a maximum delay of 10 minutes?

Microsoft's official documentation states that it may take up to approximately 10 minutes from the time an incident is created or updated in the Defender portal until the automation rule is executed on the Microsoft Sentinel side.

Additionally, it may take up to 5 minutes for a Microsoft Defender incident to appear in Microsoft Sentinel, and playbook triggers may also be delayed.

Figure 5: From incident occurrence to automated processing

Alert occurrence
　　↓
Correlation in Defender XDR
　　↓
Create unified incident
　　↓
Sync to Microsoft Sentinel
　　↓
Evaluate automation rules
　　↓
Execute Logic Apps playbook
　　↓
Notify ServiceNow, Teams, email, etc.

This path may include time lags for synchronization and evaluation.

Therefore, the following designs require re-verification:

・SLA is set to notify within 1 minute of alert occurrence
　- Review item: Measure actual performance and separate service specifications from SLA

・Treated as a failure if no notification within 5 minutes
　- Review item: Consider Defender/Sentinel synchronization delay

・Assumption that the SOC can execute playbooks immediately
　- Review item: Check incident synchronization status

・Automated ticket creation based on incident title
　- Review item: Change to analytics rule ID or tags

・Sending update notifications to the same incident multiple times
　- Review item: Check aggregation behavior of update events

11. Also verify ServiceNow and external ITSM integration

If you are integrating with Microsoft Graph or external ITSM, you need to check not only the screens but also the fields in the API responses.

Microsoft's official migration documentation shows the providerIncidentUrl, which links directly to incidents in the Defender portal, in addition to the incidentUrl for the Azure portal.

Also, the provider name changes from Azure Sentinel in the Azure portal era to Microsoft XDR in the Defender portal.

Table 9: ITSM Integration Checklist Items

・Incident URL
- Verification: Is it still the old URL pointing to the Azure portal?

・providerIncidentUrl
- Verification: Will it be used for links to the Defender portal?

・providerName
- Verification: Is it hardcoded to Azure Sentinel?

・serviceSource
- Verification: Will it be used to identify the originating service?

・detectionSource
- Verification: Will the detection source be recorded in the ticket?

・productName
- Verification: Will it be used for product-based assignment?

・Incident Name
- Verification: Is it being used as a unique key?

・Incident ID
- Verification: Can it map between the Sentinel side and the XDR side?

・Description Field
- Verification: Have you checked for cases where it is not displayed in external tickets?

・Comments
- Verification: Have you considered editing and synchronization restrictions?

Potential issues during an incident

Critical incident in Defender portal
↓
ServiceNow integration condition is
ProviderName = Azure Sentinel
remains as is
↓
Does not match condition
↓
Ticket is not created
↓
SOC contractor is not notified

In portal migration testing, it is necessary to not only view alerts on the screen but also verify that external tickets are correctly created and assigned to the right personnel.

12. Do I only need to look at Azure RBAC for permissions?

Azure RBAC continues to be used in Microsoft Sentinel.

Representative roles include the following:

・Microsoft Sentinel Reader
- Main permissions: View data, incidents, workbooks, etc.

・Microsoft Sentinel Responder
- Main permissions: Incident management in addition to read permissions

・Microsoft Sentinel Contributor
- Main permissions: Creation and editing of rules, solutions, etc.

・Microsoft Sentinel Playbook Operator
- Main permissions: Listing, viewing, and manual execution of playbooks

・Microsoft Sentinel Automation Contributor
- Main permissions: Enabling automation rules to use playbooks

Microsoft recommends using the least privileged roles possible and limiting Global Administrator access to emergencies and similar situations.

Meanwhile, in the Defender portal, Microsoft Defender XDR integrated RBAC is also relevant.

Figure 6 Two-layer permission management

【Azure RBAC】
・Log Analytics workspace
・Microsoft Sentinel
・Analytics rules
・Automation rules
・Azure resources
　　　　│
　　　　│ Check both
　　　　↓
【Defender XDR integrated RBAC】
・Unified incidents
・Alerts
・Advanced hunting
・Defender XDR data
・Sentinel scope

Table 10 Permission verification table during migration

・Onboard Sentinel workspace
- Permissions to check: Subscription Owner or User Access Administrator, Sentinel Contributor, etc.

・View Sentinel data
- Permissions to check: Azure RBAC Sentinel Reader, etc.

・Incident response
- Permissions to check: Sentinel Responder, Defender XDR side permissions

・Change analytics rules
- Permissions to check: Sentinel Contributor

・Execute playbooks
- Permissions to check: Sentinel Playbook Operator, Logic Apps permissions

・View Defender XDR incidents
- Permissions to check: Defender XDR integrated RBAC

・Create Sentinel scope
- Permissions to check: Defender XDR integrated RBAC management permissions, etc.

・Change data collection rules
- Permissions to check: DCR write permissions on the Azure side

・MSSP cross-tenant access
- Permissions to check: Lighthouse, B2B, multi-tenant portal, etc.

・View audit logs
- Permissions to check: Read-only roles and target scope

Even when connecting Microsoft Sentinel to the Defender portal, you use existing Azure RBAC permissions to view and operate accessible Sentinel features and workspaces. On the other hand, in configurations where integrated RBAC is enabled, you must also check the roles and scopes on the Defender side.

13. "Being able to view" and "being in charge" are different

Granting a SOC service provider access to the Defender portal does not automatically grant them the following permissions:

・Permission to modify analytics rules
・Permission to modify data connectors
・Permission to modify playbooks
・Permission to isolate Azure resources
・Permission to disable users
・Permission to network-isolate devices
・Permission to close incidents
・Permission to submit evidence externally

Conversely, even if they technically have the permission to close an incident, there may be cases where customer approval is required by contract.

Table 11: Technical permissions and contractual scope of work

・Viewing alerts
　- Technically possible: Yes/No
　- Contractually permitted: Yes/No
　- Final approver: SOC Manager

・Changing incident assignee
　- Technically possible: Yes/No
　- Contractually permitted: Yes/No
　- Final approver: IT Department

・Closing incidents
　- Technically possible: Yes/No
　- Contractually permitted: Yes/No
　- Final approver: IT Department/Business Manager

・Executing playbooks
　- Technically possible: Yes/No
　- Contractually permitted: Yes/No
　- Final approver: Security Manager

・Device isolation
　- Technically possible: Yes/No
　- Contractually permitted: Yes/No
　- Final approver: IT Department

・Disabling users
　- Technically possible: Yes/No
　- Contractually permitted: Yes/No
　- Final approver: ID Management Manager

・Firewall changes
　- Technically possible: Yes/No
　- Contractually permitted: Yes/No
　- Final approver: Network Manager

・Evidence download
　- Technically possible: Yes/No
　- Contractually permitted: Yes/No
　- Final approver: Legal/Information Management

・Submitting files to Microsoft
　- Technically possible: Yes/No
　- Contractually permitted: Yes/No
　- Final approver: Security Manager

・Reporting critical issues to management
　- Technically possible: -
　- Contractually permitted: Yes/No
　- Final approver: CISO/Management

14. For SOCs with multiple workspaces, check the "Primary"

In the Defender portal, you can connect one primary workspace and multiple secondary workspaces.

Users with access to the primary workspace can read and manage workspace and Defender XDR data.

For secondary workspaces, you can read and manage workspace data, but Defender XDR incidents and alerts are not synchronized.

Additionally, in a multi-workspace environment, only alerts from the primary workspace are correlated with Defender XDR data.

Figure 7: Differences between multiple workspaces

Microsoft Defender XDR
│
│ Correlation/Synchronization
↓
┌──────────────────┐
│ Primary Workspace │
└──────────────────┘
↑
│
│ Integration with Defender XDR
│
┌─────────────┴─────────────┐
↓ ↓
┌──────────────┐ ┌──────────────┐
│ Secondary WS A │ │ Secondary WS B │
│ Factory/Domestic Site │ │ Overseas Site │
└──────────────┘ └──────────────┘
Workspace data Workspace data
can be referenced/managed can be referenced/managed
No XDR incident sync No XDR incident sync

Items to confirm for multiple sites/MSSP

・Primary workspace
- Content: Which workspace to specify

・Data correlation scope
- Content: Which site's alerts are correlated with XDR

・Role of secondary
- Content: Reference/analysis only, or continue individual operations

・MSSP access
- Content: Authentication/permissions per tenant

・Azure Lighthouse
- Content: Features to continue using and constraints

・Multi-tenant portal
- Content: Screens used by MSSP and scope of work

・Incident ID
- Content: Identification method per customer/workspace

・Reporting unit
- Content: Tenant, corporation, site, factory, subsidiary

・Data location
- Content: Each workspace and XDR region

・Cost allocation
- Content: Organization by workspace, data volume, and site

15. Also be aware of IdentityInfo access control

When Microsoft Sentinel is onboarded to the Defender portal, the IdentityInfo table can be used from Advanced Hunting in a form that integrates both Defender XDR and Sentinel.

However, since there are differences in field names and supported items between the Log Analytics side and the Advanced Hunting side, you need to check and update the KQL or custom detections executed on the Defender side.

Furthermore, when migrating to the Defender portal, IdentityInfo becomes a native Defender table and does not support table-level RBAC. If you are restricting access to IdentityInfo at the table level in the Azure portal, you will no longer be able to use that control as is.

Table 12: IdentityInfo checklist

・Existing KQL
- Confirmation content: Can it be executed normally in Advanced Hunting?

・Field name
- Confirmation content: Are there any differences from the Log Analytics version?

・Custom detection
　- Verification: Does it support the Defender table?

・Access restrictions
　- Verification: Are you using table-level RBAC?

・Personal information
　- Verification: Scope of access to names, emails, departments, etc.

・External SOC
　- Verification: Can the contractor view all IdentityInfo?

・Sentinel scope
　- Verification: Will you use row-level restrictions?

・Audit trail
　- Verification: Have you recorded the permission assignments and test results?

16. The data connector screen may not be the same

Data collection via existing connectors will continue even after onboarding to the Defender portal.

However, official Microsoft migration documentation states that the following Microsoft connectors will not appear on the data connectors page of the Defender portal.

Microsoft Defender for Cloud Apps
Microsoft Defender for Endpoint
Microsoft Defender for Identity
Microsoft Defender for Office 365
Microsoft Defender XDR
Some Microsoft Defender for Cloud connectors

These are used for unified security operations, but according to current official documentation, they will continue to be displayed in Microsoft Sentinel in the Azure portal.

Since Sentinel usage in the Azure portal will not be supported after March 31, 2027, you must verify in advance in your actual tenant where to perform connector status checks, configuration changes, and troubleshooting.

Table 13: Checklist for connector operational procedures

・Connector status check
　- Current procedure: Sentinel in Azure portal
　- Post-migration procedure: Defender portal or individual product settings

・Defender XDR connection check
　- Current procedure: Sentinel data connector
　- Post-migration procedure: Check Defender integration status

・Defender for Cloud
　- Current procedure: Subscription/tenant connector
　- Post-migration procedure: Re-verify, including duplicate alerts

・Microsoft 365 series
　- Current procedure: Individual connector screen
　- Post-migration procedure: Check connection status after XDR integration

・Connection failure audit trail
　- Current procedure: Azure portal screenshots
　- Post-migration procedure: Change to Defender portal or similar audit trails

・Contractor tasks
　- Current procedure: Include Azure portal operations in the contract
　- Post-migration procedure: Revise to Defender portal operations

17. Which parts of the SOC operational procedures should be rewritten?

Table 14: Main procedures subject to revision

・SOC primary response procedure
- Main revision areas: Incident queue, filters, assignee settings

・Alert investigation procedure
- Main revision areas: Defender XDR correlation, product names, detection sources

・Incident closure procedure
- Main revision areas: Closure reasons, re-opening, comments

・Hunting procedure
- Main revision areas: Advanced Hunting, Sentinel Hunting, bookmarks

・Playbook execution procedure
- Main revision areas: Execution location, synchronization delays, permissions

・Automation rule management procedure
- Main revision areas: Title conditions, ProviderName, tags

・Data connector verification procedure
- Main revision areas: Display location, connection status, duplicate prevention

・Evidence collection procedure
- Main revision areas: Screens, URLs, incident IDs, timestamps

・ITSM integration procedure
- Main revision areas: providerIncidentUrl, API fields

・Access request procedure
- Main revision areas: Azure RBAC, Defender XDR integrated RBAC

・MSSP operational procedure
- Main revision areas: Multi-tenant/primary workspace

・Data residency documentation
- Main revision areas: Storage and processing locations for Sentinel and XDR

・CMK explanatory materials
- Main revision areas: Encryption scope for alerts and incidents

・BCP/DR procedures
- Main revision areas: Alternative verification during Defender portal outages

・Training materials
- Main revision areas: New menus, triage, correlation models

18. "Evidence collection procedure" requires more than just screen captures

If you are using screen captures as evidence for audits or incident reports, please note that screen layouts and displayed items will change after the portal migration.

Additionally, due to Defender XDR correlation, multiple alerts may be consolidated into a single incident.

Therefore, evidence must include the following identification information.

Table 15: Evidence acquisition items after migration

・Defender Incident ID
- Content: Unique identifier on the Defender XDR side

・Sentinel Incident ID
- Content: Identifier on the Sentinel side

・Provider Name
- Content: Microsoft XDR, etc.

・Product Name
- Content: Endpoint, Identity, Cloud, Sentinel, etc.

・Detection Source
- Content: Detection technology/sensor

・Analytics Rule ID
- Content: Association with Sentinel analytics rules

・Workspace
- Content: Distinction between primary and secondary

・Tenant ID
- Content: Identification for MSSP/multiple corporations

・Occurrence Date and Time
- Content: Both UTC and Japan Standard Time

・Update Date and Time
- Content: Time of correlation/additional alerts

・Person in Charge
- Content: Who handled the incident

・Status/Reason for Closure
- Content: Record before and after changes

・Comment
- Content: Content, creator, and editing restrictions

・Playbook
- Content: Execution ID, result, and execution time

・External Ticket
- Content: ServiceNow number, etc.

・Acquirer
- Content: Who acquired the evidence

・Hash, etc.
- Content: Integrity information when preserving as a file

Figure 8: Recommended evidence association

Defender Incident ID
　　　　│
　　　　├─Sentinel Incident ID
　　　　├─Alert ID
　　　　├─Analytics Rule ID
　　　　├─Workspace ID
　　　　├─External Ticket Number
　　　　├─Playbook Execution ID
　　　　└─Evidence File Management Number

19. Items to review in outsourcing contracts and SOC contracts

This migration does not automatically increase or decrease the work performed by the outsourcing partner.

However, because the actual operation screens, required permissions, incident units, and data viewing scope will change, the work descriptions in the contract may no longer match reality.

Table 16: Items to confirm with the outsourcing partner

・Usage portal
- Confirmation item: Azure portal or Defender portal

・Target tenant
- Confirmation item: Which Microsoft Entra tenant

・Target workspace
- Confirmation item: Scope of primary and secondary

・Data viewed
- Confirmation item: Sentinel only or entire XDR

・Incidents handled
- Confirmation item: Sentinel-derived only or entire integrated incidents

・Initial response
- Confirmation item: Verification, classification, assignment, comments

・Closure authority
- Confirmation item: Can the outsourcing partner close incidents?

・Automated response
- Confirmation item: Can they execute playbooks?

・Remediation authority
- Confirmation item: Can they perform device isolation, user disabling, etc.?

・Evidence collection
- Confirmation item: What to save and in what format

・Data storage
- Confirmation item: Will the outsourcing partner copy data to their own environment?

・ITSM
- Confirmation item: Which ticketing system to use

・Emergency contact
- Confirmation item: Contact method in case of Defender portal failure

・Training
- Confirmation item: Who bears the cost of training for the new portal

・Migration work
- Confirmation item: Responsibility for configuration changes, testing, and manual revisions

・Migration completion judgment
- Confirmation item: Who approves the acceptance

Example of wording in outsourcing agreements

Before revision

The contractor shall monitor incidents displayed in Microsoft Sentinel on the Azure portal.

Example of organization after revision

The contractor shall monitor the unified incident queue on the Microsoft Defender portal and perform initial assessment, personnel assignment, comment recording, and escalation in accordance with the target tenants, target workspaces, target products, and scope of authority specified in the appendix.

Device isolation, user disabling, incident closure, playbook execution, and other remediation operations shall follow the approval categories in the appendix.

This is a general example of how to organize the terms.

Legal judgments regarding actual contract clauses, responsibilities, damages, sub-contracting, etc., must be confirmed with appropriate experts such as lawyers according to the specific case.

20. RACI matrix during migration

The following is a general example.

It must be adjusted according to the organizational structure and the scope of outsourcing.

Table 17: RACI for migration project

・Approval of migration policy
　- Management/CISO: A
　- IT Dept: R
　- Sentinel Lead: C
　- SOC: C
　- Legal/Personal Info: C
　- Contractor/MSSP: I

・Inventory of current environment
　- Management/CISO: I
　- IT Dept: A
　- Sentinel Lead: R
　- SOC: C
　- Legal/Personal Info: I
　- Contractor/MSSP: C

・Confirmation of data location
　- Management/CISO: I
　- IT Dept: R
　- Sentinel Lead: R
　- SOC: C
　- Legal/Personal Info: A
　- Contractor/MSSP: C

・Confirmation of Defender XDR region
　- Management/CISO: I
　- IT Dept: A
　- Sentinel Lead: R
　- SOC: C
　- Legal/Personal Info: C
　- Contractor/MSSP: I

・Workspace design
　- Management/CISO: I
　- IT Dept: A
　- Sentinel Lead: R
　- SOC: C
　- Legal/Personal Info: I
　- Contractor/MSSP: C

・Determination of primary WS
　- Management/CISO: A
　- IT Dept: R
　- Sentinel Lead: R
　- SOC: C
　- Legal/Personal Info: I
　- Contractor/MSSP: C

・Confirmation of Azure RBAC
　- Management/CISO: I
　- IT Dept: A
　- Sentinel Lead: R
　- SOC: C
　- Legal/Personal Info: I
　- Contractor/MSSP: C

・Confirmation of Defender XDR RBAC
　- Management/CISO: I
　- IT Dept: A
　- Sentinel Lead: R
　- SOC: R
　- Legal/Personal Info: C
　- Contractor/MSSP: C

・Onboarding tasks
　- Management/CISO: I
　- IT Department: A
　- Sentinel Lead: R
　- SOC: C
　- Legal/Personal Information: I
　- Outsourced Provider/MSSP: C

・Analytics rule testing
　- Management/CISO: I
　- IT Department: C
　- Sentinel Lead: A/R
　- SOC: R
　- Legal/Personal Information: I
　- Outsourced Provider/MSSP: C

・Automation testing
　- Management/CISO: I
　- IT Department: C
　- Sentinel Lead: A/R
　- SOC: R
　- Legal/Personal Information: I
　- Outsourced Provider/MSSP: C

・ITSM integration testing
　- Management/CISO: I
　- IT Department: A
　- Sentinel Lead: R
　- SOC: R
　- Legal/Personal Information: I
　- Outsourced Provider/MSSP: C

・SOC procedure manual update
　- Management/CISO: I
　- IT Department: C
　- Sentinel Lead: C
　- SOC: A/R
　- Legal/Personal Information: C
　- Outsourced Provider/MSSP: R

・Data location documentation
　- Management/CISO: I
　- IT Department: C
　- Sentinel Lead: C
　- SOC: I
　- Legal/Personal Information: A/R
　- Outsourced Provider/MSSP: C

・Outsourcing scope definition
　- Management/CISO: I
　- IT Department: C
　- Sentinel Lead: C
　- SOC: C
　- Legal/Personal Information: R
　- Outsourced Provider/MSSP: A/C

・Analyst training
　- Management/CISO: I
　- IT Department: C
　- Sentinel Lead: C
　- SOC: A
　- Legal/Personal Information: I
　- Outsourced Provider/MSSP: R

・Tabletop exercise
　- Management/CISO: I
　- IT Department: A
　- Sentinel Lead: R
　- SOC: R
　- Legal/Personal Information: C
　- Outsourced Provider/MSSP: R

・Production migration approval
　- Management/CISO: A
　- IT Department: R
　- Sentinel Lead: C
　- SOC: C
　- Legal/Personal Information: C
　- Outsourced Provider/MSSP: I

Legend

・R
　- Meaning: Responsible for executing the task

・A
　- Meaning: Final approval/Accountable

・C
　- Meaning: Consulted

・I
　- Meaning: Informed

21. Do not determine migration completion by "Connected" status

Even if the workspace is displayed as "Connected" in the Defender portal, it does not necessarily mean that the operational migration is complete.

Table 18 Migration Completion Checklist

・Connected workspace to Defender portal
　- Completed/Not Completed:

・Recorded Defender XDR region
　- Completed/Not Completed:

Organized raw data, processed data, and configuration data
- Completed/Incomplete:

Confirmed the scope of CMK application
- Completed/Incomplete:

Determined the primary workspace
- Completed/Incomplete:

Confirmed Azure RBAC
- Completed/Incomplete:

Confirmed Defender XDR integrated RBAC
- Completed/Incomplete:

Tested permissions for the SOC contractor
- Completed/Incomplete:

Confirmed the display of integrated incidents
- Completed/Incomplete:

Tested incident correlation
- Completed/Incomplete:

Confirmed alert-only analytics rules
- Completed/Incomplete:

Confirmed alternative behavior for Fusion
- Completed/Incomplete:

Tested all automation rules
- Completed/Incomplete:

Tested all playbooks
- Completed/Incomplete:

Tested ITSM/ServiceNow integration
- Completed/Incomplete:

Confirmed changes to API fields
- Completed/Incomplete:

Confirmed KQL and custom detections
- Completed/Incomplete:

Confirmed permissions and schema for IdentityInfo
- Completed/Incomplete:

Revised audit trail acquisition procedures
- Completed/Incomplete:

Revised SOC operational manuals
- Completed/Incomplete:

Revised the division of responsibilities with the contractor
- Completed/Incomplete:

Revised responses for the business partner checklist
- Completed/Incomplete:

・Completed analyst training
　- Completed/Incomplete:

・Completed tabletop exercise
　- Completed/Incomplete:

・Recorded production acceptance approval
　- Completed/Incomplete:

22. Migration roadmap until March 31, 2027

Table 19 Recommended roadmap

・July - September 2026
　- Implementation details: Inventory of current Sentinel, XDR, SOC, and outsourced vendors
　- Deliverables: Migration impact survey table

・September - October 2026
　- Implementation details: Confirmation of data residency, CMK, retention period, and workspace configuration
　- Deliverables: Data residency explanation table

・October - November 2026
　- Implementation details: Verification onboarding to Defender portal
　- Deliverables: Verification records

・November - December 2026
　- Implementation details: Analytics rules, automation, playbooks, ITSM testing
　- Deliverables: Test results table

・January 2027
　- Implementation details: Revision of permissions, RACI, and scope of outsourcing
　- Deliverables: Permissions table, RACI

・January - February 2027
　- Implementation details: Update SOC procedures, audit trail procedures, and training materials
　- Deliverables: Revised procedures

・February 2027
　- Implementation details: SOC analyst training, tabletop exercise
　- Deliverables: Training and exercise records

・First half of March 2027
　- Implementation details: Production migration, acceptance testing
　- Deliverables: Acceptance confirmation document

・Mid-March 2027
　- Implementation details: Discontinuation of old procedures, final audit
　- Deliverables: Migration completion report

・March 31, 2027
　- Implementation details: Azure portal support end deadline
　- Deliverables: Consolidation to Defender portal operations

Figure 9 Migration priority

Highest priority
　│
　├─Incident response
　├─Automation/Playbooks
　├─ITSM/Emergency notifications
　├─Permissions
　└─Data residency
　　　↓
Next to implement
　│
　├─Procedures
　├─Audit trails
　├─Contracts/Responsibility boundaries
　└─Training
　　　↓
Final confirmation
　│
　├─Screen layout
　├─Dashboards
　└─User usability

It is important to prioritize checking operations that could lead to incidents if they stop, rather than starting with the screen appearance.

23. Self-check for IT, SOC, and Legal departments

Table 20 Sentinel migration checklist

・Does management understand the March 31, 2027 deadline?
　- Yes/No:

・Do you know who is currently using the Azure portal?
　- Yes/No:

・Do you know the onboarding status for the Defender portal?
　- Yes/No:

・Have you confirmed the Defender XDR region?
　- Yes/No:

・Can you explain the separation between raw data storage and processing locations?
　- Yes/No:

・Have you organized the locations of processed data and configuration data?
　- Yes/No:

・Do you understand the changes to the CMK application scope?
　- Yes/No:

・Do you know your primary workspace?
　- Yes/No:

・Do you understand the limitations of the secondary workspace?
　- Yes/No:

・Have you listed the Azure RBAC and Defender XDR RBAC?
　- Yes/No:

・Have you tested the access scope for your SOC contractor?
　- Yes/No:

・Have you confirmed the correlation behavior of integrated incidents?
　- Yes/No:

・Are there no automations based on incident names?
　- Yes/No:

・Are there no integrations with hardcoded ProviderNames?
　- Yes/No:

・Have you tested playbook synchronization delays?
　- Yes/No:

・Have you tested integrations such as ServiceNow?
　- Yes/No:

・Have you confirmed access control for IdentityInfo?
　- Yes/No:

・Have you revised the SOC procedures for the Defender portal?
　- Yes/No:

・Have you revised the audit trail acquisition procedures?
　- Yes/No:

・Have you revised the division of responsibilities with the contractor?
　- Yes/No:

・Revised the business partner checklist
　- Yes/No:

・Conducted analyst training
　- Yes/No:

・Have acceptance criteria after production migration
　- Yes/No:

Judgment guidelines

・0–7
　- Status: There is a possibility that the migration is only recognized as a screen change

・8–14
　- Status: Technical preparation is in place, but data, permissions, and outsourcing management are insufficient

・15–19
　- Status: The foundation is set. Strengthen automation, evidence, and training

・20–23
　- Status: Migration preparation is progressing. Continuous verification with actual operations is required

24. Questions to review in the business partner checklist

Table 21 Representative questions subject to review

・Where are logs stored?
　- Content to check after migration: Separate raw data, processed data, and configuration data

・Is data processed domestically?
　- Content to check after migration: Confirm processing locations for Sentinel and Defender XDR

・How many days is the retention period?
　- Content to check after migration: Separate Log Analytics, XDR, cases, and ITSM

・Is the encryption key managed by your company?
　- Content to check after migration: Confirm CMK exclusions for alerts and incidents

・Who can view the logs?
　- Content to check after migration: Confirm Azure RBAC, XDR RBAC, and MSSP

・Does the contractor store data?
　- Content to check after migration: Confirm external SOC, ITSM, and sub-contractors

・What is the incident response time limit?
　- Content to check after migration: Separate synchronization delays and human SLAs

・Can you submit incident evidence?
　- Content to check after migration: Link Defender, Sentinel, and ITSM IDs

・Is data deletion possible?
　- Content to check after migration: Confirm retention and deletion methods for each data type

・Is there any overseas transfer?
　- Content to check after migration: Confirm storage, processing, and sharing between Microsoft services

25. What Yamazaki Administrative Scrivener Office can support

When migrating Sentinel to the Defender portal, it is important not to separate the following two aspects.

Actual configuration of Microsoft Sentinel/Defender XDR
　　　　　　　　　　　×
SOC procedures, division of responsibilities, audit explanations, and management of outsourced vendors

Yamazaki Administrative Scrivener Office supports the creation of materials that allow IT, legal, and management teams to provide consistent explanations by organizing settings, contracts, operational rules, logs, and vendor management for Azure, Microsoft 365, Microsoft Entra ID, etc.

Table 22: Main support deliverables

・Migration impact survey
　- Content: Inventory of Azure portal-dependent screens, operations, APIs, and procedures

・Sentinel configuration organization table
　- Content: Organization of workspaces, connectors, rules, and automation

・Data location explanation table
　- Content: Organization of raw data, processed data, and configuration data

・Retention period organization table
　- Content: Retention periods for Log Analytics, XDR, cases, and external ITSM

・CMK scope table
　- Content: Organization of encryption for logs, rules, alerts, and incidents

・Role and permission table
　- Content: Visualization of Azure RBAC and Defender XDR integrated RBAC

・SOC/IT department RACI
　- Content: Division of responsibilities for detection, investigation, closure, remediation, and reporting

・Vendor responsibility division table
　- Content: Organization of work scopes for MSSP, SOC, SIer, and internal teams

・Operational manual update
　- Content: Revision for Defender portal screens and new operations

・Evidence acquisition procedure
　- Content: Methods for preserving incident IDs, screens, logs, and tickets

・ITSM integration confirmation table
　- Content: Confirmation of URLs, ProviderName, and API fields

・Migration test item table
　- Content: Testing of rules, automation, playbooks, and permissions

・Client explanation materials
　- Content: Organization of explanations regarding data location, retention periods, and outsourced vendors

・Migration completion report
　- Content: Records of tests, training, acceptance, and remaining issues

・Tabletop exercise scenario
　- Content: SOC training assuming a major incident

It is not just a matter of replacing screen screenshots.

Actual,

Log Analytics workspace region
Microsoft Defender XDR region
Primary/secondary workspace
Azure RBAC
Defender XDR integrated RBAC
Analytics rules
Automation rules
Logic Apps playbooks
ITSM integration such as ServiceNow
CMK
SOC outsourcing contracts
Existing responses to business partners

Verify these to ensure that the technical reality matches the documentation.

On March 31, 2027, it is not just the screens that will become unusable.

As Microsoft Sentinel migrates from the Azure portal to the Microsoft Defender portal, it will become possible to grasp the entire attack surface more broadly by integrating SIEM and XDR.

However, it is not just the screens that will change due to this integration.

Data storage and processing locations
Incident correlation
How alerts appear
Automation rule conditions
Playbook execution
API/ITSM fields
Permission models
CMK scope of application
MSSP scope of work
Methods for obtaining audit trails

These are what will change.

Can SOC procedures, audit trail acquisition procedures, and scopes of work in outsourcing contracts based on the Azure portal screens be used as they are?

Even if you can access the Defender portal on the deadline day,

If the SOC cannot find the correct incidents
If automation rules do not trigger
If tickets are not created in ServiceNow
If the outsourcing partner does not have the necessary permissions
If you cannot explain the data location during an audit

then the migration cannot be considered complete.

What needs to be reviewed by March 31, 2027, is not how to operate the portal.

It is to redesign the SOC operations, data explanations, permissions, and outsourcing relationships that were built around Sentinel, based on the premise of integration with Defender XDR.

That is the essence of this migration.

Technical footnotes

Footnote 1: Azure portal support deadline

After March 31, 2027, Microsoft Sentinel will no longer be supported in the Azure portal and will only be available in the Microsoft Defender portal. Azure portal users will be redirected to the Defender portal.

Footnote 2: Location of raw data and processed data

Raw data is stored in the same region as the Log Analytics workspace. However, the processing location is not necessarily the same as the storage location. Additionally, when onboarded to the Defender portal, processed data and configuration data may be stored and processed in the Defender XDR region.

Footnote 3: Defender XDR region

The geographical region for Microsoft Defender XDR can be confirmed in the account settings of the Defender portal. It is stated that it cannot be moved to a different region after creation.

Footnote 4: CMK

While logs and Sentinel content within the workspace can continue to use CMK encryption, alerts and incidents will no longer be encrypted with CMK after onboarding to the Defender portal.

Footnote 5: Responding to specification changes

Microsoft Sentinel, Microsoft Defender XDR, unified RBAC, Data Lake, and various preview features are subject to change in the future. At the time of actual migration, please re-verify Microsoft Learn, the management console, the Message Center, terms and conditions, and the displays in your actual tenant.

Notes regarding this article

This article is intended to provide general information based on official Microsoft information as of July 14, 2026.

Features, availability, storage/processing locations, retention periods, required licenses, permissions, screens, and API specifications for Microsoft Sentinel, Microsoft Defender XDR, Log Analytics, Microsoft Defender portal, etc., are subject to change.

The RACI, permission tables, contractual description examples, and migration procedures presented in this article are general templates. Adjustments are required based on individual system configurations, data, contracts, industry regulations, usage regions, and outsourcing relationships.

This article does not conclude the legality of specific cases regarding the Personal Information Protection Act, GDPR, confidentiality obligations, outsourcing contracts, etc. For individual and specific legal judgments, contract negotiations, damages, dispute resolution, or representation, you must consult with an appropriate professional such as an attorney.

Yamazaki Administrative Scrivener Office is an independent business entity from Microsoft. This article does not represent an official opinion, guarantee, or certification by Microsoft.