Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Microsoft takes its obligations under the General Data Protection Regulation (GDPR) seriously. Microsoft takes extensive security measures within its online services to protect against data breaches. These measures include both physical and logical security controls, as well as automated security processes, comprehensive information security and privacy policies, and security and privacy training for all personnel.
Security is built into Microsoft Azure, Dynamics 365, and Power Platform from the ground up, starting with the Security Development Lifecycle, a mandatory development process that incorporates privacy-by-design and privacy-by-default methodologies. The guiding principle of Microsoft's security strategy is to 'assume breach,' which is an extension of the defense-in-depth strategy. By constantly challenging the security capabilities of Microsoft Azure, Dynamics 365, and Power Platform, Microsoft stays ahead of emerging threats. For more information on Azure security, review these resources.
Microsoft has a dedicated global, 24/7 incident response service that works to mitigate the effects of attacks against Microsoft Azure, Dynamics 365, and Power Platform. Attested by multiple security and compliance audits (for example, ISO/IEC 27018), Microsoft employs rigorous operations and processes at its data centers to prevent unauthorized access, including 24/7 video monitoring, trained security personnel, smart cards, and biometric controls.
Detection of potential breaches
Due to the nature of modern cloud computing, not all data breaches that occur in a customer cloud environment involve Microsoft Azure, Dynamics 365, or Power Platform services. Microsoft uses a shared responsibility model for Microsoft Azure, Dynamics 365, and Power Platform services to define security and operational accountabilities. Shared responsibility is important when discussing security of a cloud service, because both the cloud services provider and the customer are accountable for portions of cloud security.
Microsoft doesn't monitor for or respond to security incidents within the customer's realm of responsibility. A customer-only security compromise isn't a Microsoft security incident and requires the customer tenant to manage the response effort. Given appropriate service contracts, customer incident response might involve collaboration with Microsoft Azure customer support, Dynamics 365 customer support, and Power Platform customer support. Microsoft also offers various services, such as Microsoft Defender for Cloud, that customers can use for developing and managing security incident response.
Microsoft responds to a potential data breach according to the security incident response process, which is a subset of the Microsoft incident management plan. Microsoft's Azure security incident response is implemented using a five-stage process: Detect, Assess, Diagnose, Stabilize, and Close. The Security Incident Response Team might alternate between the diagnose and stabilize stages as the investigation progresses. An overview of the security incident response process is described in the following table:
| Stage | Description |
|---|---|
| 1: Detect | First indication of a potential incident. |
| 2: Assess | An on-call incident response team member assesses the impact and severity of the event. Based on evidence, the assessment might result in further escalation to the security response team. |
| 3: Diagnose | Security response experts conduct the technical or forensic investigation, identify containment, mitigation, and work around strategies. If the security team believes that customer data might be exposed to an unlawful or unauthorized individual, execution of the Customer Incident Notification process begins in parallel. |
| 4: Stabilize and Recover | The incident response team creates a recovery plan to mitigate the issue. Crisis containment steps such as quarantining impacted systems might occur immediately and in parallel with diagnosis. Longer term mitigations might be planned which occur after the immediate risk passes. |
| 5: Close and Post-mortem | The incident response team creates a post-mortem that outlines the details of the incident, with the intention to revise policies, procedures, and processes to prevent a recurrence of the event. |
The detection processes that Microsoft Azure, Dynamics 365, and Power Platform use are designed to discover events that risk the confidentiality, integrity, and availability of Azure, Dynamics 365, and Power Platform services. Several events can trigger an investigation:
- Automated system alerts via internal monitoring and alerting frameworks. These alerts come in the form of signature-based alarms such as anti-malware, intrusion detection, or via algorithms designed to profile expected activity and alert upon anomalies.
- First party reports from Microsoft Services running on Microsoft Azure and Azure Government.
- Security vulnerabilities reported to the Microsoft Security Response Center (MSRC) via Report an issue. MSRC works with partners and security researchers around the world to help prevent security incidents and to advance Microsoft product security.
- Customer reports via portals including the Microsoft Azure Customer Support Portal, Dynamics 365 customer support, Power Platform customer support, Microsoft Azure portal, and Azure Government Management Portal, that describe suspicious activity attributed to the Azure infrastructure (as opposed to activity occurring within the customer's scope of responsibility).
- Security Red Team and Blue Team activity. This strategy uses a highly skilled Red Team of offensive Microsoft security experts to uncover and attack potential weaknesses in Microsoft Azure. The security response Blue Team must detect and defend against the Red Team's activity. Both Red and Blue Team actions are used to verify that Azure security response efforts are effectively managing security incidents. Security Red Team and Blue Team activities are operated under rules of engagement to help ensure the protection of customer data and personal data.
- Escalations by operators of Microsoft Azure, Dynamics 365, and Power Platform Services. Microsoft employees are trained to identify and escalate potential security issues.
Microsoft Azure, Dynamics 365, and Power Platform data breach response
Microsoft assigns the investigation appropriate priority and severity levels by determining the functional impact, recoverability, and information impact of the incident. Both the priority and severity can change over the course of the investigation, based on new findings and conclusions. The Security Incident Response Team treats security events that involve imminent or confirmed risk to customer data as high severity and works around the clock to resolve them.
The Security Incident Response Team works with the applicable Microsoft service engineers and subject matter experts to classify the event based on factual data from the evidence. A security event can be classified as:
- False positive: An event that meets detection criteria but is part of a normal business practice and might need to be filtered out. Service teams identify the root cause for false positives and address them in a systematic way to fine-tune them as needed.
- Security event: An observable occurrence in a system, service, and/or network for attempted attack, circumvention of security controls, or an identified problem where the facts indicate that customer data or personal data might be lost, destroyed, altered, disclosed, or accessed without authorization.
- Security Incident/Customer Reportable Security/Privacy Incident (CRSPI): A confirmed (for example, declared) breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to Customer Data or Personal Data while processed by Microsoft.
- Privacy Event: A Security Event that affects Customer Data or Personal Data or data processing that results in unintended consequences for privacy, including noncompliance with Microsoft privacy policies, standards, and controls.
- Privacy Incident/Customer Reportable Security/Privacy Incident (CRSPI): A Security Incident that affects Customer Data or Personal Data, Data, or data processing that results in unintended consequences for privacy, including noncompliance with Microsoft privacy policies, standards, and controls.
For Microsoft to declare a CRSPI, it must determine that unauthorized access to customer data happened or likely happened and/or that a legal or contractual commitment requires notification. Generally, Microsoft declares an incident a CRSPI after the conclusion of the Diagnose stage of a security incident. However, the declaration can happen at any point when all pertinent information is available.
Microsoft verifies that customer and business risk is successfully contained and that corrective measures are implemented. If necessary, Microsoft takes emergency mitigation steps to resolve immediate security risks associated with the event.
Microsoft also completes an internal post-mortem for data breaches. As a part of this exercise, the team evaluates the sufficiency of response and operating procedures, and identifies and implements any updates that might be necessary to the Security Incident Response Standard Operating Procedure (SOP) or related processes. Internal postmortems for data breaches are highly confidential records not available to customers. However, postmortems can be summarized and included in other customer event notifications. External auditors receive these reports for review as part of Microsoft Azure, Dynamics 365, and Power Platform routine audit cycles.
Customer notification
Microsoft notifies impacted customers and regulatory authorities of data breaches as required. Microsoft relies on heavy internal compartmentalization in the operation of Microsoft Azure, Dynamics 365, and Power Platform. As a benefit of this design, you can scope most incidents to specific customers. The goal is to provide impacted customers with an accurate, actionable, and timely notice when their data is breached.
After the declaration of a CRSPI, the notification process takes place as expeditiously as possible while still considering the security risks of moving quickly. Microsoft delivers customer notices without undue delay, and in any event in no more than 72 hours from the time it declared a breach except in some limited circumstances. Some examples are as follows:
- Microsoft believes that the act of performing a notification increases the risk to other customers. For example, the act of notifying might tip off an adversary and cause an inability to remediate.
- The 72-hour timeline might leave some incident details unavailable. Microsoft provides these details to customers and regulatory authorities as the investigation proceeds.
Microsoft provides impacted customers with detailed information enabling them to perform internal investigations and assisting them in meeting end-user commitments, while not unduly delaying the notification process. Microsoft delivers notification of a data breach for Azure to a customer’s Microsoft Azure service health notifications blade as a Security Advisory. If warranted, Microsoft may notify one or more of the following roles via email of a security or privacy incident in conjunction with, or in lieu of, a service health notification:
- Azure Subscription Administrators or Owners
- Microsoft Entra Global Tenant Administrators
- Microsoft Entra tenant Technical Contacts
The Microsoft Azure or Azure Government team might also elect to notify other Microsoft personnel such as members of Microsoft's Customer Support Service (CSS) team and the customer's Account Managers (AM) or Customer Success Account Manager (CSAM). These individuals often have close relationships with the customer and can facilitate faster remediation.
Microsoft delivers notification of a data breach for Microsoft Dynamics 365 and Power Platform to the Microsoft 365 admin center under Message Center and applies the Data Privacy tag. For more information, see the Message Center FAQ. The global admin role receives data privacy messages for an organization. Additionally, consider assigning the Message Center Privacy reader role to other users in your organization who should see data privacy messages. Other admin roles with access to Message Center can't view data privacy messages.
Microsoft Dynamics 365 and Power Platform built-in security features
Microsoft Dynamics 365 and Power Platform take advantage of the cloud service infrastructure and built-in security features to keep data safe by using security measures and mechanisms to protect data. In addition, Dynamics 365 and Power Platform provide efficient data access and collaboration with data integrity and privacy in the following areas: secure identity, data protection, role based security, and threat management.
The Microsoft Dynamics 365 and Power Platform offerings follow the same technical and organizational measures that one or more Microsoft Azure service teams take for securing against data breach processes. Therefore, any information documented in the 'Microsoft Azure Data Breach' notification document here applies to Microsoft Dynamics 365 and Power Platform as well.