compliance controls are associated with this Policy definition 'Subscriptions should have a contact email address for security issues' (4f4f78b8-e367-4b10-a341-d9a4ad5cf1c7)
Control Domain |
Control |
Name |
MetadataId |
Category |
Title |
Owner |
Requirements |
Description |
Info |
Policy# |
Azure_Security_Benchmark_v1.0 |
10.4 |
Azure_Security_Benchmark_v1.0_10.4 |
Azure Security Benchmark 10.4 |
Incident Response |
Provide security incident contact details and configure alert notifications for security incidents |
Customer |
Security incident contact information will be used by Microsoft to contact you if the Microsoft Security Response Center (MSRC) discovers that the customer's data has been accessed by an unlawful or unauthorized party. Review incidents after the fact to ensure that issues are resolved.
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 |
1 |
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 |
Microsoft cloud 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 |
|
C.05.5 - Monitored and reported |
C.05.5 - Monitored and reported |
404 not found |
|
|
|
n/a |
n/a |
|
3 |
Canada_Federal_PBMM_3-1-2020 |
AC_22 |
Canada_Federal_PBMM_3-1-2020_AC_22 |
Canada Federal PBMM 3-1-2020 AC 22 |
Publicly Accessible Content |
Publicly Accessible Content |
Shared |
1. The organization designates individuals authorized to post information onto a publicly accessible information system.
2. The organization trains authorized individuals to ensure that publicly accessible information does not contain confidentially sensitive information.
3. The organization reviews the proposed content of information prior to posting onto the publicly accessible information system to ensure that confidentially sensitive information is not included.
4. The organization reviews the content on the publicly accessible information system for confidentially sensitive information at least quarterly and removes such information, if discovered. |
To maintain data security and compliance. |
|
1 |
Canada_Federal_PBMM_3-1-2020 |
AT_1 |
Canada_Federal_PBMM_3-1-2020_AT_1 |
404 not found |
|
|
|
n/a |
n/a |
|
1 |
Canada_Federal_PBMM_3-1-2020 |
AT_2 |
Canada_Federal_PBMM_3-1-2020_AT_2 |
404 not found |
|
|
|
n/a |
n/a |
|
1 |
Canada_Federal_PBMM_3-1-2020 |
AT_2(2) |
Canada_Federal_PBMM_3-1-2020_AT_2(2) |
404 not found |
|
|
|
n/a |
n/a |
|
1 |
Canada_Federal_PBMM_3-1-2020 |
AT_3 |
Canada_Federal_PBMM_3-1-2020_AT_3 |
404 not found |
|
|
|
n/a |
n/a |
|
1 |
Canada_Federal_PBMM_3-1-2020 |
CP_10(2) |
Canada_Federal_PBMM_3-1-2020_CP_10(2) |
Canada Federal PBMM 3-1-2020 CP 10(2) |
Information System Recovery and Reconstitution |
Information System Recovery and Reconstitution | Transaction Recovery |
Shared |
The information system implements transaction recovery for systems that are transaction-based. |
To minimise the impact on business operations and preventing data loss or corruption. |
|
10 |
Canada_Federal_PBMM_3-1-2020 |
CP_10(4) |
Canada_Federal_PBMM_3-1-2020_CP_10(4) |
Canada Federal PBMM 3-1-2020 CP 10(4) |
Information System Recovery and Reconstitution |
Information System Recovery and Reconstitution | Restore within Time Period |
Shared |
The organization provides the capability to restore information system components within organization-defined restoration time-periods from configuration-controlled and integrity-protected information representing a known, operational state for the components. |
To minimise downtime and ensuring business continuity. |
|
10 |
Canada_Federal_PBMM_3-1-2020 |
CP_2(3) |
Canada_Federal_PBMM_3-1-2020_CP_2(3) |
Canada Federal PBMM 3-1-2020 CP 2(3) |
Contingency Plan |
Contingency Plan | Resume Essential Missions / Business Functions |
Shared |
The organization plans for the resumption of essential missions and business functions within 24 hours of contingency plan activation. |
To ensure that the organization plans for the resumption of essential missions and business functions within 24 hours of activating the contingency plan. |
|
10 |
Canada_Federal_PBMM_3-1-2020 |
CP_2(4) |
Canada_Federal_PBMM_3-1-2020_CP_2(4) |
Canada Federal PBMM 3-1-2020 CP 2(4) |
Contingency Plan |
Contingency Plan | Resume All Missions / Business Functions |
Shared |
The organization plans for the resumption of all missions and business functions within organization-defined time period of contingency plan activation. |
To ensure that the organization plans for the resumption of all missions and business functions within an organization-defined time period of contingency plan activation. |
|
10 |
Canada_Federal_PBMM_3-1-2020 |
CP_2(5) |
Canada_Federal_PBMM_3-1-2020_CP_2(5) |
Canada Federal PBMM 3-1-2020 CP 2(5) |
Contingency Plan |
Contingency Plan | Continue Essential Missions / Business Functions |
Shared |
The organization plans for the continuance of essential missions and business functions with little or no loss of operational continuity and sustains that continuity until full information system restoration at primary processing and/or storage sites. |
To minimise downtime, mitigate potential financial losses, maintain customer trust, and uphold critical services or functions.
|
|
10 |
Canada_Federal_PBMM_3-1-2020 |
CP_2(6) |
Canada_Federal_PBMM_3-1-2020_CP_2(6) |
Canada Federal PBMM 3-1-2020 CP 2(6) |
Contingency Plan |
Contingency Plan | Alternate Processing / Storage Site |
Shared |
The organization plans for the transfer of essential missions and business functions to alternate processing and/or storage sites with little or no loss of operational continuity and sustains that continuity through information system restoration to primary processing and/or storage sites. |
To minimise downtime and ensure that critical services can continue uninterrupted until full restoration is achieved. |
|
10 |
Canada_Federal_PBMM_3-1-2020 |
IR_2 |
Canada_Federal_PBMM_3-1-2020_IR_2 |
Canada Federal PBMM 3-1-2020 IR 2 |
Incident Response Training |
Incident Response Training |
Shared |
1. The organization provides incident response training to information system users consistent with assigned roles and responsibilities within 30 days of assuming an incident response role or responsibility.
2. The organization provides incident response training to information system users consistent with assigned roles and responsibilities when required by information system changes.
3. The organization provides incident response training to information system users consistent with assigned roles and responsibilities at least annually. |
To enhance security posture. |
|
1 |
Canada_Federal_PBMM_3-1-2020 |
IR_3 |
Canada_Federal_PBMM_3-1-2020_IR_3 |
Canada Federal PBMM 3-1-2020 IR 3 |
Incident Response Testing and Exercises |
Incident Response Testing |
Shared |
The organization tests the incident response capability for the information system at least annually using tests and exercises defined in NIST SP 800-61 to determine the incident response effectiveness and documents the results. |
To enhance security posture. |
|
1 |
Canada_Federal_PBMM_3-1-2020 |
IR_6 |
Canada_Federal_PBMM_3-1-2020_IR_6 |
Canada Federal PBMM 3-1-2020 IR 6 |
Incident Reporting |
Incident Reporting |
Shared |
1. The organization requires personnel to report suspected security incidents to the organizational incident response capability within 2 hours.
2. The organization reports security incident information to organization-defined authorities. |
To ensure incidents are reported promptly. |
|
1 |
Canada_Federal_PBMM_3-1-2020 |
IR_6(1) |
Canada_Federal_PBMM_3-1-2020_IR_6(1) |
Canada Federal PBMM 3-1-2020 IR 6(1) |
Incident Reporting |
Incident Reporting | Automated Reporting |
Shared |
The organization employs automated mechanisms to assist in the reporting of security incidents. |
To streamline the reporting of security incidents. |
|
1 |
CIS_Azure_1.1.0 |
2.16 |
CIS_Azure_1.1.0_2.16 |
CIS Microsoft Azure Foundations Benchmark recommendation 2.16 |
2 Security Center |
Ensure that 'Security contact emails' is set |
Shared |
The customer is responsible for implementing this recommendation. |
Provide a security contact email address. |
link |
1 |
CIS_Azure_1.3.0 |
2.13 |
CIS_Azure_1.3.0_2.13 |
CIS Microsoft Azure Foundations Benchmark recommendation 2.13 |
2 Security Center |
Ensure 'Additional email addresses' is configured with a security contact email |
Shared |
The customer is responsible for implementing this recommendation. |
Security Center emails the subscription owners whenever a high-severity alert is triggered for their subscription. You should provide a security contact email address as an additional email address. |
link |
1 |
CIS_Azure_1.4.0 |
2.13 |
CIS_Azure_1.4.0_2.13 |
CIS Microsoft Azure Foundations Benchmark recommendation 2.13 |
2 Microsoft Defender for Cloud |
Ensure 'Additional email addresses' is Configured with a Security Contact Email |
Shared |
The customer is responsible for implementing this recommendation. |
Microsoft Defender for Cloud emails the subscription owners whenever a high-severity alert is triggered for their subscription. You should provide a security contact email address as an additional email address. |
link |
1 |
CIS_Azure_2.0.0 |
2.1.19 |
CIS_Azure_2.0.0_2.1.19 |
CIS Microsoft Azure Foundations Benchmark recommendation 2.1.19 |
2.1 |
Ensure 'Additional email addresses' is Configured with a Security Contact Email |
Shared |
n/a |
Microsoft Defender for Cloud emails the subscription owners whenever a high-severity alert is triggered for their subscription. You should provide a security contact email address as an additional email address.
Microsoft Defender for Cloud emails the Subscription Owner to notify them about security alerts. Adding your Security Contact's email address to the 'Additional email addresses' field ensures that your organization's Security Team is included in these alerts. This ensures that the proper people are aware of any potential compromise in order to mitigate the risk in a timely fashion. |
link |
1 |
CIS_Azure_Foundations_v2.1.0 |
2.1.18 |
CIS_Azure_Foundations_v2.1.0_2.1.18 |
CIS Azure Foundations v2.1.0 2.1.18 |
Security Monitoring |
Ensure 'Additional email addresses' is Configured with a Security Contact Email |
Shared |
n/a |
Ensure that a security contact email is set up for alerts and notifications. |
|
3 |
CIS_Controls_v8.1 |
17.2 |
CIS_Controls_v8.1_17.2 |
CIS Controls v8.1 17.2 |
Incident Response Management |
Establish and maintain contact information for reporting security incidents |
Shared |
1. Establish and maintain contact information for parties that need to be informed of security incidents.
2. Contacts may include internal staff, third-party vendors, law enforcement, cyber insurance providers, relevant government agencies, Information Sharing and Analysis Center (ISAC) partners, or other stakeholders.
3. Verify contacts annually to ensure that information is up-to-date. |
To establish and maintain a comprehensive contact list for entities that need to be notified in the event of security incidents. |
|
3 |
CIS_Controls_v8.1 |
4.1 |
CIS_Controls_v8.1_4.1 |
CIS Controls v8.1 4.1 |
Secure Configuration of Enterprise Assets and Software |
Establish and maintain a secure configuration process. |
Shared |
1. Establish and maintain a secure configuration process for enterprise assets (end-user devices, including portable and mobile; non-computing/IoT devices; and servers) and software (operating systems and applications).
2. Review and update documentation annually, or when significant enterprise changes occur that could impact this safeguard. |
To ensure data integrity and safety of enterprise assets. |
|
44 |
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 |
|
11 |
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 |
|
25 |
CMMC_L2_v1.9.0 |
AT.L2_3.2.3 |
CMMC_L2_v1.9.0_AT.L2_3.2.3 |
Cybersecurity Maturity Model Certification (CMMC) Level 2 v1.9.0 AT.L2 3.2.3 |
Awareness and Training |
Insider Threat Awareness |
Shared |
Provide security awareness training on recognizing and reporting potential indicators of insider threat. |
To enhance the organization's ability to detect and mitigate internal security risks. |
|
2 |
CMMC_L2_v1.9.0 |
IR.L2_3.6.1 |
CMMC_L2_v1.9.0_IR.L2_3.6.1 |
Cybersecurity Maturity Model Certification (CMMC) Level 2 v1.9.0 IR.L2 3.6.1 |
Incident Response |
Incident Handling |
Shared |
Establish an operational incident handling capability for organizational systems that includes preparation, detection, analysis, containment, recovery, and user response activities. |
To effectively respond to and mitigate the impact of security incidents or breaches. |
|
2 |
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 |
CPS_234_(APRA)_2019 |
CPS_234_(APRA)_2019_23 |
CPS_234_(APRA)_2019_23 |
APRA CPS 234 2019 23 |
Incident management |
Enable the entity to identify security breaches swiftly and take appropriate action to mitigate the impact, safeguarding its information assets and ensuring the continuity of operations. |
Shared |
n/a |
An APRA-regulated entity must have robust mechanisms in place to detect and respond to information security incidents in a timely manner. |
|
1 |
CPS_234_(APRA)_2019 |
CPS_234_(APRA)_2019_24 |
CPS_234_(APRA)_2019_24 |
APRA CPS 234 2019 24 |
Incident management |
Maintain information security response plans designed to address potential security incidents that the entity deems plausible. |
Shared |
n/a |
An APRA-regulated entity must maintain plans to respond to information security incidents that the entity considers could plausibly occur (information security response plans). |
|
1 |
CPS_234_(APRA)_2019 |
CPS_234_(APRA)_2019_25 |
CPS_234_(APRA)_2019_25 |
APRA CPS 234 2019 25 |
Incident management |
Ensure APRA-regulated entities' information security response plans encompass managing all incident stages and facilitating escalation and reporting to relevant governing bodies. |
Shared |
n/a |
An APRA-regulated entity’s information security response plans must include the mechanisms in place for:
1. managing all relevant stages of an incident, from detection to post-incident review
2. escalation and reporting of information security incidents to the Board, other governing bodies and individuals responsible for information security incident management and oversight, as appropriate. |
|
1 |
CPS_234_(APRA)_2019 |
CPS_234_(APRA)_2019_26 |
CPS_234_(APRA)_2019_26 |
APRA CPS 234 2019 26 |
Incident management |
Ensure ongoing effectiveness and suitability for addressing security incidents. |
Shared |
n/a |
An APRA-regulated entity must annually review and test its information security
response plans to ensure they remain effective and fit-for-purpose. |
|
1 |
CPS_234_(APRA)_2019 |
CPS_234_(APRA)_2019_35 |
CPS_234_(APRA)_2019_35 |
APRA CPS 234 2019 35 |
APRA notification |
Ensure transparency and enable APRA to take appropriate actions to mitigate potential risks and protect the interests of stakeholders. |
Shared |
n/a |
An APRA-regulated entity must notify APRA as soon as possible and, in any case, no later than 72 hours, after becoming aware of an information security
incident that:
1. materially affected, or had the potential to materially affect, financially or non-financially, the entity or the interests of depositors, policyholders, beneficiaries or other customers; or
2. has been notified to other regulators, either in Australia or other jurisdictions. |
|
1 |
EU_2555_(NIS2)_2022 |
EU_2555_(NIS2)_2022_10 |
EU_2555_(NIS2)_2022_10 |
EU 2022/2555 (NIS2) 2022 10 |
|
Computer security incident response teams (CSIRTs) |
Shared |
n/a |
Requires Member States to designate or establish CSIRTs. |
|
3 |
EU_2555_(NIS2)_2022 |
EU_2555_(NIS2)_2022_11 |
EU_2555_(NIS2)_2022_11 |
EU 2022/2555 (NIS2) 2022 11 |
|
Requirements, technical capabilities and tasks of CSIRTs |
Shared |
n/a |
Outlines the requirements, technical capabilities, and tasks of CSIRTs. |
|
68 |
EU_2555_(NIS2)_2022 |
EU_2555_(NIS2)_2022_13 |
EU_2555_(NIS2)_2022_13 |
EU 2022/2555 (NIS2) 2022 13 |
|
Cooperation at national level |
Shared |
n/a |
Requires cooperation between competent authorities, single points of contact, and CSIRTs at the national level. |
|
3 |
EU_2555_(NIS2)_2022 |
EU_2555_(NIS2)_2022_23 |
EU_2555_(NIS2)_2022_23 |
EU 2022/2555 (NIS2) 2022 23 |
|
Reporting obligations |
Shared |
n/a |
Requires essential and important entities to notify significant incidents to their CSIRT or competent authority. |
|
3 |
EU_2555_(NIS2)_2022 |
EU_2555_(NIS2)_2022_9 |
EU_2555_(NIS2)_2022_9 |
EU 2022/2555 (NIS2) 2022 9 |
|
National cyber crisis management frameworks |
Shared |
n/a |
Requires Member States to establish frameworks for managing large-scale cybersecurity incidents and crises. |
|
14 |
EU_GDPR_2016_679_Art. |
33 |
EU_GDPR_2016_679_Art._33 |
EU General Data Protection Regulation (GDPR) 2016/679 Art. 33 |
Chapter 4 - Controller and processor |
Notification of a personal data breach to the supervisory authority |
Shared |
n/a |
n/a |
|
2 |
EU_GDPR_2016_679_Art. |
34 |
EU_GDPR_2016_679_Art._34 |
EU General Data Protection Regulation (GDPR) 2016/679 Art. 34 |
Chapter 4 - Controller and processor |
Communication of a personal data breach to the data subject |
Shared |
n/a |
n/a |
|
2 |
FBI_Criminal_Justice_Information_Services_v5.9.5_5 |
.3 |
FBI_Criminal_Justice_Information_Services_v5.9.5_5.3 |
404 not found |
|
|
|
n/a |
n/a |
|
3 |
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 |
24 |
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 |
13 |
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 |
24 |
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 |
13 |
FFIEC_CAT_2017 |
5.3.1 |
FFIEC_CAT_2017_5.3.1 |
FFIEC CAT 2017 5.3.1 |
Cyber Incident Management and Resilience |
Escalation and Reporting |
Shared |
n/a |
- A process exists to contact personnel who are responsible for analyzing and responding to an incident.
- Procedures exist to notify customers, regulators, and law enforcement as required or necessary when the institution becomes aware of an incident involving the unauthorized access to or use of sensitive customer information.
- The institution prepares an annual report of security incidents or violations for the board or an appropriate board committee.
- Incidents are classified, logged, and tracked. |
|
2 |
HITRUST_CSF_v11.3 |
11.a |
HITRUST_CSF_v11.3_11.a |
HITRUST CSF v11.3 11.a |
Reporting Information Security Incidents and Weaknesses |
Ensure information security events and weaknesses associated with information systems are handled in a manner allowing timely corrective action to be taken. |
Shared |
A designated and widely known point of contact is to be established within the organization to promptly report information security events, ensuring availability and timely responses; additionally, a maintained list of third-party contacts, such as information security officers' email addresses, facilitates for the reporting of security incidents. |
Information security events shall be reported through appropriate communications channels as quickly as possible. All employees, contractors and third-party users shall be made aware of their responsibility to report any information security events as quickly as possible. |
|
11 |
ISO_IEC_27002_2022 |
5.24 |
ISO_IEC_27002_2022_5.24 |
ISO IEC 27002 2022 5.24 |
Response,
Recovery,
Corrective Control |
Information security incident management planning and preparation |
Shared |
The organization should plan and prepare for managing information security incidents by defining, establishing and communicating information security incident management processes, roles and responsibilities.
|
To ensure quick, effective, consistent and orderly response to information security incidents, including communication on information security events |
|
1 |
ISO_IEC_27002_2022 |
5.26 |
ISO_IEC_27002_2022_5.26 |
ISO IEC 27002 2022 5.26 |
Response,
Recovery,
Corrective Control |
Response to information security incidents |
Shared |
Information security incidents should be responded to in accordance with the documented procedures.
|
To ensure efficient and effective response to information security incidents. |
|
1 |
ISO_IEC_27017_2015 |
16.1.1 |
ISO_IEC_27017_2015_16.1.1 |
ISO IEC 27017 2015 16.1.1 |
Information Security Incident Management |
Responsibilities and Procedures |
Shared |
For Cloud Service Customer:
The cloud service customer should verify the allocation of responsibilities for information security incident management and should ensure that it meets the requirements of the cloud service customer.
For Cloud Service Provider:
As a part of the service specifications, the cloud service provider should define the allocation of information security incident management responsibilities and procedures between the cloud service customer and the cloud service provider.
The cloud service provider should provide the cloud service customer with documentation covering:
(i) the scope of information security incidents that the cloud service provider will report to the cloud service customer;
(ii) the level of disclosure of the detection of information security incidents and the associated responses;
(iii) the target timeframe in which notifications of information security incidents will occur;
(iv) the procedure for the notification of information security incidents;
(v)contact information for the handling of issues relating to information security incidents;
(vi) any remedies that can apply if certain information security incidents occur. |
To ensure quick, effective, consistent and orderly response to information security incidents, including communication on information security events |
|
1 |
LGPD_2018_Art. |
48 |
LGPD_2018_Art._48 |
Brazilian General Data Protection Law (LGPD) 2018 Art. 48 |
Safety and Good Practice |
Article 48: Personal Data Security Incidents |
Shared |
n/a |
The controller must communicate to the national authority and to the data subject the occurrence of a security incident that may create risk or relevant damage to the data subjects. |
|
1 |
New_Zealand_ISM |
07.2.22.C.01 |
New_Zealand_ISM_07.2.22.C.01 |
New_Zealand_ISM_07.2.22.C.01 |
07. Information Security Incidents |
07.2.22.C.01 Outsourcing and information security incidents |
|
n/a |
Agencies that outsource their information technology services and functions MUST ensure that the service provider advises and consults with the agency when an information security incident occurs. |
|
3 |
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 |
NIST_CSF_v2.0 |
DE.AE_06 |
NIST_CSF_v2.0_DE.AE_06 |
NIST CSF v2.0 DE.AE 06 |
DETECT-Adverse Event Analysis |
Information on adverse events is provided to authorized staff and tools. |
Shared |
n/a |
To identify and analyze the cybersecurity attacks and compromises. |
|
1 |
NIST_CSF_v2.0 |
RS.CO_02 |
NIST_CSF_v2.0_RS.CO_02 |
NIST CSF v2.0 RS.CO 02 |
RESPOND-Incident Response Reporting and Communication |
Internal and external stakeholders are notified of incidents. |
Shared |
n/a |
To ensure that an action is taken upon the detected cybersecurity incident. |
|
1 |
NIST_CSF_v2.0 |
RS.CO_03 |
NIST_CSF_v2.0_RS.CO_03 |
NIST CSF v2.0 RS.CO 03 |
RESPOND-Incident Response Reporting and Communication |
Information is shared with designated internal and external stakeholders. |
Shared |
n/a |
To ensure that an action is taken upon the detected cybersecurity incident. |
|
1 |
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 |
14 |
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 |
27 |
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-171_R3_3 |
.15.2 |
NIST_SP_800-171_R3_3.15.2 |
NIST 800-171 R3 3.15.2 |
Planning Control |
System Security Plan |
Shared |
System security plans provide key characteristics of the system that is processing, storing, and transmitting CUI and how the system and information are protected. System security plans contain sufficient information to enable a design and implementation that is unambiguously compliant with the intent of the plans and the subsequent determinations of risk if the plan is implemented as intended. System security plans can be a collection of documents, including documents that already exist. Effective system security plans make use of references to policies, procedures, and additional documents (e.g., design specifications) where detailed information can be obtained. This reduces the documentation requirements associated with security programs and maintains security information in other established management or operational areas related to enterprise architecture, the system development life cycle, systems engineering, and acquisition. |
a. Develop a system security plan that:
1. Defines the constituent system components;
2. Describes the system operating environment;
3. Describes specific threats to the system that are of concern to the organization
4. Provides an overview of the security requirements for the system;
5. Identifies connections to other systems;
6. Identifies individuals that fulfill system roles and responsibilities; and
7. Includes other relevant information necessary for the protection of CUI.
b. Review and update the system security plan periodically.
c. Protect the system security plan from unauthorized disclosure. |
|
3 |
NIST_SP_800-171_R3_3 |
.17.1 |
NIST_SP_800-171_R3_3.17.1 |
NIST 800-171 R3 3.17.1 |
Supply Chain Risk Control |
Supply Chain Risk Management Plan |
Shared |
Dependence on the products, systems, and services from external providers and the nature of the relationships with those providers present an increasing level of risk to an organization. Threat actions that may increase security risks include unauthorized production; the insertion or use of counterfeits; tampering; theft; the insertion of malicious software, firmware, and hardware; and poor manufacturing and development practices in the supply chain. Supply chain risks can be endemic or systemic within a system, component, or service. Managing supply chain risks is a complex, multifaceted undertaking that requires a coordinated effort across an organization to build trust relationships and communicate with internal and external stakeholders.
Supply chain risk management (SCRM) activities include identifying and assessing risks, determining appropriate risk response actions, developing SCRM plans to document response actions, and monitoring performance against the plans. The system-level SCRM plan is implementation-specific and provides policy implementation, requirements, constraints, and implications. It can either be stand-alone or incorporated into system security plans. The SCRM plan addresses the management, implementation, and monitoring of SCRM controls and the development or sustainment of systems across the system development life cycle to support mission and business functions. Because supply chains can differ significantly across and within organizations, SCRM plans are tailored to individual program, organizational, and operational contexts. |
a. Develop a plan for managing supply chain risks associated with the research, development, design, manufacturing, acquisition, delivery, integration, operations, maintenance, and disposal of the system, system components, or system services.
b. Review and update the supply chain risk management plan periodically.
c. Protect the supply chain risk management plan from unauthorized disclosure. |
|
3 |
NIST_SP_800-171_R3_3 |
.2.1 |
NIST_SP_800-171_R3_3.2.1 |
404 not found |
|
|
|
n/a |
n/a |
|
2 |
NIST_SP_800-171_R3_3 |
.6.2 |
NIST_SP_800-171_R3_3.6.2 |
404 not found |
|
|
|
n/a |
n/a |
|
3 |
NIST_SP_800-171_R3_3 |
.6.5 |
NIST_SP_800-171_R3_3.6.5 |
404 not found |
|
|
|
n/a |
n/a |
|
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 |
24 |
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 |
13 |
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.1.1 |
IR.1 |
NIST_SP_800-53_R5.1.1_IR.1 |
NIST SP 800-53 R5.1.1 IR.1 |
Incident Response Control |
Policy and Procedures |
Shared |
a. Develop, document, and disseminate to [Assignment: organization-defined personnel or roles]:
1. [Selection (one or more): organization-level; mission/business process-level; system-level] incident response policy that:
(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and
(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and
2. Procedures to facilitate the implementation of the incident response policy and the associated incident response controls;
b. Designate an [Assignment: organization-defined official] to manage the development, documentation, and dissemination of the incident response policy and procedures; and
c. Review and update the current incident response:
1. Policy [Assignment: organization-defined frequency] and following [Assignment: organization-defined events]; and
2. Procedures [Assignment: organization-defined frequency] and following [Assignment: organization-defined events]. |
Incident response policy and procedures address the controls in the IR family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of incident response policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to incident response policy and procedures include assessment or audit findings, security or privacy incidents, or changes in laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure. |
|
1 |
NIST_SP_800-53_R5.1.1 |
IR.6 |
NIST_SP_800-53_R5.1.1_IR.6 |
NIST SP 800-53 R5.1.1 IR.6 |
Incident Response Control |
Incident Reporting |
Shared |
a. Require personnel to report suspected incidents to the organizational incident response capability within [Assignment: organization-defined time period]; and
b. Report incident information to [Assignment: organization-defined authorities]. |
The types of incidents reported, the content and timeliness of the reports, and the designated reporting authorities reflect applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. Incident information can inform risk assessments, control effectiveness assessments, security requirements for acquisitions, and selection criteria for technology products. |
|
2 |
NIST_SP_800-53_R5.1.1 |
IR.8 |
NIST_SP_800-53_R5.1.1_IR.8 |
NIST SP 800-53 R5.1.1 IR.8 |
Incident Response Control |
Incident Response Plan |
Shared |
a. Develop an incident response plan that:
1. Provides the organization with a roadmap for implementing its incident response capability;
2. Describes the structure and organization of the incident response capability;
3. Provides a high-level approach for how the incident response capability fits into the overall organization;
4. Meets the unique requirements of the organization, which relate to mission, size, structure, and functions;
5. Defines reportable incidents;
6. Provides metrics for measuring the incident response capability within the organization;
7. Defines the resources and management support needed to effectively maintain and mature an incident response capability;
8. Addresses the sharing of incident information;
9. Is reviewed and approved by [Assignment: organization-defined personnel or roles]
[Assignment: organization-defined frequency]; and
10. Explicitly designates responsibility for incident response to [Assignment: organization-defined entities, personnel, or roles].
b. Distribute copies of the incident response plan to [Assignment: organization-defined incident response personnel (identified by name and/or by role) and organizational elements];
c. Update the incident response plan to address system and organizational changes or problems encountered during plan implementation, execution, or testing;
d. Communicate incident response plan changes to [Assignment: organization-defined incident response personnel (identified by name and/or by role) and organizational elements]; and
e. Protect the incident response plan from unauthorized disclosure and modification. |
It is important that organizations develop and implement a coordinated approach to incident response. Organizational mission and business functions determine the structure of incident response capabilities. As part of the incident response capabilities, organizations consider the coordination and sharing of information with external organizations, including external service providers and other organizations involved in the supply chain. For incidents involving personally identifiable information (i.e., breaches), include a process to determine whether notice to oversight organizations or affected individuals is appropriate and provide that notice accordingly. |
|
1 |
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 |
24 |
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 |
13 |
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 |
7 |
NZISM_v3.7 |
16.4.37.C.01. |
NZISM_v3.7_16.4.37.C.01. |
NZISM v3.7 16.4.37.C.01. |
Privileged Access Management |
16.4.37.C.01. - enhance security and reduce the risk of unauthorized access or misuse. |
Shared |
n/a |
Agencies MUST implement a Privileged Access Management (PAM) policy training module as part of the agency's overall user training and awareness requirement. |
|
3 |
NZISM_v3.7 |
16.4.37.R.02. |
NZISM_v3.7_16.4.37.R.02. |
404 not found |
|
|
|
n/a |
n/a |
|
3 |
NZISM_v3.7 |
19.5.29.C.01. |
NZISM_v3.7_19.5.29.C.01. |
NZISM v3.7 19.5.29.C.01. |
Session Border Controllers |
19.5.29.C.01. - enhance security measures and protect agency assets. |
Shared |
n/a |
Agencies MUST develop and implement user awareness and training programmes to support and enable safe use of VoIP and UC services. |
|
3 |
NZISM_v3.7 |
2.1.49.C.01. |
NZISM_v3.7_2.1.49.C.01. |
NZISM v3.7 2.1.49.C.01. |
Overview of Key Agencies |
2.1.49.C.01. - facilitate collaboration and access to resources for effective security management and response. |
Shared |
n/a |
Security personnel MUST familiarise themselves with the information security roles and services provided by New Zealand Government organisations. |
|
4 |
NZISM_v3.7 |
3.3.13.C.01. |
NZISM_v3.7_3.3.13.C.01. |
NZISM v3.7 3.3.13.C.01. |
Information Technology Security Managers |
3.3.13.C.01. - foster a culture of security awareness and equipping personnel with the knowledge and skills to effectively mitigate security risks. |
Shared |
n/a |
ITSMs SHOULD provide or arrange for the provision of information security awareness and training for all agency personnel. |
|
4 |
NZISM_v3.7 |
5.1.12.C.02. |
NZISM_v3.7_5.1.12.C.02. |
NZISM v3.7 5.1.12.C.02. |
Documentation Fundamentals |
5.1.12.C.02. - enhance the agency's ability to mitigate risks and minimize disruptions to operations. |
Shared |
n/a |
Agency personnel MUST be trained in and periodically exercise the Incident Response Plan. |
|
4 |
NZISM_v3.7 |
5.7.4.C.01. |
NZISM_v3.7_5.7.4.C.01. |
NZISM v3.7 5.7.4.C.01. |
Emergency Procedures |
5.7.4.C.01. - ensure the protection of classified information and systems. |
Shared |
n/a |
Agencies MUST include in procedures for personnel evacuating a facility the requirement to secure classified information and systems prior to the evacuation. |
|
4 |
NZISM_v3.7 |
7.1.7.C.01. |
NZISM_v3.7_7.1.7.C.01. |
NZISM v3.7 7.1.7.C.01. |
Detecting Information Security Incidents |
7.1.7.C.01. - fortify information security measures. |
Shared |
n/a |
Agencies MUST develop, implement and maintain tools and procedures covering the detection of potential information security incidents, incorporating:
1. user awareness and training;
2. counter-measures against malicious code, known attack methods and types;
3. ntrusion detection strategies;
4. data egress monitoring & control;
5. access control anomalies;
6. audit analysis;
7. system integrity checking; and
8. vulnerability assessments. |
|
2 |
NZISM_v3.7 |
7.1.7.C.02. |
NZISM_v3.7_7.1.7.C.02. |
NZISM v3.7 7.1.7.C.02. |
Detecting Information Security Incidents |
7.1.7.C.02. - detecting potential security incidents. |
Shared |
n/a |
Agencies SHOULD develop, implement and maintain tools and procedures covering the detection of potential information security incidents, incorporating:
1. user awareness and training;
2. counter-measures against malicious code, known attack methods and types;
3. intrusion detection strategies;
4. data egress monitoring & control;
5. access control anomalies;
6. audit analysis;
7. system integrity checking; and
8. vulnerability assessments. |
|
2 |
NZISM_v3.7 |
7.1.7.C.03. |
NZISM_v3.7_7.1.7.C.03. |
NZISM v3.7 7.1.7.C.03. |
Detecting Information Security Incidents |
7.1.7.C.03. - optimize resource allocation and enhance overall security posture. |
Shared |
n/a |
Agencies SHOULD use the results of the security risk assessment to determine the appropriate balance of resources allocated to prevention versus resources allocated to detection of information security incidents. |
|
2 |
NZISM_v3.7 |
7.3.10.C.01. |
NZISM_v3.7_7.3.10.C.01. |
NZISM v3.7 7.3.10.C.01. |
Managing Information Security Incidents |
7.3.10.C.01. - ensure compliance with legal and regulatory requirements and mitigate potential risks. |
Shared |
n/a |
Agencies considering allowing an attacker to continue some actions under controlled conditions for the purpose of seeking further information or evidence SHOULD seek legal advice. |
|
2 |
NZISM_v3.7 |
7.3.11.C.01. |
NZISM_v3.7_7.3.11.C.01. |
NZISM v3.7 7.3.11.C.01. |
Managing Information Security Incidents |
7.3.11.C.01. - support comprehensive investigations and ensure accountability |
Shared |
n/a |
Agencies SHOULD:
1. transfer a copy of raw audit trails and other relevant data onto media for secure archiving, as well as securing manual log records for retention; and
2. ensure that all personnel involved in the investigation maintain a record of actions undertaken to support the investigation. |
|
8 |
NZISM_v3.7 |
7.3.12.C.01. |
NZISM_v3.7_7.3.12.C.01. |
NZISM v3.7 7.3.12.C.01. |
Managing Information Security Incidents |
7.3.12.C.01. - ensure that agencies promptly request assistance from the NCSC upon detecting an information security incident. |
Shared |
n/a |
Agencies SHOULD ensure that any requests for NCSC assistance are made as soon as possible after the information security incident is detected and that no actions which could affect the integrity of the evidence are carried out prior to NCSC's involvement. |
|
2 |
NZISM_v3.7 |
7.3.5.C.01. |
NZISM_v3.7_7.3.5.C.01. |
NZISM v3.7 7.3.5.C.01. |
Managing Information Security Incidents |
7.3.5.C.01. - establish clear accountability and effective incident response protocols. |
Shared |
n/a |
Agencies MUST detail information security incident responsibilities and procedures for each system in the relevant Information Security Documents. |
|
2 |
NZISM_v3.7 |
7.3.6.C.01. |
NZISM_v3.7_7.3.6.C.01. |
NZISM v3.7 7.3.6.C.01. |
Managing Information Security Incidents |
7.3.6.C.01. - enhance incident management and oversight. |
Shared |
n/a |
Agencies SHOULD ensure that all information security incidents are recorded in a register. |
|
8 |
NZISM_v3.7 |
7.3.6.C.02. |
NZISM_v3.7_7.3.6.C.02. |
NZISM v3.7 7.3.6.C.02. |
Managing Information Security Incidents |
7.3.6.C.02. - promote continuous improvement and informed decision-making. |
Shared |
n/a |
Agencies SHOULD use their incidents register as a reference for future security risk assessments. |
|
2 |
|
op.exp.7 Incident management |
op.exp.7 Incident management |
404 not found |
|
|
|
n/a |
n/a |
|
103 |
PCI_DSS_v4.0.1 |
12.10.1 |
PCI_DSS_v4.0.1_12.10.1 |
PCI DSS v4.0.1 12.10.1 |
Support Information Security with Organizational Policies and Programs |
Incident Response Plan |
Shared |
n/a |
An incident response plan exists and is ready to be activated in the event of a suspected or confirmed security incident. The plan includes, but is not limited to:
• Roles, responsibilities, and communication and contact strategies in the event of a suspected or confirmed security incident, including notification of payment brands and acquirers, at a minimum.
• Incident response procedures with specific containment and mitigation activities for different types of incidents.
• Business recovery and continuity procedures.
• Data backup processes.
• Analysis of legal requirements for reporting compromises.
• Coverage and responses of all critical system components.
• Reference or inclusion of incident response procedures from the payment brands. |
|
2 |
PCI_DSS_v4.0.1 |
12.10.2 |
PCI_DSS_v4.0.1_12.10.2 |
PCI DSS v4.0.1 12.10.2 |
Support Information Security with Organizational Policies and Programs |
Incident Response Review |
Shared |
n/a |
At least once every 12 months, the security incident response plan is:
• Reviewed and the content is updated as needed.
• Tested, including all elements listed in Requirement 12.10.1. |
|
1 |
PCI_DSS_v4.0.1 |
12.10.3 |
PCI_DSS_v4.0.1_12.10.3 |
PCI DSS v4.0.1 12.10.3 |
Support Information Security with Organizational Policies and Programs |
24/7 Incident Response Personnel |
Shared |
n/a |
Specific personnel are designated to be available on a 24/7 basis to respond to suspected or confirmed security incidents. |
|
1 |
PCI_DSS_v4.0.1 |
9.5.1 |
PCI_DSS_v4.0.1_9.5.1 |
PCI DSS v4.0.1 9.5.1 |
Restrict Physical Access to Cardholder Data |
Protection Measures for POI Devices Against Tampering and Unauthorized Substitution |
Shared |
n/a |
POI devices that capture payment card data via direct physical interaction with the payment card form factor are protected from tampering and unauthorized substitution, including the following:
• Maintaining a list of POI devices.
• Periodically inspecting POI devices to look for tampering or unauthorized substitution.
• Training personnel to be aware of suspicious behavior and to report tampering or unauthorized substitution of devices. |
|
9 |
PCI_DSS_v4.0.1 |
9.5.1.3 |
PCI_DSS_v4.0.1_9.5.1.3 |
PCI DSS v4.0.1 9.5.1.3 |
Restrict Physical Access to Cardholder Data |
Training for POI Environment Security |
Shared |
n/a |
Training is provided for personnel in POI environments to be aware of attempted tampering or replacement of POI devices, and includes:
• Verifying the identity of any third-party persons claiming to be repair or maintenance personnel, before granting them access to modify or troubleshoot devices.
• Procedures to ensure devices are not installed, replaced, or returned without verification.
• Being aware of suspicious behavior around devices.
• Reporting suspicious behavior and indications of device tampering or substitution to appropriate personnel |
|
2 |
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.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. |
|
6 |
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. |
|
13 |
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. |
|
15 |
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 |
9 |
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 |
12 |
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 |
20 |
RMiT_v1.0 |
11.18 |
RMiT_v1.0_11.18 |
RMiT 11.18 |
Security Operations Centre (SOC) |
Security Operations Centre (SOC) - 11.18 |
Shared |
n/a |
The SOC must be able to perform the following functions:
(a) log collection and the implementation of an event correlation engine with parameter-driven use cases such as Security Information and Event Management (SIEM);
(b) incident coordination and response;
(c) vulnerability management;
(d) threat hunting;
(e) remediation functions including the ability to perform forensic artifact handling, malware and implant analysis; and
(f) provision of situational awareness to detect adversaries and threats including threat intelligence analysis and operations, and monitoring indicators of compromise (IOC). This includes advanced behavioural analysis to detect signature-less and file-less malware and to identify anomalies that may pose security threats including at endpoints and network layers. |
link |
11 |
RMiT_v1.0 |
Appendix_5.7 |
RMiT_v1.0_Appendix_5.7 |
RMiT Appendix 5.7 |
Control Measures on Cybersecurity |
Control Measures on Cybersecurity - Appendix 5.7 |
Customer |
n/a |
Ensure overall network security controls are implemented including the following:
(a) dedicated firewalls at all segments. All external-facing firewalls must be deployed on High Availability (HA) configuration and “fail-close” mode activated. Deploy different brand name/model for two firewalls located in sequence within the same network path;
(b) IPS at all critical network segments with the capability to inspect and monitor encrypted network traffic;
(c) web and email filtering systems such as web-proxy, spam filter and anti-spoofing controls;
(d) endpoint protection solution to detect and remove security threats including viruses and malicious software;
(e) solution to mitigate advanced persistent threats including zero-day and signatureless malware; and
(f) capture the full network packets to rebuild relevant network sessions to aid forensics in the event of incidents. |
link |
21 |
Sarbanes_Oxley_Act_(1)_2022_1 |
Sarbanes_Oxley_Act_(1)_2022_1 |
Sarbanes_Oxley_Act_(1)_2022_1 |
Sarbanes Oxley Act 2022 1 |
PUBLIC LAW |
Sarbanes Oxley Act 2022 (SOX) |
Shared |
n/a |
n/a |
|
92 |
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 |
SOC_2023 |
A1.2 |
SOC_2023_A1.2 |
SOC 2023 A1.2 |
Additional Criteria for Availability |
Mitigate risks, maintain operational resilience, protect critical assets and data, ensure compliance, and achieve objectives effectively and efficiently. |
Shared |
n/a |
The entity authorizes, designs, develops or acquires, implements, operates, approves, maintains, and monitors environmental protections, software, data backup processes, and recovery infrastructure to meet its objectives. |
|
1 |
SOC_2023 |
CC1.4 |
SOC_2023_CC1.4 |
SOC 2023 CC1.4 |
Control Environment |
Ensure organizational resilience, innovation, and competitiveness in the long run. |
Shared |
n/a |
Entity demonstrates a commitment to attract, develop, and retain competent individuals in alignment with objectives by establishing policies and procedures, evaluating the competence required and address its shortcomings, attracts, develops and retains individuals through mentoring and training and plan and prepare for succession by developing contingency plans for assignments of responsibilities important for internal control. |
|
7 |
SOC_2023 |
CC2.2 |
SOC_2023_CC2.2 |
SOC 2023 CC2.2 |
Information and Communication |
Facilitate effective internal communication, including objectives and responsibilities for internal control. |
Shared |
n/a |
Entity internally communicates information, including objectives and responsibilities for internal control, necessary to support the functioning of internal control by setting up a process to communicate required information to enable personnel to understand and carry out responsibilities, ensure communication exists between management and board of directors, provides for separate communication channels which serve as fail-safe mechanism to enable anonymous or confidential communication and setting up relevant methods of communication by considering the timing, audience and nature information |
|
28 |
SOC_2023 |
CC2.3 |
SOC_2023_CC2.3 |
SOC 2023 CC2.3 |
Information and Communication |
Facilitate effective internal communication. |
Shared |
n/a |
Entity to communicate with external parties regarding matters affecting the functioning of internal control. |
|
218 |
SOC_2023 |
CC4.1 |
SOC_2023_CC4.1 |
SOC 2023 CC4.1 |
Monitoring Activities |
Enhance the ability to manage risks and achieve objectives. |
Shared |
n/a |
The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning. |
|
38 |
SOC_2023 |
CC5.3 |
SOC_2023_CC5.3 |
SOC 2023 CC5.3 |
Control Activities |
Maintain alignment with organizational objectives and regulatory requirements. |
Shared |
n/a |
Entity deploys control activities through policies that establish what is expected and in procedures that put policies into action by establishing Policies and Procedures to Support Deployment of Management’s Directives, Responsibility and Accountability for Executing Policies and Procedures, perform tasks in a timely manner, taking corrective actions, perform using competent personnel and reassess policies and procedures. |
|
229 |
SOC_2023 |
CC6.4 |
SOC_2023_CC6.4 |
SOC 2023 CC6.4 |
Logical and Physical Access Controls |
Safeguard against unauthorized entry, theft, or tampering. |
Shared |
n/a |
Entity restricts physical access to facilities and protected information assets (for example, data centre facilities, backup media storage, and other sensitive locations) to authorized personnel to meet the entity’s objectives. |
|
1 |
SOC_2023 |
CC6.7 |
SOC_2023_CC6.7 |
404 not found |
|
|
|
n/a |
n/a |
|
52 |
SOC_2023 |
CC7.3 |
SOC_2023_CC7.3 |
SOC 2023 CC7.3 |
Systems Operations |
Maintain operational resilience and mitigate the impact of security incidents on the ability to achieve objectives. |
Shared |
n/a |
The entity evaluates security events to determine whether they could or have resulted in a failure of the entity to meet its objectives (security incidents) and, if so, takes actions to prevent or address such failures. |
|
1 |
SOC_2023 |
CC7.4 |
SOC_2023_CC7.4 |
SOC 2023 CC7.4 |
Systems Operations |
Effectively manage security incidents, minimize their impact, and protect assets, operations, and reputation. |
Shared |
n/a |
The entity responds to identified security incidents by:
a. Executing a defined incident-response program to understand, contain, remediate, and communicate security incidents by assigning roles and responsibilities;
b. Establishing procedures to contain security incidents;
c. Mitigating ongoing security incidents, End Threats Posed by Security Incidents;
d. Restoring operations;
e. Developing and Implementing Communication Protocols for Security Incidents;
f. Obtains Understanding of Nature of Incident and Determines Containment Strategy;
g. Remediation Identified Vulnerabilities;
h. Communicating Remediation Activities; and,
i. Evaluating the Effectiveness of Incident Response and periodic incident evaluations. |
|
213 |
SOC_2023 |
CC7.5 |
SOC_2023_CC7.5 |
SOC 2023 CC7.5 |
Systems Operations |
Ensure prompt restoration of normal operations, mitigation of residual risks, and enhancement of incident response capabilities to minimize the impact of future incidents. |
Shared |
n/a |
The entity identifies, develops, and implements activities to recover from identified security incidents. |
|
12 |
SWIFT_CSCF_2024 |
11.3 |
SWIFT_CSCF_2024_11.3 |
404 not found |
|
|
|
n/a |
n/a |
|
2 |
SWIFT_CSCF_2024 |
7.1 |
SWIFT_CSCF_2024_7.1 |
SWIFT Customer Security Controls Framework 2024 7.1 |
Response Management |
Cyber Incident Response Planning |
Shared |
1. Availability and adequate resilience are of key importance to the business. In this respect, defining and testing a cyber incident response plan is a highly effective way of reducing the impact and duration of a real cyber incident.
2. As lessons are learnt either by testing this plan, or through real incidents, it is essential to apply these learnings and improve the plan.
3. Planning for the sharing of threat and incident information is also critical in helping the broader financial community to implement effective protection against cyber-attacks. |
To ensure a consistent and effective approach for the management of cyber incidents. |
|
1 |
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 |
UK_NCSC_CAF_v3.2 |
D |
UK_NCSC_CAF_v3.2_D |
404 not found |
|
|
|
n/a |
n/a |
|
1 |
UK_NCSC_CAF_v3.2 |
D1 |
UK_NCSC_CAF_v3.2_D1 |
404 not found |
|
|
|
n/a |
n/a |
|
2 |