SY0-701 Security Program Management and Oversight Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Performing due diligence assessments before onboarding new vendors

  Why this is correct

  Performing due diligence assessments before onboarding is the cornerstone of proactive vendor risk management. It involves scrutinizing a prospective vendor's security policies, compliance certifications, financial stability, and incident response history to identify risk exposure before any data is shared. This vetting process allows the organization to decide whether to proceed, require remediation, or reject the relationship altogether. By front-loading risk identification, due diligence ensures that subsequent contractual and monitoring efforts are grounded in a clear understanding of the vendor's actual security posture.

• ✗

  Requiring all vendors to use the same password manager as the organization

  Why it's wrong here

  Requiring all vendors to exclusively use the same password manager as the organization is a unilateral mandate that ignores diverse vendor infrastructure and often forces them to adopt an incompatible tool. This approach fails to address the actual security of the vendor's environment, as password storage is only a small facet of identity and access management. Moreover, forcing a specific commercial product can create supply chain dependency and conflict with the vendor's own compliance obligations, while doing little to reduce the risk of credential misuse or phishing beyond the tool's limited scope. Effective vendor risk control requires evaluating and verifying the vendor's own authentication practices, not imposing a single technical solution across independent organizations.

• ✓

  Including security requirements in contracts and service-level agreements

  Why this is correct

  Embedding security requirements in contracts and service-level agreements (SLAs) translates risk decisions into enforceable, legally binding obligations. Strong agreements specify minimum security controls, data protection standards, notification timelines for breaches, audit rights, and penalties for noncompliance, ensuring accountability throughout the relationship. They also enable the organization to take legal or financial recourse if the vendor fails to meet the agreed-upon controls, such as failing a periodic security audit or experiencing a significant incident. This contractual layer is essential because reliance on vendor self-attestations alone provides no meaningful remedy when expectations are not met.

• ✓

  Conducting periodic security reviews or audits of critical vendors

  Why this is correct

  Conducting periodic security reviews and audits of critical vendors is essential because a vendor's risk profile is not static; it evolves as their infrastructure, personnel, and threat landscape change. These reviews can take the form of annual security questionnaires, on-site assessments, or analysis of independent third-party attestations like SOC 2 reports and penetration test results. Regular audits verify that the vendor continues to meet the contractual security requirements and exposes any degradation in their controls or new vulnerabilities that have emerged after initial onboarding. Without ongoing monitoring, a once-acceptable vendor could silently become a significant supply chain liability over time.

• ✗

  Providing vendor staff with direct access to internal source code repositories

  Why it's wrong here

  Providing vendor staff with direct, unfettered access to internal source code repositories grossly violates the principle of least privilege and exposes the organization's most valuable intellectual property to an unmanaged third party. Such access creates an excessive attack surface where a vendor employee's compromised account could be used to exfiltrate proprietary algorithms, introduce malicious backdoors, or alter code to launch a software supply chain attack. Even well-intentioned vendors may have insufficient internal access controls, meaning their extended user base inherits direct cryptographic credentials to your codebase. Secure collaborative development instead relies on limited-time, read-only access to specific branches, isolated environments, and strict audit logging, never on blanket repository privileges.

• ✗

  Automatically renewing vendor contracts unless a security incident occurs

  Why it's wrong here

  Automatically renewing vendor contracts unless a security incident has occurred is a dangerously passive strategy because it fails to reassess the vendor's current risk posture, business stability, and performance against evolving security threats. The absence of a reported incident does not prove that controls are effective, as many breaches go undetected for months or years, and a vendor's security posture can degrade in ways that do not immediately produce a public incident. This approach also omits critical triggers for re-evaluation, such as mergers, changes in key personnel, or shifts in the vendor's own third-party dependencies. Effective vendor lifecycle management requires that renewal decisions be active, evidence-based opportunities to reevaluate the relationship against current risk tolerance and to renegotiate security terms as needed.

Go deeper

Related to this question