712-50 Question 438
Single answerUnderstand the IA security requirements to be included in statements of work and other appropriate procurement documentsA global manufacturing company is issuing an RFP for a third-party managed analytics platform that will process proprietary product design data and limited employee personal data. The CISO has been asked to help procurement revise the statement of work (SOW) so that security expectations are enforceable after contract award. Which requirement is MOST important to include in the SOW to ensure the vendor's information assurance obligations are clear, measurable, and contractually enforceable?
- A
Require the vendor to maintain 'industry-standard security' and provide an annual letter stating that appropriate controls are in place.
- B
Require the vendor to implement defined security controls and governance obligations, including data classification and handling requirements, incident notification timeframes, right-to-audit, personnel screening where appropriate, secure disposal/return of data, and evidence of compliance with specified standards.
- C
Require the vendor to use the same security tools the company uses internally so the security architecture remains consistent across both organizations.
- D
Require the vendor to accept financial penalties for any security incident, without specifying technical or procedural security requirements in the SOW.
Show answer and explanation
Correct answer: B
Explanation
When incorporating information assurance requirements into statements of work and related procurement documents, the key goal is to translate security expectations into explicit contractual obligations. Best practice is to define security requirements that are specific, measurable, and aligned to the sensitivity of the data and service being outsourced. Common areas include data classification and handling, access control, encryption requirements where appropriate, logging and monitoring expectations, vulnerability and patch management, personnel screening, subcontractor restrictions, incident reporting timelines, business continuity/disaster recovery expectations, right-to-audit clauses, regulatory obligations, and data return or secure destruction at contract termination. This aligns with widely used supplier-risk and control frameworks such as NIST SP 800-161 for supply chain risk management, NIST SP 800-53 control families for security/privacy requirements, ISO/IEC 27036 for supplier relationships, and ISO/IEC 27002 guidance on supplier security. The strongest answer is the one that establishes concrete, verifiable, and enforceable security obligations rather than relying on vague language, technology preferences, or penalties alone.
- A. Incorrect.
This is incorrect because 'industry-standard security' is too vague to be reliably enforced. A generic attestation letter does not define specific control expectations, service levels, reporting obligations, or audit rights. In procurement and contracting, ambiguous language creates disputes later because neither party has a measurable baseline for compliance.
- B. Correct.
This is correct because effective IA/security requirements in procurement documents should be specific, risk-based, and testable. Including defined control expectations, data handling rules, incident notification timelines, audit rights, personnel requirements, data return/destruction provisions, and objective evidence of compliance makes the vendor's obligations clear and enforceable. These are common elements in well-constructed SOWs, security schedules, and supplier security addenda.
- C. Incorrect.
This is incorrect because mandating identical internal tools is not the primary objective and may be impractical or unnecessary. What matters is that the vendor achieves required security outcomes and control objectives, not that it mirrors the buyer's exact technology stack. Overprescribing tools can also limit competition and may not improve assurance if the controls are not tied to business risk and contractual obligations.
- D. Incorrect.
This is incorrect because penalties alone do not establish the security baseline the vendor must meet. Financial consequences may be useful as a contractual remedy, but they do not replace clear preventive, detective, corrective, and reporting requirements. Without defined controls and processes, enforcement after an incident becomes difficult because the expected standard of care was not articulated.