As an MSP, you operate inside your clients' environments every day. You pull logs, export configs, open support tickets, and paste diagnostic output into tools. Most of that output contains personal data. Under GDPR, HIPAA, and SOC 2, that makes you a data processor — and the obligations that come with it are your responsibility, not your client's.
What counts as PII
PII (personally identifiable information) is broader than most engineers expect:
- Email addresses and usernames
- Phone numbers (including partial numbers that appear in logs)
- IP addresses — treated as personal data under GDPR
- National identity numbers, passport numbers, tax IDs
- Payment card numbers and IBANs
- Names when combined with any of the above
- Any internal identifier that can be linked back to a person
Application logs are dense with this data. A single authentication failure log line can contain an email address, an IP address, a user agent, and a session token — every one of which is regulated.
Where MSPs leak PII without realising it
The most common leak vectors we see:
- Support tickets — Pasting raw log output into a vendor's ticketing system. That log is now on a third-party server under different data retention policies.
- LLM prompts — Using ChatGPT or similar tools to analyse logs or write scripts against sample data.
- Shared diagnostics — Sending a config export to a vendor for troubleshooting without reviewing it for customer data first.
- Collaboration tools — Dropping a log file into Slack or Teams for a colleague to review.
- Screen sharing — Displaying a terminal or log viewer during a call where the recording gets saved.
The regulatory landscape
GDPR requires a lawful basis for processing personal data, data minimisation, and breach notification within 72 hours. If you are handling EU resident data — which is almost certain if any of your clients have European customers — GDPR applies to you regardless of where you are based.
HIPAA applies if you handle Protected Health Information (PHI) on behalf of covered entities. As a Business Associate, you need a BAA with your clients and must implement technical safeguards around PHI handling.
SOC 2 Type II is increasingly required by enterprise clients before they will sign contracts with MSPs. The Security and Confidentiality criteria both require demonstrating controls around how sensitive data is handled.
Local-first redaction as a control
The most defensible position is data minimisation at the source: remove PII from diagnostic data before it is copied anywhere. A redaction step that runs on-device, before data leaves the environment, is:
- Auditable — you can demonstrate the control exists and is applied consistently
- Repeatable — it does not depend on individual engineer judgement
- Offline — no data is sent to a third-party service for processing
This satisfies the technical safeguard requirement under HIPAA, supports the data minimisation principle under GDPR, and is a concrete example of a confidentiality control for SOC 2.
Deploying consistently across your team
A tool that lives on one engineer's machine is not a control. For a redaction practice to be auditable, it needs to be deployed to every engineer who handles client data. RedactOps supports MDM deployment — Jamf, Intune, and similar platforms — with licence pre-provisioning, so you can roll it out across your fleet without requiring individual setup by each engineer.
Documentation for auditors is straightforward: deployed tool plus deployment logs plus a policy stating that all diagnostic data must pass through redaction before leaving the managed environment.