CTPRP Practice Exam Questions with Answers Certified Third-Party Risk Professional (CTPRP) Certification

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

Termination for cause is the type of contract termination that is most likely to occur after failure to remediate assessment findings. This is because termination for cause is based on a breach of contract by the third-party, such as non-compliance, poor performance, fraud, or misconduct. Failure to remediate assessment findings indicates that the third-party has not met the contractual obligations or expectations of the entity, and thus exposes the entity to increased risk and liability. Termination for cause allows the entity to end the contract immediately or after a notice period, and to seek damages or remedies from the third-party. Termination for cause is different from other types of contract termination, such as:

• Regulatory/supervisory termination, which is triggered by a change in law or regulation that affects the legality or feasibility of the contract.
• Termination for convenience, which is exercised by the entity without any fault or breach by the third-party, usually for strategic or operational reasons.
• Normal termination, which is the natural expiration of the contract term or the completion of the contract scope. References:
• Shared Assessments. (2020). Certified Third Party Risk Professional (CTPRP) Study Guide1
• Fusion Risk Management. (2021). Exit Strategy for Terminating a Third Party2
• Volkov, M. (2016). Third-Party Risk Management – Part 2: Contract Termination3

Single Sign-On (SSO) is a convenient and efficient way of authenticating users across multiple applications and platforms with a single set of credentials. However, it also poses some security risks and challenges that need to be considered and addressed. One of the main disadvantages of SSO is that it creates a single point of failure and a high-value target for attackers. If an end-user credential is compromised, the attacker can gain access to all the systems and resources that the user is authorized to access, potentially causing significant damage and data breaches. Therefore, SSO requires strong security measures to protect the user credentials, such as encryption, multifactor authentication, password policies, and monitoring. Additionally, SSO users need to be aware of the risks and follow best practices to safeguard their credentials, such as using strong and unique passwords, changing them regularly, and avoiding phishing and social engineering attacks. References:

• 1: What are the disadvantages of single sign-on authentication? - Information Security Stack Exchange
• 2: Single Sign-On Disadvantages: 6 Advantages and Disadvantages [What You Need to Know] - Mostly Blogging
• 3: SSO Security Risks: The Drawbacks of SSO (And What Can You Do About it) - Zluri

A risk register is a tool that records and tracks the identified risks, their probability, impact, status, and mitigation actions throughout the life cycle of a third-party relationship1. A risk register typically includes the following components2:

• A unique identifier for each risk
• A description of the risk and its source
• A rating or grading of the risk according to a risk assessment table or hierarchy
• An assessment of the impact and likelihood the risk will occur and the possible seriousness
• An outline of proposed mitigation actions and assignment of risk owner
• A status update on the risk and the progress of the mitigation actions
• A target date for resolving the risk or closing the action A vendor inventory is a list of all the third parties that a banking organization engages with, along with relevant information such as the type, scope, and nature of the services provided, the contract terms and conditions, the performance indicators, and the risk ratings3. A vendor inventory is not a component of a risk register, but rather a separate document that supports the planning and due diligence phases of the third-party relationship life cycle. A vendor inventory may be prioritized by contract value, but also by other criteria such as the criticality of the service, the risk level of the vendor, and the strategic importance of the relationship. References:
• 1: Third-Party Risk Management (TPRM): Final Interagency Guidance, KPMG, June 2023
• 2: What Is Third-Party Risk Management (TPRM)? 2024 Guide, UpGuard, January 2024
• 3: Third-Party Risk Management Guidance, OCC Bulletin 2023-29, October 2023
• [4]: Certified Third Party Risk Professional (CTPRP) Study Guide, Shared Assessments, 2023
• [5]: Best Practices Guidance for Third-Party Risk, GARP, February 2023

 An Asset Management program is a set of policies, procedures, and practices that aim to optimize the value, performance, and lifecycle of the organization’s assets, such as physical, financial, human, or information assets123. An Asset Management program typically defines policy requirements for the following aspects of asset management:

• The Policy states requirements for the reuse of physical media (e.g., devices, servers, disk drives, etc.): This requirement ensures that the organization follows proper procedures for sanitizing, wiping, or destroying physical media that contain sensitive or confidential data before reusing, recycling, or disposing of them123. This requirement helps prevent data leakage, theft, or loss, and protects the organization’s reputation and compliance123.
• The Policy requires that employees and contractors return all company data and assets upon termination of their employment, contract or agreement: This requirement ensures that the organization recovers all the data and assets that were assigned, loaned, or accessed by the employees and contractors during their employment, contract, or agreement123. This requirement helps maintain the security, integrity, and availability of the organization’s data and assets, and prevents unauthorized or inappropriate use or disclosure of them123.
• The Policy defines requirements for the inventory, identification, and disposal of equipment and/or physical media: This requirement ensures that the organization maintains an accurate and up-to-date record of all the equipment and physical media that it owns, leases, or uses, and assigns unique identifiers to them123. This requirement also ensures that the organization follows proper procedures for disposing of equipment and physical media that are no longer needed, useful, or functional123. This requirement helps improve the efficiency, effectiveness, and accountability of the organization’s asset management processes, and reduces the risks of waste, fraud, or misuse of the organization’s resources123.

However, option D, a policy requirement that requires visitors (including other tenants and maintenance personnel) to sign-in and sign-out of the facility, and to be escorted at all times, is typically not defined in an Asset Management program. Rather, this requirement is more likely to be defined in a Physical Security program, which is a set of policies, procedures, and practices that aim to protect the organization’s premises, assets, and personnel from unauthorized access, damage, or harm . A Physical Security program typically defines policy requirements for the following aspects of physical security:

• The Policy requires visitors (including other tenants and maintenance personnel) to sign-in and sign-out of the facility, and to be escorted at all times: This requirement ensures that the organization controls and monitors the access of visitors to the facility, and verifies their identity, purpose, and authorization . This requirement also ensures that the organization prevents visitors from accessing restricted or sensitive areas, equipment, or information, and escorts them throughout their visit . This requirement helps enhance the security, safety, and compliance of the organization’s facility, assets, and personnel, and prevents potential threats, incidents, or breaches .
• The Policy defines requirements for the locking, alarming, and surveillance of the facility and its entrances and exits: This requirement ensures that the organization secures the perimeter and the interior of the facility, and detects and responds to any unauthorized or suspicious activity or intrusion . This requirement also ensures that the organization uses appropriate and effective physical security measures, such as locks, alarms, cameras, guards, or barriers, to deter, prevent, or delay unauthorized access . This requirement helps protect the organization’s facility, assets, and personnel from theft, vandalism, sabotage, or attack .
• The Policy specifies requirements for the emergency preparedness and response of the facility and its occupants: This requirement ensures that the organization plans and implements procedures for dealing with emergencies, such as fire, flood, earthquake, power outage, or active shooter, that may affect the facility and its occupants . This requirement also ensures that the organization provides adequate and accessible equipment, resources, and training for the emergency preparedness and response, such as fire extinguishers, first aid kits, evacuation routes, emergency contacts, or drills . This requirement helps ensure the safety, health, and continuity of the organization’s facility, assets, and personnel, and minimizes the impact and damage of emergencies .

Therefore, option D is the correct answer, as it is the only one that does not reflect a policy requirement that is typically defined in an Asset Management program. References: The following resources support the verified answer and explanation:

• 1: Asset Management Policy Guide + Free Template | Fiix
• 2: Asset Management Policy: How to Build One From Scratch - Limble CMMS
• 3: How to develop an asset management policy, strategy and governance framework: Set up a consistent approach to asset management in your municipality
• : Physical Security Policy - SANS
• : Physical Security Policy - IT Governance

The frequency of cyclical assessments is one of the key factors that determines the effectiveness and efficiency of a TPRM program. Cyclical assessments are periodic reviews of the vendor’s performance, compliance, and risk posture that are conducted after the initial onboarding assessment. The frequency of cyclical assessments should be aligned with the organization’s risk appetite and tolerance, and should reflect the level of risk and criticality of the vendor to the organization’s operations. A common approach to determine the frequency of cyclical assessments is to use a vendor risk score, which is a numerical value that represents the vendor’s inherent and residual risk based on various criteria, such as the type, scope, and complexity of the services or products provided, the vendor’s security and privacy controls, the vendor’s compliance with relevant regulations and standards, the vendor’s past performance and incident history, and the vendor’s business continuity and disaster recovery capabilities. The vendor risk score can be used to categorize the vendors into different risk tiers, such as high, medium, and low, and assign appropriate frequencies for cyclical assessments, such as annually, biannually, or quarterly. For example, a high-risk vendor may require an annual assessment, while a low-risk vendor may require a biannual or quarterly assessment. The vendor risk score and the frequency of cyclical assessments should be reviewed and updated regularly to account for any changes in the vendor’s risk profile or the organization’s risk appetite.

The other three statements do not best reflect the factors that help you determine the frequency of cyclical assessments, as they are either too rigid, too vague, or too reactive. Statement A implies that vendor assessments are only necessary during onboarding and can be replaced by continuous monitoring afterwards. However, continuous monitoring alone is not sufficient to ensure the vendor’s compliance and risk management, as it may not capture all the aspects of the vendor’s performance and risk posture, such as contractual obligations, service level agreements, audit results, and remediation actions. Therefore, vendor assessments should be conducted during onboarding and at regular intervals thereafter, complemented by continuous monitoring. Statement C suggests that vendor assessments should be scheduled based on the type of services or products provided, without considering the other factors that may affect the vendor’s risk level and criticality, such as the vendor’s security and privacy controls, the vendor’s compliance with relevant regulations and standards, the vendor’s past performance and incident history, and the vendor’s business continuity and disaster recovery capabilities. Therefore, statement C is too vague and does not provide a clear and consistent basis for determining the frequency of cyclical assessments. Statement D indicates that vendor assessment frequency may need to be changed if the vendor has disclosed a data breach, implying that the frequency of cyclical assessments is only adjusted in response to a negative event. However, this approach is too reactive and may not prevent or mitigate the impact of the data breach, as the vendor’s risk level and criticality may have already increased before the data breach occurred. Therefore, statement D does not reflect a proactive and risk-based approach to determining the frequency of cyclical assessments. References:

• Third-Party Risk Management 101: Guiding Principles
• Mastering the TPRM Lifecycle
• Third Party Risk Management Maturity Assessment

Application version control standards for software release updates are not part of the IT change management approval process, but rather a technical aspect of the software development lifecycle. The IT change management approval process is a formal and structured way of evaluating, authorizing and scheduling changes to IT systems and infrastructure, based on predefined criteria and roles. The IT change management approval process typically includes the following components123:

• A change request form that captures the details, rationale, impact, risk and benefits of the proposed change
• A change approval board (CAB) or other authorized approvers who review and approve or reject the change request based on the business case, feasibility and alignment with the organization’s objectives and policies
• A documented audit trail for all changes, especially emergency changes, that records the date, time, reason, approver and outcome of each change
• A defined roles and responsibilities matrix that clarifies the expectations and accountabilities of each stakeholder involved in the change management process, such as the change manager, change owner, change coordinator, change implementer and change requester
• A set of guidelines that restrict the approval of changes to only authorized personnel who have the appropriate knowledge, skills and authority to make decisions about the changes References:
• 1: Change Approval Process in ITIL Change Management
• 2: Guide to the IT Change Requests Approval Process
• 3: Overview of the change management approval process

This statement does not reflect current practice in addressing fourth party risk or subcontracting risk because it is not sufficient to rely on external audit reports alone. Outsourcers should also perform their own due diligence and monitoring of the subcontractors, as well as ensure that the third party has a robust TPRM program in place. External audit reports may not cover all the relevant aspects of subcontracting risk, such as data security, compliance, performance, and quality. Moreover, external audit reports may not be timely, accurate, or consistent, and may not reflect the current state of the subcontractor’s operations. Therefore, outsourcers should adopt a more proactive and comprehensive approach to managing subcontracting risk, rather than relying on external audit reports. References:

• Shared Assessments Program, page 13: “Outsourcers should not rely solely on external audit reports to address subcontracting risk. Outsourcers should also inspect the vendor’s TPRM program and require evidence of the assessments of subcontractors.”
• Five Best Practices to Manage and Control Third-Party Risk, page 3: "Restricting privileged accounts

Contract addendums are supplementary documents that modify or amend the original contract terms. They can be used to address third party risk obligations, such as security, privacy, compliance, or performance standards, without having to rewrite the entire MSA. However, contract addendums should be consistent with the MSA and clearly specify the scope, duration, and responsibilities of each party. Contract addendums can also be used to update or revise the contract terms in response to changing business needs or regulatory requirements12.

The other statements are true regarding the different types of contracts and agreements between outsourcers and service providers. Evergreen contracts are contracts that do not have a fixed end date and are automatically renewed unless one party decides to terminate them under the existing contract provisions3. RFPs are documents that solicit proposals from potential service providers for a specific project or service. RFPs should include mandatory requirements based on an organization’s TPRM program policies, standards and procedures, such as risk assessment, due diligence, monitoring, reporting, and remediation . SOWs are documents that define the operational requirements and obligations for each party, such as the scope, deliverables, timelines, costs, quality, and performance metrics . References:

• 1: Contracts and third-party risk - KPMG UK
• 2: Third-Party Risk & Contract Management: A Comprehensive Beginner’s Guide - Trackado
• 3: What Is an Evergreen Contract? | Legal Beagle
• : [Best Practices Guidance for Third Party Risk - GARP]
• : Third-Party Risk Management: A Comprehensive Guide - UpGuard
• : Statement of Work (SOW) - Definition, Contents & Examples
• : How to Write a Statement of Work for Any Industry | Smartsheet

Vendor classification or risk tiering is a process of categorizing vendors based on the level of security risk they introduce to an organization12. It is a key component of a third-party risk management (TPRM) program, as it helps to prioritize and allocate resources for vendor assessment, monitoring, and remediation12. The statement D is true, as it reflects the first step of vendor classification or risk tiering, which is to determine the inherent risk of each vendor relationship based on the nature, scope, and complexity of the product or service being outsourced3 . Inherent risk is the risk that exists before any controls or mitigating factors are applied3 . By calculating the inherent risk, an organization can assign each vendor to a risk tier that reflects the potential impact and likelihood of a security breach or incident involving the vendor3 .

The other statements are false, as they do not accurately describe the vendor classification or risk tiering process. The statement A is false, as vendor classification and risk tiers are not based on residual risk calculations, but on inherent risk calculations. Residual risk is the risk that remains after controls or mitigating factors are applied3 . Residual risk is used to evaluate the effectiveness of the controls and the need for further action, but not to classify or tier vendors3 . The statement B is false, as vendor classification and risk tiering should be used for all third party relationships, not only for critical ones. Vendor classification and risk tiering helps to identify and prioritize the critical vendors, but also to manage the low and medium risk vendors according to their respective risk profiles12. The statement C is false, as vendor classification and corresponding risk tiers do not utilize the same due diligence standards for controls evaluation based upon policy, but different ones. Due diligence standards are the criteria and methods used to assess the security posture and performance of vendors. Due diligence standards should vary according to the risk tier of the vendor, as higher risk vendors require more rigorous and frequent evaluation than lower risk vendors.

References:

• 1: What is Vendor Tiering? Optimize Your Vendor Risk Management | UpGuard Blog
• 2: Vendor Tiering Best Practices: Categorizing Vendor Risks | UpGuard Blog
• 3: Third-Party Risk Management (TPRM): A Complete Guide - BlueVoyant
• [4]: Supplemental Examination Procedures for Risk Management of Third-Party Relationships
• [5]: Third Party Risk Management: Why It’s Important And What Features To Look For - Expert Insights

An organization’s Ethics and Code of Conduct Program is a set of policies, procedures, and practices that define the expected standards of behavior and ethical values for all employees and stakeholders. A key component of such a program is a disciplinary process that outlines the consequences and actions for violating the code of conduct or any other relevant policies. A disciplinary process helps to enforce the code of conduct, deter unethical behavior, and protect the organization’s reputation and integrity. A disciplinary process should include clear criteria for determining the severity and frequency of violations, the roles and responsibilities of the parties involved, the steps and timelines for investigation and resolution, and the range of sanctions and remedies available. A disciplinary process should also be fair, consistent, transparent, and respectful of the rights and dignity of the accused and the accuser. A disciplinary process may involve formal termination or change of status of the employee, depending on the nature and impact of the violation. Therefore, option B is a correct component of an organization’s Ethics and Code of Conduct Program.

The other options are not necessarily components of an Ethics and Code of Conduct Program, although they may be related or supportive of it. Option A, participation in the company’s annual privacy awareness program, is more likely to be a component of a Privacy Program, which is a specific area of ethics and compliance that deals with the protection and use of personal information. Option C, signing acknowledgement of Acceptable Use policy for use of company assets, is more likely to be a component of an Information Security Program, which is another specific area of ethics and compliance that deals with the safeguarding and management of data and systems. Option D, a process to conduct periodic access reviews of critical Human Resource files, is more likely to be a component of an Internal Control Program, which is a general area of ethics and compliance that deals with the design and implementation of controls to ensure the reliability and accuracy of financial and operational information. References:

• 1: Creating an Effective Code of Conduct (and Code Program) - Corporate Compliance Insights
• 2: Code of Conduct & Ethics (Examples and Best Practices) - Status.net
• 3: Why Have a Code of Conduct - Free Ethics & Compliance Toolkit
• 4: “Code of Ethics” and “Code of Conduct” - GeeksforGeeks
• 5: Six Tips on How to Implement a Strong Ethics Program - KnowledgeLeader

An Information Security Incident Management Program is a set of policies, procedures, and tools that enable an organization to prevent, detect, respond to, and recover from information security incidents. An information security incident is any event that compromises the confidentiality, integrity, or availability of information assets, systems, or services12. A formal Information Security Incident Management Program typically includes the following components12:

• The definition of internal escalation processes: This component defines the roles and responsibilities, communication channels, and reporting mechanisms for escalating and managing information security incidents within the organization. It also establishes the criteria and thresholds for determining the severity and impact of incidents, and the appropriate level of response and escalation.
• The protocols for disclosure of information to external parties: This component defines the rules and guidelines for disclosing information about information security incidents to external stakeholders, such as customers, regulators, law enforcement, media, or other third parties. It also specifies the legal and contractual obligations, the timing and frequency, the format and content, and the approval and authorization processes for disclosure.
• The mechanisms for notification to clients: This component defines the methods and procedures for notifying clients or customers who may be affected by information security incidents. It also specifies the objectives, scope, and content of notification, as well as the timing and frequency, the delivery channels, and the feedback and follow-up mechanisms.
• The processes in support of disaster recovery: This component defines the steps and actions for restoring the normal operations of the organization after a major information security incident that causes significant disruption or damage to the information assets, systems, or services. It also specifies the roles and responsibilities, the resources and tools, the backup and recovery plans, and the testing and validation procedures for disaster recovery.

The statement that reflects a requirement that is NOT typically found in a formal Information Security Incident Management Program is D. The program includes processes in support of disaster recovery. While disaster recovery is an important aspect of information security, it is not a specific component of an Information Security Incident Management Program. Rather, it is a separate program that covers the broader scope of business continuity and resilience, and may involve other types of disasters besides information security incidents, such as natural disasters, power outages, or pandemics3 . Therefore, the correct answer is D. The program includes processes in support of disaster recovery. References: 1: Computer Security Incident Handling Guide 2: Develop and Implement a Security Incident Management Program 3: Business Continuity Management vs Disaster Recovery : What is the difference between disaster recovery and security incident response?

Data anonymization is the process of removing or altering any information that can be used to identify an individual from a data set. This technique provides the strongest assurance that data does not identify an individual, as it makes it impossible or extremely difficult to link the data back to the original source. Data anonymization can be achieved by various methods, such as generalization, suppression, perturbation, or pseudonymization12. Data anonymization is often used for privacy protection, compliance with data protection regulations, and data sharing purposes3. References:

• 1: Data Security: Definition, Importance, and Types | Fortinet
• 2: Data Security Best Practices: Top 10 Data Protection Methods - Ekran System
• 3: Data anonymization - Wikipedia

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

One of the key elements of a robust information security policy is the definition and implementation of requirements for third party governance and oversight. This means that the vendor should have clear and consistent processes and procedures for managing and monitoring the information security risks and controls of their subcontractors, suppliers, or service providers. Third party governance and oversight should include the following aspects12:

• Establishing criteria and standards for selecting and evaluating third parties based on their information security capabilities and performance
• Conducting regular and comprehensive assessments and audits of third parties’ information security policies, practices, and incidents
• Ensuring contractual agreements and service level agreements (SLAs) with third parties include information security clauses and obligations
• Maintaining visibility and communication with third parties regarding their information security status and issues
• Implementing corrective actions and remediation plans for any identified information security gaps or weaknesses
• Terminating or suspending the relationship with third parties that fail to meet the information security expectations or requirements If a vendor’s response does not specify any requirements for third party governance and oversight, it should trigger further investigation of their information security policies. This indicates that the vendor may not have a comprehensive and effective approach to managing the information security risks and impacts of their extended network of partners. This could expose the vendor and their clients to potential data breaches, cyberattacks, compliance violations, or reputational damages. Therefore, the vendor should be asked to provide more details and evidence of how they ensure the information security of their third parties, and how they address any information security incidents or issues involving their third parties. References:
• 1: Third-Party Information Security Risk Management Policy - SecurityStudio
• 2: Ensuring Data Protection for Third Parties: Best Practices | UpGuard Blog

In the context of Third-Party Risk Management (TPRM), problems or issues do not inherently lead to systemic failures but are indicative of underlying faults within processes or systems that could potentially result in incidents. Problem or issue management is a critical component of TPRM, focusing on identifying, classifying, and managing the root causes of incidents to prevent their recurrence and mitigate their impact. Effective problem management involves not just managing workarounds or known errors, but also implementing permanent fixes to eliminate the root causes of problems. By addressing the underlying issues, organizations can enhance their operational resilience and reduce the likelihood and impact of future incidents. This approach aligns with best practices in TPRM, emphasizing proactive risk identification, assessment, and mitigation to safeguard against potential disruptions in the supply chain and third-party ecosystems.

References:

• Best practices in TPRM suggest a structured approach to problem and issue management, including identification, assessment, prioritization, and resolution of root causes, as outlined in frameworks such as ISO 31000 (Risk Management) and NIST SP 800-53 (Security and Privacy Controls for Federal Information Systems and Organizations).
• Learning resources such as the "Third Party Risk Management Program Playbook" from Shared Assessments and the "Third-Party Risk Management Guide" from ISACA provide comprehensive guidelines on implementing effective problem and issue management processes within a TPRM program.

Change management is the process of controlling and documenting any changes to the scope, objectives, requirements, deliverables, or resources of a project or a program. Change management ensures that the impact of any change is assessed and communicated to all stakeholders, and that the changes are implemented in a controlled and coordinated manner. Compliance artifacts are the documents, records, or reports that demonstrate the adherence to the change management process and the regulatory or industry standards.

A robust change management process should include the following attributes:

• Logging: This means that any change request or proposal is recorded in a change log or a change register, along with the details of the change initiator, the change description, the change category, the change priority, the change status, and the change history. Logging helps to track and monitor the progress and outcome of each change, and to provide an audit trail for compliance purposes.
• Approvals: This means that any change request or proposal is reviewed and approved by the appropriate authority or stakeholder, such as the project manager, the sponsor, the customer, the steering committee, or the regulatory body. Approvals help to ensure that the change is justified, feasible, aligned with the project or program objectives, and acceptable to the affected parties.
• Validation: This means that any change request or proposal is verified and tested to ensure that it meets the quality standards, the functional and non-functional requirements, and the expected benefits and outcomes. Validation helps to ensure that the change is implemented correctly, effectively, and efficiently, and that it does not introduce any errors, defects, or risks.
• Back-out and exception procedures: This means that any change request or proposal has a contingency plan or a rollback plan in case the change fails, causes problems, or is rejected. Back-out and exception procedures help to minimize the negative impact of the change, and to restore the original state or the baseline of the project or program. They also help to handle any deviations or issues that may arise during the change implementation or the change review.

References:

• CTPRP Job Guide
• An Agile Approach to Change Management
• CM Overview
• Management Artifacts and its Types
• Achieving Regulatory and Industry Standards Compliance with the Scaled Agile Framework
• 8 Steps for an Effective Change 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

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

Multi-factor authentication (MFA) is an electronic authentication method that requires a user to present two or more pieces of evidence (or factors) to an authentication mechanism. The factors can be something the user knows (such as a password or a PIN), something the user has (such as a smartphone or a security token), or something the user is (such as a fingerprint or a facial recognition). MFA enhances the security of online accounts and applications by making it harder for attackers to gain access with stolen or guessed credentials. MFA is recommended as a best practice for third-party risk management, as it can reduce the risk of unauthorized access, data breaches, and identity theft. MFA is also a requirement for some regulatory standards and frameworks, such as PCI DSS, HIPAA, and NIST 800-63. References:

• What is: Multifactor Authentication
• Set up your Microsoft 365 sign-in for multi-factor authentication
• Multi-factor authentication - Wikipedia
• Shared Assessments CTPRP Study Guide, page 19
• Shared Assessments CTPRP Job Guide, page 14
• Best Practices Guidance for Third Party Risk, page 9

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

According to the Shared Assessments Certified Third Party Risk Professional (CTPRP) Study Guide, risk based decisioning is the process of applying risk criteria to prioritize and address the gaps identified during a third-party risk assessment1. The assessor should analyze the gaps based on the impact, likelihood, and urgency of the risk, and document the findings and recommendations in a report. The assessor should also review the existing or proposed compensating controls that could mitigate the risk, and submit the report to the business owner for approval of the risk treatment plan. The risk treatment plan could include accepting, transferring, avoiding, or reducing the risk, depending on the risk appetite and tolerance of the organization1.

The other statements do not reflect the best use of risk based decisioning, as they either ignore the risk analysis and documentation process, or apply a uniform or arbitrary approach to prioritizing and addressing the gaps. The assessor should not decide or conclude on the risk treatment plan without consulting the business owner, as the business owner is ultimately responsible for the third-party relationship and the risk management decisions1. The assessor should also not communicate that the gaps would not be included in the report if they were corrected immediately, as this could compromise the integrity and transparency of the assessment process and the report2.

References:

• 1: Shared Assessments Certified Third Party Risk Professional (CTPRP) Study Guide, pages 29-30, 33-34
• 2: Third-Party Risk Management: Final Interagency Guidance, page 10

When calculating residual risk, the best practice for an assessor is to adjust the vendor risk rating based on the changes to the risk level after analyzing the findings and considering the effectiveness of mitigating controls. Residual risk refers to the level of risk that remains after controls are applied to mitigate the initial (inherent) risk. By evaluating the findings from a third-party assessment and factoring in the mitigating controls implemented by the vendor, the assessor can more accurately determine the remaining risk level. This adjusted risk rating provides a more realistic view of the vendor's risk profile, aiding in informed decision-making regarding risk management and vendor oversight.

References:

• The concept of residual risk calculation is discussed in risk management frameworks such as ISO 31000 (Risk Management - Guidelines), which guides the assessment and treatment of risks.
• The "Third-Party Risk Management Guide" by ISACA outlines the process of assessing and managing risks associated with third parties, including the calculation of residual risk.

 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.

An unrecoverable data loss event after restoring a system is indicative of a failure to meet the Recovery Point Objective (RPO). The RPO represents the maximum tolerable period in which data might be lost due to an incident and is a critical component of an organization's disaster recovery and business continuity planning. If data restoration efforts are unsuccessful and lead to unrecoverable data loss, it means that the organization's data backup and recovery processes were insufficient to meet the defined RPO, leading to a loss of data beyond the acceptable threshold. This situation underscores the importance of implementing effective data backup and recovery strategies that align with the organization's RPO to minimize data loss and ensure business continuity in the event of a disruption.

References:

• Business continuity and disaster recovery standards, such as ISO 22301 (Security and Resilience - Business Continuity Management Systems - Requirements), provide guidelines on establishing and managing RPOs as part of a comprehensive business continuity plan.
• The "Disaster Recovery Planning Guide" by the Disaster Recovery Journal (DRJ) offers insights into best practices for data backup and recovery, emphasizing the importance of aligning recovery strategies with defined RPOs to minimize the impact of data loss incidents.

Notification obligations in incident response are the legal or contractual duties to inform relevant parties about a security breach or incident that affects their data or systems. These obligations may vary depending on the type, scope, and impact of the incident, as well as the jurisdiction, industry, and contractual agreements involved. The factors that are most likely to trigger notification obligations are:

• Regulatory requirements: Different laws and regulations may impose different notification obligations on organizations that experience or cause a security incident. For example, the General Data Protection Regulation (GDPR) requires data controllers to notify the supervisory authority within 72 hours of becoming aware of a personal data breach, and to notify the affected data subjects without undue delay if the breach poses a high risk to their rights and freedoms1. Similarly, the Computer-Security Incident Notification Rule requires banks and their service providers to notify their primary federal regulator as soon as possible, but no later than 36 hours, after a computer-security incident that materially disrupts, degrades, or impairs their operations, services, or customers2.
• Data classification or sensitivity: The type and sensitivity of the data involved in a security incident may also affect the notification obligations. For example, if the data contains personally identifiable information (PII), health information, financial information, or other confidential or sensitive information, the organization may have to notify the data owners, regulators, law enforcement, or other stakeholders about the incident and the potential risks to their privacy or security3. The data classification or sensitivity may also determine the content and timing of the notification, as well as the appropriate communication channels to use.
• Contractual terms: The contractual agreements between an organization and its third-party vendors or service providers may also specify the notification obligations in case of a security incident. For example, the contract may define the roles and responsibilities of each party, the notification procedures and timelines, the information to be shared, the remediation actions to be taken, and the penalties or liabilities for breach of contract. The contractual terms may also reflect the regulatory requirements or industry standards that apply to the organization or the third party.

The factor that is least likely to trigger notification obligations is:

• Encryption of data: Encryption of data is a security measure that protects the data from unauthorized access, modification, or disclosure. Encryption of data may reduce the impact or severity of a security incident, as it may prevent or limit the exposure of the data to malicious actors. However, encryption of data does not eliminate the notification obligations, as the organization still has to assess the nature and extent of the incident, and determine whether the encryption was effective or compromised. Moreover, encryption of data may not be sufficient to protect the data from other types of threats, such as deletion, corruption, or ransomware. Therefore, encryption of data is not a factor that influences the notification obligations in incident response.

References:

• 1: GDPR Article 33: Notification of a personal data breach to the supervisory authority
• 2: Computer-Security Incident Notification Rule
• 3: Third-Party Incident Management (TPIM): How to Balance IRPs with Third Parties
• : [Improving Third-Party Incident Response]
• : [Third-Party Incident Response Playbook]
• : [Does Encryption Protect You From a Data Breach?]

In the ‘Defense in Depth’ security model, the innermost layer typically focuses on protecting the most sensitive and critical assets, which are often categorized as 'Private internal'. This layer includes security controls and measures that are designed to safeguard the core, confidential aspects of an organization's infrastructure and data. It encompasses controls such as access controls, encryption, and monitoring of sensitive systems and data to prevent unauthorized access and ensure data integrity and confidentiality. The 'Private internal' layer is crucial for maintaining the security of critical information and systems that are essential to the organization's operations and could have the most significant impact if compromised. Implementing robust security measures at this layer is vital for mitigating risks associated with physical access to critical infrastructure and sensitive information.

References:

• Security frameworks and standards, including NIST SP 800-53 (Security and Privacy Controls for Federal Information Systems and Organizations) and the SANS Institute's guidelines on implementing 'Defense in Depth', provide detailed recommendations on securing the innermost layers of an organization's information systems.
• Publications such as "Physical Security Principles" by ASIS International offer insights into best practices for securing the private internal layer, including access control systems, surveillance, and intrusion detection mechanisms.

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

An enterprise information security policy (EISP) is a management-level document that details the organization’s philosophy, objectives, and expectations regarding information security. It sets the direction, scope, and tone for all security efforts and provides a framework for developing and implementing security programs and controls. According to the web search results from the search_web tool, some of the key elements of an EISP are:

• A statement of the organization’s security vision, mission, and principles that align with its business goals and values123.
• A definition of the organizational structure and accountabilities for oversight, governance, and management of information security, including roles and responsibilities of senior executives, security officers, business units, and users123 .
• A specification of the legal and regulatory compliance requirements and obligations that the organization must adhere to, such as data protection, privacy, and breach notification laws123 .
• A description of the scope and applicability of the EISP, including the types of information, systems, and assets that are covered, and the exclusions or exceptions that may apply123 .
• A declaration of the effective date and date of last review by management, as well as the frequency and criteria for reviewing and updating the EISP to ensure its relevance and adequacy123 .
• A statement of the organization’s risk appetite and tolerance, and the process for identifying, assessing, and treating information security risks123 .
• A provision of the authority and responsibility for implementing, enforcing, monitoring, and auditing the EISP and its related policies, standards, procedures, and guidelines123 .
• A determination of the access control policy and the rules for granting, revoking, and reviewing access rights and privileges to information, systems, and assets123 .
• An organization of the EISP based on an accepted control framework, such as ISO 27001, NIST SP 800-53, or COBIT, that defines the security domains, objectives, and controls that the organization must implement and maintain123 .

However, option C, a statement that security policies should be changed on an annual basis due to technology changes, is not an accurate reflection of an organization’s requirements within an EISP. While technology changes may affect the security environment and the threats and vulnerabilities that the organization faces, they are not the only factor that determines the need for changing security policies. Other factors, such as business changes, legal changes, risk changes, audit findings, incident reports, and best practices, may also trigger the need for reviewing and updating security policies. Therefore, option C is the correct answer, as it is the only one that does not reflect an organization’s requirements within an EISP. References: The following resources support the verified answer and explanation:

• 1: What Is The Purpose Of An Enterprise Information Security Policy?
• 2: Enterprise Information Security Policies and Standards
• 3: Key Elements Of An Enterprise Information Security Policy
• : Enterprise Information Security Policy (EISP) - SANS

 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

Remote monitoring of HVAC, Smoke, Fire, Water, or Power systems best reflects components of an environmental controls testing program. These systems are critical to ensuring the physical security and operational integrity of data centers and IT facilities. Environmental controls testing programs are designed to verify that these systems are functioning correctly and can effectively respond to environmental threats. This includes monitoring temperature and humidity (HVAC), detecting smoke or fire, preventing water damage, and ensuring uninterrupted power supply. Regular testing and monitoring of these systems help prevent equipment damage, data loss, and downtime due to environmental factors.

References:

• Environmental control standards such as ISO/IEC 27001 (Information Security Management) include requirements for the testing and monitoring of physical and environmental security controls.
• The "Data Center Operations Manual" by the Uptime Institute provides detailed guidelines on the testing and maintenance of environmental control systems to ensure the resilience and reliability of data center operations.

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.