CTPRP Questions and Answers

According to the Shared Assessments CTPRP Study Guide, the business unit relationship owner is the primary point of contact for the third party and is responsible for ensuring that the third party meets the contractual obligations and service level agreements. The business unit relationship owner is also involved in the third party risk assessment process and the remediation plan approval. Therefore, a meeting should be scheduled with the business unit relationship owner before sharing the findings and remediation plans with the third party, as they have the authority and accountability to approve or reject the plans. The other options are not necessarily involved in the remediation plan approval, although they may have other roles in the third party risk management lifecycle. References:

• Shared Assessments CTPRP Study Guide, page 9, section 1.3.2
• The Third-Party Vendor Risk Management Lifecycle, section on Supplier Onboarding & Risk Monitoring
• Remediation vs. Mitigation, section on Remediation

For services with system-to-system access, ensuring sufficient time for quality assurance (QA) testing before implementing changes is crucial to reducing the risk of business disruption to the outsourcer. This requirement ensures that any modifications to the system are thoroughly vetted for potential issues that could impact the outsourcer's operations. QA testing allows for the identification and remediation of bugs, compatibility issues, and other potential problems that could lead to operational disruptions or security vulnerabilities. By allocating adequate time for QA testing, organizations can ensure that changes are fully functional and secure, thereby maintaining the integrity and availability of services provided to the outsourcer. This practice is aligned with industry standards for change management, which advocate for comprehensive testing and validation processes to ensure the reliability and stability of system changes.

References:

• Industry standards such as ITIL (Information Technology Infrastructure Library) emphasize the importance of thorough testing and validation within the change management process to minimize the risk of disruptions and ensure the smooth operation of services.
• Guides like "Managing Change in IT Outsourcing Arrangements: The TPRM Perspective" provide insights into best practices for change management in third-party relationships, including the critical role of QA testing in mitigating risks associated with system changes.

One of the key objectives of a TPRM program is to identify and mitigate the risks posed by third parties throughout the relationship life cycle. Therefore, measuring the operational performance of implementing a TPRM program requires tracking the effectiveness and efficiency of the risk management processes and activities. Among the four examples given, calculating the average time to remediate identified corrective actions is the most likely to provide meaningful metrics for this purpose. This metric indicates how quickly and consistently the organization and its third parties can resolve the issues and gaps that are discovered during the risk assessment and monitoring phases. It also reflects the level of collaboration and communication between the parties, as well as the alignment of expectations and standards. A lower average time to remediate implies a higher operational performance of the TPRM program, as it demonstrates a proactive and responsive approach to risk management12.

The other three examples are less likely to provide meaningful metrics for measuring the operational performance of implementing a TPRM program, as they do not directly measure the outcomes or impacts of the risk management activities. Logging the number of exceptions to existing due diligence standards may indicate the level of compliance and consistency of the TPRM program, but it does not show how the exceptions are handled or justified. Measuring the time spent by resources for task and corrective action plan completion may indicate the level of effort and resource allocation of the TPRM program, but it does not show how the tasks and plans contribute to the risk reduction or mitigation. Tracking the number of outstanding findings may indicate the level of exposure and vulnerability of the TPRM program, but it does not show how the findings are prioritized or addressed. References:

• 1: 15 KPIs & Metrics to Measure the Success of Your TPRM Program | UpGuard Blog
• 2: Third-Party Risk Management Reporting: What You Need to Know - Venminder

 Performing due diligence during third party risk assessments is a process of verifying and validating the information provided by the third parties, as well as identifying and assessing any potential risks or issues that may arise from the relationship. Due diligence methods may vary depending on the type, scope, and complexity of the third party engagement, but they generally involve the following steps123:

• Interviewing subject matter experts or control owners: This method involves engaging with the relevant stakeholders from both the organization and the third party, such as business owners, project managers, legal counsel, compliance officers, security analysts, etc. The purpose of the interviews is to gather more information about the third party’s capabilities, processes, policies, performance, and challenges, as well as to clarify any questions or concerns that may arise from the questionnaire or other sources. The interviews can also help to establish rapport and trust between the parties, and to identify any gaps or discrepancies in the information provided.
• Reviewing compliance artifacts: This method involves examining the evidence or documentation that supports the third party’s claims or assertions, such as certifications, accreditations, audit reports, policies, procedures, contracts, SLAs, etc. The purpose of the review is to verify the accuracy, completeness, and validity of the artifacts, as well as to assess the level of compliance with the applicable standards, regulations, and best practices. The review can also help to identify any areas of improvement or weakness in the third party’s controls or processes.
• Validating controls: This method involves testing or inspecting the actual implementation and effectiveness of the third party’s controls or processes, such as security measures, quality assurance, data protection, incident response, etc. The purpose of the validation is to confirm that the controls are operating as intended and expected, and that they are sufficient to mitigate the risks or issues identified in the assessment. The validation can also help to identify any vulnerabilities or gaps in the third party’s controls or processes.

The other options are not as comprehensive or accurate as the methods described above, as they may not cover all the aspects or dimensions of the third party risk assessment, or they may rely on incomplete or outdated information. Inspecting physical and environmental security controls by conducting a facility tour is only one part of the validation method, and it may not be applicable or feasible for all types of third parties, such as cloud service providers or remote workers. Reviewing status of findings from the questionnaire and defining remediation plans is more of a follow-up or monitoring activity, rather than a due diligence method, as it assumes that the questionnaire has already been completed and analyzed. Reviewing and assessing only the obligations that are specifically defined in the contract is a narrow and limited approach, as it may not capture the full scope or complexity of the third party relationship, or the dynamic and evolving nature of the risks or issues involved. References:

• Third Party Due Diligence – a vital but challenging process
• The guide to risk based third party due diligence - VinciWorks
• Third Party Risk Assessment – Checklist & Best Practices

Terms for return or destruction of data should be defined and agreed upon during contract negotiation, as this is the phase where the organization and the third party establish the expectations, obligations, and responsibilities for the relationship, including the handling of data. According to the Shared Assessments CTPRP Study Guide, contract negotiation is the phase where "the organization and the third party negotiate and execute a contract that clearly defines the expectations and responsibilities of both parties, including the scope of work, service level agreements, performance measures, reporting requirements, compliance obligations, security and privacy controls, incident response procedures, dispute resolution mechanisms, termination rights, and other relevant terms and conditions."1 One of the key contractual terms that should be addressed is the return or destruction of data, which specifies how the third party will return or dispose of the organization’s data at the end of the relationship, or upon request, in a secure and timely manner. This term is important for ensuring the organization’s data protection, confidentiality, and compliance, as well as reducing the risk of data breaches, leaks, or misuse by the third party or unauthorized parties.

The other phases of the TPRM lifecycle are not the best choices for defining and agreeing upon terms for return or destruction of data, because:

• B. At third party selection and initial due diligence: This is the phase where the organization identifies, evaluates, and selects the third party that best meets its needs, objectives, and risk appetite. This phase involves conducting due diligence on the third party’s capabilities, qualifications, reputation, performance, security, and compliance, as well as assessing the inherent risk of the relationship. While this phase is important for screening and choosing the right third party, it does not involve defining and agreeing upon the specific terms and conditions of the relationship, such as the return or destruction of data, which are usually done in the contract negotiation phase.
• C. When deploying ongoing monitoring: This is the phase where the organization monitors and reviews the third party’s performance, service delivery, risk management, and compliance on a regular basis, as well as identifies and addresses any issues, gaps, or changes that may arise during the relationship. This phase involves collecting and analyzing data and information from various sources, such as reports, audits, assessments, surveys, feedback, incidents, and metrics, as well as communicating and collaborating with the third party to ensure alignment and improvement. While this phase is important for ensuring the quality and security of the relationship, it does not involve defining and agreeing upon the terms and conditions of the relationship, such as the return or destruction of data, which are usually done in the contract negotiation phase.
• D. At termination and exit: This is the phase where the organization terminates and exits the relationship with the third party, either by mutual agreement, expiration of contract, breach of contract, or other reasons. This phase involves executing the termination and exit plan, which may include notifying the third party, transferring or discontinuing the services, settling the financial obligations, returning or destroying the data, revoking the access rights, and conducting a post-termination review. While this phase is important for ensuring a smooth and secure transition and closure of the relationship, it does not involve defining and agreeing upon the terms and conditions of the relationship, such as the return or destruction of data, which are usually done in the contract negotiation phase.

References:

• 1: Shared Assessments CTPRP Study Guide, page 59, section 5.1: TPRM Lifecycle
• : Third-Party Risk Management: Vendor Contract Terms and Conditions, section: Data Ownership, Return and Destruction
• : [Third-Party Risk Management: The 3rd Party Ecosystem: How to Manage the Risk While Keeping the Benefit], section: Contract Negotiation
• : [Third-Party Risk Management: The 3rd Party Ecosystem: How to Manage the Risk While Keeping the Benefit], section: Termination and Exit

Virtual assessments are a method of conducting third party risk assessments remotely, using various tools and techniques to collect and verify information about the third party’s controls, processes, and performance. Virtual assessments can be used to evaluate various risk domains, such as information security, privacy, resiliency, and compliance, depending on the scope and objectives of the assessment. Virtual assessments can also be used to complement or supplement onsite assessments, especially when travel or access restrictions are in place.

One of the key components of virtual assessments is the use of interviews with subject matter experts (SMEs) from the third party, who can provide insights and clarifications on the third party’s policies, procedures, practices, and evidence. Interviews can also be used to validate or confirm the understanding of key controls, and not just to review questionnaire responses. However, interviews are not the only way to perform controls evaluation and testing in virtual assessments. Other methods include:

• Requesting and reviewing documentation and artifacts from the third party, such as policies, standards, certifications, attestations, test results, audit reports, or incident logs, that demonstrate the implementation and effectiveness of the controls.
• Performing live or recorded demonstrations of the controls, such as showing how the third party monitors, detects, and responds to security incidents, or how the third party encrypts, backs up, and restores data.
• Using remote access tools or platforms, such as screen sharing, video conferencing, or web portals, to observe and verify the controls in action, such as checking the configuration settings, access rights, or patch levels of the third party’s systems or applications.
• Using independent or external sources of information, such as ratings, benchmarks, or feedback, to validate and compare the third party’s performance, compliance, or reputation.

Therefore, the statement that virtual assessments include using interviews with SMEs since controls evaluation and testing cannot be performed virtually is false, as there are other ways to perform controls evaluation and testing in virtual assessments, besides interviews.

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 virtual assessments.
• 2: Schneider Downs, a professional services firm, provides a blog post on the best practices for conducting third party risk management virtual assessments, which includes the methods and steps for performing controls evaluation and testing remotely.
• 3: Shared Assessments, a leading provider of third party risk management solutions, offers a blog post on the value and challenges of virtual assessments, which includes the benefits and drawbacks of using interviews and other techniques for controls evaluation and testing.

Remote access is any connection made to an organization’s internal network and systems from an external source by a device or host. Remote access can enable greater worker flexibility and productivity, but it also poses significant security risks, such as unauthorized access, data leakage, malware infection, or network compromise. Therefore, it is important to evaluate a third party’s use of remote access within their information security policy, which should define the roles, responsibilities, standards, and procedures for remote access.

One of the key components of evaluating a third party’s use of remote access within their information security policy is identifying the use of multifactor authentication. Multifactor authentication is a method of verifying the identity of a remote user by requiring two or more factors, such as something the user knows (e.g., password, PIN), something the user has (e.g., token, smart card), or something the user is (e.g., fingerprint, face). Multifactor authentication enhances the security of remote access by making it harder for attackers to impersonate or compromise legitimate users. According to the NIST Guide to Enterprise Telework, Remote Access, and Bring Your Own Device (BYOD) Security1, multifactor authentication should be used for all remote access, especially for high-risk situations, such as accessing sensitive data or privileged accounts.

The other options are not components of evaluating a third party’s use of remote access within their information security policy. Maintaining blocked IP address ranges, reviewing the testing and deployment procedures to networking components, and providing guidelines to configuring ports on a router are all examples of network security controls, but they are not specific to remote access. They may be part of the overall information security policy, but they are not sufficient to assess the security of remote access. References:

• NIST Guide to Enterprise Telework, Remote Access, and Bring Your Own Device (BYOD) Security
• How to Implement an Effective Remote Access Policy
• Why Managing Third-Party Access Requires A Better Approach

Shadow IT is the use and management of any IT technologies, solutions, services, projects, and infrastructure without formal approval and support of internal IT departments. Shadow IT can pose significant security risks to the organization, such as data breaches, compliance violations, malware infections, or network disruptions. Therefore, assessing and mitigating the risk of shadow IT is an essential part of organizational security.

One of the most important factors when assessing the risk of shadow IT is whether the organization maintains adequate policies and procedures that communicate required controls for security functions. Policies and procedures are the documents that define the organization’s security objectives, standards, roles, responsibilities, and processes. They provide guidance and direction for the organization’s security activities, such as risk assessment, vendor management, incident response, data protection, access control, etc. They also establish the expectations and requirements for the organization’s employees, vendors, and other stakeholders regarding the use and management of IT resources.

By maintaining adequate policies and procedures that communicate required controls for security functions, the organization can:

• Educate and inform its employees about the security risks and implications of shadow IT, and the benefits and advantages of using authorized and supported IT resources.
• Establish and enforce clear and consistent rules and boundaries for the use and management of IT resources, and the consequences and penalties for violating them.
• Monitor and audit the compliance and performance of its employees, vendors, and other stakeholders regarding the use and management of IT resources, and identify and address any deviations or issues.
• Review and update its policies and procedures regularly, and communicate any changes or updates to its employees, vendors, and other stakeholders.

By doing so, the organization can reduce the likelihood and impact of shadow IT, and increase the visibility and accountability of its IT environment. The organization can also foster a culture of security awareness and responsibility among its employees, vendors, and other stakeholders, and encourage them to report and resolve any shadow IT incidents or problems.

The other factors, such as the organization’s security training and certification, staffing levels, and resources and investment, are also relevant for assessing the risk of shadow IT, but they are not as important as the organization’s policies and procedures. Security training and certification can help the organization’s security personnel to acquire and maintain the necessary skills and knowledge to deal with shadow IT, but they do not address the root causes or motivations of shadow IT. Staffing levels can affect the organization’s ability to detect and respond to shadow IT, but they do not prevent or deter shadow IT from occurring. Resources and investment can enable the organization to provide adequate and appropriate IT resources to its employees, vendors, and other stakeholders, but they do not guarantee the satisfaction or compliance of those parties. References:

• : Shadow IT Explained: Risks & Opportunities - BMC Software
• : What is Shadow IT? | IBM
• : Shadow IT: What Are the Risks and How Can You Mitigate Them? - Ekran System
• : Policies and Procedures - Shared Assessments

A data flow diagram (DFD) is a graphical representation of the flow of information between outsourcers and third parties, as well as within a system or process. It shows the sources and destinations of data, the processes that transform data, the data stores that hold data, and the data flows that connect them. A DFD can help to understand and refine the business processes or systems that involve data exchange with external entities. A DFD can also help to identify potential risks and vulnerabilities in the data flows, such as data leakage, data corruption, data loss, or unauthorized access.

The other options are incorrect because they do not match the definition of a visual representation of data flows. A configuration standard (A) is a set of rules or guidelines that define how a system or process should be configured, such as hardware, software, or network settings. An audit log report (B) is a record of the activities or events that occurred in a system or process, such as user actions, system changes, or security incidents. A network diagram © is a graphical representation of the physical or logical connections between devices or nodes in a network, such as routers, switches, servers, or computers. References:

https://www.visual-paradigm.com/tutorials/data-flow-diagram-dfd.jsp

https://www.lucidchart.com/pages/data-flow-diagram

Software as a Service (SaaS) is a cloud deployment model that provides users with access to software applications over the internet, without requiring them to install, maintain, or update the software on their own devices. SaaS is primarily focused on the application layer, as it delivers the complete functionality of the software to the end users, while abstracting away the underlying infrastructure, platform, and middleware layers. SaaS providers are responsible for managing the servers, databases, networks, security, and scalability of the software, as well as ensuring its availability, performance, and compliance. SaaS users only pay for the software usage, usually on a subscription or pay-per-use basis, and can access the software from any device and location, as long as they have an internet connection. Some examples of SaaS applications are Gmail, Salesforce, Dropbox, and Netflix. References:

• Shared Assessments CTPRP Study Guide, page 15, section 2.2.2
• Cloud Computing Deployment Models and Architectures, section on Cloud Computing Models
• Layered Architecture of Cloud, section on Application Layer

Peer code reviews are an essential part of the software development lifecycle (SDLC) process, as they help to improve the quality, security, and maintainability of the code. Peer code reviews involve having other developers review the code written by a developer before it is merged into the main branch or deployed to production. Peer code reviews can help to identify and fix errors, bugs, vulnerabilities, performance issues, coding standards violations, design flaws, and other issues that may affect the functionality or usability of the software. Peer code reviews also facilitate knowledge sharing, collaboration, and feedback among the development team, which can enhance the skills and productivity of the developers123.

The other options are not as likely to be included in the SDLC process, as they are either performed at different stages or not directly related to the development of the software. Scheduling the frequency of automated vulnerability scans and defining the scope of annual penetration tests are more related to the security testing and monitoring of the software, which are usually done after the development phase or as part of the maintenance phase. Scanning for data input validation in production is also a security measure that is done after the software is deployed, and it is not a good practice to rely on production testing alone, as it may expose the software to potential attacks or data breaches. Data input validation should be done during the development and testing phases, as well as in production123. References:

• What is SDLC? - Software Development Lifecycle Explained - AWS
• Software Development Life Cycle (SDLC) - GeeksforGeeks
• What Is the Software Development Life Cycle? SDLC Explained | Coursera

 TPRM program metrics are the indicators that measure the performance, effectiveness, and maturity of the TPRM program. They help to monitor and communicate the progress, achievements, and challenges of the TPRM program to various stakeholders, such as business units, executive management, risk committees, and board of directors. However, the level of reporting and the frequency of changes in TPRM program metrics vary depending on the stakeholder’s role, responsibility, and interest123:

• Business unit: This level of reporting is focused on the operational aspects of the TPRM program, such as the status of vendor assessments, remediation actions, issues, and incidents. The changes in TPRM program metrics at this level are frequent and granular, as they reflect the day-to-day activities and outcomes of the TPRM program.
• Executive management: This level of reporting is focused on the strategic aspects of the TPRM program, such as the alignment with the business objectives, the compliance with the regulatory requirements, the management of the key risks, and the optimization of the resources and costs. The changes in TPRM program metrics at this level are less frequent and more aggregated, as they reflect the overall direction and performance of the TPRM program.
• Risk committee: This level of reporting is focused on the oversight aspects of the TPRM program, such as the evaluation of the risk appetite, the review of the risk profile, the approval of the risk policies, and the escalation of the risk issues. The changes in TPRM program metrics at this level are occasional and more analytical, as they reflect the governance and assurance of the TPRM program.
• Board of Directors: This level of reporting is focused on the advisory aspects of the TPRM program, such as the endorsement of the risk strategy, the awareness of the risk trends, the guidance of the risk culture, and the support of the risk initiatives. The changes in TPRM program metrics at this level are rare and exceptional, as they reflect the high-level and long-term vision and value of the TPRM program.

Therefore, the correct answer is D. Board of Directors, as this is the level of reporting where changes in TPRM program metrics are rare and exceptional. References:

• 1: 15 KPIs & Metrics to Measure the Success of Your TPRM Program | UpGuard
• 2: Third-party risk management metrics: Best practices to enhance your … | Diligent
• 3: TPRM Metrics - Telling Your Risk Story - Shared Assessments | Shared Assessments

In the context of Third-Party Risk Management (TPRM) requirements within the Software Development Life Cycle (SDLC), a process for data destruction and disposal is not typically considered a key component. The primary focus within SDLC in TPRM is on ensuring secure software development practices, which includes maintaining artifacts to prove that SDLC gates are executed, conducting software security testing, and having processes in place for fixing security defects. While data destruction and disposal are important security considerations, they are generally associated with data lifecycle management and information security management practices rather than being integral to the SDLC process itself.

References:

• Best practices in secure software development, as outlined in frameworks like the Secure Software Development Framework (SSDF) by NIST, emphasize the importance of secure coding, vulnerability testing, and remediation processes rather than data disposal practices.
• The "Software Security Framework (SSF)" by the Open Web Application Security Project (OWASP) provides guidance on integrating security practices into the SDLC, focusing on areas like threat modeling, secure coding, and security testing.

 When a vendor contract terminates, one of the most important requirements for managing risk is to ensure that the vendor securely destroys or returns any data or assets that belong to the organization or its customers. This is to prevent any unauthorized access, use, disclosure, or loss of sensitive information or resources that could result in legal, regulatory, reputational, or financial consequences. The organization should also verify that the vendor complies with this requirement by requesting evidence or conducting audits.

The other options are also important, but not as critical as ensuring data and asset security. Performing a financial review of outstanding invoices is necessary to avoid overpaying or underpaying the vendor, and to resolve any disputes or claims. Performing a final assessment based on due diligence standards is useful to evaluate the vendor’s performance, identify any issues or gaps, and document any lessons learned or best practices. Defining contract terms for transition services is helpful to facilitate a smooth and orderly handover of responsibilities, deliverables, or processes to another vendor or internal team.

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 vendor offboarding and termination.
• 2: Prevalent, a platform for third party risk management, provides a blog post on vendor offboarding and termination risk management, which includes a checklist and a template for secure data and asset destruction or return.
• 3: Spendflo, a platform for vendor risk management, provides a guide on vendor risk management, which includes the importance of data and asset security when terminating vendor contracts.

Workstation and endpoint security refers to the protection of devices that connect to a network from malicious actors and exploits1. These devices include laptops, desktops, tablets, smartphones, and IoT devices. Workstation and endpoint security can involve various measures, such as antivirus software, firewalls, encryption, authentication, patch management, and device management1.

Among the four options, the use of multi-tenant laptops poses the greatest risk potential for workstation and endpoint security. Multi-tenant laptops are laptops that are shared by multiple users or organizations, such as in a cloud-based environment2. This means that the laptop’s resources, such as memory, CPU, storage, and network, are divided among different tenants, who may have different security policies, requirements, and access levels2. This can create several challenges and risks, such as:

• Data leakage or theft: If the laptop is not properly isolated or encrypted, one tenant may be able to access or compromise another tenant’s data or applications2. This can result in data breaches, identity theft, or compliance violations.
• Malware infection or propagation: If one tenant’s laptop is infected by malware, such as ransomware, spyware, or viruses, it may spread to other tenants’ laptops through the shared network or storage2. This can disrupt the laptop’s performance, functionality, or availability, and cause damage or loss of data or applications.
• Resource contention or exhaustion: If one tenant’s laptop consumes more resources than allocated, it may affect the performance or availability of other tenants’ laptops2. This can result in slow response, poor user experience, or service degradation or interruption.
• Configuration or compatibility issues: If one tenant’s laptop has different or conflicting settings, preferences, or applications than another tenant’s laptop, it may cause errors, crashes, or compatibility problems2. This can affect the laptop’s functionality, reliability, or usability.

Therefore, the use of multi-tenant laptops should trigger more investigation due to greater risk potential, and require more stringent and consistent security controls, such as:

• Segmentation or isolation: The laptop should be logically or physically separated into different segments or zones for each tenant, and restrict the communication or interaction between them2. This can prevent unauthorized access or interference between tenants, and limit the impact of a security incident to a specific segment or zone.
• Encryption or obfuscation: The laptop should encrypt or obfuscate the data and applications of each tenant, and use strong encryption keys or algorithms2. This can protect the confidentiality and integrity of the data and applications, and prevent data leakage or theft.
• Antivirus or anti-malware: The laptop should install and update antivirus or anti-malware software, and scan the laptop regularly for any malicious or suspicious activities2. This can detect and remove any malware infection or propagation, and prevent damage or loss of data or applications.
• Resource allocation or management: The laptop should allocate or manage the resources of each tenant, and monitor the resource consumption and utilization2. This can ensure the performance or availability of the laptop, and prevent resource contention or exhaustion.
• Configuration or standardization: The laptop should configure or standardize the settings, preferences, or applications of each tenant, and ensure the compatibility or interoperability between them2. This can avoid errors, crashes, or compatibility issues, and improve the functionality, reliability, or usability of the laptop.

References: 1: What is Desktop Virtualization? | IBM1 2: Multitenant organization scenario and Microsoft Entra capabilities2

 ESG programs are initiatives that aim to improve the environmental, social, and governance performance of a vendor or service provider. ESG programs may be driven by various factors, such as regulatory obligations, customer expectations, stakeholder pressure, industry standards, or company commitments. Therefore, statement B is true and the correct answer is B. Statement A is false because ESG expectations may come from external entities, such as regulators, investors, customers, or civil society. Statement C is false because ESG commitments can be measured both qualitatively and quantitatively, using indicators such as carbon emissions, diversity, ethics, or compliance. Statement D is false because ESG obligations may apply to any company, regardless of its size, ownership, or sector. References:

• Third-party risk management and the ESG agenda
• ESG third-party risk
• The Role of Third-Party Risk Management in ESG Compliance

 Questionnaires are one of the most common and effective tools for conducting third party risk assessments. They help organizations gather information about the security and compliance practices of their vendors and service providers, as well as identify any gaps or weaknesses that may pose a risk to the organization. However, not all questionnaires are created equal. Depending on the nature and scope of the third party relationship, different types and levels of questions may be required to adequately assess the risk. Therefore, it is important to configure the assessment questionnaires based on the risk rating and type of service being evaluated12.

The risk rating of a third party is determined by various factors, such as the criticality of the service they provide, the sensitivity of the data they handle, the regulatory requirements they must comply with, and the potential impact of a breach or disruption on the organization. The higher the risk rating, the more detailed and comprehensive the questionnaire should be. For example, a high-risk third party that processes personal or financial data may require a questionnaire that covers multiple domains of security and privacy, such as data protection, encryption, access control, incident response, and audit. A low-risk third party that provides a non-critical service or does not handle sensitive data may require a questionnaire that covers only the basic security controls, such as firewall, antivirus, and password policy12.

The type of service that a third party provides also influences the configuration of the questionnaire. Different services may have different security and compliance standards and best practices that need to be addressed. For example, a third party that provides cloud-based services may require a questionnaire that covers topics such as cloud security architecture, data residency, service level agreements, and disaster recovery. A third party that provides software development services may require a questionnaire that covers topics such as software development life cycle, code review, testing, and vulnerability management12.

By configuring the assessment questionnaires based on the risk rating and type of service being evaluated, organizations can ensure that they ask the right questions to the right third parties, and obtain relevant and meaningful information to support their risk management decisions. Therefore, the statement that assessment questionnaires should be configured based on the risk rating and type of service being evaluated is TRUE12. References: 1: How to Use SIG Questionnaires for Better Third-Party Risk Management 2: Third-party risk assessment questionnaires - KPMG India

Incident response and incident notification are two related but distinct processes that organizations should follow when dealing with security incidents. Incident response is the process of identifying, containing, analyzing, eradicating, and recovering from security incidents, while incident notification is the process of communicating the relevant information about the incident to the appropriate internal and external stakeholders, such as senior management, regulators, customers, and media12.

Not all security incidents are security breaches, which are defined as unauthorized access to or disclosure of sensitive or confidential information that could result in harm to the organization or individuals3. A security incident may become a security breach based on the analysis of the impact, scope, and severity of the incident, as well as the applicable legal and regulatory requirements. When a security breach is confirmed or suspected, the organization should trigger its incident notification or crisis communication process, which should include the following elements:

• A clear definition of roles and responsibilities for notification and communication
• A list of internal and external stakeholders who need to be notified and their contact information
• A set of predefined templates and messages for different types of incidents and audiences
• A communication strategy and timeline that aligns with the incident response plan and the business continuity plan
• A feedback mechanism to monitor and measure the effectiveness of the communication and adjust as needed

Incident notification and communication are critical for managing the reputation, trust, and compliance of the organization, as well as for mitigating the potential legal, financial, and operational consequences of a security breach. References:

• 1: Incident Response Plan: Frameworks and Steps
• 2: A Guide to Incident Response Plans, Playbooks, and Policy
• 3: What is Incident Response? Plan and Steps
• : Incident Response and Breach Notification
• : Incident Response Communication: Best Practices
• : The Importance of Incident Response Communication

The purpose of internal communications and information sharing using TPRM performance metrics is to inform and align the organization’s stakeholders on the status, progress, and outcomes of the TPRM program. This includes communicating the results of vendor assessments, the compliance level of the organization’s policies and procedures, and the periodic reporting to management and other relevant parties. However, documenting the corrective action plan between external parties is not an internal communication, but rather an external one. This is because the corrective action plan is a formal agreement between the organization and the vendor to address and resolve the issues identified in the assessment. Therefore, this statement is not an example of the purpose of internal communications and information sharing using TPRM performance metrics. References:

• 15 KPIs & Metrics to Measure the Success of Your TPRM Program
• Third-party risk management metrics: Best practices to enhance your program
• 3 Best Third-Party Risk Management Software Solutions (2024)

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

Risk treatment is the process of selecting and implementing measures to modify risk, according to the organization’s risk appetite and tolerance. There are four main risk treatment options: avoid, reduce, transfer, or retain the risk123. Among these options, risk transfer typically requires a negotiation of contract terms between parties, as it involves shifting the responsibility or burden of the risk to another entity, such as an insurer, a supplier, a partner, or a customer1234. Risk transfer can be achieved through various contractual arrangements, such as insurance policies, indemnity clauses, warranties, guarantees, service level agreements, or outsourcing agreements1234. These arrangements usually involve a cost-benefit analysis, a due diligence process, and a mutual agreement on the terms and conditions of the risk transfer1234. Therefore, option D is the correct answer, as it is the only one that reflects a risk treatment approach that typically requires a negotiation of contract terms between parties. References: The following resources support the verified answer and explanation:

• 1: Risk Treatment — ENISA
• 2: Four Basic Risk Treatment Planning Approaches - DigiLEAF
• 3: 3 Steps to Treating Your Organizational Risks - American Society of …
• 4: Risk Management Framework - Treat Risks - Chartered Accountants ANZ

A documented process to gain approvals for use of open source applications is typically not part of evaluating the vendor’s patch management controls, because it is not directly related to the patching process. Patch management controls are the policies, procedures, and tools that enable an organization to identify, acquire, install, and verify patches for software vulnerabilities. Patch management controls aim to reduce the risk of exploitation of known software flaws and ensure the functionality and compatibility of the patched systems. A documented process to gain approvals for use of open source applications is more relevant to the software development and procurement processes, as it involves assessing the legal, security, and operational implications of using open source software components in the vendor’s products or services. Open source software may have different licensing terms, quality standards, and support levels than proprietary software, and may introduce additional vulnerabilities or dependencies that need to be managed. Therefore, a documented process to gain approvals for use of open source applications is a good practice for vendors, but it is not a patch management control per se. References:

• Guide to Enterprise Patch Management Planning
• Governance of Key Aspects of System Patch Management
• Certified Third Party Risk Professional (CTPRP) Study Guide

Web content accessibility guidelines (WCAG) are a set of standards that aim to make web content more accessible to people with disabilities, such as visual, auditory, cognitive, or motor impairments. While WCAG is a good practice for web development and usability, it is not directly related to web application security. WCAG does not address the common security risks that web applications face, such as injection, broken authentication, misconfiguration, or vulnerable components. Therefore, adhering to WCAG is not a method of securing web applications, unlike the other options. References:

• 4: OWASP Top 10, a standard awareness document for web application security, lists the most critical security risks to web applications and provides best practices to prevent or mitigate them.
• 5: SANS Institute, a leading provider of cybersecurity training and certification, offers a security checklist for web application technologies (SWAT) that covers best practices for error handling, data protection, configuration, authentication, session management, input and output handling, and access control.
• 6: Built In, a platform for tech professionals, provides 13 web application security best practices, such as using a web application firewall, keeping track of APIs, enforcing expected application behaviors, and following the OWASP Top 10.

Data privacy policies are documents that outline how an organization collects, uses, stores, shares, and protects personal information from its customers, employees, partners, and other stakeholders1. Data privacy policies should address the following key elements2:

• The purpose and scope of data collection and processing
• The legal basis and consent mechanism for data processing
• The types and categories of personal data collected and processed
• The data retention and deletion policies and practices
• The data security and encryption measures and standards
• The data sharing and disclosure practices and procedures, including the use of third parties and cross-border transfers
• The data access, correction, and deletion rights and requests of individuals
• The data breach and incident response and notification procedures and responsibilities
• The data protection officer and contact details
• The data privacy policy review and update process and frequency

Procedures for configuration settings in identity access management are typically not addressed within data privacy policies, as they are more related to the technical and operational aspects of data security and access control. Identity access management (IAM) is a framework of policies, processes, and technologies that enable an organization to manage and verify the identities and access rights of its users and devices3. IAM configuration settings determine how users and devices are authenticated, authorized, and audited when accessing data and resources. IAM configuration settings should be aligned with the data privacy policies and principles, but they are not part of the data privacy policies themselves. IAM configuration settings should be documented and maintained separately from data privacy policies, and should be reviewed and updated regularly to ensure compliance and security. References: 1: What is a Data Privacy Policy? | OneTrust 2: Privacy Policy Checklist: What to Include in Your Privacy Policy 3: What is identity and access management? | IBM : [Identity and Access Management Configuration Settings] : [Why data privacy and third-party risk teams need to work … - OneTrust] : [Privacy Risk Management - ISACA] : [What Every Chief Privacy Officer Should Know About Third-Party Risk …]

Shadow IT refers to the use of IT systems, services, or devices that are not authorized, approved, or supported by the official IT department. Shadow IT can pose significant risks to an organization’s data security, compliance, performance, and reputation. One of the main risks of shadow IT is that it often lacks governance and security oversight. This means that the shadow IT functions may not follow the established policies, standards, and best practices for IT management, such as data protection, access control, encryption, backup, patching, auditing, and reporting. This can expose the organization to various threats, such as data breaches, cyberattacks, malware infections, legal liabilities, regulatory fines, and reputational damage. Additionally, shadow IT can create operational inefficiencies, compatibility issues, duplication of efforts, and increased costs for the organization.

According to the web search results from the search_web tool, shadow IT is a common and growing phenomenon in many organizations, especially with the proliferation of cloud-based services and applications. Some of the articles suggest the following best practices for managing and mitigating shadow IT risks123:

• Performing SaaS assessments to proactively detect shadow IT
• Prioritizing user experience (UX) and providing support for integrating tools
• Streamlining user account and identity management
• Using operating systems and devices with which employees are comfortable
• Compromising and collaborating with users to minimize shadow IT risks
• Educating and training users on the security risks and consequences of shadow IT
• Establishing clear policies and guidelines for IT procurement and usage
• Creating a culture of trust and transparency between IT and business units

Therefore, the verified answer to the question is B. “Shadow IT" functions often lack governance and security oversight.

References:

• Shadow IT Explained: Risks & Opportunities - BMC Software
• Start reducing your organization’s Shadow IT risk in 3 steps
• What is shadow IT? - Article | SailPoint

Fourth-Nth party risk refers to the potential threats and vulnerabilities associated with the subcontractors, vendors, or service providers of an organization’s direct third-party partners12. After contract signing and on-boarding due diligence is complete, the most important type of contract provision to manage Fourth-Nth party risk is subcontractor notice and approval. This provision requires the third party to inform the organization of any subcontracting arrangements and obtain the organization’s consent before engaging any Fourth-Nth parties345. This provision enables the organization to have visibility and control over the extended network of suppliers and service providers, and to assess the potential risks and impacts of any outsourcing decisions. Subcontractor notice and approval also helps the organization to ensure that the Fourth-Nth parties comply with the same standards and expectations as the third party, and to hold the third party accountable for the performance and security of the Fourth-Nth parties345. References:

• 1: Understanding 4th- and Nth-Party Risk: What Do You Need to Know? | Mitratech
• 2: Understanding 4th- and Nth-Party Risk: What Do You Need to Know? | Mitratech Holdings, Inc - JDSupra
• 3: First, 2nd , 3rd , 4th, 5th Parties: How to Measure the Tiers of Risk
• 4: Managing 4th Party Risk with Vendor Insurance Verification - Evident ID
• 5: How to Write Fourth-Party Vendor Requirements Into the Contract - Venminder

A cloud hosting vendor assessment program is a process of evaluating the security, compliance, and performance of a cloud service provider (CSP) that hosts an organization’s data or applications. A cloud hosting vendor assessment program typically includes the following components123:

• Reviewing the entity’s image snapshot approval and management process: This component involves verifying how the CSP creates, approves, stores, and deletes image snapshots of the virtual machines or containers that run the organization’s workloads. Image snapshots can contain sensitive data or configuration settings that need to be protected from unauthorized access or modification.
• Requiring security services documentation and audit attestation reports: This component involves requesting and reviewing the CSP’s documentation and reports that demonstrate the security controls and practices that the CSP implements to protect the organization’s data and applications. These may include service level agreements (SLAs), security policies and procedures, security certifications and standards, vulnerability scanning and patching reports, incident response and disaster recovery plans, and independent audit reports such as SOC 2 or ISO 27001.
• Requiring compliance evidence that provides the definition of patching responsibilities: This component involves asking and verifying how the CSP handles the patching of the operating systems, applications, and libraries that run on the cloud infrastructure. Patching is a critical activity to prevent security breaches and ensure compliance with regulatory requirements. The organization needs to understand the roles and responsibilities of the CSP and the organization in patching the cloud environment, and the frequency and scope of patching activities.

The component that is typically NOT part of a cloud hosting vendor assessment program is conducting customer performed penetration tests. Penetration testing is a method of simulating a cyberattack on a system or network to identify and exploit vulnerabilities and weaknesses. While penetration testing can be a valuable tool to assess the security posture of a CSP, it is not usually included in a cloud hosting vendor assessment program for the following reasons :

• Penetration testing may violate the CSP’s terms of service or acceptable use policy, which may prohibit or restrict the customer from performing any unauthorized or disruptive activities on the cloud infrastructure. The customer may face legal or contractual consequences if they conduct penetration testing without the CSP’s consent or knowledge.
• Penetration testing may interfere with the CSP’s normal operations or affect the availability and performance of the cloud services for other customers. The customer may cause unintended damage or disruption to the CSP’s systems or networks, or trigger false alarms or alerts that may divert the CSP’s resources or attention.
• Penetration testing may not provide a comprehensive or accurate assessment of the CSP’s security, as the customer may have limited visibility or access to the CSP’s internal systems or networks, or may encounter security mechanisms or countermeasures that prevent or limit the penetration testing activities. The customer may also face ethical or legal issues if they access or compromise the data or systems of other customers or the CSP.

Therefore, the verified answer to the question is D. Conducting customer performed penetration tests.

References:

• Four Important Best Practices for Assessing Cloud Vendors
• Top 11 Questionnaires for IT Vendor Assessment in 2024
• Cloud Vendor Assessments | Done The Right Way
• [Penetration Testing in the Cloud: What You Need to Know]
• [Cloud Penetration Testing: Challenges and Best Practices]

Background check requirements are applicable for vendors or service providers based outside the United States, as well as those based within the country. According to the Shared Assessments Program, background checks are a key component of third-party risk management and should be conducted for all third parties that have access to sensitive data, systems, or facilities, regardless of their location1. The FCRA also applies to background checks performed by U.S. employers on foreign nationals who work outside the U.S. for a U.S. employer or its affiliates2. Therefore, statement A is false and the correct answer is A. References:

• Shared Assessments Program: Third Party Risk Management Fundamentals
• Background Checks for Contractors or Vendors

Changes to administrator access are typically not subject to the traditional change control process, as they often pertain to user access management rather than modifications to the production environment's infrastructure or applications. Administrator access changes involve granting, altering, or revoking administrative privileges to systems, which is managed through access control policies and procedures rather than through change control. Change control processes are primarily concerned with changes to the network, systems, and applications that could affect the production environment's stability, security, and functionality. In contrast, managing administrative access is part of identity and access management (IAM), which focuses on ensuring that only authorized individuals have access to specific levels of information and system functionality.

References:

• Access control and identity management best practices, such as those outlined in NIST SP 800-53 (Security and Privacy Controls for Federal Information Systems and Organizations), emphasize the separation of duties and least privilege principles, which guide the management of administrator access changes.
• Resources like "Access Control Systems and Methodology" from ISC²'s CISSP Common Body of Knowledge provide guidelines on effectively managing access to prevent unauthorized access and maintain system security.

The most important next step after receiving a vendor questionnaire is to analyze the responses and identify any gaps, issues, or risks that may pose a threat to the organization or its customers. This analysis should be based on the inherent risk profile of the vendor, the criticality of the service or product they provide, and the applicable regulatory and contractual requirements. The analysis should also highlight any adverse or high priority responses that indicate a lack of adequate controls, policies, or procedures on the vendor’s part. These responses should be prioritized for further validation, testing, or remediation. The analysis should also document any assumptions, limitations, or dependencies that may affect the accuracy or completeness of the vendor’s responses. References:

• Shared Assessments CTPRP Study Guide, Section 4.2.2, page 43
• Third-Party Risk Management: Managing Risk, Section “Assessing and monitoring third-party risk”
• What Is Third-Party Risk Management (TPRM)? 2024 Guide, Section “Third-Party Risk Management Process”

Remote wipe is a security feature that allows an administrator or a user to remotely erase all the data and settings on a device in case it is lost or stolen. This prevents unauthorized access to sensitive information and reduces the risk of data breaches. Remote wipe is typically used for company-owned devices, as it ensures that no company data remains on the device after it is lost or stolen. Remote wipe also restores the device to its factory settings, making it unusable for the thief or finder. Remote wipe can be performed through various methods, such as using a mobile device management (MDM) solution, a cloud service, or a built-in feature of the device’s operating system. References:

• 1: How to protect your company from data breaches caused by lost or stolen devices
• 2: BYOD vs Company-Owned Devices: How to Maintain Security
• 3: Lost or Stolen Business Device? Here’s What to do Next

 This answer is correct because a change at outsourcer due to merger and acquisition (M&A) is the least likely indicator to trigger a reassessment of an existing vendor. This is because the outsourcer is not the direct vendor of the organization, but rather a third party that the vendor uses to perform some of its services. Therefore, the impact of the change at the outsourcer on the vendor’s performance and risk level may not be significant or immediate. However, the other indicators (A, B, and C) are more likely to trigger a reassessment of an existing vendor, as they directly affect the vendor’s operations, capabilities, and compliance status. For example:

• A change in vendor location or use of new fourth parties may introduce new risks such as geopolitical, regulatory, or cybersecurity risks that need to be evaluated and mitigated.
• A change in scope of existing work may alter the vendor’s access to the organization’s data or systems, which may require additional security measures and controls to protect the confidentiality, integrity, and availability of the information assets.
• A change in regulation that impacts service provider requirements may impose new obligations or standards on the vendor that need to be verified and monitored to ensure compliance and avoid penalties or fines. References:
• How to Conduct a Successful Vendor Risk Assessment in 9 Steps, Case IQ
• Why You Need to Reassess Vendor Risk on an Ongoing Basis, ThirdPartyTrust
• Vendor Assessment and Evaluation Guide, Smartsheet