This page is general engineering information and not legal advice. Laws, regulator guidance and their interpretation change. Take your specific situation to your data protection officer or counsel. Wrentrix does not make any organisation compliant and we do not claim any certification here.
Where personal data hides in telemetry
Teams tend to assume that monitoring data is about machines. Here is an inventory of what often turns up, with the concrete places to look.
| Signal | Where it hides | Example |
|---|---|---|
| Traces | URL paths and query strings | /customers/10293847561/statements?iban=... |
| Traces | Database statements | SELECT * FROM users WHERE email = 'ayse@...' |
| Traces | Custom attributes | user.id, user.email, a phone number added for debugging |
| Traces | Exception messages | Customer 10293847561 not eligible |
| Logs | Message text | Request bodies dumped at debug level |
| Logs | Auth failures | Usernames, sometimes passwords typed into the wrong field |
| RUM | Page URLs, errors | Identifiers in routes, form values in error text |
| RUM | Session timelines | A sequence of what a person did |
| Network data | Client IP addresses | In access logs, span attributes, or proxy headers |
| Hosts | Process command lines | Arguments passed to scripts |
Most of these got there by accident, and nobody decided to collect them. That is why the usual data mapping exercise misses them: it asks application owners what the application stores, not what the monitoring tool happened to capture.
A practical first step that costs nothing: pull a day's sample and search it. Look for your national ID format, phone numbers, email addresses and card-like numbers. What you find will shape everything else on this page.
The regulatory questions, in general terms
KVKK (Law No. 6698, Türkiye) regulates the processing of personal data and transfers abroad. Its transfer rules were amended in 2024, adding mechanisms such as adequacy decisions and appropriate safeguards including standard contracts. Sending data to a service outside Türkiye is a transfer that needs a valid legal route.
GDPR (EU) treats identifiers such as IP addresses and online identifiers as personal data where they relate to an identifiable person. Chapter V covers transfers to third countries. GDPR principles such as data minimisation and storage limitation apply to log data too, not only to your customer database.
Sector rules can add further layers. In Turkish banking, BDDK rules on information systems address where primary and secondary systems are held and how outsourcing is managed. In the EU, DORA covers ICT risk and third-party arrangements for financial entities. PCI DSS restricts how cardholder data is stored, and that includes logs. See banking and financial services for more on this.
The questions that come out of these for an observability system are fairly consistent:
- What personal data does our telemetry contain?
- Why do we have it, and is that purpose documented?
- Where is it stored and processed, including by subprocessors?
- Who can read it?
- How long do we keep it, and is that justified?
- Can we locate or remove an individual's data if necessary?
What on-premise changes, and what it doesn't
Hosting the backend in your own network simplifies some of those questions, without removing the rest.
| Question | Hosted service | Self-hosted |
|---|---|---|
| Is telemetry transferred abroad? | Depends on region and on the provider's subprocessors | Not unless you send it |
| Is a processor agreement needed for storage? | Generally yes | Not for that storage, since no outside party holds it |
| Is AI inference sent to a third party? | Depends on the service | Not with a local model |
| Is the data still personal data? | Yes | Yes |
| Is minimisation still required? | Yes | Yes |
| Do retention limits still apply? | Yes | Yes |
| Is access control your problem? | Partly | Entirely |
With Wrentrix, 0 bytes of telemetry leave your network, the model runs on your hardware, and AI can be turned off. The bold rows are still the point. A plain "we're on-premise" answer doesn't address them. A hosted service in a suitable region with solid contractual terms may also be acceptable for many organisations; the on-premise versus SaaS guide covers that decision. Self-hosting simply removes a whole set of transfer and third-party questions, which for some organisations is the difference between a project that can go ahead and one that can't.
Reduce the data before you store it
The best-protected personal data is the data you didn't collect. These steps work whichever backend you choose.
Fix it at the application
Stop putting identifiers into URLs and messages where you can. Use route templates for span
names: /customers/{id}/statements, with the identifier left out. Log an opaque
internal reference and not a national ID number.
Remove it in the pipeline
If you run an OpenTelemetry Collector, you can delete or hash attributes before anything is
exported. This is an example using the attributes processor. Include it in your
pipeline's processors list:
processors:
attributes/scrub:
actions:
- key: user.email
action: delete
- key: client.address
action: delete
- key: url.query
action: delete
- key: user.id
action: hashBe aware of what hashing provides. A hash of a low-entropy value, such as an 11-digit national ID number, can be reversed by trying every possibility, so it is pseudonymisation at best and not anonymisation. Pseudonymised data generally remains personal data. For guidance on deploying collectors, see running the collector on Kubernetes.
Database statements deserve separate attention. Many instrumentation libraries try to sanitise statements by replacing literal values with placeholders, but behaviour varies by language and library. Check what yours actually sends with a real query containing a literal.
Limit what the browser sends
For RUM, review how routes are grouped, strip query strings where possible, and keep form values out of errors. Tell your data protection team about session timelines, because they are more sensitive than aggregated metrics. A notice or consent update may be needed. They will know.
Control access inside the boundary
Once the data is on your own network, internal access becomes the main risk. Wrentrix provides OIDC SSO with PKCE, LDAP sync, scoped team views and an audit log of every change. Think through these questions:
- Should a developer see production logs from other teams' services? In most cases, no, and scoped views can express that.
- Who has administrative rights? Keep that group small and reviewed.
- Can you show an auditor who has access, and how it's granted? A mapping to directory groups helps here.
Retention and deletion
Keeping everything forever is the opposite of storage limitation, and it's expensive too. Define retention per signal, along with the justification for it. Logs with personal content probably warrant the shortest period. Aggregated metrics with no personal content can often live longer.
Deletion on request is a challenge in observability data. A log store generally is not designed to find every mention of a person. In practice, the strongest position is short retention and minimal personal data, so that this problem doesn't get large. Your counsel can advise on how such requests apply to operational logs.
Retention settings in Wrentrix are something to confirm for your version and your storage. Ask us at info@wrentrix.com.
Also check what's around it
Residency is more than the APM backend. A few places where data leaves quietly, despite everything above:
- Support bundles. Logs sent to a vendor for a support ticket are a transfer.
- Backups. Backups of your telemetry database that go to an offsite or cloud location carry the same data, and the same questions.
- Alert channels. If an alert contains a log excerpt and goes to an external chat or email service, that excerpt has left. Keep alert content short and link back to the platform. See alerts and remediation.
- Webhooks. Check what's in the payload, and where it's going.
- Copying into AI tools. An engineer pasting logs into a public AI chat service defeats the whole architecture. A local model gives them a sanctioned alternative, and clear policy does the rest.
Log content also ties in directly with pattern clustering. A pattern view can reveal fields that vary and shouldn't be there at all, which makes it a handy way to spot leaks.
Frequently asked questions
Is telemetry data personal data under KVKK or GDPR?
It can be. URLs, IP addresses, user identifiers and free-text log messages can all relate to an identifiable person, and that's generally the test. Sample your own data to find out, and ask your data protection officer how it should be classified. This is general information and not legal advice.
Does on-premise APM make me KVKK or GDPR compliant?
No, no tool does that on its own. Self-hosting removes international transfer and third-party storage questions for that data. Lawful basis, minimisation, retention, access control and individual rights still apply, and they stay your responsibility.
How do I remove personal data from traces?
Start by removing it at the source, using route templates and opaque identifiers. Then use an OpenTelemetry Collector to delete or hash attributes before export. Hashing low-entropy values is weak protection, so deletion is usually preferable when the value isn't needed.
Does Wrentrix send any data outside my network?
No. 0 bytes of telemetry leave your network, and there are no license calls and no external model. You can verify this by running it where outbound traffic is blocked and logged, and by reviewing your own alert channels and backups, which remain under your control.
Is an IP address personal data?
Under GDPR it can be, as the Court of Justice of the EU has considered in its case law, and it depends on whether the person can be identified by reasonable means. Regulators elsewhere take their own positions. For telemetry the simple answer is to avoid collecting full client addresses unless you have a reason.