Security incident management overview
What is a security incident?
Microsoft defines a security incident in its online services as a confirmed breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to customer data or personal data while being processed by Microsoft. For example, unauthorized access to Microsoft online services infrastructure and exfiltration of customer data would constitute a security incident, while compliance events that don't affect the confidentiality, integrity, or availability of services or customer data aren't considered security incidents.
How does Microsoft respond to security incidents?
Whenever there's a security incident, Microsoft strives to respond quickly and effectively to protect Microsoft services and customer data. Microsoft employs an incident response strategy designed to investigate, contain, and remove security threats quickly and efficiently.
Microsoft cloud services are continuously monitored for signs of compromise. In addition to automated security monitoring and alerting, all employees receive annual training to recognize and report signs of potential security incidents. Any suspicious activity detected by employees, customers, or security monitoring tools are escalated to Service-specific Security Response teams for investigation. All service operations teams, including Service-specific Security Response teams, maintain a deep on-call rotation to ensure resources are available for incident response 24x7x365. Our on-call rotations enable Microsoft to mount an effective incident response at any time or scale, including widespread or concurrent events.
When suspicious activity is detected and escalated, Service-specific Security Response teams initiate a process of analysis, containment, eradication, and recovery. These teams coordinate analysis of the potential incident to determine its scope, including any impact to customers or customer data. Based on this analysis, Service-specific Security Response teams work with impacted service teams to develop a plan to contain the threat and minimize the impact of the incident, eradicate the threat from the environment, and fully recover to a known secure state. Relevant service teams implement the plan with support from Service-specific Security Response teams to ensure the threat is successfully eliminated and impacted services undergo a complete recovery.
After an incident is resolved, service teams implement any lessons learned from the incident to better prevent, detect, and respond to similar incidents in the future. Select security incidents, especially those incidents that are customer-impacting or result in a data breach, undergo a full incident post-mortem. The post-mortem is designed to identify technical lapses, procedural failures, manual errors, and other process flaws that might have contributed to the incident or that were identified during the incident response process. Improvements identified during the post-mortem are implemented with coordination from Service-specific Security Response teams to help prevent future incidents and improve detection and response capabilities.
How and when are customers notified of security or privacy incidents?
Whenever Microsoft becomes aware of a breach of security involving unauthorized loss, disclosure, or modification of customer data, Microsoft notifies affected customers within 72 hours as outlined in the Data Protection Addendum (DPA). The notification timeline commitment begins when the official security incident declaration occurs. Upon declaring a security incident, the notification process occurs as expeditiously as possible, without undue delay.
Notifications include a description of the nature of the breach, approximate user impact, and mitigation steps (if applicable). If Microsoft's investigation isn't complete at the time of initial notification, the notification will also indicate next steps and timelines for subsequent communication.
If a customer becomes aware of an incident that could have an impact on Microsoft, including but not limited to a data breach, the customer is responsible for promptly notifying Microsoft of the incident as defined in the DPA.
Related external regulations & certifications
Microsoft's online services are regularly audited for compliance with external regulations and certifications. Refer to the following table for validation of controls related to incident management.
Azure and Dynamics 365
| External audits | Section | Latest report date |
|---|---|---|
| ISO 27001 Statement of Applicability Certificate |
A.16.1: Management of information security incidents and improvements | April 8, 2024 |
| ISO 27017 Statement of Applicability Certificate |
A.16.1: Management of information security incidents and improvements | April 8, 2024 |
| ISO 27018 Statement of Applicability Certificate |
A.9.1: Notification of a data breach involving PII | April 8, 2024 |
| SOC 1 | IM-1: Incident management framework IM-2: Detection mechanisms and alerting IM-3: Incident response execution IM-4: Incident postmortems IM-6: Incident response testing OA-7: On-call engineer access |
August 16, 2024 |
| SOC 2 SOC 3 |
CCM-9: Forensic procedures CUEC: Reporting incidents IM-1: Incident management framework IM-2: Detection mechanisms and alerting IM-3: Incident response execution IM-4: Incident postmortems IM-6: Incident response testing OA-7: On-call engineer access SOC2-6: Customer Support website SOC2-9: Service dashboards |
May 20, 2024 |
Microsoft 365
| External audits | Section | Latest report date |
|---|---|---|
| FedRAMP | IR-4: Incident handling IR-6: Incident reporting IR-8: Incident response plan |
August 21, 2024 |
| ISO 27001/27017 Statement of Applicability Certification (27001) Certification (27017) |
A.16.1: Management of information security incidents and improvements | March 2024 |
| ISO 27018 Statement of Applicability Certificate |
A.10.1: Notification of a data breach involving PII | March 2024 |
| SOC 1 | CA-26: Security incident reporting CA-47: Incident response |
August 1, 2024 |
| SOC 2 | CA-12: Service level agreements (SLAs) CA-13: Incident response guides CA-15: Service health notifications CA-26: Security incident reporting CA-29: On-call engineers CA-47: Incident response |
January 23, 2024 |
| SOC 3 | CUEC-08: Reporting incidents | January 23, 2024 |