---
title: "What Log Settings can affect the GDPR Audit Trail?"
url: "https://dm0bkdes5q7a2ls.productfruits.help/en/article/c38a07d4-82d6-4320-bee8-e4af58a0085c"
language: "en"
last_updated: "2026-04-29T18:11:24.157Z"
---

# What Log Settings can affect the GDPR Audit Trail?

In the Spirion Sensitive Data Platform (SDP), the logging settings on the Local Logging page (specifically under the Console and Discovery Teams sections) directly impact the integrity, detail, and defensibility of your GDPR Audit Trail.

Under GDPR, you must be able to demonstrate "Accountability" (Article 5.2) and provide a record of processing activities. If your logging is too restrictive, you may lose the evidence needed to prove compliance during an audit or breach investigation.

## 1\. "Standard Logging" (The Compliance Baseline)

For a valid GDPR audit trail, **Standard Logging** should be the minimum setting for all categories (Console, Discovery Teams, etc.).

-   **What it records:** Successful scan completions, remediation actions (Shred, Quarantine), and policy applications.
-   **GDPR Impact:** This provides the "Proof of Remediation." If a data subject exercises their **Right to Erasure (Article 17)**, these logs serve as the official record that the data was actually deleted and when the action occurred.

## 2\. "Log Informational Messages" (The Activity Trail)

Enabling **Informational Messages** for Discovery Teams and Console interactions adds a layer of "Process Integrity" to your audit trail.

-   **What it records:** Which agents participated in a scan, when they checked in, and how the workload was distributed.
-   **GDPR Impact:** This supports **Article 30 (Records of Processing Activities)**. It proves that the "Data Processor" (the Spirion Agent) was active and following the instructions of the "Data Controller" (the Admin/Policy). It shows the *scope* of the effort to find personal data.

## 3\. "Log Debugging Messages" (The Forensic Trail)

While not typically enabled for daily operations, **Debug Logging** is critical during a suspected data breach.

-   **What it records:** Technical handshakes, connection attempts, and specific file-access errors.
-   **GDPR Impact:** Under **Article 33 (Breach Notification)**, you have 72 hours to report a breach. If a scan failed to reach a specific folder due to a permission error, Debug logs will show that "blind spot." This allows you to accurately report the *limitations* of your data discovery to the Data Protection Authority (DPA).

## 4\. "Disabled" Logging (The Audit Gap)

Setting any category to **Disabled** creates a significant risk to GDPR compliance.

-   **The Risk:** If you remediate (delete) a student's or customer's data but have logging "Disabled," you have **no technical proof** that the action was taken.
-   **GDPR Impact:** You fail the "Accountability" principle. In a legal dispute regarding the "Right to be Forgotten," you would be unable to provide an auditable trail showing that the personal data was removed from the endpoint.

## 5\. "Full" or "Trace" Logging (The Privacy Risk)

Ironically, the highest logging levels (**Detailed Trace** or **All Trace**) can actually *harm* your GDPR standing if not managed carefully.

-   **The Risk:** These settings may capture raw technical metadata or snippets of data being processed in the "handshake" between agents.
-   **GDPR Impact:** This can lead to **Data Minimization (Article 5.1.c)** violations. You are essentially creating "new" logs that might contain fragments of personal data, which then must be protected and eventually deleted, increasing your overall risk surface.

## 6\. Agent-Side Masking (The "Privacy by Design" Setting)

While not on the "Local Logging" page, the **Agent-Side Masking** setting in the Policy determines what actually appears in the logs sent to the Console.

-   **GDPR Impact:** This is the ultimate **Privacy by Design (Article 25)** setting. By masking the personal data in the log evidence, you ensure that the audit trail itself does not become a repository of unprotected PII.

## Recommendations for a GDPR-Compliant Audit Trail

1.  **Set Console & Discovery Teams to "Standard":** This ensures all remediation and scan milestones are recorded without creating excessive "noise."
2.  **Enable "Informational Messages" during DSARs:** If you are running a specific scan to find a single person's data (Data Subject Access Request), higher logging provides better proof of the "thoroughness" of your search.
3.  **Never use "Disabled" for Production Agents:** An unlogged remediation is, from an auditor's perspective, a remediation that never happened.
4.  **Centralize and Protect:** Ensure your Spirion Console logs are being forwarded to a secure SIEM (like Splunk or Sentinel) to ensure the audit trail is immutable and long-lived.

## Summary

The **Logging Settings** are the "witnesses" to your GDPR compliance. **Standard** and **Informational** levels provide the necessary evidence for accountability and remediation, while **Disabled** creates an indefensible gap in your legal record.