Merge pull request #225192 from v-edmckillop/patch-98

Update toc.yml

Author: v-dirichards

articles/active-directory/fundamentals/data-operational-considerations.md

@@ -0,0 +1,55 @@
+---
+title: Data operational considerations
+description: Learn how 
+services: active-directory
+author: janicericketts
+manager: martinco
+ms.service: active-directory
+ms.workload: identity
+ms.subservice: fundamentals
+ms.topic: conceptual
+ms.date: 01/26/2023
+ms.author: jricketts
+ms.reviewer: jricketts
+ms.custom: "it-pro"
+ms.collection:
+---
+
+# Data operational considerations
+
+In this article, learn about data operational considerations for your configuration. There's information about how log files and other features work in relation to Azure Active Directory (Azure AD), such as usage data and operator security. You’ll learn about physical security considerations in addition to guidance on how the Azure AD team defines deployments and change. 
+
+## Log files
+
+Azure AD generates log files for auditing, investigation, and debugging for actions and events in the service. Log files might contain data about users, devices, and Azure AD configuration, for instance policies, apps, and groups. Log files are created and stored in Azure Storage in the data center where the Azure AD service runs.  
+
+Log files are used for local debugging, security, usage analysis, system-health monitoring, and service-wide analysis. These logs are copied over a Transport Layer Security (TLS) connection to Microsoft reporting machine learning systems, which are in Microsoft-owned data centers in the continental United States.  
+
+## Usage data
+
+Usage data is metadata generated by the Azure AD service that indicates how the service is being used. This metadata is used to generate administrator- and user-facing reports. The Azure AD engineering team uses the metadata to evaluate system usage and identify opportunities to improve the service. Generally, this data is written to log files, but in some cases, is collected by our service monitoring and reporting systems.  
+
+## Operator security
+
+Access to Azure AD by Microsoft personnel, contractors, and vendors (system admins) is highly restricted. Wherever possible, human intervention is replaced by an automated, tool-based process, including routine functions such as deployment, debugging, diagnostic collection, and restarting services. 
+
+Administrator access is limited to a subset of qualified engineers and requires completion of an authentication challenge with phishing-resistant credentials. System access and update functions are assigned to roles managed by the Microsoft just-in-time (JIT) privileged-access management system. System administrators request elevation using the JIT system, which routes the request for manual or automated approval. Upon approval, JIT elevates the account. Requests for elevation, approval, elevation into roles, and removal from roles are logged for future debugging or investigations.  
+
+Microsoft personnel can execute operations only from a secure access workstation, which uses an internal isolated strong authentication identity platform. Access to other Microsoft identity systems doesn't grant access to the security access workstation. The identity platform runs separately from other Microsoft identity systems. 
+
+## Physical security
+
+Physical access to servers that comprise the Azure AD service, and access to Azure AD back-end systems, is restricted by Azure facility, premises, and physical security. Azure AD customers have no access to physical assets or locations, therefore they can't bypass the logical role-based access control (RBAC) policy checks. Personnel with operator access are authorized to run approved workflows for maintenance.  
+
+Learn more: [Azure facilities, premises, and physical security](../../security/fundamentals/physical-security.md)
+
+## Change control process
+
+To roll out changes to the service across data centers, the Azure AD team defines the layers of a deployment environment. Applying the change layers is constrained by strict exit criteria. The amount of time to roll a change across layers is defined by the operations team and is based on potential effects. Typically a rollout takes between 1 to 2 weeks. Critical changes, such as security fixes or hot fixes, can be deployed faster. If a change doesn't meet the exit criteria when applied to a deployment layer, it's rolled back to the prior, stable state. 
+
+## Resources
+
+* [Azure AD and data residency](azure-ad-data-residency.md)
+* [Microsoft Service Trust Documents](https://servicetrust.microsoft.com/Documents/TrustDocuments)
+* [Microsoft Azure Trusted Cloud](https://azure.microsoft.com/explore/trusted-cloud/)
+* [Office 365 data centers](https://social.technet.microsoft.com/wiki/contents/articles/37502.office-365-how-to-change-data-center-regions.aspx#Moving_Office_365_Data_Centers)

articles/active-directory/fundamentals/toc.yml

@@ -98,6 +98,8 @@ items:
     items:
     - name: Azure AD and data residency
       href: azure-ad-data-residency.md
+    - name: Data operational considerations
+      href: data-operational-considerations.md
     - name: Data protection considerations
       href: data-protection-considerations.md
     - name: Customer data storage and processing for Europe