The short answer is "more than you'd think," and if you're in a regulated space, you've got homework to do.
Cybereason's EDR/XDR is, by design, a data vacuum. It needs process details, file paths, network connections, and loaded modules to do its job. The problem is that this telemetry often contains PII by adjacency. A process command line can contain a database connection string with credentials. A file path might be `C:UsersJaneDoeDocumentspatient_records_2023.xlsx`. Network telemetry will show internal hostnames that can be mapped to individuals, especially in smaller orgs.
If you're doing a vendor risk assessment, you need to go straight to their data handling exhibit or subprocessor list. Their privacy policy is too high-level. You're looking for answers to:
* Data residency commitments (where is the telemetry processed/stored?)
* Subprocessors for things like object storage and analytics.
* Their data retention schedule and deletion procedures.
* How they handle your data subject access/deletion requests (DSAR) for data in their platform.
I pulled this from a sample logging config during a trial a while back. It's illustrative of what gets scooped up by default:
```
# Example sensor policy snippet (paraphrased)
collect_command_line: true
collect_loaded_modules: true
collect_file_access_events: true
enable_network_data: true
```
Each of those can be a PII leak. You'll need to weigh turning them off against security efficacy. The real compliance headache is proving you've done that risk assessment and have compensating controls. If you're subject to GDPR, CCPA, or similar, you must map this data flow into your RoPA.
Don't take their marketing site's word for it. Request their current SOC 2 Type II, and specifically look at the controls around data classification and privacy. If they balk, that's your answer.
Trust but verify – and audit
You've hit on the exact pain point. That command line and file path telemetry is a compliance nightmare waiting to happen. Even with the best data handling agreements, you've still got that raw data transiting their systems.
I actually had to write a custom parser in Make last year to filter and redact specific strings from our EDR logs before they were forwarded to a SIEM, specifically because of those adjacency issues. It was a clunky workaround, but it was the only way to meet a specific data residency requirement without disabling core features.
Your advice on going straight to the data handling exhibit is spot on. Their sales engineering team should have that document ready to go. If they don't, consider that a major red flag for any regulated environment.
api first
The adjacency problem is worse than many realize because of how data is stored and correlated. That telemetry, especially command lines, often lands in an immutable audit log within their platform. Even if their processing pipeline later redacts a credential, the raw log ingested during collection might retain it for a compliance-mandated retention period. Your data handling exhibit must confirm whether raw or normalized data is stored, and the deletion procedure for each.
I've seen environments where the only mitigation was to use their API to purge specific log entries post-incident, which creates a massive operational burden. The subprocessor list is critical, but you also need the data flow diagram to see where logs are at rest versus in transit; a processor in a compliant region means little if the data is briefly staged elsewhere.