last sync: 2023-Jan-27 18:40:07 UTC

Azure Policy definition

Email notification to subscription owner for high severity alerts should be enabled

Name Email notification to subscription owner for high severity alerts should be enabled
Azure Portal
Id 0b15565f-aa9e-48ba-8619-45960f2c314d
Version 2.0.0
details on versioning
Category Security Center
Microsoft docs
Description To ensure your subscription owners are notified when there is a potential security breach in their subscription, set email notifications to subscription owners for high severity alerts in Security Center.
Mode All
Type BuiltIn
Preview FALSE
Deprecated FALSE
Effect Default
AuditIfNotExists
Allowed
AuditIfNotExists, Disabled
RBAC
Role(s)
none
Rule
Aliases
THEN-ExistenceCondition (2)
Alias Namespace ResourceType DefaultPath Modifiable
Microsoft.Security/securityContacts/alertNotifications.minimalSeverity Microsoft.Security securityContacts properties.alertNotifications.minimalSeverity false
Microsoft.Security/securityContacts/alertsToAdmins Microsoft.Security securityContacts properties.notificationsByRole.state false
Rule
ResourceTypes
IF (1)
Microsoft.Resources/subscriptions
Compliance The following 42 compliance controls are associated with this Policy definition 'Email notification to subscription owner for high severity alerts should be enabled' (0b15565f-aa9e-48ba-8619-45960f2c314d)
Control Domain Control Name MetadataId Category Title Owner Requirements Description Info Policy#
Azure_Security_Benchmark_v2.0 IR-2 Azure_Security_Benchmark_v2.0_IR-2 Azure Security Benchmark IR-2 Incident Response Preparation - setup incident notification Customer Set up security incident contact information in Azure Security Center. This contact information is used by Microsoft to contact you if the Microsoft Security Response Center (MSRC) discovers that your data has been accessed by an unlawful or unauthorized party. You also have options to customize incident alert and notification in different Azure services based on your incident response needs. How to set the Azure Security Center security contact: https://docs.microsoft.com/azure/security-center/security-center-provide-security-contact-details n/a link 3
Azure_Security_Benchmark_v3.0 IR-2 Azure_Security_Benchmark_v3.0_IR-2 Azure Security Benchmark IR-2 Incident Response Preparation - setup incident notification Shared **Security Principle:** Ensure the security alerts and incident notification from the cloud service provider's platform and your environments can be received by correct contact in your incident response organization. **Azure Guidance:** Set up security incident contact information in Microsoft Defender for Cloud. This contact information is used by Microsoft to contact you if the Microsoft Security Response Center (MSRC) discovers that your data has been accessed by an unlawful or unauthorized party. You also have options to customize incident alert and notification in different Azure services based on your incident response needs. **Implementation and additional context:** How to set the Microsoft Defender for Cloud security contact: https://docs.microsoft.com/azure/security-center/security-center-provide-security-contact-details n/a link 3
CIS_Azure_1.1.0 2.19 CIS_Azure_1.1.0_2.19 CIS Microsoft Azure Foundations Benchmark recommendation 2.19 2 Security Center Ensure that 'Send email also to subscription owners' is set to 'On' Shared The customer is responsible for implementing this recommendation. Enable security alert emails to subscription owners. link 1
CMMC_2.0_L2 IR.L2-3.6.2 CMMC_2.0_L2_IR.L2-3.6.2 404 not found n/a n/a 3
CMMC_2.0_L2 SI.L2-3.14.3 CMMC_2.0_L2_SI.L2-3.14.3 404 not found n/a n/a 13
CMMC_2.0_L2 SI.L2-3.14.6 CMMC_2.0_L2_SI.L2-3.14.6 404 not found n/a n/a 29
CMMC_L3 IR.2.092 CMMC_L3_IR.2.092 CMMC L3 IR.2.092 Incident Response Establish an operational incident-handling capability for organizational systems that includes preparation, detection, analysis, containment, recovery, and user response activities. Shared Microsoft and the customer share responsibilities for implementing this requirement. Organizations recognize that incident handling capability is dependent on the capabilities of organizational systems and the mission/business processes being supported by those systems. Organizations consider incident handling as part of the definition, design, and development of mission/business processes and systems. Incident-related information can be obtained from a variety of sources including audit monitoring, network monitoring, physical access monitoring, user and administrator reports, and reported supply chain events. Effective incident handling capability includes coordination among many organizational entities including mission/business owners, system owners, authorizing officials, human resources offices, physical and personnel security offices, legal departments, operations personnel, procurement offices, and the risk executive. As part of user response activities, incident response training is provided by organizations and is linked directly to the assigned roles and responsibilities of organizational personnel to ensure that the appropriate content and level of detail is included in such training. For example, regular users may only need to know who to call or how to recognize an incident on the system; system administrators may require additional training on how to handle or remediate incidents; and incident responders may receive more specific training on forensics, reporting, system recovery, and restoration. Incident response training includes user training in the identification/reporting of suspicious activities from external and internal sources. User response activities also includes incident response assistance which may consist of help desk support, assistance groups, and access to forensics services or consumer redress services, when required. link 3
CMMC_L3 SI.2.216 CMMC_L3_SI.2.216 CMMC L3 SI.2.216 System and Information Integrity Monitor organizational systems, including inbound and outbound communications traffic, to detect attacks and indicators of potential attacks. Shared Microsoft and the customer share responsibilities for implementing this requirement. System monitoring includes external and internal monitoring. External monitoring includes the observation of events occurring at the system boundary (i.e., part of perimeter defense and boundary protection). Internal monitoring includes the observation of events occurring within the system. Organizations can monitor systems, for example, by observing audit record activities in real time or by observing other system aspects such as access patterns, characteristics of access, and other actions. The monitoring objectives may guide determination of the events. System monitoring capability is achieved through a variety of tools and techniques (e.g., intrusion detection systems, intrusion prevention systems, malicious code protection software, scanning tools, audit record monitoring software, network monitoring software). Strategic locations for monitoring devices include selected perimeter locations and near server farms supporting critical applications, with such devices being employed at managed system interfaces. The granularity of monitoring information collected is based on organizational monitoring objectives and the capability of systems to support such objectives. System monitoring is an integral part of continuous monitoring and incident response programs. Output from system monitoring serves as input to continuous monitoring and incident response programs. A network connection is any connection with a device that communicates through a network (e.g., local area network, Internet). A remote connection is any connection with a device communicating through an external network (e.g., the Internet). Local, network, and remote connections can be either wired or wireless. Unusual or unauthorized activities or conditions related to inbound/outbound communications traffic include internal traffic that indicates the presence of malicious code in systems or propagating among system components, the unauthorized exporting of information, or signaling to external systems. Evidence of malicious code is used to identify potentially compromised systems or system components. System monitoring requirements, including the need for specific types of system monitoring, may be referenced in other requirements. link 23
CMMC_L3 SI.2.217 CMMC_L3_SI.2.217 CMMC L3 SI.2.217 System and Information Integrity Identify unauthorized use of organizational systems. Shared Microsoft and the customer share responsibilities for implementing this requirement. System monitoring includes external and internal monitoring. System monitoring can detect unauthorized use of organizational systems. System monitoring is an integral part of continuous monitoring and incident response programs. Monitoring is achieved through a variety of tools and techniques (e.g., intrusion detection systems, intrusion prevention systems, malicious code protection software, scanning tools, audit record monitoring software, network monitoring software). Output from system monitoring serves as input to continuous monitoring and incident response programs. Unusual/unauthorized activities or conditions related to inbound and outbound communications traffic include internal traffic that indicates the presence of malicious code in systems or propagating among system components, the unauthorized exporting of information, or signaling to external systems. Evidence of malicious code is used to identify potentially compromised systems or system components. System monitoring requirements, including the need for specific types of system monitoring, may be referenced in other requirements. link 11
FedRAMP_High_R4 IR-4 FedRAMP_High_R4_IR-4 FedRAMP High IR-4 Incident Response Incident Handling Shared n/a The organization: a. Implements an incident handling capability for security incidents that includes preparation, detection and analysis, containment, eradication, and recovery; b. Coordinates incident handling activities with contingency planning activities; and c. Incorporates lessons learned from ongoing incident handling activities into incident response procedures, training, and testing/exercises, and implements the resulting changes accordingly. Supplemental Guidance: Organizations recognize that incident response capability is dependent on the capabilities of organizational information systems and the mission/business processes being supported by those systems. Therefore, organizations consider incident response as part of the definition, design, and development of mission/business processes and information systems. Incident-related information can be obtained from a variety of sources including, for example, audit monitoring, network monitoring, physical access monitoring, user/administrator reports, and reported supply chain events. Effective incident handling capability includes coordination among many organizational entities including, for example, mission/business owners, information system owners, authorizing officials, human resources offices, physical and personnel security offices, legal departments, operations personnel, procurement offices, and the risk executive (function). Related controls: AU-6, CM-6, CP-2, CP-4, IR-2, IR-3, IR-8, PE-6, SC-5, SC-7, SI-3, SI-4, SI-7. References: Executive Order 13587; NIST Special Publication 800-61. link 25
FedRAMP_High_R4 IR-5 FedRAMP_High_R4_IR-5 FedRAMP High IR-5 Incident Response Incident Monitoring Shared n/a The organization tracks and documents information system security incidents. Supplemental Guidance: Documenting information system security incidents includes, for example, maintaining records about each incident, the status of the incident, and other pertinent information necessary for forensics, evaluating incident details, trends, and handling. Incident information can be obtained from a variety of sources including, for example, incident reports, incident response teams, audit monitoring, network monitoring, physical access monitoring, and user/administrator reports. Related controls: AU-6, IR-8, PE-6, SC-5, SC-7, SI-3, SI-4, SI-7. References: NIST Special Publication 800-61. link 14
FedRAMP_Moderate_R4 IR-4 FedRAMP_Moderate_R4_IR-4 FedRAMP Moderate IR-4 Incident Response Incident Handling Shared n/a The organization: a. Implements an incident handling capability for security incidents that includes preparation, detection and analysis, containment, eradication, and recovery; b. Coordinates incident handling activities with contingency planning activities; and c. Incorporates lessons learned from ongoing incident handling activities into incident response procedures, training, and testing/exercises, and implements the resulting changes accordingly. Supplemental Guidance: Organizations recognize that incident response capability is dependent on the capabilities of organizational information systems and the mission/business processes being supported by those systems. Therefore, organizations consider incident response as part of the definition, design, and development of mission/business processes and information systems. Incident-related information can be obtained from a variety of sources including, for example, audit monitoring, network monitoring, physical access monitoring, user/administrator reports, and reported supply chain events. Effective incident handling capability includes coordination among many organizational entities including, for example, mission/business owners, information system owners, authorizing officials, human resources offices, physical and personnel security offices, legal departments, operations personnel, procurement offices, and the risk executive (function). Related controls: AU-6, CM-6, CP-2, CP-4, IR-2, IR-3, IR-8, PE-6, SC-5, SC-7, SI-3, SI-4, SI-7. References: Executive Order 13587; NIST Special Publication 800-61. link 25
FedRAMP_Moderate_R4 IR-5 FedRAMP_Moderate_R4_IR-5 FedRAMP Moderate IR-5 Incident Response Incident Monitoring Shared n/a The organization tracks and documents information system security incidents. Supplemental Guidance: Documenting information system security incidents includes, for example, maintaining records about each incident, the status of the incident, and other pertinent information necessary for forensics, evaluating incident details, trends, and handling. Incident information can be obtained from a variety of sources including, for example, incident reports, incident response teams, audit monitoring, network monitoring, physical access monitoring, and user/administrator reports. Related controls: AU-6, IR-8, PE-6, SC-5, SC-7, SI-3, SI-4, SI-7. References: NIST Special Publication 800-61. link 14
NIST_SP_800-171_R2_3 .14.3 NIST_SP_800-171_R2_3.14.3 NIST SP 800-171 R2 3.14.3 System and Information Integrity Monitor system security alerts and advisories and take action in response. Shared Microsoft and the customer share responsibilities for implementing this requirement. There are many publicly available sources of system security alerts and advisories. For example, the Department of Homeland Security’s Cybersecurity and Infrastructure Security Agency (CISA) generates security alerts and advisories to maintain situational awareness across the federal government and in nonfederal organizations. Software vendors, subscription services, and industry information sharing and analysis centers (ISACs) may also provide security alerts and advisories. Examples of response actions include notifying relevant external organizations, for example, external mission/business partners, supply chain partners, external service providers, and peer or supporting organizations. [SP 800-161] provides guidance on supply chain risk management. link 16
NIST_SP_800-171_R2_3 .14.6 NIST_SP_800-171_R2_3.14.6 NIST SP 800-171 R2 3.14.6 System and Information Integrity Monitor organizational systems, including inbound and outbound communications traffic, to detect attacks and indicators of potential attacks. Shared Microsoft and the customer share responsibilities for implementing this requirement. System monitoring includes external and internal monitoring. External monitoring includes the observation of events occurring at the system boundary (i.e., part of perimeter defense and boundary protection). Internal monitoring includes the observation of events occurring within the system. Organizations can monitor systems, for example, by observing audit record activities in real time or by observing other system aspects such as access patterns, characteristics of access, and other actions. The monitoring objectives may guide determination of the events. System monitoring capability is achieved through a variety of tools and techniques (e.g., intrusion detection systems, intrusion prevention systems, malicious code protection software, scanning tools, audit record monitoring software, network monitoring software). Strategic locations for monitoring devices include selected perimeter locations and near server farms supporting critical applications, with such devices being employed at managed system interfaces. The granularity of monitoring information collected is based on organizational monitoring objectives and the capability of systems to support such objectives. System monitoring is an integral part of continuous monitoring and incident response programs. Output from system monitoring serves as input to continuous monitoring and incident response programs. A network connection is any connection with a device that communicates through a network (e.g., local area network, Internet). A remote connection is any connection with a device communicating through an external network (e.g., the Internet). Local, network, and remote connections can be either wired or wireless. Unusual or unauthorized activities or conditions related to inbound/outbound communications traffic include internal traffic that indicates the presence of malicious code in systems or propagating among system components, the unauthorized exporting of information, or signaling to external systems. Evidence of malicious code is used to identify potentially compromised systems or system components. System monitoring requirements, including the need for specific types of system monitoring, may be referenced in other requirements. [SP 800-94] provides guidance on intrusion detection and prevention systems. link 31
NIST_SP_800-171_R2_3 .6.2 NIST_SP_800-171_R2_3.6.2 NIST SP 800-171 R2 3.6.2 Incident response Track, document, and report incidents to designated officials and/or authorities both internal and external to the organization. Shared Microsoft and the customer share responsibilities for implementing this requirement. Tracking and documenting system security incidents includes maintaining records about each incident, the status of the incident, and other pertinent information necessary for forensics, evaluating incident details, trends, and handling. Incident information can be obtained from a variety of sources including incident reports, incident response teams, audit monitoring, network monitoring, physical access monitoring, and user/administrator reports. Reporting incidents addresses specific incident reporting requirements within an organization and the formal incident reporting requirements for the organization. Suspected security incidents may also be reported and include the receipt of suspicious email communications that can potentially contain malicious code. The types of security incidents reported, the content and timeliness of the reports, and the designated reporting authorities reflect applicable laws, Executive Orders, directives, regulations, and policies. [SP 800-61] provides guidance on incident handling. link 3
NIST_SP_800-53_R4 IR-4 NIST_SP_800-53_R4_IR-4 NIST SP 800-53 Rev. 4 IR-4 Incident Response Incident Handling Shared n/a The organization: a. Implements an incident handling capability for security incidents that includes preparation, detection and analysis, containment, eradication, and recovery; b. Coordinates incident handling activities with contingency planning activities; and c. Incorporates lessons learned from ongoing incident handling activities into incident response procedures, training, and testing/exercises, and implements the resulting changes accordingly. Supplemental Guidance: Organizations recognize that incident response capability is dependent on the capabilities of organizational information systems and the mission/business processes being supported by those systems. Therefore, organizations consider incident response as part of the definition, design, and development of mission/business processes and information systems. Incident-related information can be obtained from a variety of sources including, for example, audit monitoring, network monitoring, physical access monitoring, user/administrator reports, and reported supply chain events. Effective incident handling capability includes coordination among many organizational entities including, for example, mission/business owners, information system owners, authorizing officials, human resources offices, physical and personnel security offices, legal departments, operations personnel, procurement offices, and the risk executive (function). Related controls: AU-6, CM-6, CP-2, CP-4, IR-2, IR-3, IR-8, PE-6, SC-5, SC-7, SI-3, SI-4, SI-7. References: Executive Order 13587; NIST Special Publication 800-61. link 25
NIST_SP_800-53_R4 IR-5 NIST_SP_800-53_R4_IR-5 NIST SP 800-53 Rev. 4 IR-5 Incident Response Incident Monitoring Shared n/a The organization tracks and documents information system security incidents. Supplemental Guidance: Documenting information system security incidents includes, for example, maintaining records about each incident, the status of the incident, and other pertinent information necessary for forensics, evaluating incident details, trends, and handling. Incident information can be obtained from a variety of sources including, for example, incident reports, incident response teams, audit monitoring, network monitoring, physical access monitoring, and user/administrator reports. Related controls: AU-6, IR-8, PE-6, SC-5, SC-7, SI-3, SI-4, SI-7. References: NIST Special Publication 800-61. link 14
NIST_SP_800-53_R4 IR-6(2) NIST_SP_800-53_R4_IR-6(2) NIST SP 800-53 Rev. 4 IR-6 (2) Incident Response Vulnerabilities Related to Incidents Customer n/a The organization reports information system vulnerabilities associated with reported security incidents to [Assignment: organization-defined personnel or roles]. link 3
NIST_SP_800-53_R4 SI-4(12) NIST_SP_800-53_R4_SI-4(12) NIST SP 800-53 Rev. 4 SI-4 (12) System and Information Integrity Automated Alerts Customer n/a The organization employs automated mechanisms to alert security personnel of the following inappropriate or unusual activities with security implications: [Assignment: organization-defined activities that trigger alerts]. link 3
NIST_SP_800-53_R5 IR-4 NIST_SP_800-53_R5_IR-4 NIST SP 800-53 Rev. 5 IR-4 Incident Response Incident Handling Shared n/a a. Implement an incident handling capability for incidents that is consistent with the incident response plan and includes preparation, detection and analysis, containment, eradication, and recovery; b. Coordinate incident handling activities with contingency planning activities; c. Incorporate lessons learned from ongoing incident handling activities into incident response procedures, training, and testing, and implement the resulting changes accordingly; and d. Ensure the rigor, intensity, scope, and results of incident handling activities are comparable and predictable across the organization. link 25
NIST_SP_800-53_R5 IR-5 NIST_SP_800-53_R5_IR-5 NIST SP 800-53 Rev. 5 IR-5 Incident Response Incident Monitoring Shared n/a Track and document incidents. link 14
NIST_SP_800-53_R5 IR-6(2) NIST_SP_800-53_R5_IR-6(2) NIST SP 800-53 Rev. 5 IR-6 (2) Incident Response Vulnerabilities Related to Incidents Customer n/a Report system vulnerabilities associated with reported incidents to [Assignment: organization-defined personnel or roles]. link 3
NIST_SP_800-53_R5 SI-4(12) NIST_SP_800-53_R5_SI-4(12) NIST SP 800-53 Rev. 5 SI-4 (12) System and Information Integrity Automated Organization-generated Alerts Customer n/a Alert [Assignment: organization-defined personnel or roles] using [Assignment: organization-defined automated mechanisms] when the following indications of inappropriate or unusual activities with security or privacy implications occur: [Assignment: organization-defined activities that trigger alerts]. link 3
NZ_ISM_v3.5 ISM-4 NZ_ISM_v3.5_ISM-4 NZISM Security Benchmark ISM-4 Information security monitoring 6.2.6 Resolving vulnerabilities Customer n/a Vulnerabilities may occur as a result of poorly designed or implemented information security practices, accidental activities or malicious activities, and not just as the result of a technical issue. link 11
RBI_CSF_Banks_v2016 19.2 RBI_CSF_Banks_v2016_19.2 Incident Response & Management Responding To Cyber-Incidents:-19.2 n/a Have written incident response procedures including the roles of staff / outsourced staff handling such incidents; Response strategies shall consider readiness to meet various incident scenarios based on situational awareness and potential/post impact, consistent communication & co-ordination with stakeholders during response; 3
RBI_CSF_Banks_v2016 19.6 RBI_CSF_Banks_v2016_19.6 Incident Response & Management Recovery From Cyber - Incidents-19.6 n/a Such testing shall also include testing of crisis communication to customers and other internal and external stakeholders, reputation management. Adequate capacity shall be planned and maintained, in consideration thereof. The following may be considered: 4
RBI_CSF_Banks_v2016 19.6b RBI_CSF_Banks_v2016_19.6b Incident Response & Management Recovery From Cyber - Incidents-19.6b n/a Establish and implement a Security Operations Centre for centralised and coordinated monitoring and management of security related incidents. 4
RBI_CSF_Banks_v2016 19.6c RBI_CSF_Banks_v2016_19.6c Incident Response & Management Recovery From Cyber - Incidents-19.6c n/a Establish and implement systems to collect and share threat information from local/national/international sources following legally accepted/defined means/process 3
RBI_CSF_Banks_v2016 20.1 RBI_CSF_Banks_v2016_20.1 Risk Based Transaction Monitoring Risk Based Transaction Monitoring-20.1 n/a Risk based transaction monitoring or surveillance process shall be implemented as part of fraud risk management system across all -delivery channels. 7
RBI_CSF_Banks_v2016 4.7 RBI_CSF_Banks_v2016_4.7 Network Management And Security Anomaly Detection-4.7 n/a Put in place mechanism to detect and remedy any unusual activities in systems, servers, network devices and endpoints. 14
RBI_CSF_Banks_v2016 4.9 RBI_CSF_Banks_v2016_4.9 Network Management And Security Security Operation Centre-4.9 n/a Security Operation Centre to monitor the logs of various network activities and should have the capability to escalate any abnormal / undesirable activities. 16
RBI_ITF_NBFC_v2017 1 RBI_ITF_NBFC_v2017_1 RBI IT Framework 1 IT Governance IT Governance-1 n/a IT Governance is an integral part of corporate governance. It involves leadership support, organizational structure and processes to ensure that the NBFC???s IT sustains and extends business strategies and objectives. Effective IT Governance is the responsibility of the Board of Directors and Executive Management. Well-defined roles and responsibilities of Board and Senior Management are critical, while implementing IT Governance. Clearly-defined roles enable effective project control. People, when they are aware of others' expectations from them, are able to complete work on time, within budget and to the expected level of quality. IT Governance Stakeholders include: Board of Directors, IT Strategy Committees, CEOs, Business Executives, Chief Information Officers (CIOs), Chief Technology Officers (CTOs), IT Steering Committees (operating at an executive level and focusing on priority setting, resource allocation and project tracking), Chief Risk Officer and Risk Committees. The basic principles of value delivery, IT Risk Management, IT resource management and performance management must form the basis of governance framework. IT Governance has a continuous life-cycle. It's a process in which IT strategy drives the processes, using resources necessary to execute responsibilities. Given the criticality of the IT, NBFCs may follow relevant aspects of such prudential governance standards that have found acceptability in the finance industry. link 20
RBI_ITF_NBFC_v2017 3.1.c RBI_ITF_NBFC_v2017_3.1.c RBI IT Framework 3.1.c Information and Cyber Security Role based Access Control-3.1 n/a The IS Policy must provide for a IS framework with the following basic tenets: Role based Access Control ??? Access to information should be based on well-defined user roles (system administrator, user manager, application owner etc.), NBFCs shall avoid dependence on one or few persons for a particular job. There should be clear delegation of authority for right to upgrade/change user profiles and permissions and also key business parameters (eg. interest rates) which should be documented. link 15
RBI_ITF_NBFC_v2017 3.1.f RBI_ITF_NBFC_v2017_3.1.f RBI IT Framework 3.1.f Information and Cyber Security Maker-checker-3.1 n/a The IS Policy must provide for a IS framework with the following basic tenets: Maker-checker is one of the important principles of authorization in the information systems of financial entities. For each transaction, there must be at least two individuals necessary for its completion as this will reduce the risk of error and will ensure reliability of information. link 24
RMiT_v1.0 11.17 RMiT_v1.0_11.17 RMiT 11.17 Security Operations Centre (SOC) Security Operations Centre (SOC) - 11.17 Shared n/a A financial institution must ensure its SOC, whether managed in-house or by third party service providers, has adequate capabilities for proactive monitoring of its technology security posture. This shall enable the financial institution to detect anomalous user or network activities, flag potential breaches and establish the appropriate response supported by skilled resources based on the level of complexity of the alerts. The outcome of the SOC activities shall also inform the financial institution's reviews of its cybersecurity posture and strategy. link 4
SOC_2 CC2.2 SOC_2_CC2.2 SOC 2 Type 2 CC2.2 Communication and Information COSO Principle 14 Shared The customer is responsible for implementing this recommendation. • Communicates Internal Control Information — A process is in place to communicate required information to enable all personnel to understand and carry out their internal control responsibilities. • Communicates With the Board of Directors — Communication exists between management and the board of directors so that both have information needed to fulfill their roles with respect to the entity’s objectives. • Provides Separate Communication Lines — Separate communication channels, such as whistle-blower hotlines, are in place and serve as fail-safe mechanisms to enable anonymous or confidential communication when normal channels are inoperative or ineffective. • Selects Relevant Method of Communication — The method of communication considers the timing, audience, and nature of • Communicates Responsibilities — Entity personnel with responsibility for designing, developing, implementing, operating, maintaining, or monitoring system controls receive communications about their responsibilities, including changes in their responsibilities, and have the information necessary to carry out those responsibilities. • Communicates Information on Reporting Failures, Incidents, Concerns, and Other Matters — Entity personnel are provided with information on how to report systems failures, incidents, concerns, and other complaints to personnel. • Communicates Objectives and Changes to Objectives — The entity communicates its objectives and changes to those objectives to personnel in a timely manner. • Communicates Information to Improve Security Knowledge and Awareness — The entity communicates information to improve security knowledge and awareness and to model appropriate security behaviors to personnel through a security awareness training program 9
SOC_2 CC2.3 SOC_2_CC2.3 SOC 2 Type 2 CC2.3 Communication and Information COSO Principle 15 Shared The customer is responsible for implementing this recommendation. Communicates to External Parties — Processes are in place to communicate relevant and timely information to external parties, including shareholders, partners, owners, regulators, customers, financial analysts, and other external parties. • Enables Inbound Communications — Open communication channels allow input from customers, consumers, suppliers, external auditors, regulators, financial analysts, and others, providing management and the board of directors with relevant information. • Communicates With the Board of Directors — Relevant information resulting from assessments conducted by external parties is communicated to the board of directors. • Provides Separate Communication Lines — Separate communication channels, such as whistle-blower hotlines, are in place and serve as fail-safe mechanisms to enable anonymous or confidential communication when normal channels are inoperative or ineffective. • Selects Relevant Method of Communication — The method of communication considers the timing, audience, and nature of the communication and legal, regulatory, and fiduciary requirements and expectations. Additional point of focus that applies only to an engagement using the trust services criteria for confidentiality: • Communicates Objectives Related to Confidentiality and Changes to Objectives — The entity communicates, to external users, vendors, business partners, and others whose products and services are part of the system, objectives and changes to objectives related to confidentiality.Page 20 TSP Ref. # TRUST SERVICES CRITERIA AND POINTS OF FOCUS Additional point of focus that applies only to an engagement using the trust services criteria for privacy: • Communicates Objectives Related to Privacy and Changes to Objectives — The entity communicates, to external users, vendors, business partners, and others whose products and services are part of the system, objectives related to privacy and changes to those objectives. Additional points of focus that apply only when an engagement using the trust services criteria is performed at the system level: • Communicates Information About System Operation and Boundaries — The entity prepares and communicates information about the design and operation of the system and its boundaries to authorized external users to permit users to understand their role in the system and the results of system operation. • Communicates System Objectives — The entity communicates its system objectives to appropriate external users. • Communicates System Responsibilities — External users with responsibility for designing, developing, implementing, operating, maintaining, and monitoring system controls receive communications about their responsibilities and have the information necessary to carry out those responsibilities. • Communicates Information on Reporting System Failures, Incidents, Concerns, and Other Matters — External users are provided with information on how to report systems failures, incidents, concerns, and other complaints to appropriate personnel. 14
SOC_2 CC7.4 SOC_2_CC7.4 SOC 2 Type 2 CC7.4 System Operations Security incidents response Shared The customer is responsible for implementing this recommendation. Assigns Roles and Responsibilities — Roles and responsibilities for the design, implementation, maintenance, and execution of the incident response program are assigned, including the use of external resources when necessary. • Contains Security Incidents — Procedures are in place to contain security incidents that actively threaten entity objectives. • Mitigates Ongoing Security Incidents — Procedures are in place to mitigate the effects of ongoing security incidents. • Ends Threats Posed by Security Incidents — Procedures are in place to end the threats posed by security incidents through closure of the vulnerability, removal of unauthorized access, and other remediation actions. • Restores Operations — Procedures are in place to restore data and business operations to an interim state that permits the achievement of entity objectives. • Develops and Implements Communication Protocols for Security Incidents — Protocols for communicating security incidents and actions taken to affected parties are developed and implemented to meet the entity's objectives. • Obtains Understanding of Nature of Incident and Determines Containment Strategy — An understanding of the nature (for example, the method by which the incident occurred and the affected system resources) and severity of the security incident is obtained to determine the appropriate containment strategy, including (1) a determination of the appropriate response time frame, and (2) the determination and execution of the containment approach. • Remediates Identified Vulnerabilities — Identified vulnerabilities are remediated through the development and execution of remediation activities. • Communicates Remediation Activities — Remediation activities are documented and communicated in accordance with the incident-response program. • Evaluates the Effectiveness of Incident Response — The design of incident-response activities is evaluated for effectiveness on a periodic basis. • Periodically Evaluates Incidents — Periodically, management reviews incidents related to security, availability, processing integrity, confidentiality, and privacy and identifies the need for system changes based on incident patterns and root causes Communicates Unauthorized Use and Disclosure — Events that resulted in unauthorized use or disclosure of personal information are communicated to the data subjects, legal and regulatory authorities, and others as required. • Application of Sanctions — The conduct of individuals and organizations operating under the authority of the entity and involved in the unauthorized use or disclosure of personal information is evaluated and, if appropriate, sanctioned in accordance with entity policies and legal and regulatory requirements 17
SOC_2 CC7.5 SOC_2_CC7.5 SOC 2 Type 2 CC7.5 System Operations Recovery from identified security incidents Shared The customer is responsible for implementing this recommendation. • Restores the Affected Environment — The activities restore the affected environment to functional operation by rebuilding systems, updating software, installing patches, and changing configurations, as needed. • Communicates Information About the Event — Communications about the nature of the incident, recovery actions taken, and activities required for the prevention of future security events are made to management and others as appropriate (internal and external). • Determines Root Cause of the Event — The root cause of the event is determined. • Implements Changes to Prevent and Detect Recurrences — Additional architecture or changes to preventive and detective controls, or both, are implemented to prevent and detect recurrences on a timely basis. • Improves Response and Recovery Procedures — Lessons learned are analyzed and the incident-response plan and recovery procedures are improved. • Implements Incident-Recovery Plan Testing — Incident-recovery plan testing is performed on a periodic basis. The testing includes (1) development of testing scenarios based on threat likelihood and magnitude; (2) consideration of relevant system components from across the entity that can impair availability; (3) scenarios that consider the potential for the lack of availability of key personnel; and (4) revision of continuity plans and systems based on test results 19
SWIFT_CSCF_v2021 7.1 SWIFT_CSCF_v2021_7.1 SWIFT CSCF v2021 7.1 Plan for Incident Response and Information Sharing Cyber Incident Response Planning n/a Ensure a consistent and effective approach for the management of cyber incidents. link 3
SWIFT_CSCF_v2022 7.1 SWIFT_CSCF_v2022_7.1 SWIFT CSCF v2022 7.1 7. Plan for Incident Response and Information Sharing Ensure a consistent and effective approach for the management of cyber incidents. Shared n/a The user has a defined and tested cyber-incident response plan. link 8
History
Date/Time (UTC ymd) (i) Change type Change detail
2021-02-17 14:28:42 change Major (1.0.1 > 2.0.0)
2020-12-11 15:42:52 change Patch (1.0.0 > 1.0.1) *changes on text case sensitivity are not tracked
Initiatives
usage
Initiative DisplayName Initiative Id Initiative Category State Type
[Deprecated]: Azure Security Benchmark v2 bb522ac1-bc39-4957-b194-429bcd3bcb0b Regulatory Compliance Deprecated BuiltIn
[Deprecated]: DoD Impact Level 4 8d792a84-723c-4d92-a3c3-e4ed16a2d133 Regulatory Compliance Deprecated BuiltIn
[Preview]: CMMC 2.0 Level 2 4e50fd13-098b-3206-61d6-d1d78205cb45 Regulatory Compliance Preview BuiltIn
[Preview]: Reserve Bank of India - IT Framework for Banks d0d5578d-cc08-2b22-31e3-f525374f235a Regulatory Compliance Preview BuiltIn
[Preview]: Reserve Bank of India - IT Framework for NBFC 7f89f09c-48c1-f28d-1bd5-84f3fb22f86c Regulatory Compliance Preview BuiltIn
[Preview]: SWIFT CSP-CSCF v2021 abf84fac-f817-a70c-14b5-47eec767458a Regulatory Compliance Preview BuiltIn
Azure Security Benchmark 1f3afdf9-d0c9-4c3d-847f-89da613e70a8 Security Center GA BuiltIn
CIS Microsoft Azure Foundations Benchmark v1.1.0 1a5bb27d-173f-493e-9568-eb56638dde4d Regulatory Compliance GA BuiltIn
CMMC Level 3 b5629c75-5c77-4422-87b9-2509e680f8de Regulatory Compliance GA BuiltIn
FedRAMP High d5264498-16f4-418a-b659-fa7ef418175f Regulatory Compliance GA BuiltIn
FedRAMP Moderate e95f5a9f-57ad-4d03-bb0b-b1d16db93693 Regulatory Compliance GA BuiltIn
New Zealand ISM Restricted v3.5 93d2179e-3068-c82f-2428-d614ae836a04 Regulatory Compliance GA BuiltIn
NIST SP 800-171 Rev. 2 03055927-78bd-4236-86c0-f36125a10dc9 Regulatory Compliance GA BuiltIn
NIST SP 800-53 Rev. 4 cf25b9c1-bd23-4eb6-bd2c-f4f3ac644a5f Regulatory Compliance GA BuiltIn
NIST SP 800-53 Rev. 5 179d1daa-458f-4e47-8086-2a68d0d6c38f Regulatory Compliance GA BuiltIn
RMIT Malaysia 97a6d4f1-3bed-4cf4-ac5b-0e444c0408d6 Regulatory Compliance GA BuiltIn
SOC 2 Type 2 4054785f-702b-4a98-9215-009cbd58b141 Regulatory Compliance GA BuiltIn
SWIFT CSP-CSCF v2022 7bc7cd6c-4114-ff31-3cac-59be3157596d Regulatory Compliance GA BuiltIn
JSON
changes

JSON