712-50 Question 434
Single answerA global enterprise is replacing its legacy endpoint security platform with a managed endpoint detection and response (MDR) service and related agent software. The procurement team wants to accelerate onboarding because the current tool contract expires in 45 days. The proposed vendor has provided a strong sales demonstration and a SOC 2 report, but the draft contract only states that the service will be considered accepted upon installation of the agents in production. As the CCISO, you are asked to define the contract administration policy for evaluating and accepting the delivered security service and software. Which action is the MOST appropriate to include in the policy before formal acceptance?
- A
Require documented security acceptance criteria tied to contractual deliverables, including functional testing, security validation of the agent and service, remediation timelines for identified gaps, and formal sign-off by designated business and security owners before production acceptance
- B
Accept the solution after successful installation because a SOC 2 report demonstrates that the vendor's controls are effective and replaces the need for enterprise-specific acceptance testing
- C
Defer security evaluation until after go-live and use service credits to address any security weaknesses discovered during operations, since business continuity is the higher priority
- D
Rely on the vendor's standard terms and annual penetration test summary as sufficient evidence that the software and MDR service meet the enterprise's security requirements
Show answer and explanation
Correct answer: A
Explanation
The best answer is Option 1 because contract administration policies for security procurements should distinguish installation from acceptance. Acceptance should occur only after predefined criteria are met and documented. In practice, this means the contract or supporting schedules should define security requirements, test procedures, evidence to be provided by the vendor, defect classification, remediation timelines, and the authority to grant or withhold acceptance. For managed security services and associated software, acceptance should typically address both the service and the technology being deployed, including secure configuration, integration with enterprise monitoring and identity systems, data protection expectations, vulnerability handling, and exit or transition obligations.
This approach is consistent with recognized practices in supplier and acquisition security governance. NIST SP 800-161 emphasizes integrating cybersecurity requirements into supply chain processes and verifying that suppliers meet those requirements. NIST SP 800-53 controls such as SA-4 (Acquisition Process), SA-11 (Developer Testing and Evaluation), and CA-2/CA-7 concepts around assessment and ongoing monitoring support defining security evaluation and acceptance activities. ISO/IEC 27036 also reinforces supplier relationship security and the need to specify and verify information security requirements in supplier agreements. From a CCISO perspective, the key leadership objective is to ensure procurement, legal, operations, and security are aligned so that acceptance is based on risk-informed, contractually enforceable criteria rather than installation status or vendor marketing evidence alone.
- A. Correct.
Correct. A sound contract administration policy should define measurable acceptance criteria and a formal acceptance process before the organization deems the product or service accepted. For security products and outsourced security services, this should include testing against contractual requirements, validation of security configuration and integration, review of evidence such as vulnerability status and remediation plans, and explicit approval by accountable stakeholders. This approach aligns procurement and security governance and reduces the risk of accepting a solution that is operationally installed but not contractually or security-wise fit for use.
- B. Incorrect.
Incorrect. A SOC 2 report can provide useful assurance about the vendor's control environment, but it does not prove that the specific delivered implementation, software agent, integration, or service configuration satisfies this enterprise's contractual, technical, or risk requirements. A common misconception is to treat third-party assurance reports as a substitute for internal acceptance testing. They are complementary, not a replacement.
- C. Incorrect.
Incorrect. Deferring security evaluation until after go-live weakens governance and exposes the organization to avoidable risk. Service credits may compensate financially for service failures, but they do not adequately address the impact of deploying insecure software or an inadequately validated managed security service. This option reflects a frequent procurement error: confusing commercial remedies with pre-acceptance security assurance.
- D. Incorrect.
Incorrect. Vendor standard terms and a high-level penetration test summary are not enough to establish acceptance. They may support due diligence, but they do not verify whether the delivered service and software meet the organization's specific contractual security requirements, integration needs, logging expectations, data handling controls, or remediation obligations. This option is plausible because such documents are commonly requested, but they are insufficient as the sole basis for acceptance.