Enable debug logging in a health app production system only for a named reason, a narrow scope, a fixed expiry and an approver, then confirm it is off and the output is deleted. Debug logs tend to capture payloads that normal logs avoid, so treat them as sensitive data until proven otherwise.
Why debug mode is risky
Verbose logging is often added during an outage. A developer turns on request and response logging for one service, finds the problem and forgets to turn it off. For weeks, full payloads flow into the log store, where the usual review and redaction never expected them.
The OWASP Logging Cheat Sheet addresses this directly: temporary debug logs, along with backups and extractions, must not be destroyed before the required retention period, and they also must not be kept beyond that period. In other words, debug output is still log data with rules attached. It also says sensitive items should be removed, masked, hashed or encrypted before logging.
Rules to adopt
- A ticket exists that says why debug logging is needed and what question it answers.
- The scope is one service, one environment and, where possible, one test account.
- An approver other than the requester signs off.
- A fixed expiry is set, ideally within hours.
- The output goes to a separate, access restricted location.
- A named person confirms the setting is reverted and deletes the debug output once it is no longer needed under your retention rule.
- The ticket records the dates, the scope and the cleanup.
Safer alternatives first
- Reproduce in staging with synthetic data. Keep real patient records out of test systems where you can.
- Add a targeted log line for the specific variable, with a safe identifier, instead of dumping the whole object.
- Use sampling, such as capturing one in a thousand requests.
- Use a feature flag that can only be turned on for a test account.
A quick runbook
| Step | Owner | Done when |
|---|---|---|
| Raise ticket with scope | Requester | Ticket links the incident |
| Approve and set expiry | Approver | Expiry time recorded |
| Enable on one service | On call | Config change in version control |
| Investigate | Requester | Cause found or time up |
| Revert and delete | On call | Config reverted, output removed |
| Review log sample | Security owner | No sensitive fields found |
Keeping the config change in version control gives you a timestamped record without extra tools.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a policy gate blocks a change that breaks a rule. A check that fails when a debug flag appears in a production config follows the same idea.
Where Safeguard fits
Safeguard provides policies, gates and guardrails for pull requests and compliance and evidence automation. You can use them to hold the review trail for changes like these. The logging rules and approvals are your team's decisions. A free scan is available at gold.safeguard.sh/scan.
Quick check
How long should debug logging stay on?
As short as the investigation allows, usually hours. Set the expiry when you enable it.
Do we have to delete debug logs?
Delete them once your retention rule allows. The OWASP guidance says not to keep them beyond that period.
Sources
Last reviewed: 19 October 2026.
