A project team has already shortlisted data loss prevention products for a new customer data platform, but no one has agreed what the controls must achieve. What should the information security manager do FIRST?
Select an answer to reveal the explanation.
Short Explanation
Shopping before you know what you need is how you end up with a garage full of gadgets. Decide what the control has to accomplish first; then judge the products against that. The trap is the proof of concept: testing products before you have objectives just tests features.
Full Explanation
Control objectives state what a control must achieve in response to an identified risk, for example preventing customer records from leaving approved channels or detecting bulk extraction. They come from the risk assessment of the data and the business requirements, and they become the criteria against which any solution is selected and later tested. Without them, product choice is driven by features rather than need. A proof of concept is valuable later, but run before objectives exist it can only show what each product does, not whether it addresses the organization's risk, and it may anchor the team on a tool too early. Choosing the product with the strongest analyst ratings substitutes a market view for the organization's own requirements; a highly rated product can still be the wrong fit for this platform's data flows and risks. Asking vendors to define the necessary controls hands requirement setting to parties with an interest in selling their product and abdicates the security manager's responsibility. Exam caveat: the sequence of risk assessment, then control objectives, then control selection and design recurs throughout CISM, and questions often place a product decision too early. Operational check: confirm that a documented set of control objectives traceable to the risk assessment exists and that evaluation criteria for the products are derived from it.