Shared Assessments CTPRP Certified Third-Party Risk Professional (CTPRP) Exam Practice Test

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.

 Criticality is a measure of how essential a service provider is to the organization’s core business functions and objectives. It reflects the potential consequences of a service disruption or failure on the organization’s operations, reputation, compliance, and financial performance. Criticality is not the same as risk, which is the likelihood and severity of a negative event occurring. Criticality helps to prioritize the risk assessment and mitigation efforts for different service providers based on their relative importance to the organization. Criticality is not limited to a specific type of service, such as disaster recovery or personal information, nor is it determined by the mode of access or connectivity. Criticality is assigned to the service providers that have the greatest impact on the organization’s ability to deliver its products or services to its customers and stakeholders in a timely and satisfactory manner. References:

• Shared Assessments. (2020). Certified Third Party Risk Professional (CTPRP) Study Guide1
• Milliman. (2017). Defining “critical or important functions or activities” for outsourcing purposes2
• Webster, C. and Sundaram, D.S. (2009). Effect of service provider’s communication style on customer satisfaction in professional services setting: the moderating role of criticality and service nature. Journal of Services Marketing, 23(2), 103-1131

According to the Certified Third Party Risk Professional (CTPRP) Job Guide, one of the key tasks of a third party risk professional is to “manage the corrective action process for identified issues and ensure timely resolution” (p. 10). This task involves the following steps:

• Document the findings and recommendations from the assessment and communicate them to the appropriate stakeholders
• Review the findings and recommendations with the line of business (LOB) and obtain their risk acceptance or rejection
• If the LOB accepts the risk, document the rationale and approval in the risk register
• If the LOB rejects the risk, work with the vendor to develop a remediation plan that addresses the root cause and mitigates the risk
• Monitor the progress and completion of the remediation plan and verify the effectiveness of the corrective actions
• Update the risk register and the vendor profile with the results of the remediation

Therefore, the statement that best represents the roles and responsibilities for managing corrective actions is C, as it reflects the need to review the findings and need for remediation with the LOB for risk acceptance before sharing the remediation plan with the vendor. This ensures that the LOB is aware of the risks and their impact, and that the vendor is committed to resolving the issues in a timely and satisfactory manner.

References:

• CTPRP Job Guide, Shared Assessments, 2020
• Best Practices Guidance for Third Party Risk, Global Association of Risk Professionals (GARP), 2019
• Simple Guide for Corrective and Preventative Action (CAPA), Qualcy eQMS, 2020
• [The Three Key Parts of an EHS Corrective Action Plan], EHS Daily Advisor, 2021

A BCP or IT DR plan is a set of procedures and actions that an organization takes to ensure the continuity and recovery of its critical business functions and IT systems in the event of a disruption. A BCP or IT DR plan typically covers the following aspects12:

• Identification and prioritization of critical business functions and IT systems
• Assessment and mitigation of risks and threats to the organization
• Allocation and mobilization of resources and personnel
• Communication and coordination with internal and external stakeholders
• Testing and updating of the plan

Among the four examples of a response to external environmental factors, protocols for social media channels and PR communication are the least likely to be managed directly within the BCP or IT DR plan. This is because social media and PR communication are not critical business functions or IT systems that need to be restored or maintained during a disruption. They are rather supplementary tools that can be used to inform and engage with the public, customers, partners, and media about the organization’s situation and actions3. Therefore, protocols for social media and PR communication are more likely to be part of a crisis communication plan, which is a separate but related document that outlines the strategies and tactics for communicating with various audiences during a crisis.

The other three examples are more likely to be managed directly within the BCP or IT DR plan, as they directly affect the organization’s ability to perform its critical business functions and IT systems. For instance, a response to a natural or man-made disruption would involve activating the BCP or IT DR plan, assessing the impact and extent of the damage, deploying backup and recovery solutions, and restoring normal operations as soon as possible. A response to a dependency on key employee or supplier issues would involve identifying and managing the single points of failure, implementing contingency plans, and ensuring the availability and redundancy of essential skills and resources. A response to a large scale illness or health outbreak would involve implementing health and safety measures, enabling remote work arrangements, and ensuring the resilience and continuity of the workforce. References:

• Business continuity vs. disaster recovery: Which plan is right … - IBM
• Business Continuity vs Disaster Recovery: What’s The Difference?
• Disaster recovery plan vs. business continuity plan: Is there a difference?
• [Crisis Communication Plan: A PR Blue Print by Sandra K. Clawson Freeo]
• [Disaster Recovery Planning (DRP) | Business Continuity Plan (BCP) | Disaster Recovery Journal]
• [Managing Third Party Risk in a Disrupted World]
• [Business Continuity Planning for a Pandemic]

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

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

 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

 Personal information is any information that can be used to identify an individual, either directly or indirectly, such as name, address, email, phone number, ID number, etc. Personal data is a term used in some jurisdictions, such as the European Union, to refer to personal information that is subject to data protection laws and regulations. However, the scope and definition of personal data may vary depending on the jurisdiction and the context. For example, the GDPR defines personal data as “any information relating to an identified or identifiable natural person” and includes online identifiers, such as IP addresses, cookies, or device IDs, as well as special categories of data, such as biometric, genetic, health, or political data. On the other hand, the US does not have a single federal law that regulates personal data, but rather a patchwork of sector-specific and state-level laws that may have different definitions and requirements. For example, the California Consumer Privacy Act (CCPA) defines personal information as “information that identifies, relates to, describes, is reasonably capable of being associated with, or could reasonably be linked, directly or indirectly, with a particular consumer or household” and excludes publicly available information from its scope. Therefore, from a privacy perspective, it is important to understand the different legal definitions and obligations that may apply to personal information or personal data depending on the jurisdiction and the context of the data processing activity. References:

• GDPR personal data – what information does this cover?
• Personal Information, Data Classification, Life Cycle and Best Practices
• 5 Types of Data Classification (With Examples)

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.

Indemnification is a contractual obligation by which one party agrees to compensate another party for any losses or damages that may arise from a specified event or circumstance. Mutual indemnification means that both parties agree to indemnify each other for certain losses or damages, such as those caused by a breach of contract, negligence, or violation of law. Mutual indemnification can enable each party to share the amount of information security risk, as it can provide a mechanism for allocating the responsibility and liability for any security incidents or breaches that may affect either party or their customers. Mutual indemnification can also incentivize each party to maintain adequate security controls and practices, as well as to cooperate and communicate effectively in the event of a security incident or breach.

The other options are not contract clauses that enable each party to share the amount of information security risk, because:

• A. Limitation of liability is a contract clause that limits the amount or type of damages that one party can claim from another party in the event of a breach of contract or other legal action. Limitation of liability does not enable each party to share the amount of information security risk, as it can reduce or cap the liability of one party, but not necessarily distribute or balance the risk between both parties.
• B. Cyber insurance is a type of insurance policy that covers the costs and losses resulting from cyberattacks, data breaches, or other cyber incidents. Cyber insurance does not enable each party to share the amount of information security risk, as it can transfer or mitigate the risk to a third-party insurer, but not necessarily allocate or share the risk between both parties.
• C. Force majeure is a contract clause that excuses one or both parties from performing their contractual obligations in the event of an unforeseen or unavoidable event or circumstance that is beyond their control, such as a natural disaster, war, or pandemic. Force majeure does not enable each party to share the amount of information security risk, as it can suspend or terminate the contract in the event of a force majeure event, but not necessarily distribute or balance the risk between both parties.

References:

• Shared Assessments CTPRP Study Guide, page 62, section 5.2.2: Contractual Terms
• Third-Party Risk Management: Vendor Contract Terms and Conditions, section: Indemnification
• Cybersecurity risks from third party vendors: PwC, section: Contractual terms and conditions
• [Third-Party Risk Management: The 3rd Party Ecosystem: How to Manage the Risk While Keeping the Benefit], section: Contractual Terms and Conditions

Asset management is the process of identifying, tracking, and managing the physical and digital assets of an organization. An asset management program is a set of policies, procedures, and tools that help to ensure the optimal use, security, and disposal of assets. According to the Shared Assessments CTPRP Study Guide1, an asset management program should include the following components:

• Asset inventories: A comprehensive and accurate list of all assets owned, leased, or used by the organization, including hardware, software, data, and services. Asset inventories should include connections to external parties, networks, or systems that process data, as this may introduce additional risks and dependencies12.
• Asset owners: A clear assignment of roles and responsibilities for each asset, including an organizational owner who is accountable for the asset throughout its life cycle. Asset owners should ensure that assets are properly maintained, updated, secured, and disposed of in accordance with the organization’s policies and standards13.
• Asset classification: A consistent and objective method of categorizing assets based on their criticality or data sensitivity. Asset classification helps to determine the appropriate level of protection, monitoring, and testing for each asset, as well as the potential impact of asset loss or compromise1 .
• Asset controls: A set of measures and mechanisms that help to safeguard assets from unauthorized access, use, modification, disclosure, or destruction. Asset controls may include physical, technical, administrative, or contractual means, such as locks, encryption, passwords, policies, or agreements1 .

The statement that is least likely to represent a component of an asset management program is D. Asset inventories should track the flow or distribution of items used to fulfill products and Services across production lines. This statement describes a supply chain management function, not an asset management function. Supply chain management is the process of planning, coordinating, and controlling the flow of materials, information, and services from suppliers to customers. Supply chain management may involve some aspects of asset management, such as inventory control, quality assurance, or vendor risk management, but it is not the same as asset management . Asset management focuses on the assets that the organization owns or uses, not the assets that the organization produces or delivers.

References:

• 1: Shared Assessments. (2020). Certified Third Party Risk Professional (CTPRP) Study Guide.
• 2: ISACA. (2019). COBIT 2019 Framework: Governance and Management Objectives. APO03 Manage enterprise architecture.
• 3: ISO. (2018). ISO/IEC 27001:2018 Information technology — Security techniques — Information security management systems — Requirements. Clause 8.1.2 Asset management roles and responsibilities.
• : NIST. (2013). NIST Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations. RA-2 Security Categorization.
• : NIST. (2013). NIST Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations. CM-8 Information System Component Inventory.
• : APICS. (2018). APICS Dictionary, 16th edition. Supply chain management.
• : ISACA. (2019). COBIT 2019 Framework: Governance and Management Objectives. APO13 Manage security.

In patch management, testing is the most crucial factor when conducting post-cybersecurity incident analysis related to systems and applications. Proper testing of patches before deployment ensures that they effectively address vulnerabilities without introducing new issues or incompatibilities that could impact system functionality or security. Testing allows organizations to verify that the patch resolves the identified security issue without adversely affecting the system or application's performance. It also helps in identifying potential conflicts with existing configurations or dependencies. Effective testing strategies include regression testing, performance testing, and security testing to ensure comprehensive validation of the patch's effectiveness and safety before widespread deployment. This approach aligns with best practices in patch management, emphasizing the importance of thorough testing to mitigate the risk of unintended consequences and ensure the continued security and stability of systems and applications.

References:

• Industry standards such as ISO/IEC 27001 (Information Security Management) highlight the importance of a systematic approach to managing patches, including the role of testing in assessing the effectiveness and impact of patches.
• Resources like "Patch Management Best Practices" from the Center for Internet Security (CIS) provide guidance on developing and implementing a patch management program that includes rigorous testing procedures to ensure patches are safely and effectively applied.

Application security design standards are a set of principles for software development that address the top application security risks and industry web requirements. They provide guidance on how to design, develop, and deploy secure applications that meet the security objectives of the organization and the expectations of the customers and regulators. Application security design standards cover topics such as secure design principles, threat modeling, encryption, identity and access management, logging and auditing, coding standards and conventions, safe functions, data handling, error handling, third-party components, and testing and validation. Application security design standards help developers avoid common security pitfalls, reduce vulnerabilities, and enhance the quality and reliability of the software. Application security design standards also facilitate the alignment of the software development lifecycle with the third-party risk management framework, by ensuring that security requirements are defined, implemented, verified, and maintained throughout the development process. References:

• Fundamental Practices for Secure Software Development
• Secure Coding Practices
• Secure Software Development Best Practices
• Certified Third Party Risk Professional (CTPRP) Study Guide

  Performance risk, defined as the risk that a third party may not be able to meet its obligations due to inadequate systems or processes, accurately describes the situation. This type of risk involves concerns about the third party's ability to deliver services or products at the required performance level, potentially due to limitations in their technology infrastructure, operational procedures, or management practices. Identifying and managing performance risk is essential in Third-Party Risk Management (TPRM) to ensure that third-party vendors can reliably meet contractual and service-level agreements, thereby minimizing the impact on the organization's operations and service delivery.

References:

• TPRM guidelines, such as those from the Office of the Comptroller of the Currency (OCC) and the Federal Financial Institutions Examination Council (FFIEC), highlight the importance of assessing and managing performance risks associated with third-party relationships.
• The "Third-Party Risk Management Guide" by ISACA discusses various types of risks, including performance risk, associated with engaging third-party service providers, emphasizing the need for thorough due diligence and ongoing monitoring.

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)

A network access policy is a set of rules and conditions that define how authorized users and devices can access the network resources and services of an organization. It typically includes the following elements12:

• Firewall settings: These are the rules that control the incoming and outgoing network traffic based on the source, destination, protocol, and port of the packets. Firewall settings help to protect the network from unauthorized or malicious access, and to enforce the network security policy of the organization.
• Unauthorized device detection: This is the process of identifying and preventing unauthorized devices from accessing the network. Unauthorized devices can pose a security risk to the network, as they may not comply with the security standards and policies of the organization, or they may be compromised by malware or hackers. Unauthorized device detection can be done by using various methods, such as network access control (NAC), network admission control (NAC), or 802.1X authentication.
• Remote access: This is the ability of authorized users to access the network resources and services of the organization from a remote location, such as a home office, a hotel, or a public hotspot. Remote access can be provided by using various technologies, such as virtual private networks (VPNs), remote desktop services (RDS), or remote access services (RAS). Remote access requires a secure and reliable connection, and it must comply with the network access policy of the organization.
• Website privacy consent banners: These are the messages that appear on websites to inform the visitors about the use of cookies and other tracking technologies, and to obtain their consent for such use. Website privacy consent banners are part of the website privacy policy, which is a legal document that discloses how the website collects, uses, and protects the personal data of the visitors. Website privacy consent banners are not related to the network access policy of the organization, as they do not affect how the users and devices can access the network resources and services of the organization.

Therefore, the correct answer is C. Website privacy consent banners, as they are typically not included within the scope of an organization’s network access policy. References:

• 1: Network Policy Server (NPS) | Microsoft Learn
• 2: Network Access Policy | University Policies

 According to the CTPRP Job Guide, the TPRM program should establish minimum risk assessment standards for third party due diligence based on the company’s risk tolerance and risk appetite. This means that the TPRM program should define the scope, depth, frequency, and methodology of the risk assessment process for different categories of third parties, taking into account the potential impact and likelihood of various risks. The risk assessment standards should be consistent, transparent, and aligned with the company’s strategic objectives and regulatory obligations. The TPRM program should also monitor and update the risk assessment standards as needed to reflect changes in the business environment, risk profile, and best practices. The other options are not correct because they do not reflect a holistic and risk-based approach to third party due diligence. Setting the standards by each business unit may result in inconsistency, duplication, or gaps in the risk assessment process. Defining the standards in the contract or statement of work may limit the flexibility and adaptability of the risk assessment process to changing circumstances. Identifying the standards by procurement may overlook the input and involvement of other stakeholders and functions in the risk assessment process. References:

• CTPRP Job Guide, page 17
• Third-Party Risk Management and ISO Requirements for 2022, section “Benefits of Implementing Risk Management”
• Managing third-party risk through effective due diligence, section “Complying with regulators’ demands”
• Third-Party Due Diligence Checklist: 3 Essential Steps, section “Step 2: Conduct a Risk Assessment”

A Business Impact Analysis (BIA) is a process of determining the criticality of business activities and associated resource requirements to ensure operational resilience and continuity of operations during and after a business disruption1. A BIA is used to identify the potential impacts of disruptions on business processes, such as lost sales, delayed revenue, increased expenses, regulatory fines, or contractual penalties2. A BIA is not concerned with the probability or causes of disruptions, but rather with the effects and consequences of disruptions3. Therefore, a BIA typically does not include requiring vendor participation in testing, as this is a part of the business continuity and disaster recovery planning and implementation, not the impact analysis. Vendor participation in testing is important to validate the effectiveness and alignment of the vendor’s business continuity and disaster recovery plans with the organization’s objectives and expectations, but it is not a component of the BIA itself. References: 1: Using Business Impact Analysis to Inform Risk Prioritization and Response 2: Business Impact Analysis (BIA): Prepare for Anything [2024] • Asana 3: The Difference Between a Vendor’s BIA and Risk Analysis - Venminder : Best Practices Guidance for Third Party Risk

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.

The onboarding process for new hires is a key part of the third-party risk management program, as it ensures that the right people are hired and trained to perform their roles effectively and securely. One of the best practices for onboarding new hires is to conduct applicant screening, which may include background checks, reference checks, verification of credentials, and assessment of skills and competencies. Applicant screening helps to identify and mitigate potential risks such as fraud, theft, corruption, or data breaches that may arise from hiring unqualified, dishonest, or malicious individuals. Therefore, it is important to wait for the results of applicant screening before onboarding new employees and contractors, as this can prevent costly and damaging incidents in the future.

The other statements are false regarding the onboarding process for new hires. It is necessary to have employees, contractors, and third-party users sign confidentiality or non-disclosure agreements, as this protects the company’s sensitive information and intellectual property from unauthorized disclosure or misuse. Non-compete agreements may not be required for all job roles, as they may limit the employee’s ability to work for other companies or in the same industry after leaving the current employer. They may also be subject to legal challenges depending on the jurisdiction and the scope of the agreement. Security and privacy awareness training is essential for all new employees and contractors, regardless of their existing certifications, as it educates them on the company’s policies, procedures, and standards for protecting data and systems from cyber threats. It also helps to foster a culture of security and compliance within the organization. References:

• 5 Steps to Effective Third-Party Onboarding
• Using a third-party onboarding tool to address new challenges in third-party risk
• Onboarding and terminating third parties
• CTPRP Job Guide

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

An outsourcer’s vendor risk assessment process should include all the steps mentioned in options A, B, and C, as they are essential for ensuring a consistent, comprehensive, and effective evaluation of the vendor’s performance, compliance, and risk profile. However, option D is not a necessary or recommended part of the vendor risk assessment process, as it does not reflect the actual level of risk posed by the vendor, but rather the availability of resources within the outsourcer’s organization. Defining assessment frequency based on resource capacity could lead to under-assessing or over-assessing vendors, depending on the outsourcer’s workload, budget, and staff. This could result in missing critical issues, wasting time and money, or creating gaps in the vendor oversight program. Therefore, option D is the correct answer, as it is the only one that does not belong to the vendor risk assessment process. References: The following resources support the verified answer and explanation:

• Shared Assessments’ CTPRP Job Guide, page 10, section 2.1.1, states that “The frequency of assessments should be based on the risk tier of the third party, not on the availability of resources.”
• Guide to Vendor Risk Assessment, section “Step 3: Determine the Frequency of Vendor Risk Assessments”, explains that “The frequency of vendor risk assessments should be based on the level of risk each vendor poses to your organization, not on the availability of resources or convenience.”
• How to Conduct a Successful Vendor Risk Assessment in 9 Steps, section “Step 8: Determine the Frequency of Vendor Risk Assessments”, advises that “The frequency of vendor risk assessments should be based on the level of risk each vendor poses to your organization, not on the availability of resources or convenience.”

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

A well-defined third party risk management program does not require conducting onsite or virtual assessments for all third parties, as this would be impractical, costly, and inefficient. Instead, a TPRM program should adopt a risk-based approach to determine the frequency, scope, and depth of assessments based on the inherent and residual risks posed by each third party. This means that some third parties may require more frequent and comprehensive assessments than others, depending on factors such as the nature, scope, and criticality of their services, the sensitivity and volume of data they access or process, the regulatory and contractual obligations they must comply with, and the results of previous assessments and monitoring activities. A risk-based approach to assessments allows an organization to allocate its resources and efforts more effectively and efficiently, while also ensuring that the most significant risks are adequately addressed and mitigated. References:

• Shared Assessments, CTPRP Job Guide, page 9: “The frequency, scope, and depth of assessments should be determined by the inherent and residual risks posed by each third party.”
• OneTrust, [What is Third-Party Risk Management?]: “A risk-based approach to third-party risk management means that you prioritize your efforts and resources based on the level of risk each vendor poses to your organization.”
• [Deloitte], [Third Party Risk Management: Managing Risk]: “A risk-based approach to third-party risk management helps organizations prioritize their efforts and resources based on the level of risk each third party poses to the organization.”

According to the Shared Assessments Certified Third Party Risk Professional (CTPRP) Study Guide, the third party risk assessor’s role is to evaluate the design and operating effectiveness of the third party’s controls based on an industry framework, such as ISO, NIST, COBIT, or COSO1. The assessor’s role is not to provide an opinion on the effectiveness of controls, but rather to report the results of the evaluation in a factual and objective manner2. The assessor’s role is also to conduct discovery with subject matter experts to understand the control environment, to conduct discovery and validate responses from the risk assessment questionnaire by testing or validating controls, and to review compliance artifacts and identify potential control gaps based on evaluation of the presence of control attributes1. These are all true statements that describe the assessor’s role when conducting a controls evaluation using an industry framework.

References:

• 1: Shared Assessments Certified Third Party Risk Professional (CTPRP) Study Guide, page 29
• 2: What is a Third-Party Risk Assessment? — RiskOptics

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

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

Third-party risk management (TPRM) is the process of identifying, assessing, and mitigating the risks associated with outsourcing business activities or functions to external entities. TPRM is influenced by various regulations that aim to protect the interests of customers, stakeholders, and regulators from the potential harm caused by third-party failures or misconduct. These regulations may vary depending on the industry, jurisdiction, and nature of the third-party relationship. Therefore, it is important for organizations to update their inventory of regulations that impact their TPRM program during their annual risk assessment, and prioritize the regulations that are most relevant and critical for their business objectives and risk appetite.

The optimal approach to prioritizing the regulations is to identify the applicable regulations that require an extension of specific obligations to service providers. This means that the organization should focus on the regulations that impose certain requirements or expectations on the organization and its third-party partners, such as data protection, security, compliance, reporting, auditing, or performance standards. These regulations may also specify the roles and responsibilities of the organization and the service provider, the scope and frequency of due diligence and monitoring activities, the contractual clauses and terms, and the remediation and termination procedures. By identifying these regulations, the organization can ensure that its TPRM program is aligned with the regulatory expectations and obligations, and that it can effectively manage and mitigate the risks associated with its third-party relationships.

Some examples of regulations that require an extension of specific obligations to service providers are:

• The General Data Protection Regulation (GDPR): This is a European Union regulation that governs the collection, processing, and transfer of personal data of individuals in the EU. The GDPR requires organizations to implement appropriate technical and organizational measures to protect the personal data, and to only engage with service providers that can provide sufficient guarantees of data protection. The GDPR also requires organizations to enter into written contracts with their service providers that specify the subject matter, duration, nature, and purpose of the data processing, as well as the rights and obligations of both parties. The GDPR also imposes strict notification and reporting requirements in case of data breaches or violations.
• The Health Insurance Portability and Accountability Act (HIPAA): This is a US federal law that regulates the privacy and security of health information of individuals. The HIPAA requires covered entities, such as health care providers, health plans, and health care clearinghouses, to safeguard the health information of their patients, and to only disclose or share it with authorized parties. The HIPAA also requires covered entities to enter into business associate agreements with their service providers that handle or access the health information on their behalf. These agreements must specify the permitted and required uses and disclosures of the health information, the safeguards and measures to protect the health information, and the reporting and notification obligations in case of breaches or incidents.
• The Sarbanes-Oxley Act (SOX): This is a US federal law that aims to improve the accuracy and reliability of corporate financial reporting and disclosure. The SOX requires public companies to establish and maintain internal controls over their financial reporting processes, and to assess and report on the effectiveness of these controls. The SOX also requires public companies to ensure that their external auditors are independent and qualified, and to disclose any material weaknesses or deficiencies in their internal controls. The SOX also applies to the service providers that perform or support the financial reporting functions of the public companies, such as accounting firms, information technology vendors, or consultants. The SOX requires public companies to evaluate and monitor the internal controls of their service providers, and to include them in their scope of audit and reporting.

References:

• Third-Party Risk Management and Mitigation | Gartner
• Best Practices to Jumpstart Third-Party Risk Management Program
• Third-party risk management best practices and why they matter
• GDPR and Third-Party Risk Management
• HIPAA Compliance for Business Associates and Third-Party Service Providers
• SOX Compliance Requirements for Third-Party Service Providers

TPRM compliance requirements are the rules and expectations that an organization must follow when engaging with third parties, such as vendors, suppliers, partners, or contractors. These requirements are derived from various sources, such as laws, regulations, standards, frameworks, contracts, policies, and best practices. However, relying solely on regulatory mandates to define and structure TPRM compliance requirements is a false statement, because123:

• Regulatory mandates are not the only source of TPRM compliance requirements. Organizations may also need to consider other factors, such as industry benchmarks, customer expectations, stakeholder interests, ethical principles, and social responsibility.
• Regulatory mandates are not always comprehensive, clear, or consistent. Organizations may face different or conflicting regulations across jurisdictions, sectors, or domains. Organizations may also need to interpret and apply the regulations to their specific context and risk profile, which may require additional guidance or expertise.
• Regulatory mandates are not always sufficient, effective, or efficient. Organizations may need to go beyond the minimum requirements of the regulations to achieve their business objectives, mitigate their risks, or enhance their performance. Organizations may also need to adopt more flexible, scalable, and innovative approaches to TPRM compliance, rather than following a rigid, one-size-fits-all, or check-the-box model.

Therefore, the correct answer is B. Organizations rely on regulatory mandates to define and structure TPRM compliance requirements, as this is a false statement regarding the risk factors an organization may include when defining TPRM compliance requirements. References:

• 1: Understanding TPRM Compliance: A Comprehensive Guide | Prevalent
• 2: What Is Third-Party Risk Management (TPRM)? 2024 Guide | UpGuard
• 3: Third-Party Risk Management and ISO Requirements for 2022 | Reciprocity

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

A secure SDLC is a framework that integrates security best practices and standards throughout the software development life cycle, from planning to deployment and maintenance. A secure SDLC aims to ensure that security is considered and implemented at every stage of the development process, not just as an afterthought or a compliance check. A secure SDLC can help organizations to achieve the following benefits12:

• Reduce the risk of security breaches and incidents by identifying and mitigating vulnerabilities early and continuously
• Improve the quality and reliability of software products by ensuring that they meet both the functional and the security requirements
• Save time and money by avoiding costly rework, remediation, and reputation damage caused by security flaws
• Enhance customer trust and satisfaction by delivering secure and compliant software solutions
• Foster a culture of security awareness and responsibility among developers, testers, and other stakeholders References:
• Secure SDLC | Secure Software Development Life Cycle | Snyk
• What is Secure Software Development Life Cycle (SSDLC )? - GeeksforGeeks

The most important factor when scoping assessments of cloud-based third parties that access, process, and retain personal data is to identify the type of cloud hosting deployment or service model. This is because different cloud models have different implications for the allocation of security responsibilities between the third party and the cloud hosting provider. For example, in a Software as a Service (SaaS) model, the cloud provider is responsible for most of the security controls, while in an Infrastructure as a Service (IaaS) model, the third party is responsible for securing its own data and applications. Therefore, it is essential to understand the type of cloud model and the corresponding security roles and responsibilities before conducting an assessment. This will help to avoid gaps, overlaps, or conflicts in security controls and expectations. References:

• Guidance on Cloud Security Assessment and Authorization - ITSP.50.105, Canadian Centre for Cyber Security, May 2020, Section 2.1.1
• The Importance of Properly Scoping Cloud Environments, PCI Security Standards Council and Cloud Security Alliance, August 2021
• Third party and cloud: Regulatory challenges, KPMG, 2022, Section 2.1
• Certified Third Party Risk Professional (CTPRP) Study Guide, Shared Assessments, 2021, Section 4.2.2

Application whitelisting is a security technique that allows only authorized applications to run on a device or network, preventing malware or unauthorized software from executing. While this can be a useful security measure, it is not directly related to remote access risk evaluation, which focuses on the security of the connection and the access rights of the remote users. The other options are more relevant to remote access risk evaluation, as they help to monitor, control, and audit the remote access activities and prevent unauthorized or malicious access. References:

• 1: Secure Remote Access: Risks, Auditing, and Best Practices
• 2: 5 Common Vulnerabilities Associated With Remote Access

 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

When reviewing application risk for application service providers, the most important factors are the functionality and type of data the application processes, the remote connectivity options, and the APl integration methods. These factors determine the level of exposure, sensitivity, and complexity of the application, and thus the potential impact and likelihood of a security breach or a compliance violation. The number of software releases is less important, as it does not directly affect the application’s security or functionality. However, it may indicate the maturity and quality of the software development process, which is another aspect of application risk assessment. References:

• Application Security Risk: Assessment and Modeling, ISACA Journal, Volume 2, 2016

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”

Risk registers are tools that help organizations document, monitor, and manage their third party risks. They typically include information such as the risk description, category, source, impact, likelihood, rating, owner, status, and action plan. Risk registers enable organizations to prioritize their risks, assign responsibilities, track progress, and report on their risk posture. According to the CTPRP Study Guide, "A risk register is a tool for capturing and managing risks throughout the third-party lifecycle. It provides a comprehensive view of the organization’s third-party risk profile and facilitates risk reporting and communication."1 Similarly, the GARP Best Practices Guidance for Third-Party Risk states, "A risk register is a tool that records and tracks the risks associated with third parties. It helps to identify, assess, and prioritize risks, as well as to assign ownership, mitigation actions, and target dates."2

References:

• CTPRP Study Guide
• GARP Best Practices Guidance for Third-Party Risk