Skip to content
MoftgateMoftgate Docs
Product guide

Incidents & Investigation

Investigate DLP incidents, review the evidence, record the outcome, and fix the rule that produced them.

What Incident Investigation Is#

An incident is what a DLP policy produces when content matches. Investigation is the step that decides whether the match was a real data movement or a rule that needs tuning.

Treat investigation as part of policy quality, not as a separate queue to clear. Every false positive you review is a rule that should be improved.

Forensic Violation Audit Logs with source client, leak vector, sensitive file, action, and score.
Moftgate incident investigation screen
Close image

Triage#

An incident record contains six fields. Read them in this order:

FieldWhat it tells you
Matched ruleThe classification or pattern rule that produced the match.
Endpoint and userThe device where the match happened and the operating system user who was active at the time.
ChannelWhich protected channel the content was moving through: USB, web, email, clipboard, screenshot, or printing.
TimeWhen the match occurred, in the platform time format.
EvidenceThe captured detail that supports the match, subject to your evidence settings.
PolicyThe policy that raised the incident, including its current action and target scope.
  • Read the matched rule first. A rule that matches too broadly explains most of the incident volume.
  • Check the channel. The same content leaving over USB and over email are two different risks.
  • Confirm the user. Because the agent runs as a service, user attribution is reliable even when the account is not an administrator.
  • Look for repetition on the same endpoint. Repeated matches usually mean a workflow that needs an exception, not a malicious user.

Evidence#

Evidence is the detail captured at the moment of the match. What is captured depends on your evidence settings and on the channel, because different channels expose different information.

Evidence is evidence
Do not edit or re-create evidence. Record your interpretation in the incident note and leave the captured detail as it was recorded.

Notes and Closing#

  1. 1
    Record the decision

    Write a note that explains what you concluded and why. The note is what makes the incident reviewable later.

  2. 2
    Set the outcome

    Mark the incident as resolved or as a false positive. A false positive is a signal that the rule needs attention.

  3. 3
    Adjust the policy or rule

    If the incident was a false positive, change the rule or add an exception instead of only closing the incident.

  4. 4
    Escalate when needed

    If the incident suggests a real data movement, assign it and follow your organisation’s incident process.

Closing is not fixing
Closing an incident does not change the policy. If the incident was a false positive, the rule will produce it again until you change the rule.

Frequently Asked Questions#

How long are incidents retained?
Incidents are stored on your appliance as part of the platform database, so retention is under your control. Export or report on them before any planned retention change.
Can I close an incident without a note?
The platform allows it, but a closed incident without a note loses its reasoning. Treat the note as part of the investigation, not as optional paperwork.
What if the same user appears repeatedly?
Check whether a legitimate workflow is being blocked. Repeated incidents from one team usually indicate a rule that needs an exception or a narrower classification.
Are incident actions audited?
Yes. Assigning, noting, and closing an incident are panel actions and are written to the audit log.