CQ-10 Tech Due Diligence

Tech Due Diligence CQ-10: Feature Flag and Release Management

What This Control Requires

The assessor evaluates the organisation's approach to feature management, progressive rollouts, and release coordination, including the use of feature flags, canary deployments, and the ability to quickly disable problematic features in production.

In Plain Language

The best engineering teams decouple deployment from release. They can push code to production without immediately exposing new features to every user. Feature flags, canary releases, and progressive rollouts are how they do it - and their presence tells assessors that the team ships confidently while managing risk.

Assessors want to see whether you use feature flags to control feature visibility, whether new features can be rolled out gradually (by percentage, geography, or user segment), whether a problematic feature can be switched off without a full redeployment, and whether there is a clear release management process behind feature launches.

Being able to kill a broken feature via a flag in seconds, rather than waiting for an emergency rollback deployment that takes minutes or longer, is a powerful risk mitigation tool. It shrinks the blast radius of any bug or performance regression to zero almost instantly. That capability makes frequent deployments far less risky.

How to Implement

Set up a feature flag system using a third-party service (LaunchDarkly, Unleash, Flagsmith) or build your own. It should support boolean flags, percentage-based rollouts, user-segment targeting (specific users, organisations, or tiers), and environment-specific configurations.

Define a clear flag lifecycle. Flags get created when a feature enters development, configured for gradual rollout during release, progressively increased to 100% as confidence builds, and cleaned up from the code once the feature is stable. Stale flags that linger indefinitely add complexity, so track flag age and enforce cleanup deadlines.

Use canary or blue-green deployments for infrastructure changes. Route a small percentage of traffic to the new version first, monitor for errors or performance issues, and increase traffic gradually. Automate rollback if health metrics drop.

Separate the concepts of deployment and release. Not every deployment is a release. Define how features get flagged for launch, who approves rollout increases, which metrics are watched during rollout, what criteria trigger a rollback, and how releases are communicated internally and externally.

Keep an eye on performance. Feature flag evaluation should be sub-millisecond and not introduce user-facing latency. Cache evaluations where appropriate and implement graceful fallback if the flag service goes down.

Maintain a dashboard of all active flags with their purpose, current state, and owners. This gives the team and assessors visibility into what is in rollout and at what exposure level.

Audit flag changes. Since flags control production behaviour, every change should be logged with who made it, when, and why. For critical features, require approval before flag changes go live.

Evidence Your Auditor Will Request

Feature flag system implementation and configuration
Feature flag inventory with lifecycle tracking
Evidence of progressive rollouts for recent features
Canary or blue-green deployment configuration
Feature flag change audit logs

Common Mistakes

No feature flag system; all features are immediately exposed upon deployment
Feature flags exist but are never cleaned up, creating dead code and complexity
No canary or gradual rollout mechanism; deployments are all-or-nothing
Feature flags lack audit trails; unclear who changed what and when
Flag evaluation adds significant latency to request processing

Related Controls Across Frameworks

Framework	Control ID	Relationship
ISO 27001	A.8.25	Related

Frequently Asked Questions

Is a feature flag system essential for every company?

For an early-stage startup with a small codebase, a simple config-based approach can work. But as the team and product grow, a proper feature flag system pays for itself quickly. In due diligence, the absence of feature flags in a mature product is a notable gap.

How should we handle flag cleanup?

Set a maximum flag lifespan - say 90 days after full rollout - and automate reminders. Assign cleanup to the team that created the flag. Track the number of active flags as a metric and set an alert if it gets too high. Flag cleanup is technical debt, and deferring it indefinitely makes the codebase harder to work with.

Track Tech Due Diligence compliance in one place

AuditFront helps you manage every Tech Due Diligence control, collect evidence, and stay audit-ready.

Start Free Assessment