Yes. Many outages and security gaps start with a setting change, such as a flag turned on, a limit raised or a check disabled. Record who changed which setting, the old and new values, when and why, and link the change to the logs around it. Alert on changes to security settings.
Why settings changes need a trail
When behaviour shifts, the first question is what changed. Code deployments leave a history. Settings often do not, especially flags toggled in a dashboard or values edited in an environment console.
The OWASP Logging Cheat Sheet lists configuration changes among the application errors and system events to log, and lists higher risk functionality such as admin actions and use of break glass accounts. Its optional events include configuration modifications. It also says required events should not be possible to switch off completely, so the logging setting itself is a change to watch.
Which settings matter most for security
| Setting group | Examples | Why it matters |
|---|---|---|
| Authentication | MFA required, session lifetime, password rules | Weakening these opens accounts |
| Access control | Default roles, public sharing, allowed origins | Widens exposure |
| Logging and monitoring | Log level, retention, alert rules, sinks | Hides later activity |
| Limits | Rate limits, upload size, export caps | Controls abuse |
| Network | Allowed IP ranges, TLS settings | Changes reach |
| Feature flags | Flags guarding new security checks | Turning one off removes a control |
| Secrets and keys | Rotation schedule, key IDs | Affects trust |
Attackers who gain admin rights often change logging first. A change that lowers log verbosity or retention deserves its own alert.
A change event schema
- Timestamp in UTC.
- Actor: person, service account or automation, with identity.
- Setting name and scope, such as environment, tenant or global.
- Old value and new value. Mask secrets, and store a reference or hash instead.
- Reason, ticket or approval link where your process has one.
- Source: console, API, infrastructure as code pipeline.
- Request ID and, if applicable, the commit that produced the change.
Prefer making changes through a reviewed pipeline, so the approval record and commit already exist, and use the event as confirmation. Treat console edits as exceptions that require a reason.
Make it useful in an incident
Show change events on the same timeline as your error and latency graphs. When an alert fires, the first view should include every setting change in the previous few hours. This single habit shortens many investigations.
Add a drift check as well. Compare running values with the intended values in version control, and raise an alert on a mismatch. See what is drift detection.
Steps
- List your settings stores: flags, environment variables, cloud consoles, admin pages.
- Make each emit a change event, or route changes through a pipeline that does.
- Classify settings as security relevant, and alert on those.
- Restrict who can change them and record break glass use.
- Test by flipping a staging setting and confirming the event, the alert and the timeline entry.
Quick check
Do I log secret values when they change?
No. Log that a secret was rotated, with a key ID or version, never the value.
Is the deployment log enough?
Only for code and pipeline driven changes. Dashboard flags and console edits need their own events.
Safeguard's policies and gates, and its compliance and evidence automation, record control decisions and proof as they happen. Try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
