DisasterLab
PlaybooksSensitive data appears in logs
Datacritical35 minutes to prepare

Sensitive data appears in logs

Passwords, tokens, payment details, personal data, or private content are being recorded in application or vendor logs.

01DetectConfirm the signal
02ContainStop more damage
03RecoverRestore control
04VerifyProve it works

What do you need right now?

Prepare before it happensRecover from this now

Your preparation

0 of 0 safeguards ready
0%
Continue the prevention checklist
Incident worksheet

Make the next decision with evidence

Stop new sensitive events, restrict and expire existing copies, identify every downstream log destination, and replace any credential that appeared.

EvidenceDecisionActionProof

Capture before evidence disappears

  • Capture the exact field, event, logger, code version, environment, first and last occurrence, volume, tenant, and retention policy.
  • Map the path through agents, stdout, files, collectors, processors, indexes, dashboards, alerts, tickets, exports, archives, and vendor support.
  • Export access and query logs showing who or what viewed, downloaded, forwarded, or integrated the affected records.
  • Classify passwords, tokens, session cookies, payment data, health data, identifiers, message bodies, and customer content separately.

Decisions that change the response

QuestionAct whenAction
Purge or restrict first?Deletion is slow, replicated, or risks destroying the access evidence needed for scope.Restrict access and exports immediately, preserve audit evidence, then run a documented purge.
Rotate credentials?Any password, token, cookie, private key, reset link, or reusable signed URL was logged.Revoke it at the issuer and invalidate related sessions.
Disable logging or the feature?New sensitive events continue and a safe filter cannot be deployed quickly.Disable the narrowest emitting path; keep security and incident logging that does not repeat the data.

Proof that recovery worked

  • A synthetic sensitive value no longer appears in application, collector, vendor, alert, ticket, or archive searches.
  • Affected indexes, replicas, exports, caches, and archives have documented deletion or restricted retention outcomes.
  • All exposed credentials fail and associated sessions are invalidated.
  • Access history and notification decisions account for operators, vendors, integrations, and customer tenants.

Controls to put in place

  • Use structured logging with an allowlist of fields and central redaction before transport.
  • Ban request bodies, authorization headers, cookies, secrets, and full customer records from default logs.
  • Restrict production log access, exports, and retention by role and environment.
  • Test redaction with canary values and scan log pipelines continuously for secret and data patterns.
Tabletop drill

Emit a synthetic token and customer identifier in a controlled environment. Trace every destination, block access, purge it, rotate the test token, and prove a regression test prevents the same field.

Escalate when

Engage the logging vendor, security responders, privacy counsel, and customers when regulated data or reusable credentials entered broad-access logs, vendor systems, long-lived archives, or locations without access auditing.

What this means

Data sent to logs may be copied into monitoring vendors, backups, exports, alerts, and developer laptops. Fixing the logging line does not remove existing copies.

Warning signs

  • Request bodies, headers, URLs, or exception traces contain secrets.
  • Support or developers can search customer content they should not see.
  • Alerts paste tokens or personal data into email or chat.
  • A logging vendor reports detection of sensitive fields.

Recover now

First 15 minutes

  1. Stop the offending log path or redact the field without disabling all evidence.
  2. Restrict access to affected log stores and exports.
  3. Identify data types, systems, recipients, and the earliest affected time.
  4. Revoke credentials found in logs at their issuing providers.

Today

  1. Purge affected records through supported retention and deletion controls.
  2. Trace copies into alerts, dashboards, archives, tickets, and local exports.
  3. Review access logs to learn who viewed or downloaded the data.
  4. Assess notification obligations with qualified legal and security help.

Verify recovery

  • New test requests produce redacted logs.
  • Exposed credentials fail.
  • Known copies follow an approved deletion or retention decision.
  • Log access is limited and reviewed.

Prepare now

Access

  • Production logs use named roles and least privilege.

Backups and evidence

  • Structured logging excludes or redacts classified fields by default.
  • Automated tests detect credentials and personal data in log output.

Contacts and ownership

  • Log stores, exports, and alert destinations have owners and retention rules.

Practice

  • A synthetic secret can be found, contained, and removed safely.

Common mistakes

  • Deleting only the visible dashboard entry.
  • Rotating secrets but leaving personal data exposed.
  • Turning off all logging during a security incident.

Sources

Last reviewed July 19, 2026Guidance changes. Confirm provider-specific actions in the linked official sources.