Az Policy Advertizer

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

C.05.5 - Monitored and reported

404 not found

n/a

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.

CMMC_2.0_L2

IR.L2-3.6.2

CMMC_2.0_L2_IR.L2-3.6.2

404 not found

n/a

CMMC_2.0_L2

SI.L2-3.14.3

CMMC_2.0_L2_SI.L2-3.14.3

404 not found

n/a

CMMC_2.0_L2

SI.L2-3.14.6

CMMC_2.0_L2_SI.L2-3.14.6

404 not found

n/a

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.

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.

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.

EU_GDPR_2016_679_Art._24

EU General Data Protection Regulation (GDPR) 2016/679 Art. 24

Chapter 4 - Controller and processor

Responsibility of the controller

Shared

n/a

306

EU_GDPR_2016_679_Art._25

EU General Data Protection Regulation (GDPR) 2016/679 Art. 25

Chapter 4 - Controller and processor

Data protection by design and by default

Shared

n/a

306

EU_GDPR_2016_679_Art._28

EU General Data Protection Regulation (GDPR) 2016/679 Art. 28

Chapter 4 - Controller and processor

Processor

Shared

n/a

306

EU_GDPR_2016_679_Art._32

EU General Data Protection Regulation (GDPR) 2016/679 Art. 32

Chapter 4 - Controller and processor

Security of processing

Shared

n/a

306

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.

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.

FedRAMP_Moderate_R4

IR-4

FedRAMP_Moderate_R4_IR-4

FedRAMP Moderate IR-4

Incident Response

Incident Handling

Shared

n/a

FedRAMP_Moderate_R4

IR-5

FedRAMP_Moderate_R4_IR-5

FedRAMP Moderate IR-5

Incident Response

Incident Monitoring

Shared

n/a

New_Zealand_ISM_07.2.22.C.01

K_ISMS_P_2018

2.10.1

K_ISMS_P_2018_2.10.1

K ISMS P 2018 2.10.1

2.10

Establish Procedures for Managing the Security of System Operations

Shared

n/a

Establish and implement operating procedures for managing the security of system operations such as designating system administrators, updating policies, changing rulesets, monitoring events, managing policy implementations or exceptions.

408

K_ISMS_P_2018

2.10.2

K_ISMS_P_2018_2.10.2

K ISMS P 2018 2.10.2

2.10

Establish Protective Measures for Administrator Privileges and Security Configurations

Shared

n/a

Establish and implement protective measures with regard to administrator privileges and security configurations to ensure that important information and personal information are not exposed as a result of unauthorized access by service type or misconfigurations.

385

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.

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

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.

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.

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.

IR-4

NIST_SP_800-53_R4_IR-4

NIST SP 800-53 Rev. 4 IR-4

Incident Response

Incident Handling

Shared

n/a

IR-5

NIST_SP_800-53_R4_IR-5

NIST SP 800-53 Rev. 4 IR-5

Incident Response

Incident Monitoring

Shared

n/a

NIST_SP_800-53_R4_IR-6(2)

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].

NIST_SP_800-53_R4_SI-4(12)

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].

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.

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.

NIST_SP_800-53_R5_IR-6(2)

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].

NIST_SP_800-53_R5_SI-4(12)

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].

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.

op.exp.7 Incident management

404 not found

n/a

103

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;

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:

RBI_CSF_Banks_v2016_19.6b

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.

RBI_CSF_Banks_v2016_19.6c

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

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.

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.

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.

RBI_ITF_NBFC_v2017

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.

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.

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.

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.

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

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.

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

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

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.

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.