> Markdown version of https://www.getunleash.io//blog/how-do-feature-flags-support-ict-change-management-under-the-digital-operational-resilience-act
> For clean Markdown of any blog post, append .md to its URL.
> For a site index, see https://www.getunleash.io//llms.txt.

# How do feature flags support ICT change management under the Digital Operational Resilience Act?

_Published 2026-10-13 by Michael Ferranti in Product._

## Key takeaways

-   A production feature flag change alters live behavior, so treat it as an ICT change that needs approval and a record, like a deployment.
-   [Change requests](https://docs.getunleash.io/concepts/change-requests) put four-eyes approval inside the release workflow, and you can require approvals in production while leaving development open.
-   Syncing change request state to ServiceNow keeps the audit trail in the system you already use, and the [ServiceNow integration is in beta](https://www.getunleash.io/blog/unleash-8-1) as of the 8.1 release.
-   Custom approver roles and a narrowly granted skip permission keep governance from becoming a bottleneck while still allowing fast containment.
-   Audit logs should capture approver, environment, and outcome, and they should be exportable.

If a production feature flag change alters live behavior, who approved it, who applied it, and where is the record? ICT change management starts with those three questions, and they apply to production feature flag changes as much as to deployments. The Digital Operational Resilience Act (DORA) has applied since January 2025, so the questions are live now.

This article covers change management for production feature flag changes. It covers [how feature flags support the change controls](https://www.getunleash.io/blog/designing-secure-kill-switches-for-financial-services) your entity runs. Your risk and compliance partners own the regulation’s detailed text.

## Why a production feature flag change is an ICT change

A feature flag changes how software behaves in production without a deploy. Changing behavior without a deploy is the benefit. It also means the change needs the same approval as a release.

Peter Ho, VP, DevOps Tech Lead at Prudential, a financial services company with more than 40,000 employees that evaluated four feature management platforms, put it this way: “[Flipping a flag in production is considered a change that requires auditing.](https://www.getunleash.io/prudential-case-study)”

DORA became applicable in January 2025 and requires [financial entities to activate containment measures](https://www.getunleash.io/blog/designing-secure-kill-switches-for-financial-services) without delay. That statement covers containment, not the approval step for a change.

If a deployment needs approval and traceability, a production feature flag change that alters the same behavior needs them too. Otherwise the control moves out of the deployment pipeline and into the runtime layer, where changes can go unrecorded if no approval or audit step exists. The sections below describe how to keep that control in place without adding a queue that engineers learn to route around.

## Four-eyes approval built into the release workflow

[Change requests in Unleash](https://docs.getunleash.io/concepts/change-requests) add an approval step before a change is made in an environment, and they support the four-eyes principle, where a second person reviews a change before it takes effect.

You can configure the requirement per environment within a project, or globally for an environment. A typical setup requires approval in production and leaves development open. A change request can require up to 10 approvals, and approvers are notified by email, so review does not depend on someone watching a dashboard.

Each change request moves through defined lifecycle states: Draft, In review, Approved, Scheduled, Applied, Cancelled, and Rejected. Risk and compliance partners can map each state to a step in the change process. Editing a change request that is in review revokes existing approvals, so an approver cannot sign off on one version while a different one goes live. Approved changes can also be grouped and applied at a specific point in time, such as a maintenance window.

Out-of-band ticketing works differently. In many [enterprise feature flag programs](https://www.getunleash.io/blog/scaling-feature-flags-across-the-enterprise-governance-without-bottlenecks), an engineer changes a feature flag, opens a ticket, waits for approval, and then returns to finish the release. The approval sits in a separate tool from the change. With four-eyes change requests in Unleash, the approval is part of the change itself.

The four-eyes principle is also documented in [SOC2](https://www.getunleash.io/blog/soc-2-how-feature-flags-can-help-achieve-compliance) and [ISO27001](https://www.getunleash.io/blog/iso-27001-how-feature-flags-can-help). That is context for auditors and not a DORA statement. DORA’s text on approval belongs to your risk and compliance partners, who should decide which production feature flag changes need four-eyes review.

## An audit trail in the system you already use

Approval needs a matching record that survives an audit and sits where your change management process already looks.

The [ServiceNow integration](https://docs.getunleash.io/integrate/servicenow) in Unleash 8.1 is currently in beta. It tracks the state of change requests in ServiceNow, which gives you an additional audit trail of what was created, approved, and applied in the system your organization already uses for change management. You can also track [change request state](https://docs.getunleash.io/concepts/change-requests) in ServiceNow through the same integration.

You can see the underlying pattern at a large financial services company. For example, Prudential describes a developer-facing flow where all changes and [approvals are synced to ServiceNow in the background](https://www.getunleash.io/prudential-case-study), so developers never have to see ServiceNow.

[Audit logs](https://docs.getunleash.io/concepts/events) should capture the approver, the environment, and the outcome. A record that shows only the editor leaves an auditor to reconstruct the rest.

Regulated teams need exportable, machine-readable audit logs rather than vendor-managed dashboards. With an export, your risk and compliance partners can pull evidence into their own tooling and answer an auditor’s question without depending on a screen they do not control.

## Scoped permissions so governance does not become a bottleneck

Anyone with project access can create a change request. Only users with specific permissions can approve, apply, or skip one. None of the predefined roles carry [change request permissions](https://docs.getunleash.io/concepts/change-requests#change-request-permissions), so you create custom project roles for your approvers. Define those roles around accountability: who in each product, region, or environment you trust to approve a production feature flag change.

[Role-based access control](https://docs.getunleash.io/concepts/rbac) removes the single-admin bottleneck, and permission boundaries double as audit boundaries. If you scope approvers to a product, region, or environment, the approver recorded on an entry tells an auditor something useful.

Four-eyes approvals and role-based access control can be aligned to the same product, region, and environment boundaries. That alignment is the basis of audit-ready release governance.

At Lloyds Banking Group, [more than 1,000 users across 20 platforms and 23 million customers](https://www.getunleash.io/lloyds-case-study-featureops-regulated-environments) work in a regulated setting where releases that once came every three to four weeks sped up, with release cycles accelerated by 35% and compliance workflows retained.

For your own setup, require approvals in production and relax them in development.

The skip change requests permission lets a user bypass the flow for environment-specific actions, such as turning a feature flag off or enabling a kill switch during an incident. It does not cover feature-level actions such as archiving or deleting a feature flag, which still go through a change request. Grant it narrowly and have your risk and compliance partners confirm how its use is recorded.

## Containment when a change goes wrong

The skip change requests permission and kill switches let responders act without waiting for approval. Instant rollback likewise lets operators stop a misbehaving feature at runtime.

[Switches scoped to the smallest logical unit of risk](https://www.getunleash.io/blog/designing-secure-kill-switches-for-financial-services) let operators disable one affected capability without hesitating over a full outage. Dual control and immutable audit logs protect the switch itself from misuse.

You can also automate part of containment. [Safeguards use production signals to progress or pause exposure](https://docs.getunleash.io/guides/getting-started-release-management), and you can now create [impact metrics](https://docs.getunleash.io/concepts/impact-metrics) in the Admin UI and use them to drive a safeguard that guards a rollout. You can self-host or run on a hosted single-tenant environment, which suits entities that must run the deployment inside their own infrastructure.

## What to put in place first

In production, enable change requests, define custom approver roles, connect change request state to your change management system, and review audit log contents with your risk and compliance partners to confirm they capture approver, environment, and outcome.

Unleash provides change requests, scoped permissions, and audit logs for [FeatureOps](https://featureops.io/) runtime control, and the [ServiceNow integration is in beta](https://www.getunleash.io/blog/unleash-8-1) (as of September 2026).

## Try change requests on your own release process

If you are evaluating how approvals, scoped permissions, and an audit trail fit your change management process, start a [free trial](https://www.getunleash.io/plans/enterprise-payg) of Unleash Enterprise, require approvals on one production environment, and walk through the resulting records with your risk and compliance partners.

## FAQs

### Is a production feature flag change an ICT change?

Yes. A feature flag changes production behavior without a deploy, so it needs the same approval and traceability as a deployment. At [Prudential](https://www.getunleash.io/prudential-case-study), flipping a flag in production is a change that requires auditing.

### Does DORA require four-eyes approval for feature flag changes?

DORA’s text on approval belongs to your risk and compliance partners, who should decide which production feature flag changes need four-eyes review. The four-eyes principle is also documented in [SOC2 and ISO27001](https://www.getunleash.io/blog/scaling-feature-flags-across-the-enterprise-governance-without-bottlenecks).

### How do change requests work in Unleash?

[Change requests](https://docs.getunleash.io/concepts/change-requests) add an approval step before a change is made in an environment. You can configure them per environment within a project, or globally for an environment, with up to 10 approvals.

Each request moves through Draft, In review, Approved, Scheduled, Applied, Cancelled, and Rejected. Editing a request that is in review revokes existing approvals.

### How does the audit trail reach ServiceNow from Unleash?

The [ServiceNow integration](https://docs.getunleash.io/integrate/servicenow) in the 8.1 release (August 10, 2026) is currently in beta. It tracks the state of change requests in ServiceNow, so you have a record of what was created, approved, and applied. Validate it against your own change process before relying on it.

### Can responders stop a feature during an incident without waiting for approval?

Yes, with the skip change requests permission. It lets a user bypass the flow for environment-specific actions, such as turning a feature flag off or enabling a kill switch during an incident. It does not cover feature-level actions such as archiving or deleting a feature flag, which still go through a change request. Grant it narrowly and have your risk and compliance partners confirm how its use is recorded.

### What should an audit log capture?

[Audit logs should capture the approver, the environment, and the outcome](https://www.getunleash.io/blog/scaling-feature-flags-across-the-enterprise-governance-without-bottlenecks). Regulated teams also need exportable, machine-readable logs, so your risk and compliance partners can use the evidence in their own tooling.