A data loss prevention control was installed six months ago and the project was closed, but nobody confirmed that it actually blocks the data types it was meant to protect. What should the information security manager do NEXT?
Select an answer to reveal the explanation.
Short Explanation
Installing a smoke alarm and never pressing the test button doesn't tell you it'll go off in a fire. A control isn't done when it's installed; it's done when you've proven it works. The trap is reporting it as implemented, which tells management something you don't actually know.
Full Explanation
Implementation is not complete until the control has been verified to operate as designed. Post-implementation verification tests the control against its documented objectives, for example by attempting to send sample sensitive data through monitored channels and confirming it is blocked or alerted as intended, and checks that alerts reach the people responsible for responding. Until that is done, the organization cannot rely on the control or report reduced risk. Expanding the control to more business units extends coverage of something whose effectiveness is unknown and could multiply a false sense of security. Reporting the control as implemented in the risk report would present an unverified assumption to management as fact, potentially leading the risk owner to accept residual risk on a false basis. Buying a second product to back up the first assumes a failure that has not been established, adds cost and complexity, and still leaves both controls unverified. Exam caveat: verification after implementation differs from periodic operating effectiveness testing; both are needed, the first to confirm the build and the second to confirm continued operation. Operational check: define test cases from each control objective, execute them, document results and residual issues, and update the risk register only after the results are reviewed with the control owner.