AzPolicyAdvertizer

last sync: 2024-Apr-19 17:43:58 UTC

Establish a risk management strategy | Regulatory Compliance - Operational

Azure BuiltIn Policy definition

Source Azure Portal
Display name Establish a risk management strategy
Id d36700f2-2f0d-7c2a-059c-bdadd1d79f70
Version 1.1.0
Details on versioning
Category Regulatory Compliance
Microsoft Learn
Description CMA_0258 - Establish a risk management strategy
Additional metadata Name/Id: CMA_0258 / CMA_0258
Category: Operational
Title: Establish a risk management strategy
Ownership: Customer
Description: Microsoft recommends that your organization establish a comprehensive risk management strategy addressing processes to understand, assess, treat, and manage technical, environmental, and financial risks to your organization's operations, assets, people, and third parties. Ideally, the risk management strategy will identify the following: - Objectives - Risk assessment tools and techniques - Risk factors (i.e., Threat sources) - Risk treatment options (i.e., Modify/reduce risk, retain risk, etc.) - Risk tolerance and criteria for risk acceptance, including multiple thresholds with a desired target level of risk, requirements for future additional treatment, expressed as the ratio of estimated profit to the estimated risk - Risk treatment plans - Perform cost benefit analysis prior to selecting treatment plans or mitigating controls - Roles and responsibilities, including staffing requirements to run the risk program, competencies and qualifications needed, and separation of duties It is also recommended that your organization appoint a Chief Risk Officer (CRO) or risk manager responsible for handling organizational risks. The CRO may report to the Senior management or management board and be responsible for managing risks relating to business or compliance with applicable acts and regulations. We recommend that the Chief Risk Officer or risk manager manage the communications related to risk with internal and external stakeholders. This role may also be responsible for measuring the performance of the risk management process prior to and when changes are made within the organization. In addition to a CRO in some organizations, especially financial organizations, it is recommended that a three-line defense approach be taken. These three lines are commonly business unit management, an independent corporate operational risk management function, and independent assurance. The first line of defense is typically responsible for identifying and managing the risks inherent in the products, activities, processes, and systems for which the business unit is responsible for. The second line of defense typically develops and provides an independent view regarding a business unit's risk and an assessment of the effectiveness of key controls. The third line typically provides independent assurance to the board and usually involves internal and external audit. Microsoft recommends the organization's risk strategy be agreed to by organizational stakeholders and undergo regular review. Where necessary, organization management can record the decision to accept the risks and responsibilities. This information along with other relevant information can be documented in a risk file. Ongoing monitoring for emerging risks and periodic review of all risk management processes and their outcomes can be conducted to drive continuous improvement. It is also recommended that your organization consider including an exit mechanism as part of your organization's risk management when there is a business or financial deterioration. Taiwan's Implementation Rules of Internal Audit and Internal Control System of Financial Holding Companies and Banking Industries states that organizations must implement finance-related risk principles and guidelines to establish the mechanisms for measuring and monitoring the capital adequacy, liquidity positions and liabilities to manage liquidity and investment risks. The German Minimum Requirements for Risk Management (MaRisk BA) requires: - The management board members of the superordinate enterprise of a group of institutions or a financing holding group as well as the management board members of the superordinate financial conglomerate enterprise of a financial conglomerate to be responsible for establishing appropriate and effective risk management at group level - All members of the management board to be responsible for ensuring an institution's proper business organization, taking account of all material elements of risk management, and carrying out the responsibility to assess risks and take the necessary measures to limit them - The management board to define a risk strategy that is consistent with the business strategy, risk management objectives for key business activities, and measures to be taken to achieve those objectives - The management board to be responsible for defining, reviewing, and adjusting risk management strategies (this responsibility cannot be delegated) - Where applicable, adjustments to the strategies shall be brought to the attention of and discussed with the institution's supervisory board - Communicate adjustments to the strategies within the institution in a suitable manner Revisions to the principles for the sound management of operational risk require banks to have policies and procedures for the review and approval of new products, activities, processes and systems and consider inherent risks in the launch of new products, services, activities, operations in unfamiliar markets, and in the implementation of new processes, people and systems, changes to the bank's operational risk profile, appetite and tolerance, including changes to the risk of existing products or activities, necessary controls, risk management processes, and risk mitigation strategies, the residual risk and changes to relevant risk thresholds or limits and ensure appropriate investment has been made for human resources and technology infrastructure before changes are introduced. The guidelines shall also ensure the operational risk assessment tools' outputs are based on accurate data and consideration of pricing and performance measurement mechanisms as subject to CORF (corporate operational risk function) monitored action or remediation plans when necessary and have unified classification, methodology, procedures of operational risk management established by the CORF.
Requirements: The customer is responsible for implementing this recommendation.
Mode All
Type BuiltIn
Preview False
Deprecated False
Effect Default
Manual
Allowed
Manual, Disabled
RBAC role(s) none
Rule aliases none
Rule resource types IF (1)
Microsoft.Resources/subscriptions
Compliance
The following 56 compliance controls are associated with this Policy definition 'Establish a risk management strategy' (d36700f2-2f0d-7c2a-059c-bdadd1d79f70)
Control Domain Control Name MetadataId Category Title Owner Requirements Description Info Policy#
FedRAMP_High_R4 CM-3 FedRAMP_High_R4_CM-3 FedRAMP High CM-3 Configuration Management Configuration Change Control Shared n/a The organization: a. Determines the types of changes to the information system that are configuration-controlled; b. Reviews proposed configuration-controlled changes to the information system and approves or disapproves such changes with explicit consideration for security impact analyses; c. Documents configuration change decisions associated with the information system; d. Implements approved configuration-controlled changes to the information system; e. Retains records of configuration-controlled changes to the information system for [Assignment: organization-defined time period]; f. Audits and reviews activities associated with configuration-controlled changes to the information system; and g. Coordinates and provides oversight for configuration change control activities through [Assignment: organization-defined configuration change control element (e.g., committee, board] that convenes [Selection (one or more): [Assignment: organization-defined frequency]; [Assignment: organization-defined configuration change conditions]]. Supplemental Guidance: Configuration change controls for organizational information systems involve the systematic proposal, justification, implementation, testing, review, and disposition of changes to the systems, including system upgrades and modifications. Configuration change control includes changes to baseline configurations for components and configuration items of information systems, changes to configuration settings for information technology products (e.g., operating systems, applications, firewalls, routers, and mobile devices), unscheduled/unauthorized changes, and changes to remediate vulnerabilities. Typical processes for managing configuration changes to information systems include, for example, Configuration Control Boards that approve proposed changes to systems. For new development information systems or systems undergoing major upgrades, organizations consider including representatives from development organizations on the Configuration Control Boards. Auditing of changes includes activities before and after changes are made to organizational information systems and the auditing activities required to implement such changes. Related controls: CM-2, CM-4, CM-5, CM-6, CM-9, SA-10, SI-2, SI-12. References: NIST Special Publication 800-128. link 8
FedRAMP_High_R4 CM-4 FedRAMP_High_R4_CM-4 FedRAMP High CM-4 Configuration Management Security Impact Analysis Shared n/a The organization analyzes changes to the information system to determine potential security impacts prior to change implementation. Supplemental Guidance: Organizational personnel with information security responsibilities (e.g., Information System Administrators, Information System Security Officers, Information System Security Managers, and Information System Security Engineers) conduct security impact analyses. Individuals conducting security impact analyses possess the necessary skills/technical expertise to analyze the changes to information systems and the associated security ramifications. Security impact analysis may include, for example, reviewing security plans to understand security control requirements and reviewing system design documentation to understand control implementation and how specific changes might affect the controls. Security impact analyses may also include assessments of risk to better understand the impact of the changes and to determine if additional security controls are required. Security impact analyses are scaled in accordance with the security categories of the information systems. Related controls: CA-2, CA-7, CM-3, CM-9, SA-4, SA-5, SA-10, SI-2. References: NIST Special Publication 800-128. link 8
FedRAMP_Moderate_R4 CM-3 FedRAMP_Moderate_R4_CM-3 FedRAMP Moderate CM-3 Configuration Management Configuration Change Control Shared n/a The organization: a. Determines the types of changes to the information system that are configuration-controlled; b. Reviews proposed configuration-controlled changes to the information system and approves or disapproves such changes with explicit consideration for security impact analyses; c. Documents configuration change decisions associated with the information system; d. Implements approved configuration-controlled changes to the information system; e. Retains records of configuration-controlled changes to the information system for [Assignment: organization-defined time period]; f. Audits and reviews activities associated with configuration-controlled changes to the information system; and g. Coordinates and provides oversight for configuration change control activities through [Assignment: organization-defined configuration change control element (e.g., committee, board] that convenes [Selection (one or more): [Assignment: organization-defined frequency]; [Assignment: organization-defined configuration change conditions]]. Supplemental Guidance: Configuration change controls for organizational information systems involve the systematic proposal, justification, implementation, testing, review, and disposition of changes to the systems, including system upgrades and modifications. Configuration change control includes changes to baseline configurations for components and configuration items of information systems, changes to configuration settings for information technology products (e.g., operating systems, applications, firewalls, routers, and mobile devices), unscheduled/unauthorized changes, and changes to remediate vulnerabilities. Typical processes for managing configuration changes to information systems include, for example, Configuration Control Boards that approve proposed changes to systems. For new development information systems or systems undergoing major upgrades, organizations consider including representatives from development organizations on the Configuration Control Boards. Auditing of changes includes activities before and after changes are made to organizational information systems and the auditing activities required to implement such changes. Related controls: CM-2, CM-4, CM-5, CM-6, CM-9, SA-10, SI-2, SI-12. References: NIST Special Publication 800-128. link 8
FedRAMP_Moderate_R4 CM-4 FedRAMP_Moderate_R4_CM-4 FedRAMP Moderate CM-4 Configuration Management Security Impact Analysis Shared n/a The organization analyzes changes to the information system to determine potential security impacts prior to change implementation. Supplemental Guidance: Organizational personnel with information security responsibilities (e.g., Information System Administrators, Information System Security Officers, Information System Security Managers, and Information System Security Engineers) conduct security impact analyses. Individuals conducting security impact analyses possess the necessary skills/technical expertise to analyze the changes to information systems and the associated security ramifications. Security impact analysis may include, for example, reviewing security plans to understand security control requirements and reviewing system design documentation to understand control implementation and how specific changes might affect the controls. Security impact analyses may also include assessments of risk to better understand the impact of the changes and to determine if additional security controls are required. Security impact analyses are scaled in accordance with the security categories of the information systems. Related controls: CA-2, CA-7, CM-3, CM-9, SA-4, SA-5, SA-10, SI-2. References: NIST Special Publication 800-128. link 8
hipaa 0121.05a2Organizational.12-05.a hipaa-0121.05a2Organizational.12-05.a 0121.05a2Organizational.12-05.a 01 Information Protection Program 0121.05a2Organizational.12-05.a 05.01 Internal Organization Shared n/a The organization's information protection and risk management programs, including the risk assessment process, are formally approved, and are reviewed for effectiveness and updated annually. 6
hipaa 0179.05h1Organizational.4-05.h hipaa-0179.05h1Organizational.4-05.h 0179.05h1Organizational.4-05.h 01 Information Protection Program 0179.05h1Organizational.4-05.h 05.01 Internal Organization Shared n/a If an independent review identifies that the organization's approach and implementation to managing information security is inadequate or not compliant with the direction for information security stated in the information security policy document, management takes corrective actions. 3
hipaa 0618.09b1System.1-09.b hipaa-0618.09b1System.1-09.b 0618.09b1System.1-09.b 06 Configuration Management 0618.09b1System.1-09.b 09.01 Documented Operating Procedures Shared n/a Changes to information assets, including systems, networks, and network services, are controlled and archived. 16
hipaa 0638.10k2Organizational.34569-10.k hipaa-0638.10k2Organizational.34569-10.k 0638.10k2Organizational.34569-10.k 06 Configuration Management 0638.10k2Organizational.34569-10.k 10.05 Security In Development and Support Processes Shared n/a Changes are formally controlled, documented, and enforced in order to minimize the corruption of information systems. 14
hipaa 0641.10k2Organizational.11-10.k hipaa-0641.10k2Organizational.11-10.k 0641.10k2Organizational.11-10.k 06 Configuration Management 0641.10k2Organizational.11-10.k 10.05 Security In Development and Support Processes Shared n/a The organization does not use automated updates on critical systems. 13
hipaa 0643.10k3Organizational.3-10.k hipaa-0643.10k3Organizational.3-10.k 0643.10k3Organizational.3-10.k 06 Configuration Management 0643.10k3Organizational.3-10.k 10.05 Security In Development and Support Processes Shared n/a The organization (i) establishes and documents mandatory configuration settings for information technology products employed within the information system using the latest security configuration baselines; (ii) identifies, documents, and approves exceptions from the mandatory established configuration settings for individual components based on explicit operational requirements; and, (iii) monitors and controls changes to the configuration settings in accordance with organizational policies and procedures. 17
hipaa 0672.10k3System.5-10.k hipaa-0672.10k3System.5-10.k 0672.10k3System.5-10.k 06 Configuration Management 0672.10k3System.5-10.k 10.05 Security In Development and Support Processes Shared n/a The integrity of all virtual machine images is ensured at all times by (i) logging and raising an alert for any changes made to virtual machine images, and (ii) making available to the business owner(s) and/or customer(s) through electronic methods (e.g., portals or alerts) the results of a change or move and the subsequent validation of the image's integrity. 12
hipaa 0821.09m2Organizational.2-09.m hipaa-0821.09m2Organizational.2-09.m 0821.09m2Organizational.2-09.m 08 Network Protection 0821.09m2Organizational.2-09.m 09.06 Network Security Management Shared n/a The organization tests and approves all network connections and firewall, router, and switch configuration changes prior to implementation. Any deviations from the standard configuration or updates to the standard configuration are documented and approved in a change control system. All new configuration rules beyond a baseline-hardened configuration that allow traffic to flow through network security devices, such as firewalls and network-based IPS, are also documented and recorded, with a specific business reason for each change, a specific individual’s name responsible for that business need, and an expected duration of the need. 18
hipaa 0863.09m2Organizational.910-09.m hipaa-0863.09m2Organizational.910-09.m 0863.09m2Organizational.910-09.m 08 Network Protection 0863.09m2Organizational.910-09.m 09.06 Network Security Management Shared n/a The organization builds a firewall configuration that restricts connections between untrusted networks and any system components in the covered information environment; and any changes to the firewall configuration are updated in the network diagram. 25
hipaa 1208.09aa3System.1-09.aa hipaa-1208.09aa3System.1-09.aa 1208.09aa3System.1-09.aa 12 Audit Logging & Monitoring 1208.09aa3System.1-09.aa 09.10 Monitoring Shared n/a Audit logs are maintained for management activities, system and application startup/shutdown/errors, file changes, and security policy changes. 18
hipaa 1314.02e2Organizational.5-02.e hipaa-1314.02e2Organizational.5-02.e 1314.02e2Organizational.5-02.e 13 Education, Training and Awareness 1314.02e2Organizational.5-02.e 02.03 During Employment Shared n/a The organization conducts an internal annual review of the effectiveness of its security and privacy education and training program, and updates the program to reflect risks identified in the organization's risk assessment. 4
hipaa 17126.03c1System.6-03.c hipaa-17126.03c1System.6-03.c 17126.03c1System.6-03.c 17 Risk Management 17126.03c1System.6-03.c 03.01 Risk Management Program Shared n/a The organization has implemented an integrated control system characterized using different control types (e.g., layered, preventative, detective, corrective, and compensating) that mitigates identified risks. 3
hipaa 1733.03d1Organizational.1-03.d hipaa-1733.03d1Organizational.1-03.d 1733.03d1Organizational.1-03.d 17 Risk Management 1733.03d1Organizational.1-03.d 03.01 Risk Management Program Shared n/a The risk management program includes the requirement that risk assessments be re-evaluated at least annually, or when there are significant changes in the environment. 3
hipaa 1734.03d2Organizational.1-03.d hipaa-1734.03d2Organizational.1-03.d 1734.03d2Organizational.1-03.d 17 Risk Management 1734.03d2Organizational.1-03.d 03.01 Risk Management Program Shared n/a The risk management process is integrated with the change management process within the organization. 8
hipaa 1735.03d2Organizational.23-03.d hipaa-1735.03d2Organizational.23-03.d 1735.03d2Organizational.23-03.d 17 Risk Management 1735.03d2Organizational.23-03.d 03.01 Risk Management Program Shared n/a Risk assessments are conducted whenever there is a significant change in the environment, or a change that could have a significant impact, and the results of the assessments are included in the change management process, so they may guide the decisions within the change management process (e.g., approvals for changes). 8
hipaa 1737.03d2Organizational.5-03.d hipaa-1737.03d2Organizational.5-03.d 1737.03d2Organizational.5-03.d 17 Risk Management 1737.03d2Organizational.5-03.d 03.01 Risk Management Program Shared n/a The privacy, security and risk management program(s) is/are updated to reflect changes in risks. 4
ISO27001-2013 A.12.1.2 ISO27001-2013_A.12.1.2 ISO 27001:2013 A.12.1.2 Operations Security Change management Shared n/a Changes to organization, business processes, information processing facilities and systems that affect information security shall be controlled. link 27
ISO27001-2013 A.12.5.1 ISO27001-2013_A.12.5.1 ISO 27001:2013 A.12.5.1 Operations Security Installation of software on operational systems Shared n/a Procedures shall be implemented to control the installation of software on operational systems. link 19
ISO27001-2013 A.12.6.2 ISO27001-2013_A.12.6.2 ISO 27001:2013 A.12.6.2 Operations Security Restrictions on software installation Shared n/a Rules governing the installation of software by users shall be established and implemented. link 19
ISO27001-2013 A.14.2.2 ISO27001-2013_A.14.2.2 ISO 27001:2013 A.14.2.2 System Acquisition, Development And Maintenance System change control procedures Shared n/a Changes to systems within the development lifecycle shall be controlled by the use of formal change control procedures. link 25
ISO27001-2013 A.14.2.3 ISO27001-2013_A.14.2.3 ISO 27001:2013 A.14.2.3 System Acquisition, Development And Maintenance Technical review of applications after operating platform changes Shared n/a When operating platforms are changed, business critical applications shall be reviewed and tested to ensure there is no adverse impact on organizational operations or security. link 18
ISO27001-2013 A.14.2.4 ISO27001-2013_A.14.2.4 ISO 27001:2013 A.14.2.4 System Acquisition, Development And Maintenance Restrictions on changes to software packages Shared n/a Modifications to software packages shall be discouraged, limited to necessary changes and all changes shall be strictly controlled. link 24
ISO27001-2013 A.18.1.1 ISO27001-2013_A.18.1.1 ISO 27001:2013 A.18.1.1 Compliance Identification applicable legislation and contractual requirements Shared n/a All relevant legislative statutory, regulatory, contractual requirements and the organization's approach to meet these requirements shall be explicitly identified, documented and kept up to date for each information system and the organization. link 30
ISO27001-2013 A.18.2.1 ISO27001-2013_A.18.2.1 ISO 27001:2013 A.18.2.1 Compliance Independent review of information security Shared n/a The organization's approach to managing information security and its implementation (i.e. control objectives, controls, policies, processes, and procedures for information security) shall be reviewed independently at planned intervals, or when significant changes occur. link 2
ISO27001-2013 C.6.1.1.a ISO27001-2013_C.6.1.1.a ISO 27001:2013 C.6.1.1.a Planning General Shared n/a When planning for the information security management system, the organization shall consider the issues referred to in 4.1 and the requirements referred to in 4.2 and determine the risks and opportunities that need to be addressed to: a) ensure the information security management system can achieve its intended outcome(s). link 3
ISO27001-2013 C.6.1.1.b ISO27001-2013_C.6.1.1.b ISO 27001:2013 C.6.1.1.b Planning General Shared n/a When planning for the information security management system, the organization shall consider the issues referred to in 4.1 and the requirements referred to in 4.2 and determine the risks and opportunities that need to be addressed to: b) prevent, or reduce, undesired effects. link 3
ISO27001-2013 C.6.1.1.c ISO27001-2013_C.6.1.1.c ISO 27001:2013 C.6.1.1.c Planning General Shared n/a When planning for the information security management system, the organization shall consider the issues referred to in 4.1 and the requirements referred to in 4.2 and determine the risks and opportunities that need to be addressed to: c) achieve continual improvement. link 3
ISO27001-2013 C.6.1.1.d ISO27001-2013_C.6.1.1.d ISO 27001:2013 C.6.1.1.d Planning General Shared n/a When planning for the information security management system, the organization shall consider the issues referred to in 4.1 and the requirements referred to in 4.2 and determine the risks and opportunities that need to be addressed. The organization shall plan: d) actions to address these risks and opportunities. link 3
ISO27001-2013 C.6.1.1.e.1 ISO27001-2013_C.6.1.1.e.1 ISO 27001:2013 C.6.1.1.e.1 Planning General Shared n/a When planning for the information security management system, the organization shall consider the issues referred to in 4.1 and the requirements referred to in 4.2 and determine the risks and opportunities that need to be addressed. The organization shall plan: e) how to - 1) integrate and implement the actions into its information security management system processes. link 3
ISO27001-2013 C.6.1.1.e.2 ISO27001-2013_C.6.1.1.e.2 ISO 27001:2013 C.6.1.1.e.2 Planning General Shared n/a When planning for the information security management system, the organization shall consider the issues referred to in 4.1 and the requirements referred to in 4.2 and determine the risks and opportunities that need to be addressed. The organization shall plan: e) how to - 2) evaluate the effectiveness of these actions. link 3
ISO27001-2013 C.6.1.2.a.1 ISO27001-2013_C.6.1.2.a.1 ISO 27001:2013 C.6.1.2.a.1 Planning Information security risk assessment Shared n/a The organization shall define and apply an information security risk assessment process that: a) establishes and maintains information security risk criteria that include: - 1) the risk acceptance criteria. The organization shall retain documented information about the information security risk assessment process. link 2
ISO27001-2013 C.6.1.2.a.2 ISO27001-2013_C.6.1.2.a.2 ISO 27001:2013 C.6.1.2.a.2 Planning Information security risk assessment Shared n/a The organization shall define and apply an information security risk assessment process that: a) establishes and maintains information security risk criteria that include: - 2) criteria for performing information security risk assessments. The organization shall retain documented information about the information security risk assessment process. link 2
NIST_SP_800-171_R2_3 .12.2 NIST_SP_800-171_R2_3.12.2 NIST SP 800-171 R2 3.12.2 Security Assessment Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems. Shared Microsoft and the customer share responsibilities for implementing this requirement. The plan of action is a key document in the information security program. Organizations develop plans of action that describe how any unimplemented security requirements will be met and how any planned mitigations will be implemented. Organizations can document the system security plan and plan of action as separate or combined documents and in any chosen format. Federal agencies may consider the submitted system security plans and plans of action as critical inputs to an overall risk management decision to process, store, or transmit CUI on a system hosted by a nonfederal organization and whether it is advisable to pursue an agreement or contract with the nonfederal organization. [NIST CUI] provides supplemental material for Special Publication 800-171 including templates for plans of action. link 4
NIST_SP_800-171_R2_3 .4.3 NIST_SP_800-171_R2_3.4.3 NIST SP 800-171 R2 3.4.3 Configuration Management Track, review, approve or disapprove, and log changes to organizational systems. Shared Microsoft and the customer share responsibilities for implementing this requirement. Tracking, reviewing, approving/disapproving, and logging changes is called configuration change control. Configuration change control for organizational systems involves the systematic proposal, justification, implementation, testing, review, and disposition of changes to the systems, including system upgrades and modifications. Configuration change control includes changes to baseline configurations for components and configuration items of systems, changes to configuration settings for information technology products (e.g., operating systems, applications, firewalls, routers, and mobile devices), unscheduled and unauthorized changes, and changes to remediate vulnerabilities. Processes for managing configuration changes to systems include Configuration Control Boards or Change Advisory Boards that review and approve proposed changes to systems. For new development systems or systems undergoing major upgrades, organizations consider including representatives from development organizations on the Configuration Control Boards or Change Advisory Boards. Audit logs of changes include activities before and after changes are made to organizational systems and the activities required to implement such changes. [SP 800-128] provides guidance on configuration change control. link 15
NIST_SP_800-171_R2_3 .4.4 NIST_SP_800-171_R2_3.4.4 NIST SP 800-171 R2 3.4.4 Configuration Management Analyze the security impact of changes prior to implementation. Shared Microsoft and the customer share responsibilities for implementing this requirement. Organizational personnel with information security responsibilities (e.g., system administrators, system security officers, system security managers, and systems security engineers) conduct security impact analyses. Individuals conducting security impact analyses possess the necessary skills and technical expertise to analyze the changes to systems and the associated security ramifications. Security impact analysis may include reviewing security plans to understand security requirements and reviewing system design documentation to understand the implementation of controls and how specific changes might affect the controls. Security impact analyses may also include risk assessments to better understand the impact of the changes and to determine if additional controls are required. [SP 800-128] provides guidance on configuration change control and security impact analysis. link 8
NIST_SP_800-53_R4 CM-3 NIST_SP_800-53_R4_CM-3 NIST SP 800-53 Rev. 4 CM-3 Configuration Management Configuration Change Control Shared n/a The organization: a. Determines the types of changes to the information system that are configuration-controlled; b. Reviews proposed configuration-controlled changes to the information system and approves or disapproves such changes with explicit consideration for security impact analyses; c. Documents configuration change decisions associated with the information system; d. Implements approved configuration-controlled changes to the information system; e. Retains records of configuration-controlled changes to the information system for [Assignment: organization-defined time period]; f. Audits and reviews activities associated with configuration-controlled changes to the information system; and g. Coordinates and provides oversight for configuration change control activities through [Assignment: organization-defined configuration change control element (e.g., committee, board] that convenes [Selection (one or more): [Assignment: organization-defined frequency]; [Assignment: organization-defined configuration change conditions]]. Supplemental Guidance: Configuration change controls for organizational information systems involve the systematic proposal, justification, implementation, testing, review, and disposition of changes to the systems, including system upgrades and modifications. Configuration change control includes changes to baseline configurations for components and configuration items of information systems, changes to configuration settings for information technology products (e.g., operating systems, applications, firewalls, routers, and mobile devices), unscheduled/unauthorized changes, and changes to remediate vulnerabilities. Typical processes for managing configuration changes to information systems include, for example, Configuration Control Boards that approve proposed changes to systems. For new development information systems or systems undergoing major upgrades, organizations consider including representatives from development organizations on the Configuration Control Boards. Auditing of changes includes activities before and after changes are made to organizational information systems and the auditing activities required to implement such changes. Related controls: CM-2, CM-4, CM-5, CM-6, CM-9, SA-10, SI-2, SI-12. References: NIST Special Publication 800-128. link 8
NIST_SP_800-53_R4 CM-4 NIST_SP_800-53_R4_CM-4 NIST SP 800-53 Rev. 4 CM-4 Configuration Management Security Impact Analysis Shared n/a The organization analyzes changes to the information system to determine potential security impacts prior to change implementation. Supplemental Guidance: Organizational personnel with information security responsibilities (e.g., Information System Administrators, Information System Security Officers, Information System Security Managers, and Information System Security Engineers) conduct security impact analyses. Individuals conducting security impact analyses possess the necessary skills/technical expertise to analyze the changes to information systems and the associated security ramifications. Security impact analysis may include, for example, reviewing security plans to understand security control requirements and reviewing system design documentation to understand control implementation and how specific changes might affect the controls. Security impact analyses may also include assessments of risk to better understand the impact of the changes and to determine if additional security controls are required. Security impact analyses are scaled in accordance with the security categories of the information systems. Related controls: CA-2, CA-7, CM-3, CM-9, SA-4, SA-5, SA-10, SI-2. References: NIST Special Publication 800-128. link 8
NIST_SP_800-53_R5 CM-3 NIST_SP_800-53_R5_CM-3 NIST SP 800-53 Rev. 5 CM-3 Configuration Management Configuration Change Control Shared n/a a. Determine and document the types of changes to the system that are configuration-controlled; b. Review proposed configuration-controlled changes to the system and approve or disapprove such changes with explicit consideration for security and privacy impact analyses; c. Document configuration change decisions associated with the system; d. Implement approved configuration-controlled changes to the system; e. Retain records of configuration-controlled changes to the system for [Assignment: organization-defined time period]; f. Monitor and review activities associated with configuration-controlled changes to the system; and g. Coordinate and provide oversight for configuration change control activities through [Assignment: organization-defined configuration change control element] that convenes [Selection (OneOrMore): [Assignment: organization-defined frequency] ;when [Assignment: organization-defined configuration change conditions] ] . link 8
NIST_SP_800-53_R5 CM-4 NIST_SP_800-53_R5_CM-4 NIST SP 800-53 Rev. 5 CM-4 Configuration Management Impact Analyses Shared n/a Analyze changes to the system to determine potential security and privacy impacts prior to change implementation. link 8
PCI_DSS_v4.0 1.2.2 PCI_DSS_v4.0_1.2.2 PCI DSS v4.0 1.2.2 Requirement 01: Install and Maintain Network Security Controls Network security controls (NSCs) are configured and maintained Shared n/a All changes to network connections and to configurations of NSCs are approved and managed in accordance with the change control process defined at Requirement 6.5.1. link 8
PCI_DSS_v4.0 5.3.5 PCI_DSS_v4.0_5.3.5 PCI DSS v4.0 5.3.5 Requirement 05: Protect All Systems and Networks from Malicious Software Anti-malware mechanisms and processes are active, maintained, and monitored Shared n/a Anti-malware mechanisms cannot be disabled or altered by users, unless specifically documented, and authorized by management on a case-by-case basis for a limited time period. link 8
PCI_DSS_v4.0 6.5.1 PCI_DSS_v4.0_6.5.1 PCI DSS v4.0 6.5.1 Requirement 06: Develop and Maintain Secure Systems and Software Changes to all system components are managed securely Shared n/a Changes to all system components in the production environment are made according to established procedures that include: • Reason for, and description of, the change. • Documentation of security impact. • Documented change approval by authorized parties. • Testing to verify that the change does not adversely impact system security. • For bespoke and custom software changes, all updates are tested for compliance with Requirement 6.2.4 before being deployed into production. • Procedures to address failures and return to a secure state. link 8
SOC_2 CC1.2 SOC_2_CC1.2 SOC 2 Type 2 CC1.2 Control Environment COSO Principle 2 Shared The customer is responsible for implementing this recommendation. • Establishes Oversight Responsibilities — The board of directors identifies and accepts its oversight responsibilities in relation to established requirements and expectations. • Applies Relevant Expertise — The board of directors defines, maintains, and periodically evaluates the skills and expertise needed among its members to enable them to ask probing questions of senior management and take commensurate action. • Operates Independently — The board of directors has sufficient members who are independent from management and objective in evaluations and decision making. 5
SOC_2 CC1.3 SOC_2_CC1.3 SOC 2 Type 2 CC1.3 Control Environment COSO Principle 3 Shared The customer is responsible for implementing this recommendation. Considers All Structures of the Entity — Management and the board of directors consider the multiple structures used (including operating units, legal entities, geographic distribution, and outsourced service providers) to support the achievement of objectives. • Establishes Reporting Lines — Management designs and evaluates lines of reporting for each entity structure to enable execution of authorities and responsibilities and flow of information to manage the activities of the entity. • Defines, Assigns, and Limits Authorities and Responsibilities — Management and the board of directors delegate authority, define responsibilities, and use appropriate processes and technology to assign responsibility and segregate duties as necessary at the various levels of the organization • Addresses Specific Requirements When Defining Authorities and Responsibilities — Management and the board of directors consider requirements relevant to security, availability, processing integrity, confidentiality, and privacy when defining authorities and responsibilities. • Considers Interactions With External Parties When Establishing Structures, Reporting Lines, Authorities, and Responsibilities — Management and the board of directors consider the need for the entity to interact with and monitor the activities of external parties when establishing structures, reporting lines, authorities, and responsibilities 5
SOC_2 CC3.1 SOC_2_CC3.1 SOC 2 Type 2 CC3.1 Risk Assessment COSO Principle 6 Shared The customer is responsible for implementing this recommendation. • Reflects Management's Choices — Operations objectives reflect management's choices about structure, industry considerations, and performance of the entity. • Considers Tolerances for Risk — Management considers the acceptable levels of variation relative to the achievement of operations objectives. • Includes Operations and Financial Performance Goals — The organization reflects the desired level of operations and financial performance for the entity within operations objectives. • Forms a Basis for Committing of Resources — Management uses operations objectives as a basis for allocating resources needed to attain desired operations and financial performance. External Financial Reporting Objectives • Complies With Applicable Accounting Standards — Financial reporting objectives are consistent with accounting principles suitable and available for that entity. The accounting principles selected are appropriate in the circumstances. • Considers Materiality — Management considers materiality in financial statement presentation. • Reflects Entity Activities — External reporting reflects the underlying transactions and events to show qualitative characteristics and assertions. External Nonfinancial Reporting Objectives • Complies With Externally Established Frameworks — Management establishes objectives consistent with laws and regulations or standards and frameworks of recognized external organizations. • Considers the Required Level of Precision — Management reflects the required level of precision and accuracy suitable for user needs and based on criteria established by third parties in nonfinancial reporting. • Reflects Entity Activities — External reporting reflects the underlying transactions and events within a range of acceptable limits. Internal Reporting Objectives • Reflects Management's Choices — Internal reporting provides management with accurate and complete information regarding management's choices and information Page 22 TSP Ref. # TRUST SERVICES CRITERIA AND POINTS OF FOCUS needed in managing the entity. • Considers the Required Level of Precision — Management reflects the required level of precision and accuracy suitable for user needs in nonfinancial reporting objectives and materiality within financial reporting objectives. • Reflects Entity Activities — Internal reporting reflects the underlying transactions and events within a range of acceptable limits. Compliance Objectives • Reflects External Laws and Regulations — Laws and regulations establish minimum standards of conduct, which the entity integrates into compliance objectives. • Considers Tolerances for Risk — Management considers the acceptable levels of variation relative to the achievement of operations objectives 7
SOC_2 CC3.2 SOC_2_CC3.2 SOC 2 Type 2 CC3.2 Risk Assessment COSO Principle 7 Shared The customer is responsible for implementing this recommendation. Points of focus specified in the COSO framework: • Includes Entity, Subsidiary, Division, Operating Unit, and Functional Levels — The entity identifies and assesses risk at the entity, subsidiary, division, operating unit, and functional levels relevant to the achievement of objectives. • Analyzes Internal and External Factors — Risk identification considers both internal and external factors and their impact on the achievement of objectives. • Involves Appropriate Levels of Management — The entity puts into place effective risk assessment mechanisms that involve appropriate levels of management. • Estimates Significance of Risks Identified — Identified risks are analyzed through a process that includes estimating the potential significance of the risk. • Determines How to Respond to Risks — Risk assessment includes considering how the risk should be managed and whether to accept, avoid, reduce, or share the risk. Additional points of focus specifically related to all engagements using the trust services criteria: • Identifies and Assesses Criticality of Information Assets and Identifies Threats and Vulnerabilities — The entity's risk identification and assessment process includes (1) identifying information assets, including physical devices and systems, virtual devices, software, data and data flows, external information systems, and organizational roles; (2) assessing the criticality of those information assets; (3) identifying the threats to the assets from intentional (including malicious) and unintentional acts and environmental events; and (4) identifying the vulnerabilities of the identified assets. • Analyzes Threats and Vulnerabilities From Vendors, Business Partners, and Other Parties — The entity's risk assessment process includes the analysis of potential threats and vulnerabilities arising from vendors providing goods and services, as well as threats and vulnerabilities arising from business partners, customers, and others with access to the entity's information systems. • Considers the Significance of the Risk — The entity’s consideration of the potential significance of the identified risks includes (1) determining the criticality of identified assets in meeting objectives; (2) assessing the impact of identified threats and vulnerabilities in meeting objectives; (3) assessing the likelihood of identified threats; and (4) determining the risk associated with assets based on asset criticality, threat impact, and likelihood. 11
SOC_2 CC3.4 SOC_2_CC3.4 SOC 2 Type 2 CC3.4 Risk Assessment COSO Principle 9 Shared The customer is responsible for implementing this recommendation. • Assesses Changes in the External Environment — The risk identification process considers changes to the regulatory, economic, and physical environment in which the entity operates. • Assesses Changes in the Business Model — The entity considers the potential impacts of new business lines, dramatically altered compositions of existing business lines, acquired or divested business operations on the system of internal control, rapid growth, changing reliance on foreign geographies, and new technologies. • Assesses Changes in Leadership — The entity considers changes in management and respective attitudes and philosophies on the system of internal control. Page 25 TSP Ref. # TRUST SERVICES CRITERIA AND POINTS OF FOCUS Additional point of focus specifically related to all engagements using the trust services criteria: • Assesses Changes in Systems and Technology — The risk identification process considers changes arising from changes in the entity’s systems and changes in the technology environment. • Assesses Changes in Vendor and Business Partner Relationships — The risk identification process considers changes in vendor and business partner relationships 6
SOC_2 CC5.1 SOC_2_CC5.1 SOC 2 Type 2 CC5.1 Control Activities COSO Principle 10 Shared The customer is responsible for implementing this recommendation. • Integrates With Risk Assessment — Control activities help ensure that risk responses that address and mitigate risks are carried out. • Considers Entity-Specific Factors — Management considers how the environment, complexity, nature, and scope of its operations, as well as the specific characteristics of its organization, affect the selection and development of control activities. • Determines Relevant Business Processes — Management determines which relevant business processes require control activities. • Evaluates a Mix of Control Activity Types — Control activities include a range and variety of controls and may include a balance of approaches to mitigate risks, considering both manual and automated controls, and preventive and detective controls. • Considers at What Level Activities Are Applied — Management considers control activities at various levels in the entity. • Addresses Segregation of Duties — Management segregates incompatible duties and, where such segregation is not practical, management selects and develops alternative control activities. 2
SOC_2 CC8.1 SOC_2_CC8.1 SOC 2 Type 2 CC8.1 Change Management Changes to infrastructure, data, and software Shared The customer is responsible for implementing this recommendation. Manages Changes Throughout the System Life Cycle — A process for managing system changes throughout the life cycle of the system and its components (infrastructure, data, software, and procedures) is used to support system availability and processing integrity. • Authorizes Changes — A process is in place to authorize system changes prior to development. • Designs and Develops Changes — A process is in place to design and develop system changes. • Documents Changes — A process is in place to document system changes to support ongoing maintenance of the system and to support system users in performing their responsibilities. • Tracks System Changes — A process is in place to track system changes prior to implementation. • Configures Software — A process is in place to select and implement the configuration parameters used to control the functionality of software. • Tests System Changes — A process is in place to test system changes prior to implementation. • Approves System Changes — A process is in place to approve system changes prior to implementation. • Deploys System Changes — A process is in place to implement system changes. • Identifies and Evaluates System Changes — Objectives affected by system changes are identified and the ability of the modified system to meet the objectives is evaluated throughout the system development life cycle. • Identifies Changes in Infrastructure, Data, Software, and Procedures Required to Remediate Incidents — Changes in infrastructure, data, software, and procedures required to remediate incidents to continue to meet objectives are identified and the change process is initiated upon identification. • Creates Baseline Configuration of IT Technology — A baseline configuration of IT and control systems is created and maintained. • Provides for Changes Necessary in Emergency Situations — A process is in place for authorizing, designing, testing, approving, and implementing changes necessary in emergency situations (that is, changes that need to be implemented in an urgent time frame). Additional points of focus that apply only in an engagement using the trust services criteria for confidentiality: • Protects Confidential Information — The entity protects confidential information during system design, development, testing, implementation, and change processes to meet the entity’s objectives related to confidentiality. Additional points of focus that apply only in an engagement using the trust services criteria for privacy: • Protects Personal Information — The entity protects personal information during system design, development, testing, implementation, and change processes to meet the entity’s objectives related to privacy. 52
SOC_2 CC9.1 SOC_2_CC9.1 SOC 2 Type 2 CC9.1 Risk Mitigation Risk mitigation activities Shared The customer is responsible for implementing this recommendation. • Considers Mitigation of Risks of Business Disruption — Risk mitigation activities include the development of planned policies, procedures, communications, and alternative processing solutions to respond to, mitigate, and recover from security events that disrupt business operations. Those policies and procedures include monitoring processes, information, and communications to meet the entity's objectives during response, mitigation, and recovery efforts. • Considers the Use of Insurance to Mitigate Financial Impact Risks — The risk management activities consider the use of insurance to offset the financial impact of loss events that would otherwise impair the ability of the entity to meet its objectives 3
SWIFT_CSCF_v2022 2.3 SWIFT_CSCF_v2022_2.3 SWIFT CSCF v2022 2.3 2. Reduce Attack Surface and Vulnerabilities Reduce the cyber-attack surface of SWIFT-related components by performing system hardening. Shared n/a Security hardening is conducted and maintained on all in-scope components. link 25
SWIFT_CSCF_v2022 7.4A SWIFT_CSCF_v2022_7.4A SWIFT CSCF v2022 7.4A 7. Plan for Incident Response and Information Sharing Evaluate the risk and readiness of the organisation based on plausible cyber-attack scenarios. Shared n/a Scenario-based risk assessments are conducted regularly to improve incident response preparedness and to increase the maturity of the organisation’s security programme. link 7
Initiatives usage
Initiative DisplayName Initiative Id Initiative Category State Type
FedRAMP High d5264498-16f4-418a-b659-fa7ef418175f Regulatory Compliance GA BuiltIn
FedRAMP Moderate e95f5a9f-57ad-4d03-bb0b-b1d16db93693 Regulatory Compliance GA BuiltIn
HITRUST/HIPAA a169a624-5599-4385-a696-c8d643089fab Regulatory Compliance GA BuiltIn
ISO 27001:2013 89c6cddc-1c73-4ac1-b19c-54d1a15a42f2 Regulatory Compliance GA BuiltIn
NIST SP 800-171 Rev. 2 03055927-78bd-4236-86c0-f36125a10dc9 Regulatory Compliance GA BuiltIn
NIST SP 800-53 Rev. 4 cf25b9c1-bd23-4eb6-bd2c-f4f3ac644a5f Regulatory Compliance GA BuiltIn
NIST SP 800-53 Rev. 5 179d1daa-458f-4e47-8086-2a68d0d6c38f Regulatory Compliance GA BuiltIn
PCI DSS v4 c676748e-3af9-4e22-bc28-50feed564afb Regulatory Compliance GA BuiltIn
SOC 2 Type 2 4054785f-702b-4a98-9215-009cbd58b141 Regulatory Compliance GA BuiltIn
SWIFT CSP-CSCF v2022 7bc7cd6c-4114-ff31-3cac-59be3157596d Regulatory Compliance GA BuiltIn
History
Date/Time (UTC ymd) (i) Change type Change detail
2022-09-27 16:35:32 change Minor (1.0.0 > 1.1.0)
2022-09-13 16:35:29 add d36700f2-2f0d-7c2a-059c-bdadd1d79f70
JSON compare
compare mode: version left: version right:
JSON
api-version=2021-06-01
EPAC