In a regulated org, how do you enforce “who can change what in prod” with approvals and an audit trail?

Most regulated organizations don’t fail audits because they lack process; they fail because the process only exists on paper, not in the runtime where production changes actually happen. If you want to control who can change what in prod—and prove it—you need approvals and an audit trail wired directly into your release surface, not bolted on after the fact.

Quick Answer: You enforce “who can change what in prod” by moving approvals and audit controls into the same runtime surface you use for releases—feature flags—then backing them with policies, roles, automated workflows (including ServiceNow), and a tamper‑proof audit log that spans every flag change in every environment.

---

The Quick Overview

• What It Is: A runtime approval and audit framework built around LaunchDarkly feature flags, approvals, and policies that define and enforce who can change production behavior—and under what conditions.
• Who It Is For: Engineering, platform, SRE, and compliance teams in regulated orgs (finance, healthcare, public sector, critical infrastructure) that must prove control over production changes to internal auditors and external regulators.
• Core Problem Solved: Preventing unauthorized or unsafe production changes—and eliminating 2am “who changed what?” fire drills—while still letting teams ship and fix issues quickly, without redeploys.

---

How It Works

You govern production changes by treating every runtime change as a controlled, observable event:

1. Define control boundaries with policies and roles.
   You decide which environments are locked down (usually staging and prod), which flags/segments are “sensitive,” and which people/teams can touch them. You encode this as policies and custom roles.

2. Enforce approvals before anything changes in prod.
   When someone edits a controlled flag, LaunchDarkly can require an approval—either inside LaunchDarkly or via ServiceNow—before changes are applied. Approvers can review, approve, or reject from the UI, API, or Slack.

3. Capture everything in an end‑to‑end audit trail.
   Every change—who requested, who approved, when it was applied, and what exactly changed—is written to a tamper‑evident audit log. You can replay any incident, satisfy audits, and show evidence of control for any production change.

1. Define who can change what (before anyone touches prod)

You start by modeling your governance rules in LaunchDarkly instead of buried in a wiki:

• Environments: Decide where approvals are mandatory (e.g., production and regulated staging).
• Scope: Choose whether approvals are required for:
  • All flags and segments in an environment, or
  • Only those with specific tags (e.g., payment, PHI, trading, SOX-critical).
• Roles & permissions: Use custom roles to restrict:
  • Who can edit flags or segments.
  • Who can approve changes.
  • Who can override or bypass a rule (if allowed at all).

This turns “policy” into executable guardrails. Engineers still use feature flags as usual, but sensitive toggles are now governed by runtime rules, not tribal knowledge.

2. Enforce approvals where regulation cares most

Once rules are in place, approvals become a built‑in step of the release, not a separate CAB meeting:

• LaunchDarkly native approvals:
  • A dev proposes a flag change (e.g., enable a feature for 5% of prod).
  • LaunchDarkly creates an approval request and blocks the change from going live.
  • An approver reviews the request, sees the flag, environment, targeting rules, and rollout plan, then approves or denies.
• ServiceNow‑backed approvals:
  • LaunchDarkly can automatically generate a change request in ServiceNow when a flag change needs approval.
  • Your existing change management workflow runs in ServiceNow.
  • Once the request is approved in ServiceNow, LaunchDarkly can automatically apply the associated flag changes (if you opt into auto‑apply).
• Slack for real-time decisions:
  Approvers see the approval request in Slack, and can approve/deny directly there. This keeps the workflow fast without losing control.

You decide, per environment and per tag, whether approvals go through LaunchDarkly, ServiceNow, or both.

3. Capture a complete, queryable audit trail

Every action is recorded, so you can answer “what changed in prod?” in seconds:

• Who did what, where, and when
  • Flag created, modified, or archived.
  • Targeting rules changed, rollouts adjusted, segments edited.
  • Approvals requested, approved, or rejected.
• What exactly changed
  • Previous and new values.
  • Environments impacted.
  • Linked change request IDs (e.g., from ServiceNow).
• How it was executed
  • Whether changes were auto‑applied after external approval.
  • Whether a change was triggered via UI, API, CLI, or integration.

Because LaunchDarkly runs at production scale (45T+ flag evaluations/day, 99.99% uptime, <200ms flag changes worldwide), you’re not just logging config updates—you’re logging the control points that actually govern live behavior.

---

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
Environment‑level approvals	Require approvals for changes to specific environments (e.g., prod) and scoped flags/segments.	Ensures high‑risk environments can’t be modified without explicit review.
ServiceNow & Slack integration	Auto‑create ServiceNow change requests and surface approvals in Slack.	Aligns runtime changes with formal change management, without slowing teams down.
Audit logs & change history	Record every flag/segment change, who made it, and who approved it.	Provides a defensible audit trail for regulators, security, and incident reviews.

---

Ideal Use Cases

• Best for SOX / PCI / HIPAA‑regulated production systems:
  Because it lets you enforce that no material behavior change goes live without peer or managerial approval, with a complete audit trail mapped to change tickets.

• Best for platform teams standardizing release governance across squads:
  Because you can template and tag policies once (e.g., “critical payment flags require approvals in prod”) and apply them consistently across all services and teams.

---

Limitations & Considerations

• Approvals don’t replace good flag hygiene:
  You still need a flag lifecycle strategy—naming conventions, tags, TTLs, and cleanup—to avoid accumulating technical debt. Approvals help with safety, not clutter; pair them with lifecycle policies.

• You must intentionally design your approval model:
  If you require approvals for every trivial change, teams will either slow to a crawl or push back. Start with high‑risk flags and environments, and expand once the workflow proves itself.

---

Pricing & Plans

LaunchDarkly is sold as a runtime control platform; approvals and audit capabilities are available on plans designed for organizations that need formal governance and compliance.

• Team / Growth‑style plans: Best for engineering orgs that need feature flags, progressive delivery, and a basic audit trail, and are beginning to formalize approvals in higher‑risk environments.
• Enterprise‑grade plans: Best for regulated organizations that need fine‑grained policies, custom roles, approvals tightly integrated with ServiceNow and Slack, and a comprehensive, exportable audit history.

For specifics on which plans include which governance features, talk to our team—we’ll map the capabilities to your regulatory requirements and existing change management process.

---

Frequently Asked Questions

How do I decide which changes should require approvals?

Short Answer: Start with production and high‑risk flags—tag them and require approvals only there, then expand as needed.

Details:
You don’t want approvals on every experiment toggle or internal beta. Instead:

• Tag flags and segments that touch:
  • Financial reporting or trading logic (SOX, MiFID, etc.)
  • Payment flows (PCI)
  • Patient or customer data (HIPAA, GDPR)
  • Safety‑critical behavior (healthcare, industrial, public sector)
• Configure LaunchDarkly so:
  • Approvals are required in production (and possibly regulated staging).
  • Only tagged flags in those environments are gated.
• Use repeatable release templates and policies so these rules are consistent across teams.

This gives auditors clear evidence that “material” runtime changes are controlled, without blocking everyday iteration.

---

Can I still move fast in an incident if approvals are required?

Short Answer: Yes—approvals are designed to be fast (Slack, ServiceNow, UI/API) and you can use emergency policies for kill switches when needed.

Details:
In an incident, speed matters as much as control:

• For most changes, you keep the normal approval paths:
  • Approvers get Slack alerts and can approve on mobile.
  • ServiceNow workflows run as they do today, but now they directly control flag changes.
• For true emergencies:
  • You can designate specific flags as kill switches with a streamlined path and pre‑approved responders.
  • Policies can allow on‑call engineers to flip designated kill switches without extra approvals, while still logging every action.
• Observability integrations (e.g., Datadog) show you when error rates spike and correlate that to flag changes, so you know exactly which switch to flip.

This way you meet compliance requirements without re‑introducing the “redeploy to rollback” risk that causes 2am fire drills.

---

Summary

Enforcing “who can change what in prod” in a regulated org isn’t about adding more meetings; it’s about moving governance into the same runtime control plane you already use to ship. With LaunchDarkly, you:

• Define policies and roles that encode your change management rules.
• Require approvals—via LaunchDarkly or ServiceNow—before high‑risk flag changes go live.
• Capture a complete audit trail of every request, approval, and change, with <200ms propagation worldwide and 99.99% uptime.

You get the safety and evidence your auditors need, with the speed and autonomy your engineers expect.

---

Next Step

Get Started