An IT change management approval process includes all of the following components EXCEPT:
Application version control standards for software release updates
Documented audit trail for all emergency changes
Defined roles between business and IT functions
Guidelines that restrict approval of changes to only authorized personnel
Application version control standards for software release updates are not part of the IT change management approval process, but rather a technical aspect of the software development lifecycle. The IT change management approval process is a formal and structured way of evaluating, authorizing and scheduling changes to IT systems and infrastructure, based on predefined criteria and roles. The IT change management approval process typically includes the following components123:
A change request form that captures the details, rationale, impact, risk and benefits of the proposed change
A change approval board (CAB) or other authorized approvers who review and approve or reject the change request based on the business case, feasibility and alignment with the organization’s objectives and policies
A documented audit trail for all changes, especially emergency changes, that records the date, time, reason, approver and outcome of each change
A defined roles and responsibilities matrix that clarifies the expectations and accountabilities of each stakeholder involved in the change management process, such as the change manager, change owner, change coordinator, change implementer and change requester
A set of guidelines that restrict the approval of changes to only authorized personnel who have the appropriate knowledge, skills and authority to make decisions about the changes References:
1: Change Approval Process in ITIL Change Management
2: Guide to the IT Change Requests Approval Process
3: Overview of the change management approval process
When defining third party requirements for transmitting Pll, which factors provide stranger controls?
Full disk encryption and backup
Available bandwidth and redundancy
Strength of encryption cipher and authentication method
Logging and monitoring
Personally identifiable information (PII) is any data that can be used to identify, contact, or locate an individual, such as name, address, email, phone number, social security number, etc. PII is subject to various legal and regulatory requirements, such as the GDPR, HIPAA, PCI DSS, and others, depending on the industry and jurisdiction. PII also poses significant security and privacy risks, as it can be exploited by malicious actors for identity theft, fraud, phishing, or other cyberattacks. Therefore, organizations that collect, store, process, or transmit PII must implement appropriate safeguards to protect it from unauthorized access, disclosure, modification, or loss.
One of the key safeguards for PII protection is encryption, which is the process of transforming data into an unreadable format using a secret key. Encryption ensures that only authorized parties who have the key can access the original data. Encryption can be applied to data at rest (stored on a device or a server) or data in transit (moving across a network or the internet). Encryption can also be symmetric (using the same key for encryption and decryption) or asymmetric (using a public key for encryption and a private key for decryption).
Another key safeguard for PII protection is authentication, which is the process of verifying the identity of a user or a system that requests access to data. Authentication ensures that only legitimate and authorized parties can access the data. Authentication can be based on something the user knows (such as a password or a PIN), something the user has (such as a token or a smart card), something the user is (such as a fingerprint or a face scan), or a combination of these factors. Authentication can also be enhanced by using additional methods, such as one-time passwords, challenge-response questions, or multi-factor authentication.
When defining third party requirements for transmitting PII, the factors that provide stronger controls are the strength of encryption cipher and authentication method. These factors determine how secure and reliable the data transmission is, and how resistant it is to potential attacks or breaches. The strength of encryption cipher refers to the algorithm and the key size used to encrypt the data. The stronger the cipher, the more difficult it is to break or crack the encryption. The strength of authentication method refers to the type and the number of factors used to verify the identity of the user or the system. The stronger the authentication method, the more difficult it is to impersonate or compromise the user or the system.
The other factors, such as full disk encryption and backup, available bandwidth and redundancy, and logging and monitoring, are also important for PII protection, but they do not directly affect the data transmission process. Full disk encryption and backup are relevant for data at rest, not data in transit. They provide protection in case of device theft, loss, or damage, but they do not prevent data interception or modification during transmission. Available bandwidth and redundancy are relevant for data availability and performance, not data security and privacy. They ensure that the data transmission is fast and reliable, but they do not prevent data exposure or corruption during transmission. Logging and monitoring are relevant for data audit and compliance, not data encryption and authentication. They provide visibility and accountability for the data transmission activities, but they do not prevent data access or misuse during transmission. References:
: What is Data Encryption? | Definition and Examples | Imperva
: What is Authentication? | Definition and Examples | Imperva
: Personally Identifiable Information (PII) - Imperva
: Data Protection - Shared Assessments
Which vendor statement provides the BEST description of the concept of least privilege?
We require dual authorization for restricted areas
We grant people access to the minimum necessary to do their job
We require separation of duties for performance of high risk activities
We limit root and administrator access to only a few personnel
The concept of least privilege is a security principle that requires giving each user, service, and application only the permissions needed to perform their work and no more12. It is one of the most important concepts in network and system security, as it reduces the attack surface and the risk of unauthorized access, data breaches, and malware infections12. The statement B best describes this concept, as it implies that the vendor follows the principle of least privilege by granting people access to the minimum necessary to do their job. The other statements do not capture the essence of the concept, as they either describe other security practices (such as dual authorization and separation of duties) or limit the scope of the concept to a specific type of access (such as root and administrator access).
References:
1: 9 Ways to Prevent Third-Party Data Breaches in 2024 | UpGuard
2: Best Practice Guide to Implementing the Least Privilege Principle - Netwrix
Which of the following actions reflects the first step in developing an emergency response plan?
Conduct an assessment that includes an inventory of the types of events that have the greatest potential to trigger an emergency response plan
Consider work-from-home parameters in the emergency response plan
incorporate periodic crisis management team tabletop exercises to test different scenarios
Use the results of continuous monitoring tools to develop the emergency response plan
An emergency response plan (ERP) is a document that outlines the procedures and actions to be taken by an organization in the event of a disruptive incident that threatens its operations, assets, reputation, or stakeholders1. An ERP should be aligned with the organization’s business continuity and disaster recovery plans, and should cover the roles and responsibilities, communication channels, escalation processes, resources, and recovery strategies for different types of emergencies2.
The first step in developing an ERP is to conduct an assessment that includes an inventory of the types of events that have the greatest potential to trigger an ERP3. This assessment should consider the likelihood and impact of various scenarios, such as natural disasters, cyberattacks, pandemics, civil unrest, terrorism, or supply chain disruptions, and identify the critical functions, processes, assets, and dependencies that could be affected by these events4. The assessment should also evaluate the existing capabilities and gaps in the organization’s preparedness and response, and prioritize the areas that need improvement or enhancement5. The assessment should be based on a comprehensive risk analysis and a business impact analysis, and should involve input from relevant stakeholders, such as senior management, business units, IT, security, legal, compliance, human resources, and third parties.
The other options are not the first step in developing an ERP, but rather subsequent or complementary steps that should be performed after the initial assessment. Considering work-from-home parameters, incorporating periodic crisis management team tabletop exercises, and using the results of continuous monitoring tools are all important aspects of an ERP, but they are not the starting point for creating one. These steps should be based on the findings and recommendations of the assessment, and should be updated and tested regularly to ensure the effectiveness and relevance of the ERP. References: 1: What is an Emergency Response Plan? | IBM 2: Emergency Response Plan | Ready.gov 3: 8 Steps to Building a Third-Party Incident Response Plan | Prevalent 4: How to create an effective business continuity plan | CIO 5: Emergency Response Planning: 4 Steps to Creating a Plan : Third-Party Risk Management: Final Interagency Guidance : Improving Third-Party Incident Response | Prevalent
Which of the following is NOT an attribute in the vendor inventory used to assign risk rating and vendor classification?
Type of data accessed, processed, or retained
Type of systems accessed
Type of contract addendum
Type of network connectivity
Vendor inventory is a list of all the third-party vendors that an organization engages with, along with relevant information about their products, services, contracts, and risks. Vendor inventory is a crucial tool for vendor risk management, as it helps an organization identify, assess, monitor, and mitigate the potential risks associated with its vendors. Vendor inventory also helps an organization prioritize its vendor oversight activities, allocate its resources efficiently, and comply with its regulatory obligations12.
One of the key steps in creating and maintaining a vendor inventory is to assign a risk rating and a vendor classification to each vendor, based on various attributes that reflect the level of risk and criticality they pose to the organization. The risk rating and vendor classification help an organization determine the frequency and depth of its vendor due diligence, review, and audit processes, as well as the appropriate controls and remediation actions to implement3 .
Some of the common attributes used to assign risk rating and vendor classification are :
Type of data accessed, processed, or retained: This attribute indicates the sensitivity and confidentiality of the data that the vendor handles on behalf of the organization, such as personally identifiable information (PII), protected health information (PHI), financial information, intellectual property, etc. The more sensitive and confidential the data, the higher the risk rating and vendor classification, as the vendor must comply with strict security and privacy standards and regulations, and the organization must protect itself from data breaches, leaks, or losses.
Type of systems accessed: This attribute indicates the access level and privileges that the vendor has to the organization’s systems, such as networks, servers, databases, applications, etc. The more access and privileges the vendor has, the higher the risk rating and vendor classification, as the vendor must adhere to the organization’s policies and procedures, and the organization must safeguard itself from unauthorized or malicious activities, such as cyberattacks, sabotage, or espionage.
Type of network connectivity: This attribute indicates the mode and frequency of the data transmission and communication between the vendor and the organization, such as online, offline, real-time, batch, etc. The more network connectivity the vendor has, the higher the risk rating and vendor classification, as the vendor must ensure the availability, integrity, and reliability of the data, and the organization must prevent data interception, modification, or disruption.
The type of contract addendum is NOT an attribute used to assign risk rating and vendor classification, as it is not directly related to the risk or criticality of the vendor. The type of contract addendum is a legal document that modifies or supplements the original contract between the vendor and the organization, such as adding or deleting terms, clauses, or provisions. The type of contract addendum may reflect the changes or updates in the vendor relationship, such as scope, duration, price, service level, etc., but it does not indicate the level of risk or impact that the vendor has on the organization. Therefore, the type of contract addendum is not a relevant factor for vendor risk assessment and management . References:
1: Vendor Inventory - Shared Assessments
2: Vendor Inventory Management: A Guide to Third-Party Risk Management
3: Vendor Risk Rating - Shared Assessments
: [Vendor Risk Rating: How to Rate Your Vendors | Smartsheet]
: [Vendor Classification - Shared Assessments]
: [Vendor Tiering: How to Classify Your Vendors | Smartsheet]
: Contract Addendum - Shared Assessments
: What is a Contract Addendum? | Definition and Examples | Imperva
All of the following processes are components of controls evaluation in the Third Party Risk Assessment process EXCEPT:
Reviewing compliance artifacts for the presence of control attributes
Negotiating contract terms for the right to audit
Analyzing assessment results to identify and report risk
Scoping the assessment based on identified risk factors
Controls evaluation is the process of verifying and validating the effectiveness of the controls implemented by the third party to mitigate the identified risks. It involves reviewing the evidence provided by the third party, such as policies, procedures, certifications, attestations, or test results, to determine if the controls are adequate, consistent, and compliant with the requirements and standards of the organization. Controls evaluation also involves analyzing the assessment results to identify any gaps, weaknesses, or issues in the third party’s controls, and reporting the findings and recommendations to the relevant stakeholders. Negotiating contract terms for the right to audit is not a component of controls evaluation, but rather a component of contract management. Contract management is the process of establishing, maintaining, and enforcing the contractual agreements between the organization and the third party. It involves defining the roles, responsibilities, expectations, and obligations of both parties, as well as the terms and conditions for service delivery, performance measurement, risk management, dispute resolution, and termination. Negotiating contract terms for the right to audit is a key aspect of contract management, as it allows the organization to monitor and verify the third party’s compliance with the contract and the applicable regulations and standards. It also enables the organization to conduct independent audits or assessments of the third party’s controls, processes, and performance, and to request remediation actions if necessary. References:
1: Shared Assessments, a leading provider of third party risk management solutions, offers a comprehensive guide for Certified Third Party Risk Professional (CTPRP) candidates, which covers the core concepts and best practices of third party risk management, including controls evaluation and contract management.
2: UpGuard, a platform for cybersecurity and third party risk management, provides a detailed overview of the best practices for third party risk assessment, which includes the steps and criteria for evaluating the controls of third parties.
3: Deloitte, a global professional services firm, offers an end-to-end managed service for third party risk management, which includes controls evaluation and contract management as key components of the service.
Which of the following data safeguarding techniques provides the STRONGEST assurance that data does not identify an individual?
Data masking
Data encryption
Data anonymization
Data compression
Data anonymization is the process of removing or altering any information that can be used to identify an individual from a data set. This technique provides the strongest assurance that data does not identify an individual, as it makes it impossible or extremely difficult to link the data back to the original source. Data anonymization can be achieved by various methods, such as generalization, suppression, perturbation, or pseudonymization12. Data anonymization is often used for privacy protection, compliance with data protection regulations, and data sharing purposes3. References:
1: Data Security: Definition, Importance, and Types | Fortinet
2: Data Security Best Practices: Top 10 Data Protection Methods - Ekran System
3: Data anonymization - Wikipedia
Which statement BEST describes the use of risk based decisioning in prioritizing gaps identified at a critical vendor when defining the corrective action plan?
The assessor determined that gaps should be analyzed, documented, reviewed for compensating controls, and submitted to the business owner to approve risk treatment plan
The assessor decided that the critical gaps should be discussed in the closing meeting so that the vendor can begin to implement corrective actions immediately
The assessor concluded that all gaps should be logged and treated as high severity findings since the assessment was performed on a critical vendor
The assessor determined that all gaps should be logged and communicated that if the gaps were corrected immediately they would not need to be included in the findings report
According to the Shared Assessments Certified Third Party Risk Professional (CTPRP) Study Guide, risk based decisioning is the process of applying risk criteria to prioritize and address the gaps identified during a third-party risk assessment1. The assessor should analyze the gaps based on the impact, likelihood, and urgency of the risk, and document the findings and recommendations in a report. The assessor should also review the existing or proposed compensating controls that could mitigate the risk, and submit the report to the business owner for approval of the risk treatment plan. The risk treatment plan could include accepting, transferring, avoiding, or reducing the risk, depending on the risk appetite and tolerance of the organization1.
The other statements do not reflect the best use of risk based decisioning, as they either ignore the risk analysis and documentation process, or apply a uniform or arbitrary approach to prioritizing and addressing the gaps. The assessor should not decide or conclude on the risk treatment plan without consulting the business owner, as the business owner is ultimately responsible for the third-party relationship and the risk management decisions1. The assessor should also not communicate that the gaps would not be included in the report if they were corrected immediately, as this could compromise the integrity and transparency of the assessment process and the report2.
References:
1: Shared Assessments Certified Third Party Risk Professional (CTPRP) Study Guide, pages 29-30, 33-34
2: Third-Party Risk Management: Final Interagency Guidance, page 10
When working with third parties, which of the following requirements does not reflect a “Zero Trust" approach to access management?
Utilizing a solution that allows direct access by third parties to the organization's network
Ensure that access is granted on a per session basis regardless of network location, user, or device
Implement device monitoring, continual inspection and monitoring of logs/traffic
Require that all communication is secured regardless of network location
A Zero Trust approach to access management is based on the principle of verifying every access request as if it originates from an open network, regardless of the source, destination, or context. This means that no implicit trust is granted based on network location, user identity, or device status. Instead, every access request is evaluated based on multiple factors, such as user credentials, device health, data sensitivity, and threat intelligence. A Zero Trust approach also requires that all communication is encrypted and protected, and that access is granted on a per session basis with the least privilege principle123.
Utilizing a solution that allows direct access by third parties to the organization’s network does not reflect a Zero Trust approach, because it implies that the network perimeter is a reliable boundary for security and trust. This assumption is risky, because it exposes the organization to potential breaches and attacks from compromised or malicious third parties, who may have access to sensitive data and resources without proper verification or protection. A Zero Trust approach would require that third parties use secure and isolated channels to access the organization’s network, such as VPNs, proxies, or gateways, and that their access is monitored and controlled based on granular policies and conditions123. References:
Zero Trust part 1: Identity and access management
Zero Trust Model - Modern Security Architecture | Microsoft Security
Zero Trust identity and access management development best practices …
Which type of contract termination is MOST likely to occur after failure to remediate assessment findings?
Regulatory/supervisory termination
Termination for convenience
Normal termination
Termination for cause
Termination for cause is the type of contract termination that is most likely to occur after failure to remediate assessment findings. This is because termination for cause is based on a breach of contract by the third-party, such as non-compliance, poor performance, fraud, or misconduct. Failure to remediate assessment findings indicates that the third-party has not met the contractual obligations or expectations of the entity, and thus exposes the entity to increased risk and liability. Termination for cause allows the entity to end the contract immediately or after a notice period, and to seek damages or remedies from the third-party. Termination for cause is different from other types of contract termination, such as:
Regulatory/supervisory termination, which is triggered by a change in law or regulation that affects the legality or feasibility of the contract.
Termination for convenience, which is exercised by the entity without any fault or breach by the third-party, usually for strategic or operational reasons.
Normal termination, which is the natural expiration of the contract term or the completion of the contract scope. References:
Shared Assessments. (2020). Certified Third Party Risk Professional (CTPRP) Study Guide1
Fusion Risk Management. (2021). Exit Strategy for Terminating a Third Party2
Volkov, M. (2016). Third-Party Risk Management – Part 2: Contract Termination3
