Dash0 acquires Polar Signals

Last updated:

About Data Privacy

Understand which telemetry fields cardholder data redaction scans, how it masks or replaces sensitive values, and where its protection ends.

These Data Privacy topics cover cardholder data redaction in telemetry. Telemetry from payment paths can carry cardholder data: a card number in a logged request body, a query string, an exception message, or a metric label. Cardholder data redaction detects likely payment card numbers and related sensitive data in logs, spans, web events, and metrics, and masks or replaces them. It runs in one of two places, or both:

  • At ingestion: An opt-in dataset setting. Dash0 redacts the telemetry before it stores anything.
  • On SignalControl Edge: The dash0redaction processor in your own edge collector. The collector redacts the telemetry before it leaves your network.

Both use the same detection and masking rules. Dash0 does not scan telemetry again after an edge collector has redacted it. See Combine Edge and Ingestion Redaction.

Ingestion redaction is a second line of defense for telemetry that your own filtering missed. Redaction at the source is the stronger guarantee, because the content never leaves your network. Use redaction on SignalControl Edge, or the OpenTelemetry Collector Contrib redaction processor in another collector. For browser telemetry, use the Web SDK's urlAttributeScrubber and ignoreUrls configuration options. None of these makes a dataset PCI compliant on its own.

What Gets Redacted

Redaction scans these parts of each signal, at ingestion and on the edge alike:

  • Logs: Log bodies (plain strings, nested maps, and lists), log record attributes, and scope attributes.
  • Spans: Span names, span attributes, span event names, span event attributes, span link attributes, and scope attributes. This includes spans sent by the Web SDK.
  • Web events: Web event bodies, web event attributes, and scope attributes, including web events that carry stack traces.
  • Metrics: Data point attributes on every metric type, and scope attributes. Dash0 never inspects metric data point values.
  • Resource attributes: Checked by attribute key only, on every scanned signal. Dash0 redacts a resource attribute whose key names a card field.

Dash0 masks card numbers and replaces everything else it detects:

DataHow Dash0 detects itWhat Dash0 stores
Card number (PAN)By value: a run of 13 to 19 digits that passes the Luhn check and has a payment-network shape. Also by key: card_number, cardnumber, card_no.The first six and last four digits, with the digits between them masked. For example 411111******1111.
Track 1 / Track 2 dataBy value: a magnetic-stripe record (%B…^… or ;…=…) with an embedded Luhn-valid card number, at any position in the string. Also by key: track1, track2, track_1, track_2.<REDACTED> in place of the whole value.
Card verification code (CVV, CVC, CAV2)By key only: any attribute or log body key that contains cvv, cvc, or cav2, such as payment.card.cvv.<REDACTED> in place of the whole value.
PIN blockBy key only: any key that contains pin_block or pinblock.<REDACTED> in place of the whole value.

Dash0 masks a card number instead of removing it, so the record stays useful for troubleshooting. PCI DSS forbids storing verification codes, PIN blocks, and track data in any form, so Dash0 replaces the whole value with <REDACTED>. Key matching redacts the value without reading it. If a field named card_number holds a token or an already-masked value, Dash0 still replaces it with <REDACTED>. Redaction never removes an attribute or body field. Dash0 stores an integer attribute that held a card number as the masked string.

Dash0 skips keys that cannot hold cardholder data: keys starting with dash0., k8s., service., telemetry.sdk., or otel., the keys trace.id and span.id, and any key ending in .timestamp.

Dash0 changes only the values it detects as card data. Everything else stays as it was, including timestamps, service and resource identity, span structure, and metric values. Dashboards, traces, and log searches keep working on redacted data.

Limitations

When you describe this control internally or to an assessor, state these boundaries:

  • It never drops telemetry. Dash0 forwards every log record, span, web event, and metric data point, with the sensitive value rewritten. To drop telemetry by rule, use spam filters.
  • It is not a compliance guarantee. Redaction is a defense-in-depth control with the gaps listed here. It reduces exposure but does not certify a dataset as free of cardholder data.
  • It does not detect card numbers that are not literally present. Dash0 does not detect base64 or hex encoded, encrypted, tokenized, hashed, or JSON-escaped numbers. It also does not detect numbers split across several attributes.
  • It does not detect cardholder names, expiry dates, or service codes. These have no recognizable shape. A field name such as cardholder_id does not reliably indicate card data.
  • It does not detect bank account numbers, IBANs, or routing numbers. Those are not payment card data.
  • It does not scan session recordings, metric values, or profiles. Dash0 stores Web SDK session recordings without redaction. Spans and web events from the Web SDK are scanned.
  • It does not inspect resource attribute values. Dash0 derives resource identity from those values, so rewriting one would move the telemetry to a different resource.

Redaction can also produce false positives. Dash0 masks any 13 to 19 digit identifier that passes the Luhn check and starts with a digit in the payment-network range. It also redacts any field whose name contains cvv or cvc, whatever the field holds. A false positive costs you one masked value, and it shows up in the redaction metrics.

Further Reading