Digital Operational Resilience Act: a buyer’s guide to runtime controls

• A production flag change alters live behavior, so treat it as an ICT change with an approver and a record, the same as a deployment.
• Score vendors per control area: change approval, logs, containment, access, and hosting and exit. Ask for the evidence each one produces.
• Check the edges: the ServiceNow integration’s beta status, the login history retention period, and the skip permission’s limits.
• Hosted and self-hosted platforms put different work on your team. Self-hosting moves hosting, encryption, backups, and log retention onto your team. A self-hosted license and support contract is still an ICT arrangement to assess and record.
• The platform supports its own part of each obligation. Your risk and compliance partners own the regulation’s detailed text.

A production flag change alters live behavior, so a review under the Digital Operational Resilience Act (DORA) asks two questions: who approved it, and where is the record? This guide gives you a buyer’s checklist of runtime controls for a feature management platform, organized by the obligation each control serves.

DORA, Regulation (EU) 2022/2554, was adopted on 14 December 2022 and has applied since January 2025. A production feature flag change needs approval and a record, as a deployment does, so score each vendor on the evidence it can produce for its own part of each obligation. The sections that follow cover scope, change control, logging, containment, access control, hosting, a scorecard, and limits.

Why a feature management platform falls inside your DORA scope

This section decides whether the platform is in scope. The regulation’s scope covers banks, insurers, investment firms, payment institutions, and information and communications technology (ICT) third parties, among others, and its requirements apply, in proportion to your size and risk profile, to the ICT systems that support a financial entity’s business. The DORA documentation lists the platform controlling application behavior in production among those systems.

One detailed technical standard is the ICT risk regulatory technical standard (RTS), Commission Delegated Regulation (EU) 2024/1774.

An auditor reviewing a production flag flip asks the same question as for a release: who approved it, and when? Deployment pipelines record commits, but runtime toggles can bypass that record unless the platform adds approval and logging. When you evaluate a vendor, treat every production toggle as a change that needs an approver and a trace. Change control is the first test of that.

What to require for change control

This section covers the approval controls to require. First, ask for the platform’s approval step in front of each environment change. With Unleash change requests, you can require up to 10 approvals, and approvers get email notifications.

A request moves through these states: Draft, In review, Approved, Scheduled, Applied, Cancelled, and Rejected. Editing a request in review revokes its approvals, so approvals do not carry over to text that has since changed.

Second, check the bypass path around the gate. Admin users can approve and apply their own change requests, so restrict and review the Admin role, and ask every vendor the same question about its administrators. Project Owners and users with project update permissions can also override environment-level approval defaults, so check who holds those roles before you call approval mandatory.

Third, you can also require approval per environment. Require it in production and leave development open, so engineers keep their speed where the risk is low.

Fourth, approvals matter more when they appear where your change managers already look. The ServiceNow integration mirrors each change request into ServiceNow as a standard change and updates its stage as the request progresses, while approval still happens in the platform and ServiceNow holds an additional audit trail. Changes made with the skip permission never become change requests, so they do not reach ServiceNow. The integration has been in beta since 8.1, so confirm its current status with the vendor before you rely on it, and do not treat it as generally available until the vendor says so in writing.

The DORA documentation maps change request features to Article 9(4)(e) and to RTS Article 17. Request an equivalent mapping from each vendor and check each row for a specific feature you can demonstrate, because the mappings in this guide come from the platform’s own documentation and each vendor’s version will come from theirs. Next comes the evidence those changes leave behind.

What to require for logging and audit evidence

This section covers the evidence that proves what changed.

What a reconstructable log contains

A log is useful when you can rebuild the sequence of changes from it. The event log records the user, IP address, timestamp, previous state (preData), and new state (data) where the event type supplies them. You can search it in the Admin UI and the Events API, and you can also export it as CSV or JSON to a security information and event management (SIEM) tool. In the DORA documentation, this falls under RTS Article 12.

In a demo, ask the vendor to change a flag and then show you that exact entry. Look for the user and the IP address of the change, and the value before and after it.

Retention terms to ask about

Read the retention terms before the feature list. Login history is kept for 14 days, so download it periodically if your retention policy requires longer. Ask every vendor for its retention terms in writing, and do not assume them. In practice, exportable, machine-readable logs beat vendor-only dashboards, because your own tooling and your own retention policy then set the retention period of the evidence. With the evidence defined, containment is next.

What to require for containment and detection

This section covers how to withdraw a feature and how to detect the need.

Kill switches and the skip permission

Disabling a flag or an environment withdraws a feature without a deployment. In the DORA documentation, this falls under Article 11. Ask for the kill switch’s fallback state, because a pre-built fallback returns the application to a known-good path instead of leaving it undefined.

Next, check the permission model around that speed. The skip change requests permission, held together with the permission to turn flags on or off, covers environment-specific actions such as turning a flag on or off or updating its activation strategies in that environment. Your incident responders get a fast path to containment, but holders can also change exposure without approval, so grant it narrowly. Archiving or deleting a flag keeps its approval gate, and you should also ask how the vendor records skip use, because the RTS expects emergency changes to be documented, assessed, and approved after they are implemented.

Detection, response, and agentic AI

Impact metrics and safeguards can disable an environment or pause release plan automation when a metric crosses a threshold. The disable is not an instant client-side cut-off, because SDKs pick up the change on their next refresh interval. Unleash backend SDKs refresh every 15 seconds by default, and frontend SDK defaults range from 15 to 60 seconds. As a result, request that interval from each vendor and plan your recovery-time objectives around it.

Actions can also disable a flag when monitoring reports a regression, and the DORA documentation lists this under Article 11 as well. Actions run on a polling cadence: signals are processed once per minute, with at most 10 signals per cycle by default (self-hosted installations can change the limits), so add that delay to your recovery-time planning.

If your teams ship AI agents, containment matters more. Runtime control for agentic AI sits between the model and the application and intervenes during execution, and you can also encode rollout policies once at the flag evaluation layer, so every agent change inherits them.

A kill switch does not replace infrastructure-layer sandboxing, which is one of the limits of a kill switch for AI. Who may use these controls is the next decision.

What to require for access control

This section covers who may approve, apply, or skip a change. None of the predefined roles carry change request permissions, so plan custom project roles first. Then check the rest of the access stack:

• RBAC with custom root and project roles
• SSO via SAML or OIDC, with MFA enforced by your identity provider
• SCIM provisioning
• Service accounts with scoped API tokens

The same roles control kill switch access, and the DORA documentation maps these controls to Article 9(4)(c) and RTS Articles 20 and 21.

Lloyds Banking Group, a UK bank serving 23 million digitally active customers, has 1,000+ users across 20 platforms managing features through the platform and achieving release cycles accelerated by 35% with compliance workflows retained. Hosting then decides which of these controls your team runs.

What to require for hosting, data, and third-party risk

This section covers where the platform runs, where data sits, and how you leave.

Where the control plane runs

Decide first between a hosted and a self-hosted platform. A hosted service is an ICT third-party service, so it brings due diligence, the register of information, contract terms, and exit planning, whereas a self-hosted deployment runs in your infrastructure and the operational controls are yours. A licensed, supported self-hosted deployment is still an ICT arrangement to assess and record.

A feature flag platform has three layers: the control plane, the SDKs, and a proxy or edge. It is self-hosted only when the control plane runs on infrastructure you operate. Ask each vendor for the list of layers it runs for you and the list of layers you run yourself. For example, Eika chose self-hosting to settle data regulation questions.

Do not stop at the scorecard when you reach contract terms. Collect the evidence your register of information and exit planning depend on: service locations, audit and access rights, subcontractors, and termination assistance. The DORA documentation lists service locations, audit and access rights, and termination assistance under Article 30, and subcontractors under Article 28(3).

Keeping user data local

With local flag evaluation, user attributes remain inside your infrastructure. Request the evaluation location and the list of attributes that leave your network. Enterprise Edge, which can be self-hosted or vendor-managed, serves evaluations from a cache close to your applications and keeps serving if the platform’s API is unavailable. Ask where your Edge runs, because that decides whether attributes leave your network. The DORA documentation lists that availability under Article 7.

Exit and concentration

Plan your exit before you sign. Unleash is open source under AGPLv3, configuration is exportable, and an OpenFeature provider option reduces SDK lock-in. The DORA documentation maps these to Article 28(8), which applies to ICT services that support critical or important functions.

The DORA documentation reports no critical ICT third-party provider designation for the vendor, but your team makes the determination on the platform’s support for a critical or important function. Then a scorecard can compress the checklist.

A short scorecard to take into a demo

Let’s turn the checklist into scores you can compare. Score each vendor from 0 to 2 on these questions, and ask for evidence behind every answer. The 0 to 2 scale is a buying device and is not a DORA standard.

1. Can you turn a feature off in seconds without a deployment?
2. Who approves a production change, and can approval be required per environment?
3. Would the audit trail satisfy a regulator, and can you export it to your SIEM?
4. Who controls the kill switch system itself, and which roles can use it?
5. Where does the control plane run, and where is user data held?
6. How do you export your configuration and leave?
7. Will the vendor take part in your threat-led penetration testing, and can you include the platform in your own testing program?

The platform’s limits

This section marks where the platform’s responsibility ends. Your risk and compliance partners own DORA’s detailed text, and they set the four-eyes review scope for flag changes. Unleash supplies controls and evidence for its own part of each obligation; its features map to and support requirements, while your own ICT risk management framework meets the rest.

Take your next step

To test a platform against this checklist, run change requests, the event log, and kill switches in your own environment. Book a demo of Unleash to try them firsthand.

FAQs

Does DORA apply to a feature flag platform?

Yes, as part of the ICT systems that support your business: the obligation sits with you, and the platform is covered through your ICT risk and third-party-risk work. DORA’s requirements apply, proportionately, to the ICT systems that support a financial entity’s business, and the DORA documentation lists the platform controlling application behavior in production among those systems. That is why a production feature flag change needs approval and a record.

Can responders turn off a feature during an incident?

They can, if you grant the skip change requests permission together with the permission to turn flags on or off. It covers environment-specific actions such as turning a flag off or updating its activation strategies, so responders contain the problem without waiting for approval. Grant it narrowly, because it does not cover archiving or deleting a flag, which still need a change request. In a demo, ask the vendor to show that action in the event log.

Should you choose hosted or self-hosted?

The choice changes which tasks sit with you and which with the vendor, and you stay responsible for compliance either way. A hosted service is an ICT third-party service, so it brings due diligence, the register of information, contract terms, and exit planning. A self-hosted deployment runs in your infrastructure, and the operational controls are yours, but a licensed, supported deployment is still an ICT arrangement to assess and record. A deployment is self-hosted only with a control plane on infrastructure you operate.

How long are logs retained, and can you export them?

Login history is kept for 14 days, so download it periodically if your retention policy requires longer. The event log is searchable in the Admin UI and the Events API, and you can export it as CSV or JSON to a SIEM. Ask every vendor for its retention terms in writing, and do not assume them.

Is the vendor a critical ICT third-party provider?

The DORA documentation reports no critical ICT third-party provider designation for the vendor, but your risk and compliance partners determine the platform’s support for a critical or important function in your organization.

Does local evaluation keep user data in your network?

It can. With local flag evaluation, user attributes remain inside your infrastructure, so request the evaluation location and the list of attributes that leave your network from each vendor. Enterprise Edge, which can be self-hosted or vendor-managed, also serves evaluations from a cache close to your applications and keeps serving if the platform’s API is unavailable. Ask where it runs.