When rolling out a new DLP filter to protect the flow of operational data from the grid-operations network toward the internet-facing back-office segment, which action choice lets the security team observe matches before committing to enforcement?
Select an answer to reveal the explanation.
Short Explanation
It's like watching a new smoke detector for a week before wiring it to shut off the whole building's power. Let it just report first, then decide what it should be allowed to do.
Full Explanation
Configuring a new DLP filter's action as log-only lets the team see exactly what it would have matched in real traffic without risking disruption to legitimate business flows, and only after reviewing that evidence does it make sense to tighten the action to block. This staged approach catches over-broad filters before they cause an operational incident. Setting the action to block immediately on a brand-new, unreviewed filter risks halting legitimate transfers the moment the filter is even slightly too aggressive, with no data collected beforehand to justify the risk. Removing the DLP profile from the policy entirely defeats the purpose of testing it at all — there is no visibility gained by not running it. Applying the profile only to policies with logging disabled directly contradicts the goal of observing matches, since without logging there is no record to review regardless of the filter's action. A caveat: after the monitoring period, only the specific filters confirmed to behave correctly should move to block — tightening the whole profile at once can re-introduce the same risk being tested against. To verify readiness before switching, pull the DLP logs from the monitor period and confirm the expected sensitive-data matches appear without an unexpected volume of unrelated noise.