Which fields to redact before sending tickets and chat logs

Support pastes a customer message into Zendesk. Ops exports a signup sheet into Slack. A developer drops an error log into a thread. Those three moves happen every day. The last article covered which URL parameters to strip: utm_source and fbclid can go; id= has to stay. After that pass, people often stop. A North American number such as 415-555-0100, a nine-digit SSN, a PAN, and an email do not disappear because the link got shorter.

The question is not “should we redact.” It is how to split two kinds of string. Anything that lets the next person reach a human or move money must be masked. Order IDs, ticket numbers, and product SKUs locate work, not people — mask those and the next shift cannot open the same record. The table, exceptions, and checks below stay on that one decision. MyPassGen’s Clean URL page follows the same split for text redaction. This article is not a tool tour. It answers which fields to mask before you forward a ticket or chat log, and how to verify the result.

A clean URL does not clean the body

The GDPR Article 4 definition of personal data is any information relating to an identified or identifiable natural person. A phone number, national ID, or email in a ticket sits on the “identifiable” side. Forward the full original into the next channel, the next spreadsheet, or the next “online tool,” and you also forward that ability to identify.

Article 9 treats health data, biometrics, and similar categories as special. California’s CCPA / CPRA lists Social Security numbers, financial-account numbers, and government IDs as sensitive personal information. Article 5’s data-minimisation rule is the working line for a support thread: send what the next person needs to finish the job, not a complete account file. Pasting a full PAN into Slack, or leaving a child’s contact details on a public ticket, fails that test.

The statutes do not place every asterisk for you. They set a default: the copy you send should let someone keep working without seeing a complete number. If a mask or a ticket ID is enough, send that. If a named person must receive a live key, do not put the live key in the ticket body. Use a one-time channel.

Fields that must be redacted

The table groups fields you will actually see in tickets, signup sheets, demo decks, and pasted logs. It is not an exhaustive compliance catalog — vendors invent new prefixes — but it covers the values that leak most often. After the mask, a reader should still recognize “this is a phone / an ID / an email,” and should no longer be able to use it as-is.

Phone numbers: if it still dials, you are not done

ITU-T E.164 caps an international public number at 15 digits, not counting the international prefix. The plus sign is notation, not a digit. North American numbers are usually written as ten digits, sometimes with a leading 1. A ticket mask such as ***-***-0100 tells the next agent “this is a phone” without giving them a number they can call.

Pull digits out of spaces, parentheses, and +1 before you decide. Do not only match a compact ten-digit run. The reverse is also true: an 8-to-15-digit blob can be an order ID. Without a +, a separator, or a NANP / mainland-China mobile shape, do not treat every long number as a phone. Masking the order ID is the more common failure — the next shift then cannot match the invoice.

National IDs: the middle is the identifying part

A US SSN is nine digits in three groups. The Social Security Administration’s own public examples mask as ***-**-1234: keep the last four so staff can confirm “is this the same person we already have,” and hide the area and group. A number that merely has nine digits is not automatically an SSN. Area 000, 666, or a leading 9, and a group or serial of all zeroes, are invalid — those strings are more often order IDs or copy errors.

A UK National Insurance number is two letters, six digits, and a suffix letter. A common outbound mask keeps the two leading letters and the suffix so the shape is still recognizable, and covers the digits. Cross-border tickets sometimes include an 18-digit Chinese resident ID. The middle eight digits are a date of birth. Masking only the last four and leaving the birth date still forwards age and region. The same rule as an SSN applies: leave the shape of “this is an ID,” take the middle that says which person.

Payment cards: the display ceiling is not a target

A primary account number (PAN) carries a check digit computed with the Luhn algorithm, documented in ISO/IEC 7812-1 Annex B. Luhn catches typing errors. It does not prove the card is live. Length is usually 13 to 19 digits. PCI DSS’s ceiling for display is at most the first six and last four. If you do not have a concrete need for the BIN, do not use the full ceiling.

Almost no outbound ticket needs the BIN. Last four is enough for “is this the card ending 4242.” Putting a full PAN and the cardholder name in the same Slack message stacks a financial account with identity data — worse than a lone last four. Only treat a long number as a card if it passes Luhn. If it fails, prefer “business ID” and leave the tracking number alone.

Email, keys, and addresses

Most of an email’s identifying power sits before @. Keep the first character, mask the rest, leave the domain. That is usually enough to tell a work mailbox from a personal one, and not enough to write to it. Forwarding local@domain intact hands a contact channel to everyone who opens the thread.

API keys usually carry a family prefix: sk- / sk_live_, AKIA / ASIA, AIza, ghp_ / github_pat_, glpat-, npm_, xoxb-, and the token after Bearer. The prefix names the family. It is not there so someone can keep calling the API. If the masked string still authenticates, you masked too little — or you should never have put a live key in the ticket. A complete key belongs on a one-time link, with the key after # in the URL. The read page does not require an account.

For IPv4, keeping the first two octets (the documentation range 203.0.113.0/24 written as 203.0.*.*) is usually enough to see the provider or office block, and not enough to pinpoint a host. Apply the same rule to private addresses, VPN egress, and home broadband that show up in pasted stack traces: mask the last two octets.

Number strings you should leave alone

The body has the same split as a query string. Some numbers look random and are there so the next person can open the same record. Mask those and the handoff breaks.

• Orders and shipping: store order IDs, carrier tracking numbers, return-authorization numbers. Length often overlaps a phone or a PAN, but the string has no phone or Luhn shape.
• Tickets and object IDs: Zendesk / Jira keys, internal user IDs, SKUs, auto-increment database IDs. The reason you forwarded the note is often so someone else can open that row.
• Builds and clocks: build numbers, short commit prefixes, timestamps. Mask those and the reproduction steps die.

A check you can run in a notes app: copy the outbound text, handle one type at a time (phone, then ID, then card), and reread after each pass. Are the business IDs still there? Does the sentence still parse? Do not replace every long number with asterisks and then guess which one you broke.

Passport-style “one or two letters plus six to nine digits” is easy to confuse with a PNR or a plate. If a checksum fails, or the surrounding words are clearly a flight and a seat, leave it and mark it by hand. Do not hand that decision to a single regex.

Redaction is not anonymization

GDPR Recital 26 puts anonymous information outside the Regulation only when the person is no longer identifiable. Article 4(5) defines pseudonymisation as processing that can no longer be attributed to a person without additional information. A ticket that says ***-***-0100 plus a name, an address, and an order ID is still identifiable inside the helpdesk. That is pseudonymisation at best. It is not anonymization, and it is not a license to publish.

Write the goal accurately: reduce direct usability on the next forward, the next screenshot, the next channel. Redaction does not let you post the resulting sheet on a public page, and it does not replace “send only what is needed.” Names, street addresses, faces, children’s data, and live keys often sit where a regex never looks: another column, pixels in a screenshot, or a number split by spaces.

Stacking a name, a phone, an ID, and a home address in one message is more sensitive than a single masked phone. If you can split them, do not put all four in one Slack line. If a ticket number is enough for the other person to open the record themselves, do not copy the customer file out of the system.

Check on the spot: side-by-side text, asterisks, and Network

Slogans cannot be checked. Characters can. These steps do not depend on a brand promise. A notes app and DevTools are enough.

1. Paste the full outbound original into a local editor and keep an untouched copy, so you are not masking from memory.
2. Using the table above, handle phones first, then IDs, cards, and emails. One type per pass. Leave business IDs alone for now.
3. Put the original and the result side by side. Masked fields should show asterisks or an equivalent. Order IDs, SKUs, and dates should still be readable.
4. Search the result for a complete phone from the original, a full SSN, or the local part before @. If you can still find it, you are not done.
5. If a tool lists hit types in the browser, read that list against the asterisks in the result. A type on the list with a matching mask in the output is finished. A type on the list with a complete value still showing is not.
6. Open DevTools → Network, enable “Preserve log,” and run redaction again. Document and API requests should not contain the original you just pasted. Analytics should not carry a full ID or a full mailbox.

MyPassGen’s Clean URL page works on that boundary. In Data redaction, pick one type at a time — phone, ID number, bank card, email, API key, or IP — and compare the original with the result side by side. NANP numbers mask as last four; E.164 keeps a country-code hint; an 18-digit Chinese resident ID is checked with ISO 7064 before it is masked; cards run Luhn, then keep only the last four (tighter than “first six + last four”); emails keep the first character of the local part. Processing finishes in the current tab. The original is not uploaded and is not written to analytics. You do not create an account. The page says it is an aid. Important cases still need a human pass.

Screenshots, spreadsheets, and the illusion of “already redacted”

A sheet is harder than a paragraph. The phone is in column A, the name in column B, and a scanned ID is an image on page three. Text rules do not see pixels. Before you send a deck, look for uncropped ID photos, screen recordings that still show a complete number, and an Excel file with the original sitting in a hidden column or a second sheet.

Chat “reply” quotes the previous message. You masked the latest line; the quote still holds the complete number. Slack threads, email forwards, and Intercom notes do the same thing. Expand the quote before you send, or write a new message without the quote. Forwarding a whole mail thread also forwards early, unmasked signatures and ticket bodies.

A short link or a QR code does not fix the body. The last article treated short links as a redirect layer. Add this: people write “order for 415-555-0100” into a page title or into utm_content. After you strip tracking names, the title and the paragraph are still there. Cleaning a URL and redacting text are two jobs. Neither replaces the other.

Common mistakes

“Last four is enough on a phone.” Leaving the first six digits of a US number and hiding only the last four still gives someone a lot to combine with a people-search dump. Last-four-only is a common compromise for display, not a proof. On an SSN, leaving the area and group and hiding only the serial is the same unfinished job.

“HTTPS already protects privacy.” HTTPS stops an eavesdropper on the path. The recipient, every member of the channel, and every admin on the helpdesk still see the plaintext you pasted. What you are reducing is unnecessary complete numbers on the copy you send.

“Redacted means we can publish it.” After pseudonymisation, the helpdesk can still re-identify the person. A public page, an external case study, or a training deck needs information that cannot be reversed without extra data. That is anonymization. A few asterisks are not.

“The rule already ran, so we can skip a review.” Split numbers (415 555 0100), words that spell a number, IDs inside images, and key prefixes the rule has not learned will leak. The human pass is: can you still search the result for a complete original, and can the remaining context still assemble the same person?

Where to start redacting

Start with the one paragraph you are about to send today. Copy it locally, mask phones first, compare with the original, then decide whether IDs and emails need the same pass. Old channel topics and knowledge-base pages can wait. You do not have to scrub the whole history in one sitting.

If one paste mixes a URL and a body, strip UTM and click IDs first using the previous article’s table, then redact the body. When one message holds both an order ID and a phone, keep the order ID, mask the phone, and reread the sentence. After that one pass you can already answer the title: mask the fields that reach a person or move money; leave the IDs that open the same business record.

If a named person must receive a live password, recovery code, or API key, do not write the complete secret into the ticket, and do not treat a mask as “we did not send it.” Generate a one-time link. A file that must be decryptable more than once belongs in the file encryption box, which builds a .lock / .enc file on this device; send the passphrase on a separate message. Text redaction reduces complete numbers in a discussion. It is not a key-exchange channel.

FAQ

After redaction, does the other person still know who this is?

Often yes. A ticket ID, a name, and a masked phone together still resolve inside the helpdesk. Redaction reduces the chance that someone outside that system can dial or impersonate from a complete number. It does not turn the text into anonymous statistics.

Why was this ten-digit number not treated as a phone?

A long digit run with no NANP shape, no leading 1, and no + or separator is more likely an order ID. Treating every run as a phone masks the locator the next shift needs. If you are unsure, leave it, handle only numbers that look like NANP, +, or a known mobile form, and mark the rest by hand.

Is last-four on a card compliant?

PCI DSS’s display ceiling is first six + last four. Last-four-only is tighter and is usually enough to confirm a tail. It is still not permission to post the number on a public channel. A full PAN plus a name should not appear in Slack.

Do I need an account to redact? Is the original uploaded?

No account. The log risk starts when you hand a full ticket to a site that uploads the original. Local processing keeps the original in the current tab. What you check is whether Network sent a full ID or mailbox to a third party, and whether you can still search the result for an unmasked complete number.