Changing a feature flag alters production behavior without a deploy, so treat it like a code change. Limit who can edit flags per environment, require a second person for risky ones, and keep a record of who changed what, when and why. Otherwise your flag console is a side door around review.
Why this needs its own controls
The OpenFeature documentation lists the pieces a full flagging system needs beyond an SDK: an admin UI, audit trails and environment management. Those are in the list because flags are changed by people, at runtime, with real effect.
A code change goes through review, CI and a deploy log. A flag flip, by default, goes through a button.
Roles that work
Keep it simple. Three levels cover most teams.
Viewers can see flags and their state. Most engineers, support and product people.
Editors can change flags in non-production environments. Developers working on the feature.
Production editors can change flags in production. A smaller group, ideally those on call and the owning team.
Separate permissions per environment. Someone who edits staging all day should not hold production rights by default.
Which flags need a second person
Not every flip needs a ticket. A rollout from 5 to 10 percent on a release flag can be one person's call. Require approval for flags that affect:
- Access to data or tenant boundaries.
- Authentication, authorization or session handling.
- Billing or money movement.
- Switches that turn off a protection.
Fowler's article describes permissioning flags and ops flags as separate categories with different lifetimes, and says to manage toggles differently by category. Approval rules by category follow the same idea.
What to record
For every change, capture the flag key, old and new value, environment, the person, the time and a free-text reason or ticket link. Include automated actors such as scripts and integrations, and give each a named identity.
Send the records to a place the flag editors cannot alter, such as your normal log store. Then connect them to deployment history, so during an incident you can see code and flag changes on one timeline.
Break-glass for incidents
Some flags exist to be flipped fast, such as a kill switch. Allow on-call staff to flip those without approval, and require a short written reason afterward. Review those flips weekly.
Review the review
Once a quarter, list who holds production edit rights and compare it to the current on-call and owner lists. Remove people who changed teams. Check that each flag listed as sensitive has an owner.
Evidence for auditors
If you work toward a compliance framework, flag change records are evidence of change management. Map them to the relevant control and keep exports, as shown in the demo below.
Safeguard's compliance and evidence automation can collect this kind of record against framework controls, and its policies and gates can enforce rules on code changes. Flag consoles are a separate system, so check what your own tool can export before you promise an auditor anything.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a control maps to evidence, and think about where flag change records would sit.
Quick check
Does a flag change need the same review as a code change?
For flags that affect access, authentication, billing or protections, yes. Low-risk release flags can use lighter rules.
Where should flag change records be stored?
In a log store the flag editors cannot alter, linked to deployment history so incidents show code and flag changes together.
Sources
Last reviewed: 19 October 2026.
