712-50 Question 430
Single answerA global manufacturing company is outsourcing operation of a cloud-based supplier portal that will process purchase orders, pricing data, and limited personal information for supplier contacts across several regions. The procurement team wants to accelerate the award and has asked the CISO to provide only a high-level security policy attachment after the vendor is selected. The CISO is concerned that doing so will weaken the organization's ability to enforce security and privacy expectations later. Which action should the CISO take FIRST to best ensure risk-based security requirements are embedded into the procurement process and are enforceable after award?
- A
Work with procurement, legal, privacy, and business owners to translate the portal's risk profile into specific security requirements, service levels, contract clauses, and weighted evaluation criteria before issuing the solicitation
- B
Allow procurement to complete vendor selection based on cost and delivery timelines, then negotiate security controls during contract finalization with the preferred bidder
- C
Require all bidders to submit their existing security policies and select the vendor with the most comprehensive documentation package
- D
Defer detailed security requirements until the implementation phase because the exact architecture will not be known during source selection
Show answer and explanation
Correct answer: A
Explanation
The best answer is to embed risk-based security requirements into procurement artifacts before the solicitation is issued. For a CCISO, this reflects governance, risk management, and cross-functional leadership responsibilities. Security requirements should be driven by business impact and risk assessment, then incorporated into acquisition plans, cost estimates, statements of work, contracts, SLAs, and evaluation criteria. In practice, this includes requirements such as access control, encryption, logging and monitoring, vulnerability management, incident response obligations, data retention and destruction, privacy obligations, audit rights, business continuity, subcontractor flow-down clauses, and measurable service levels. This approach aligns with widely accepted practices in supplier risk management and secure acquisition, including principles reflected in NIST SP 800-161 on cyber supply chain risk management and NIST SP 800-53 control families such as SR and SA, as well as common enterprise procurement and third-party risk management frameworks. The key leadership point is that security must be defined as a contractual and evaluation requirement up front, not appended after vendor selection.
- A. Correct.
Correct. This is the strongest first action because it integrates security into acquisition planning rather than treating it as an afterthought. A risk-based approach means defining requirements based on the sensitivity of data, regulatory exposure, operational criticality, geographic scope, and dependency on the supplier. These requirements should appear in the statement of work, security exhibits, service level agreements, incident notification clauses, audit rights, data handling requirements, subcontractor obligations, and evaluation factors for award. Weighting security in the source-selection criteria also ensures bidders are evaluated on their ability to meet the organization's risk tolerance, not just on price or schedule.
- B. Incorrect.
Incorrect. This is a common procurement mistake. If security requirements are not part of the solicitation and evaluation process, the organization loses leverage after down-selection and may face change requests, higher costs, or contractual gaps. Negotiating major security requirements only after selecting a preferred bidder can create delay, reduce competition, and result in controls that are weaker than the enterprise risk profile requires.
- C. Incorrect.
Incorrect. Reviewing bidder policies may provide due diligence input, but it does not substitute for defining the organization's own risk-based contractual requirements. Vendors often have generic policy sets that may not address the company's required controls, service levels, breach notification timelines, data residency needs, logging expectations, right-to-audit provisions, or regulatory obligations. The misconception is assuming strong-looking documentation equals acceptable control obligations.
- D. Incorrect.
Incorrect. While some technical details mature during implementation, core security and privacy obligations must be established before award. Deferring them until implementation creates ambiguity, weakens enforceability, and can lead to disputes over scope and cost. Procurement documents should establish baseline requirements and governance expectations even if some design-level details are refined later.