last sync: 2025-Apr-29 17:16:02 UTC

Microsoft Managed Control 1378 - Incident Response Plan | Regulatory Compliance - Incident Response

Azure BuiltIn Policy definition

Source Azure Portal
Display name Microsoft Managed Control 1378 - Incident Response Plan
Id 97fceb70-6983-42d0-9331-18ad8253184d
Version 1.0.0
Details on versioning
Versioning Versions supported for Versioning: 0
Built-in Versioning [Preview]
Category Regulatory Compliance
Microsoft Learn
Description Microsoft implements this Incident Response control
Cloud environments AzureCloud = true
AzureUSGovernment = true
AzureChinaCloud = unknown
Available in AzUSGov The Policy is available in AzureUSGovernment cloud. Version: '1.0.0'
Repository: Azure-Policy 97fceb70-6983-42d0-9331-18ad8253184d
Additional metadata Name/Id: ACF1378 / Microsoft Managed Control 1378
Category: Incident Response
Title: Incident Response Plan - Develop Plan
Ownership: Customer, Microsoft
Description: The organization: Develops an incident response plan that: Provides the organization with a roadmap for implementing its incident response capability; Describes the structure and organization of the incident response capability; Provides a high-level approach for how the incident response capability fits into the overall organization; Meets the unique requirements of the organization, which relate to mission, size, structure, and functions; Defines reportable incidents; Provides metrics for measuring the incident response capability within the organization; Defines the resources and management support needed to effectively maintain and mature an incident response capability; and Is reviewed and approved by Microsoft Azure ISSO;
Requirements: Azure has developed and implemented the Incident Management SOP. The Incident Management SOP provides Azure a roadmap for implementing its incident management capability. The purpose of the SOP is to provide guidance concerning the responsibilities of involved parties during any incident that affects the confidentiality, integrity, or availability of Azure. The SOP provides a high-level approach for how the incident management capability fits into the overall organization and describes the structure and organization of the incident management capabilities, including: * Describing the end-to-end process of security incident management, and how it is executed across the various functional groups within Microsoft. * Defining a methodical approach that may be applied to resolve security incidents and escalate incidents to the proper internal authorities. The Incident Management SOP explains the different phases of the incident management lifecycle. Details for each of the phases are explained in the plan. The SOP also identifies the internal partners, cross-team contacts, roles and responsibilities, and lists the individuals and management support needed to effectively maintain and mature the incident management capability. The SOP provides guidance for classifying the incidents and assigning severity. It also provides the characteristics that could be associated with incidents to help categorize the incidents. Security incidents are tracked in a ticketing system where they are categorized and assigned a severity rating. Security incidents include, but are not limited to: e-mail viruses, rootkits, worms, denial of service attacks, unauthorized access, inappropriate use of network resources, any other type of unauthorized, unacceptable, unlawful activity involving Azure computer networks or data processing equipment, and compromise, disclosure, or use of information that occurs outside its intended purpose. There are five phases in the Azure incident management lifecycle: detect, assess, diagnose, stabilize and recover, and close. The SOP meets the unique requirements of the organization, which relate to mission, size, structure, and functions. The Microsoft Security Response Center (MSRC) is responsible for reporting on its efforts with Azure as a Quality of Service (QoS) Metric. Metrics are defined as the following: * Total Number of Incidents: The Security Response Team reports the total number of incidents experienced by online services and can report incidents with respect to incident category, property affected, and other dimensions. * Time to Detect (TTD): The time between when an incident began and when it was identified by the finder. This metric can only be determined after an investigation has been conducted by the Security Response Team. * Time to Engage (TTE): The time between when an incident is reported to Security Response Team and Security Response Team takes action. * Time to Mitigate (TTM): The time between when an incident is reported to Security Response Team and the incident is mitigated and/or resolved. A formal Incident Report is produced by the service teams and augmented with the Azure Security Response Team’s additions. These reports, which include lessons learned, are created for all events with a Severity 1 rating. For incidents of lesser severity, if there are significant lessons learned that have general applicability across the Azure environment, an incident report is created. The incident reports are maintained by Azure Security incident management or by the impacted service team and are provided to the relevant stakeholders for review.
Mode Indexed
Type Static
Preview False
Deprecated False
Effect Fixed
audit
RBAC role(s) none
Rule aliases none
Rule resource types IF (2)
Compliance
The following 2 compliance controls are associated with this Policy definition 'Microsoft Managed Control 1378 - Incident Response Plan' (97fceb70-6983-42d0-9331-18ad8253184d)
Control Domain Control Name MetadataId Category Title Owner Requirements Description Info Policy#
NIS2 IR._Incident_Response_2 NIS2_IR._Incident_Response_2 NIS2_IR._Incident_Response_2 IR. Incident Response Incident handling n/a Where essential or important entities become aware of a significant incident, they should be required to submit an early warning without undue delay and in any event within 24 hours. That early warning should be followed by an incident notification. The entities concerned should submit an incident notification without undue delay and in any event within 72 hours of becoming aware of the significant incident, with the aim, in particular, of updating information submitted through the early warning and indicating an initial assessment of the significant incident, including its severity and impact, as well as indicators of compromise, where available. A final report should be submitted not later than one month after the incident notification. The early warning should only include the information necessary to make the CSIRT, or where applicable the competent authority, aware of the significant incident and allow the entity concerned to seek assistance, if required. Such early warning, where applicable, should indicate whether the significant incident is suspected of being caused by unlawful or malicious acts, and whether it is likely to have a cross-border impact. Member States should ensure that the obligation to submit that early warning, or the subsequent incident notification, does not divert the notifying entity’s resources from activities related to incident handling that should be prioritised, in order to prevent incident reporting obligations from either diverting resources from significant incident response handling or otherwise compromising the entity’s efforts in that respect. 27.12.2022 EN Official Journal of the European Union L 333/99 In the event of an ongoing incident at the time of the submission of the final report, Member States should ensure that entities concerned provide a progress report at that time, and a final report within one month of their handling of the significant incident 34
op.exp.7 Incident management op.exp.7 Incident management 404 not found n/a n/a 103
Initiatives usage
Initiative DisplayName Initiative Id Initiative Category State Type polSet in AzUSGov
[Preview]: NIS2 32ff9e30-4725-4ca7-ba3a-904a7721ee87 Regulatory Compliance Preview BuiltIn unknown
Spain ENS 175daf90-21e1-4fec-b745-7b4c909aa94c Regulatory Compliance GA BuiltIn unknown
History none
JSON compare n/a
JSON
api-version=2021-06-01
EPAC