How do I Configure Agent-side Masking for GDPR?

Configuring Agent-Side Masking transforms Spirion Sensitive Data Platform from a data collection tool into a privacy-preserving discovery engine. By enabling masking within your policies, you ensure that your GDPR audit trail is robust and informative while remaining fully compliant with strict data minimization standards.

How to Configure Agent-Side Masking

Agent-side masking is configured within the Policy settings in the Spirion Console. Follow these steps:

1. Navigate to Policies: Log in to the Spirion Console and go to the Policies section.
2. Select or Create a Policy: Open the policy you intend to use for your GDPR discovery scans.
3. Go to the "Data Types" or "Search" Settings: Look for the section where you define which sensitive data types (AnyFind® or custom SDD) the agent should look for.
4. Locate the Masking/Redaction Options:
5. • For each sensitive data type (e.g., Name, Email, National ID), there is typically a setting for "Masking" or "Redaction."
   • Enable Masking: Check the box to enable masking for that specific data type.
5. Define the Masking Pattern:
6. • You can often choose how much of the data to mask. For GDPR, a common practice is to mask everything except the first and last characters (e.g., j****n@email.com or 1*********9).
   • Select the Masking Character: Choose the character to be used for masking (usually * or #).
6. Apply to "Match Evidence": Ensure that the masking is applied to the "Match Evidence" or "Snippets." This is the small piece of text surrounding the match that the agent ships to the console to help you verify the finding.
7. Save and Deploy: Save the policy. The next time an agent performs a scan using this policy, it will automatically redact the sensitive values locally before shipping the results payload to the SaaS ingestion layer.

Why this is Important for GDPR

• Data Minimization (Article 5.1.c): You are only collecting the "minimum necessary" information (the location of the data) without centrally storing the actual personal data.
• Privacy by Design (Article 25): By redacting data at the source (the agent), you are building privacy protections directly into your data discovery workflow.
• Reduced Breach Impact: If your Spirion Console were ever compromised, the attacker would only see masked values, significantly reducing the risk of a secondary data breach.
• Operational Proof: You can still "prove" to an auditor that you found the data (because the masked result is visible in the console) without the liability of holding the raw data.

Recommendations

• Mask All GDPR Identifiers: Don't just mask SSNs or Credit Cards. For GDPR, you should also mask Names, Email Addresses, and Physical Addresses in your match evidence.
• Test Your Masking: Run a test scan on a single machine and review the results in the Console to ensure the masking is appearing exactly as you intended before deploying the policy to your entire fleet.
• Use "Take No Action" for Discovery: When first setting up GDPR discovery, create and use a Scan Playbook classifies only. This playbook utilizes a "Take No Action" path. This enables you to see the masked findings and build your data map without accidentally deleting or moving files before you've verified the results.

How to Verify Masking is Working Correctly

To verify that Agent-Side Masking is working correctly in the Spirion Sensitive Data Platform (SDP), you need to perform a "closed-loop" test. This involves running a scan on a known sample and then inspecting the results in the Console to ensure the sensitive values are redacted.

Follow these steps to verify your configuration:

1. Create a "Known Positive" Test File

On a test machine with a Spirion Agent installed, create a simple text file (e.g., GDPR_Test.txt) containing clear examples of the data types you are masking.

• Example Content:
• • Name: John Doe
  • Email: john.doe@example.com
  • ID: 123-456-789

2. Execute a Targeted Scan

In the Spirion Console, launch a scan specifically for that test machine and file location.

• Use the Correct Policy: Ensure the scan is using the Policy where you enabled masking.
• Run the Scan: Start the job and wait for it to reach the "Completed" status.

3. Inspect the Results in the Console

Once the scan is finished, navigate to the Results or Findings area of the Console.

• Locate the Test File: Find the entry for GDPR_Test.txt.
• View Match Evidence: Click on the finding to view the Match Evidence (sometimes called the "Snippet" or "Context").
• Verify Redaction: Look at the sensitive values.
• • Correct Behavior: You should see the masking characters you configured (e.g., J*** D** or j*******@*******.com).
  • Incorrect Behavior: If you see the full, clear-text name or email, masking is not working.

4. Check the "Match Value" Column

In the results grid, look at the Match Value column.

• This column should also show the masked version of the data. If the policy is set correctly, the raw, unmasked value should never have left the agent's local environment.

5. Verify the Local Agent Log (Optional/Advanced)

If you want to be 100% certain that the data was masked before it was sent, you can check the local agent's database (for Windows agents).

• Check the shipper_queue: The results staged for shipment in the local Postgres database should already contain the masked values. If the data is masked here, it proves the "Pre-Shipping Redaction" occurred on the endpoint.

Common Reasons Masking Fails

If you still see clear-text data in the Console, check the following:

• Policy Sync: The Agent may not have received the updated policy yet. Ensure the Agent has "checked in" since you saved the masking changes.
• Data Type Mismatch: You may have enabled masking for "Credit Cards" but not for "Email Addresses." Ensure masking is enabled for every data type you are searching for.
• "Match Evidence" vs. "Match Value": Ensure you enabled masking for both the evidence/snippet and the value itself.
• Global vs. Policy Settings: Ensure you didn't override the policy settings with a "Global" setting that allows clear-text results.

Recommendations

• The "Double-Check" Rule: Always verify masking whenever you create a new custom Sensitive Data Definition (SDD). Custom patterns often require explicit masking configuration that differs from the built-in AnyFind® types.
• Audit the Results Regularly: Periodically review your production results to ensure that no clear-text PII is "leaking" into the console due to a misconfigured policy or a new data type being added without masking.

Summary

Verification is a simple three-step process: Scan a known file → View the result in the Console → Confirm the presence of masking characters. If the Console only shows ****, your "Privacy by Design" configuration is working correctly and your GDPR risk is minimized.