THIRTEENFOLDSYSTEMS
Menu

By Thirteenfold Systems · Updated

Redact logs before sharing: a worked example

Use a log redaction checklist and downloadable review template. Follow a synthetic before-and-after example to remove sensitive details and preserve useful context.

How do you review logs before sharing?

Make a copy, select the relevant excerpt, remove complete secrets and unnecessary identifiers, and review the final output. Keep event order and useful diagnostic context where disclosure is appropriate, and record what you changed.

Download text template

Step 1

Make a separate sharing copy

Keep the original private and unchanged. Select the smallest useful time window or excerpt. Review locally before uploading anything to a public service.

  • Record the source and time window.
  • Avoid collecting unrelated files just in case.
  • Use synthetic examples when a real record is unnecessary.

Step 2

Look beyond passwords

Review tokens, API keys, cookies, connection strings, authorization headers, email addresses, customer names, user and device names, private URLs, IP addresses, file paths, and message content. What is sensitive depends on the context.

  • Replace identifiers consistently, such as [USER-1] and [PROJECT-1].
  • Remove complete secret values, including values split across lines or embedded in URL query strings.
  • Do not upload a secret to a redaction service to find out whether it is secret.

Step 3

Preserve the evidence needed to understand the error

Keep relevant error codes, ordering, and surrounding lines when safe. Record intentional removals. Preserve timestamps when appropriate, or shift them consistently and disclose that transformation.

  • Do not claim a redacted excerpt is byte-identical to its original.
  • If integrity matters, keep original and sharing-copy fingerprints separate.
  • A hash demonstrates byte identity, not whether the content is safe to disclose.

Step 4

Inspect the final output

Search again, read the full excerpt, and inspect any screenshot or exported file you plan to send. Automated redaction and these examples are not guarantees of complete removal.

  • Check image backgrounds, notifications, and metadata.
  • Do not rely on reversible visual overlays to conceal text.
  • If a secret has already escaped, use the responsible service’s revocation process; editing your local copy does not recall it.

Synthetic example · no real credential

Before: a fabricated application log

Every value below is fictional. The example illustrates a failed request and the kinds of details a real log can expose.

2026-09-08T14:32:00.000Z INFO request=req-demo-1
  operation=load_settings app=ExampleApp/1.2
  user=demo@example.invalid
  path=C:\Users\DemoUser\Projects\DemoProject\settings.json

2026-09-08T14:32:00.100Z DEBUG request=req-demo-1
  Authorization: Bearer NOT-A-REAL-TOKEN

2026-09-08T14:32:00.450Z ERROR request=req-demo-1
  status=401 code=AUTHENTICATION_REQUIRED duration_ms=450

Synthetic example · reviewed sharing copy

After: identifiers removed, context retained

The sharing copy keeps the event order, operation, status code, and duration while replacing identity and authentication values.

2026-09-08T14:32:00.000Z INFO request=[REQUEST-1]
  operation=load_settings app=ExampleApp/1.2
  user=[USER-1]
  path=C:\Users\[USER-1]\Projects\[PROJECT-1]\settings.json

2026-09-08T14:32:00.100Z DEBUG request=[REQUEST-1]
  Authorization: [REDACTED]

2026-09-08T14:32:00.450Z ERROR request=[REQUEST-1]
  status=401 code=AUTHENTICATION_REQUIRED duration_ms=450

Redaction note:
Email, user/project path components, request identifier,
and the complete authentication value were replaced.
Timestamps were retained. The original remains private.
  • [REQUEST-1] still connects the three events. Consistent placeholders preserve useful relationships.
  • The complete authentication value is removed. A visible prefix or suffix may still disclose information.
  • The operation, application version, and timing help explain this sequence. These fields also need a disclosure review in a real case.
  • The 401 response does not establish whether a credential was missing, expired, rejected, or handled incorrectly elsewhere.
  • These replacements change the evidence. Describe transformations, including any consistent timestamp shift, and review the final copy before sending it.

Log redaction checklist and review record

Use the text below to record your review. Complete only relevant fields, and review the record itself before sharing.

LOG REDACTION REVIEW RECORD
Thirteenfold Systems | Revised 2026-09-08
Guide: https://www.thirteenfoldsystems.com/guides/share-logs-safely

Work on a copy. This checklist does not guarantee complete removal.
Keep originals and any placeholder mapping private.

PURPOSE AND SCOPE
Question the excerpt should help answer:
Source application and version:
Selected time window and time zone:
Material excluded from this sharing copy:

REVIEW CHECKLIST
[ ] Complete secrets, tokens, cookies, and authorization values reviewed
[ ] Email addresses, user/device names, paths, and private URLs reviewed
[ ] IP addresses, message content, and unrelated personal data reviewed
[ ] Multiline values and URL query strings reviewed
[ ] Event order and necessary diagnostic context checked
[ ] Screenshots, backgrounds, filenames, and metadata reviewed
[ ] Final exported copy reopened and reviewed

TRANSFORMATION RECORD
Information removed or replaced:
Consistent placeholders used (do not include the private mapping):
Timestamps retained or shifted; describe the transformation:
Relevant context lost through redaction:

BEFORE SHARING
Intended recipient and agreed channel:
Unresolved disclosure concerns:
Review date:
Final decision: [not yet reviewed / ready for agreed recipient / do not share]

Do not include this record in a public report without reviewing it too.