Share via


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.

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

Resources