Feature Flag Management & Progressive Delivery3 min readUpdated September 2026

A Federal Contractor's Runbook for Feature Flag Adoption

A federal or defense contractor's software sits inside an authorization boundary that most commercial SaaS teams never have to think about, and that boundary changes the first question when adopting any new tool, including a feature flag platform: not which one is better, but which one you can even deploy inside your environment at all.

Here's a runbook for working through that, in order.

None of this is a knock on either vendor specifically; it's a reminder that a compliance boundary changes which questions matter most, ahead of any feature comparison.

None of this should be read as a knock on cloud-based flag platforms generally. Plenty of contractor programs run entirely in commercial cloud environments where this is a straightforward question with a straightforward answer; the point is simply to ask it explicitly rather than assuming a commercial SaaS tool's general reputation tells you anything about your specific program's requirements.

Vendors Covered in this Article

Disclosure: We may earn a commission if you buy through some links on this page. It doesn't change what we recommend.

Step 1: confirm the authorization boundary question before comparing features

Before evaluating LaunchDarkly or Split on capability, confirm directly with each vendor what authorization or compliance status their platform currently holds, and whether it covers the specific environment your system operates in, GovCloud, an air-gapped network, or a standard commercial cloud. Don't assume either vendor's marketing claims about compliance apply to your specific authorization boundary; get it in writing from the vendor for your exact deployment scenario.

Step 2: work out what data the SDK actually sends outside your boundary

A flag SDK typically calls out to the vendor's service to fetch targeting rules and report flag evaluations, and for a system handling controlled unclassified information, that outbound call itself may need review. Ask each vendor for their data flow diagram and confirm what leaves your boundary, even metadata, before integrating either platform into a system that touches CUI.

Questions to put to each vendor:

  • Ask each vendor for its data flow diagram showing what the SDK sends to its service.
  • Confirm what leaves your authorization boundary, including flag evaluations reported back to the vendor.
  • Check whether that outbound call needs review, especially for a system handling controlled unclassified information.
  • Record the answers in writing so you can show them to whoever manages your ATO process.

Step 3: build the recovery story into your change-control documentation

Recovery time after a failed deployment varies widely across engineering organizations, from under an hour for the fastest-shipping teams to weeks for the slowest1. For a contractor, that recovery time isn't just an internal metric, it's something your change-control documentation and possibly an ATO review will ask about directly. A flag-based rollback that doesn't require a new deployment is worth documenting explicitly as your fastest recovery path, separate from your standard deployment rollback procedure.

Step 4: decide what still needs a human approval chain, not just a platform feature

Even if a platform supports approval workflows, confirm those workflows actually satisfy your program's specific change-control requirements rather than assuming a generic feature checks the box. Walk your actual approval chain, who has to sign off on a production change and why, against what the platform can enforce, and document any gap you'll need to cover with a manual process alongside the tool.

What changes if your program later needs to move environments

A program that starts in a standard commercial cloud environment and later needs to move to a higher-compliance environment, GovCloud or an air-gapped network, may find that its flag platform choice doesn't travel with it, since not every deployment option is available in every environment. Ask each vendor directly about migration paths between environments before committing, especially if your program's classification or compliance requirements are expected to change over its lifecycle.

Why a smaller, better-documented rollout beats a faster, undocumented one

In a commercial SaaS context, shipping fast is usually the goal worth optimizing for. In a government contracting context, a slower rollout with a complete, reviewable paper trail is often the better trade, since an examiner or auditor's confidence in your process matters as much as how quickly a feature reached production. Weigh both platforms on how easily they produce that paper trail, not just on how fast they let you ship.

What to do while waiting on a vendor's compliance answer

If a vendor can't quickly confirm their platform's compliance status for your specific environment, that delay itself is useful information about how prepared they are to work with contractors like yours. Give yourself a firm deadline for getting a written answer before committing engineering time to an integration, and have a fallback plan, a simpler homegrown flag mechanism, ready in case neither vendor's answer satisfies your program's requirements in time.

Why a paper trail from day one beats reconstructing one later

A program that waits until an ATO review is imminent to start documenting its flag change-control process will find that reconstructing months of history from memory or scattered tickets is far harder than it would have been to log contemporaneously. Start the documentation habit with your very first flag, even before a review is scheduled, since a thin but complete record from the start beats a thorough one assembled under deadline pressure later.

Executive Capability Standard

What Good Looks Like

A contractor can produce, on request, a data flow diagram showing exactly what a flag platform's SDK sends outside the authorization boundary, and a written recovery procedure that doesn't depend on a new deployment.

Building The Capability (5-Stage Skill Ladder)

1. Learn:Confirm the authorization boundary and compliance status of any flag platform under consideration, in writing, for your specific environment.
2. Do Manually:Document your current manual change-control and rollback process before adopting any new tool, as a baseline to compare against.
3. Delegate:Assign your ISSO or equivalent compliance role to review the platform's data flow before any integration begins.
4. Automate:Integrate LaunchDarkly or Split only within the environment the vendor has confirmed and documented support for.
5. Buy:Fold flag-based rollback into your program's standard change-control and ATO documentation as a named recovery path.

How to Get Started

Disclosure: We may earn a commission if you buy through some links on this page. It doesn't change what we recommend.

Frequently Asked Questions

Can we use LaunchDarkly or Split inside an air-gapped environment?

This depends entirely on the specific deployment and needs to be confirmed directly with the vendor for your program's exact requirements. Don't rely on general marketing claims; ask for documentation specific to air-gapped or restricted-network deployment before assuming either platform will work in your environment.

Does using a commercial flag platform create a new item for our ATO review?

Potentially, since it's a new external service with a data flow crossing your authorization boundary. Raise it with whoever manages your ATO process early, before integration, rather than after the platform is already wired into a system under review.

What should we do while waiting on a vendor's compliance answer?

Set a firm deadline for a written answer before committing engineering time. A vendor that can't quickly confirm its compliance status for your specific environment is telling you something about how prepared it is to work with contractors, so treat the delay as useful information in the evaluation.

Sources

Where we quote a benchmark, we show its source. Other figures in this guide are estimates or general guidance, so check them against your own numbers.

  1. Failed deployment recovery time by DORA performance cluster (upper bound, days). DORA Accelerate State of DevOps 2024 (Google Cloud), cluster table via Octopus Deploy analysis, 2024.

Related Guides