<p>It depends on how you're managing your feature flags. Ideally, you're using a flagging system that allows you to target specific users or segments of users so that an untested feature isn't inadvertently enabled for all your users. Some feature management systems (like LaunchDarkly) allow you to target users any way you want.</p>

<p>For example, a common workflow (for teams who use feature flags) is to release a new feature under a flag that's only turned on for the product team that's working on that feature. So, even if the feature hasn't been tested, it's guaranteed that only the right users have access to that new feature.</p>

<p>This allows your product team to continue to work on the feature and test it in production (if that's appropriate). Of course, a full set of tests should cover that feature before it's released, but it's nice that product teams have a way to iterate quickly without the hangups of a process that didn't involve feature flags.</p>

CC BY-SA 4.0
2019-10-21T21:34:39.470Z
"So, even if the feature hasn't been tested, it's guaranteed that only the right users have access to that new feature."  But if the toggle is changed, the "wrong" users might now have access to untested code, which I believe is a SOX violation.  This is the whole point of feature toggles, to toggle who might have access. Thoughts?
Patrick Szalapski
CC BY-SA 4.0
2019-10-21T21:35:33.783Z
Maybe you are proposing that the feature toggles be untoggleable for ordinary users, and only be toggleable for testers, until the feature has been fully tested?
Patrick Szalapski
CC BY-SA 4.0
2019-10-21T23:45:08.740Z
"Maybe you are proposing that the feature toggles be untoggleable for ordinary users, and only be toggleable for testers, until the feature has been fully tested?" Yes. I'm only familiar with LaunchDarkly since that's the feature management system I've used, but in LD, you can specify who to target in the flag config. So, when you turn the flag on, it's only going to target the segment of users specified in the config. You'd have to manually change those targeting rules to change that.
manalang
CC BY-SA 4.0
2019-10-22T02:44:48.140Z
Okay, great.  But the question remains that *someone* can toggle on the feature for some or all real users, and the feature toggled on will not have gone through the same SOX gate that the deployment did with the toggle off  Are you saying that whenever a toggle changes for real users, the same SOX controls have to be in place as in a deployment?
Patrick Szalapski
CC BY-SA 4.0
2019-10-22T04:19:56.953Z
In the case of LaunchDarkly, every change to a flag is audited and can be traced to the user who made the change. Also, changes to different environments (like production) can be locked down with a role/policy. So, for example, you can be permissive about flag changes in staging, but not in prod. It's pretty adaptable to any process you want to comply with.
manalang
CC BY-SA 4.0
2019-10-21T21:25:11.013Z
2019-10-21T21:30:22.403Z
2019-10-21T21:30:22.403Z
manalang
<p>Feature toggles (or feature flags) enable me to deploy unfinished features without comprehensive manual testing of features toggled off. We can toggle the feature on for certain users, try it out, and then choose to toggle it off or on for all users. This enables more frequent integration as suggested by version control strategies such as Trunk-Based Development, and more frequent deployment of the trunk (master) branch into user's hands.</p>

<p>Sarbanes-Oxley rules require that all features that are in user's hands be fully tested.</p>

<p>So if I have a SOX-compliant system, how do I proceed with using feature toggles without having to do full manual testing of the feature toggled ON? It makes sense to do regression testing with the feature toggled OFF, but the most common need is to integrate and deploy good code but not incur the manual testing cost of the "on" state for a feature toggled off by default.</p>

<p><strong>So any suggestions on ways to have Sox-compliant feature toggles without comprehensive manual testing of the toggled-off feature on every release?</strong></p>

<continuous-deployment><feature-toggles><feature-flags>
How to use feature toggles and frequent deployment under SOX compliance?
Patrick Szalapski
# How to use feature toggles and frequent deployment under SOX compliance?

(Asked by: username_0 on 2019-10-21)

Feature toggles (or feature flags) enable me to deploy unfinished features without comprehensive manual testing of features toggled off. We can toggle the feature on for certain users, try it out, and then choose to toggle it off or on for all users. This enables more frequent integration as suggested by version control strategies such as Trunk-Based Development, and more frequent deployment of the trunk (master) branch into user's hands.

Sarbanes-Oxley rules require that all features that are in user's hands be fully tested.

So if I have a SOX-compliant system, how do I proceed with using feature toggles without having to do full manual testing of the feature toggled ON? It makes sense to do regression testing with the feature toggled OFF, but the most common need is to integrate and deploy good code but not incur the manual testing cost of the "on" state for a feature toggled off by default.

**So any suggestions on ways to have Sox-compliant feature toggles without comprehensive manual testing of the toggled-off feature on every release?**

**Tags:** continuous-deployment, feature-toggles, feature-flags


---

## 1 answers

### Answer by username_1 on 2019-10-21. Score: 1

It depends on how you're managing your feature flags. Ideally, you're using a flagging system that allows you to target specific users or segments of users so that an untested feature isn't inadvertently enabled for all your users. Some feature management systems (like LaunchDarkly) allow you to target users any way you want.

For example, a common workflow (for teams who use feature flags) is to release a new feature under a flag that's only turned on for the product team that's working on that feature. So, even if the feature hasn't been tested, it's guaranteed that only the right users have access to that new feature.

This allows your product team to continue to work on the feature and test it in production (if that's appropriate). Of course, a full set of tests should cover that feature before it's released, but it's nice that product teams have a way to iterate quickly without the hangups of a process that didn't involve feature flags.

> **Comments:**
> **username_0**: "So, even if the feature hasn't been tested, it's guaranteed that only the right users have access to that new feature."  But if the toggle is changed, the "wrong" users might now have access to untested code, which I believe is a SOX violation.  This is the whole point of feature toggles, to toggle who might have access. Thoughts?  
> **username_0**: Maybe you are proposing that the feature toggles be untoggleable for ordinary users, and only be toggleable for testers, until the feature has been fully tested?  
> **username_1**: "Maybe you are proposing that the feature toggles be untoggleable for ordinary users, and only be toggleable for testers, until the feature has been fully tested?" Yes. I'm only familiar with LaunchDarkly since that's the feature management system I've used, but in LD, you can specify who to target in the flag config. So, when you turn the flag on, it's only going to target the segment of users specified in the config. You'd have to manually change those targeting rules to change that.  
> **username_0**: Okay, great.  But the question remains that *someone* can toggle on the feature for some or all real users, and the feature toggled on will not have gone through the same SOX gate that the deployment did with the toggle off  Are you saying that whenever a toggle changes for real users, the same SOX controls have to be in place as in a deployment?  
> **username_1**: In the case of LaunchDarkly, every change to a flag is audited and can be traced to the user who made the change. Also, changes to different environments (like production) can be locked down with a role/policy. So, for example, you can be permissive about flag changes in staging, but not in prod. It's pretty adaptable to any process you want to comply with.  

---

