Does a feature flag toggle need SOX change management controls?
A flag change can be a production change within the scope of internal control over financial reporting when it alters logic that affects financial figures. Consider a public company whose checkout, pricing, billing or period-close system is switched by flags: turning on a new discount calculation, changing a tax rule for a region or routing invoices through a different path is a change to financially relevant behavior, even though no code was deployed. For each such flag, the IT general control evidence should show who requested the change, who approved it, who made it in the flag platform and when it took effect. Whether a given toggle lands in scope depends on what it controls, so the first decision is an inventory of flags that touch ledgers, revenue, payments or reporting data, reviewed with the external auditor before the controls are designed.
No SEC rule or PCAOB standard publishes a catalog of IT general controls. Release 33-8810 names program development, program changes, computer operations and access to programs and data as example areas management might consider, and states that the relevant aspects vary with each company's facts and circumstances. Program changes and access to programs and data are the two areas where feature flags most often create gaps, because a flag can alter production behavior while sitting outside the normal deployment pipeline. Management should therefore map each in-scope flag to a change category, a named approver, the environments it can be changed in, and the roles allowed to edit it. Confirm with the external auditor how they expect that mapping to be documented, since the standards they apply expect them to understand the IT general controls important to automated controls.
A platform does not make a company compliant with Section 404, and no product can supply the judgment about which toggles matter. What a self-hosted flag platform can supply is configuration that makes the evidence reliable: role-based access, change requests with approval steps, and audit logs that record edits. Editions differ on these features, so before selecting a platform, check in the vendor's current documentation whether change requests, approval workflows and audit logs are included in the edition you plan to run, and whether the audit log is retained and exportable in a form the auditor can sample. Management should also confirm that the flag platform itself falls within the ITGC program, including who administers its database and servers, since those administrators could alter flag state outside the approval path.
Which ITGC change requirements a flag platform must support
This table maps the ICFR, COSO and PCAOB expectations, plus the program change and access areas named in Release 33-8810, to what a self-hosted flag platform must do and how to configure it. Read each row as a question to answer during platform selection and configuration. The main takeaway is that the approval gate, role separation and exported change history carry most of the evidence, and the edition you choose determines whether those controls exist at all.
| Requirement area | What the flag function must do | How to configure it and what to confirm |
|---|---|---|
| Management ICFR evaluation (Section 404, Rule 13a-15(c)) | Show that flag changes affecting financially relevant systems are inside the scope management evaluates each fiscal year | Document which flags and environments feed financial processes. Confirm the platform keeps a complete record of each toggle for the full evaluation period. |
| COSO Principle 11 (technology general controls) | Support general control activities over technology that match the flag function's role in the control environment | Write a flag change procedure that names owners, approvers and escalation. Map each step to a platform feature, such as change requests, and confirm it is available in your edition. |
| Program change area (Release 33-8810) | Require that every production toggle passes through an authorized, documented change | Enable change requests or an equivalent approval gate for production environments. Confirm whether the free self-hosted edition offers this or whether an Enterprise edition is needed. |
| Access to programs and data (Release 33-8810) | Limit who can create, edit, approve and promote flags in production | Set project and environment roles so requesters, approvers and deployers are different people. Confirm the platform supports custom roles and group-based access tied to your identity provider. |
| Segregation of duties | Prevent one person from requesting and approving the same production change | Configure approval rules that exclude the requester. Test the rule with a sample change before go-live and keep the test record. |
| Environment promotion rules | Ensure changes are tested in lower environments before reaching production | Export flag definitions between environments in JSON and promote only through the approved path. Confirm that segments and custom strategies exist in the target before import, since exports carry references only. |
| Audit trail for sampling (AS 2201, AS 2110 general controls over automated controls) | Retain who changed a flag, what changed, when, and who approved it, in a form an auditor can sample | Export change logs on a schedule to your evidence store. Confirm the log includes the before and after values, the approver and timestamps, and that it cannot be edited by administrators. |
How approval and segregation of duties work for flag changes
Five decisions decide whether flag changes stay inside an auditable change process: who may create flags, who approves production changes, who toggles, who authorizes emergency switches, and who approves cleanup. The requester and approver should be different people for each of them, and the resulting role model has to be configured and tested in the platform rather than assumed from the org chart.
Who may create a flag
Flag creation is the first point where a future production change is introduced, so it belongs in the access model. Decide which roles can create flags, which projects and environments they can see, and whether a new flag can be created in production without a request. Check whether the platform's role model lets you restrict creation separately from editing and toggling. Ask the implementation partner to document the role names and the exact permissions each one grants, then test them with non-admin accounts.
Who approves production changes
The approver must not be the person who requested the change. For any change to a flag that affects a financially relevant system, define the approval step as a separate role with its own membership list. Confirm whether the platform can require an approval before a change is applied, or whether approval exists only as a convention in a ticket. Where the platform does not enforce it, record the approval in your change system and reconcile it against the platform's change log at each review.
Who may deploy or toggle
Toggling a flag in production can change revenue, ledger or reporting behavior as much as a code deployment. Limit the toggle permission to named operators who are not also the approvers for the same change, and confirm that the platform records who toggled, when, and from which environment. Test the case where one person holds both the request and the toggle permission, and document whether your process blocks it or detects it afterward.
Emergency kill switch authorization
Operational kill switches often need to act faster than a standard approval cycle, which creates an exception auditors will sample. Define in advance who may switch off a flag in an incident, the conditions that justify it, and the deadline for recording the change in your change system. Then decide who reviews each emergency toggle afterward and how the review is evidenced. Ask the partner to show a drill in a non-production environment that produces both the platform entry and the review record.
Cleanup approval for stale flags
Removing a flag or retiring a rollout changes the code path and the behavior of production, even when it looks like housekeeping. Require an approval for flag removal in the same way as a toggle, with a named owner confirming the flag is no longer needed. Track stale flags with a regular review so that old flags do not accumulate outside any control. Confirm whether the platform's change requests or approval workflows cover archival and deletion, not only toggles.
Which edition provides change requests and logs
GrowthBook splits its controls between the free self-hosted Open Source plan and self-hosted Enterprise. The free plan covers the core flag and experiment functions, with unlimited users, 1 project and unlimited API requests. The controls an auditor usually asks about sit in the Enterprise tier, which the pricing page lists as adding features that the Open Source plan does not include. For a SOX scope, the question is whether the approval step that gates a production toggle is inside the edition you license.
- Approval workflows: The pricing page lists approval workflows as a self-hosted Enterprise feature. Confirm that approvals apply to production flag changes and that the approver cannot be the requester.
- SSO and SCIM: Self-hosted Enterprise adds SSO and SCIM, which tie approver and editor identities to the corporate directory and remove access when people leave.
- Advanced permissioning: Role controls beyond the free plan determine who can edit production environments. Map these roles to your segregation of duties matrix.
- Free self-hosted limits: The Open Source plan does not list approval workflows or advanced permissioning, so a production-facing SOX scope needs an Enterprise quote before go-live.
- Source licensing: GrowthBook's enterprise directories fall under the GrowthBook Enterprise License, while the rest of the code is MIT Expat licensed. Your legal team should confirm which directories your deployment uses.
Ask the vendor which events are written to the audit log, how long those entries are retained, and whether they can be exported to your own log store.
Unleash draws its line at scope rather than at approval alone. Unleash Open Source is limited to 1 project and 2 environments with basic roles, which typically leaves little room to separate development from production in a financial system. Unleash Enterprise adds unlimited projects and environments, single sign-on, SCIM provisioning, project and custom roles, user groups and change requests. The change request feature is the one most relevant to a SOX change path, because it can hold a proposed toggle until a reviewer approves it.
- Environment limits: The Open Source edition's 1 project and 2 environments limit how far you can separate a test path from a production path.
- Change requests: Enterprise includes change requests. Confirm that a request requires an approver other than the requester and that the approval is recorded.
- Project and custom roles: These let you restrict production editing to named groups, which supports segregation of duties.
- SCIM provisioning: Enterprise provisioning removes access when an employee leaves, which auditors often sample.
- Open Source licensing change: From v8.0.0, the main repository moved to AGPLv3, while the official open-source Docker images remain under Apache 2.0. Your legal team should review this before choosing a version.
Ask the vendor to show a sample audit log export for a production toggle and to confirm the retention period for that log in your deployment.
No Flagsmith edition details were supplied for this page, so this tab does not state Flagsmith's limits. Flagsmith is a common candidate in the same category, and it may offer approval, role, identity and audit features in a paid tier. Those features must be verified against Flagsmith's own documentation and current pricing before any SOX design depends on them. The comparison below is a checklist for that verification, not a claim about what Flagsmith provides.
- Change approval: Check whether production toggles can require a second approver and whether the approval record is kept.
- Audit log: Check which actions are logged, who can read the log, and how long entries are retained.
- Identity integration: Check support for SSO and SCIM, and whether provisioning removes access automatically.
- Role model: Check whether roles can be scoped to individual environments, so production editing is limited to named groups.
- Self-hosting scope: Check which of these controls exist in the self-hosted edition, not only in the managed cloud service.
Request written answers to each point from Flagsmith, and treat any answer you cannot find in its documentation as unconfirmed.
Edition feature sets, prices and log retention change over time, and the supplied facts reflect the pages as researched, not a commitment for your contract. Before you base a control on any edition, obtain the current feature list in writing and test the feature in a non-production instance. The audit trail question matters as much as the approval question, because an auditor tests evidence, not intent. A control that exists only in a sales deck will not satisfy a sample request.
- Feature confirmation: Ask for the current edition comparison in writing, dated to the quote.
- Audit log content: Confirm which fields are recorded for each toggle change, including the old and new values, the actor and the time.
- Log retention: Confirm the retention period and whether logs can be exported to your own store before the period ends.
- Test evidence: Run a sample change through approval and export the record to confirm it is complete.
- Support terms: Confirm how the vendor supports a change to edition scope after go-live.
Record the confirmed answers in your change management procedure, with the version of the platform and the date of confirmation.
Which audit trails auditors test and how to keep them
An auditor sampling a flag change will look for one connected record: the change request, the identity of the person who approved it, the time it was requested, approved and applied, the value before and after the change, and the business justification that explains why the change was made. If any link in that chain lives in a different place from the others, the sample has to be rebuilt by hand. Before the first audit, pick a few real toggles on financially relevant systems and trace each one from the justification to the production state. Where the trail breaks is where the control needs work.
Logs held in the platform database need a retention decision, an export path and protection against editing. Confirm with your vendor whether the audit log is append-only, who holds database administrator rights over it, how long entries persist by default, and whether the log can be exported in a form you can hand to an auditor without an engineer querying tables. Store exports in a location that the flag administrators cannot modify. Exporting JSON configuration snapshots, such as the flag definitions moved between environments with Unleash export and import, shows what state a flag was in at a point in time. It does not show who approved the change or why, so approval records belong in a system of record your audit team already tests, such as the ticketing or change management tool, with the flag change identifier cross-referenced in both places.
What evidence auditors ask for on flag changes
How do auditors test a sample of feature flag changes?
Auditors pick a sample of changes in the period under review and ask for the request, the approval, the change itself and the evidence that it reached production as approved. For a flag, that means the change record, the reviewer's sign-off dated before the toggle, and the audit entry showing who flipped it and when. On GrowthBook and Unleash, the Enterprise edition provides approval workflows and change requests that hold this record in the platform. On the open-source editions, that record usually has to come from your ticketing system, so the gap is a manual link between the ticket and the flag change.
What proves approval happened before a financial logic flag went live?
The strongest evidence is a system-enforced approval step that blocks the change until a second person approves it. GrowthBook Enterprise lists approval workflows among its self-hosted Enterprise features, and Unleash Enterprise lists change requests. If your edition lacks these, you need a documented procedure with a ticket reference in each flag's description and a periodic reconciliation of flag history against approved tickets. Confirm with the vendor exactly which approval states are logged and whether approvers can be the same person as the requester.
How do you show segregation of duties between flag authors and approvers?
Segregation means the person who designs or edits a flag cannot also approve and release it to production. Show this with role definitions that separate editors from approvers and with an access list for each environment. Unleash Enterprise offers project and custom roles, and GrowthBook Enterprise offers advanced permissioning. Auditors will check the role matrix against the actual user list, so any engineer holding both roles on the production environment needs a documented compensating control.
What access review evidence should exist for flag administrators?
Auditors usually ask for periodic reviews of who holds administrator and production-editing rights on the flag platform, signed by a manager who did not grant the access. Export the user and role list from the platform, compare it with the identity provider, and record removals. Single sign-on and SCIM provisioning, which Unleash Enterprise and GrowthBook Enterprise both list, keep this list aligned with the directory. Without them, the review is a manual export and reconciliation, and the gap is that leavers can keep access until someone removes them.
How do you demonstrate that emergency toggles were reviewed afterward?
Emergency toggles, such as kill switches used during an incident, are changes that skip normal approval, so auditors look for a retrospective review. Keep the incident ticket, the toggle timestamp and actor from the flag audit log, and a post-incident sign-off that confirms the change was appropriate and whether it should be reverted or formalized. The flag platform records the toggle, but it cannot judge the reason. If your edition does not enforce approvals, the emergency path is where the gap is widest, so define it in writing before the first use.
Which audit log fields do auditors expect a flag platform to record?
Auditors expect each entry to show the flag, the environment, the old and new values or rules, the user, the timestamp and the change reason or linked ticket. Confirm that the log cannot be edited by flag administrators and that it is retained for the full period auditors sample. Test this yourself before the audit by making a harmless change in a non-production environment and checking that every field appears. Because the open-source editions have limited history features, verify the log in your own version rather than relying on the feature list.
Can DeployOpen prepare the flag change evidence for our ITGC testing?
DeployOpen can configure the self-hosted platform, document the change procedure, set up role definitions and export evidence for the controls you choose to test, under a written, fixed scope. It does not issue audit reports or attestations, and independent auditors decide whether your controls are effective. Expect the scope to depend on which edition you run and which flags touch financially relevant systems. Ask for the evidence list as part of the written scope before work starts.
What does it cost to meet these evidence needs, and what recurs?
Cost has three parts: the platform edition, the implementation and documentation work, and the internal time to run access reviews and change reconciliation. The GrowthBook pricing page lists self-hosted Enterprise features, and the Unleash pricing page lists Pay-As-You-Go at $75 per seat per month with a 5-seat minimum for self-hosted, so edition choice drives the recurring subscription. Implementation is one-time. Access reviews and evidence exports recur each audit period. Ask any quote to separate these lines and state which controls it covers.
Evidence auditors request and the component that produces it
This table lists the change evidence auditors typically sample for a flag change on a financially relevant system, the component that produces each item, and who should own its retention. Read it as a checklist to confirm with your auditor before the first testing cycle. The main takeaway is that the flag platform log alone rarely answers the approval and identity questions, so the change request, identity and pipeline records must be retained alongside it.
| Evidence item | Producing component | Retention owner |
|---|---|---|
| Flag toggle history with actor, timestamp and old and new values | Flag platform audit log (confirm the edition and retention setting) | Platform owner, with IT compliance |
| Approval record showing a second person approved the change before it went live | Change request record in the flag platform (Enterprise editions) or ticketing system | Change management owner |
| Evidence that the approver was not the requester | Change request record and SSO and SCIM identity records showing role assignments | Identity and access team |
| Joiner, mover and leaver records for users with toggle rights | SSO and SCIM identity records, mapped to the flag platform roles | Identity and access team, with HR |
| Link from each flag change to a ticket with business justification | Ticketing system, referenced in the change request | Change management owner |
| Deployment record showing code and configuration released through the pipeline | CI pipeline record, linked to the flag key and change ID | Engineering release manager |
| Pre and post change metrics showing the impact of a financial rule change | Warehouse export or query output stored with the change ticket | Data or finance systems owner |
| Periodic access review of users with production toggle rights | Flag platform role export, reviewed against identity records | Control owner for access reviews |
What the flag platform alone does not satisfy
A flag platform records toggles, but an auditor tests the whole control environment around them. The gaps below sit outside the tool itself, and each one needs a named owner, a written procedure and retained evidence before the first assessment period begins. DeployOpen prepares these controls and evidence for review; independent auditors issue the opinion.
Documented scope decision
Management must decide which systems, flags and environments fall within ICFR and document why. SEC Release 33-8810 says the relevant IT general control areas vary with each company's facts and circumstances, so no tool can make this call. Write the scoping memo, name the financially relevant applications it covers, and tie each flag namespace to a process or account it could affect. Re-approve the memo when new flags are added to in-scope systems.
Emergency change policy
Kill switches exist to change production behavior in seconds, which is exactly why an emergency toggle can bypass the normal approval path. Define who may flip a flag during an incident, the conditions that qualify, and the deadline for retrospective approval. Confirm whether your edition's change requests can be created after the toggle, and if not, require a ticket reference in the incident record before the next business day.
Periodic access reviews outside the tool
Role assignments in the flag platform are only one population. Review who holds administrative rights to the flag server, the database that stores its state, the CI pipeline tokens and the SSO group mappings that grant flag editing. Compare each list against HR records for leavers and transfers. Keep the reviewer's sign-off and the exception log, because an auditor will sample the review itself, not only the access it covered.
Reconciliation to the system of record
A flag can show a state in the dashboard that differs from the behavior users see, particularly after an import, a cache refresh or an environment copy. Schedule a comparison between the flag configuration export and the change tickets approved for it, and investigate any difference. For Unleash, environment exports carry flag configuration as JSON, but segments and custom strategies travel only as references and must exist in the target first, so verify those dependencies in every reconciliation.
SDK defaults that change behavior
A flag's fallback value lives in application code and in SDK configuration, and a change there can alter financial logic without any logged toggle. Inventory every hardcoded default, offline value and cache setting, then bring those values into the same change control as the flag itself. Review them whenever an SDK version or caching layer changes, since a new library default can take effect without any approval record.
Ownership of evidence
Auditors ask for evidence that a control operated during the period, and they expect it to come from a source the company controls. Assign an owner for each evidence type, such as the approval record, the audit log export, the access review and the reconciliation result, and define where each is stored and for how long. Confirm the audit log retention set by your hosting configuration and whether logs can be altered by platform administrators.
How to sequence the controls before the first audit
This sequence moves from agreeing scope with the auditor to a walked-through sample change, so the flag controls are designed, tested and evidenced before anyone sits down with the auditor for a walkthrough. Each step closes with a named output that the next step depends on.
Agree scope with the external auditor
Before configuring anything, meet the external auditor and agree which systems, flags and change types fall inside the ICFR evaluation. Management should document why each in-scope item affects financial reporting, since SEC guidance in Release 33-8810 says IT general controls are assessed only where they support other controls that address financial reporting risks. The output is a written scope memo signed off by the control owner and the audit lead, and it defines what the rest of the sequence must cover.
Classify flags by financial relevance
Using the agreed scope, the finance systems owner and the application owner tag every flag that can alter a financially relevant system, such as pricing, billing, revenue recognition, payment routing or ledger interfaces. Flags that only change layout, copy or operational settings are recorded as out of scope with a reason. The output is a flag register with a relevance field, an owner and a list of the environments where each flag can change behavior.
Select the edition and configure roles and environments
Confirm which edition provides the features the register requires, such as change requests, approval workflows, SSO, SCIM and custom roles, because the free editions of GrowthBook and Unleash do not include all of them. Then create roles that separate who requests a change, who approves it and who can toggle it in production, and map each role to a separate environment. The output is a role matrix and an environment map reviewed against the scope memo, with each vendor's current edition documentation attached as evidence.
Wire change requests into the ticketing process
Connect every production flag change to a ticket in the organization's existing change management system, so the flag request, the approval and the implementation share one identifier. Decide which changes need a change request in the platform and which are pre-approved standard changes, and write that rule down. The output is a documented workflow in which no financially relevant toggle can run without a linked ticket and a recorded approver, and this link is checked during testing.
Test a sample change end to end
Run one representative change through the full path: request, approval by someone other than the requester, production toggle, and rollback. Include a change that should be rejected to confirm the approval gate works. Pull the audit log entries for each step and check that the timestamp, actor, before and after state and linked ticket are all present. The output is a dated test record that shows the control operated as designed, with any gaps logged and fixed before the walkthrough.
Collect evidence for the walkthrough
Assemble the artifacts an auditor will ask to see: the signed scope memo, the flag register, the role matrix, the workflow document, the sample test record, exported audit logs and access review results for the platform. Confirm that log retention and export work as the documentation says. The output is an evidence folder indexed to each control, so the team can walk the auditor through one change from request to log entry without searching for records.
Questions controllers and IT leaders ask before scoping SOX flag controls
What drives the cost of SOX change management for feature flags?
The main drivers are the edition you need, the number of flags in scope, the integrations that feed approvals and logs, and how much evidence design the auditors expect. Edition matters most: the Unleash OSS vs Enterprise comparison lists change requests, SSO, SCIM and project roles as Enterprise features, and GrowthBook's pricing page places approval workflows and advanced permissioning in self-hosted Enterprise, not the free Open Source plan. Confirm current edition terms with each vendor before you size the work. Cost splits into licences, infrastructure, implementation by a partner or internal staff, and recurring operation, testing and evidence collection. Ask any partner for a fixed-scope quote that lists the flags, environments and systems covered, the integrations in scope and the evidence deliverables.
Can our team set up flag change controls without outside help?
Often yes, if you have engineers who can run the platform and a clear owner for the control design. The harder work is usually not the software but deciding which toggles count as production changes, who approves them, how segregation of duties is enforced and which logs prove each step. Internal teams tend to struggle with two items: keeping evidence consistent across dozens of services and testing the controls before the auditors do. An implementation partner can carry the build and documentation, while your staff keeps ownership of the control decisions. Whichever route you take, the control design should be written down and owned internally.
Which teams must be involved in a SOX flag change project?
Three groups need to be involved from the start. Finance and the controller define which systems and processes affect financial reporting, because SEC Release 33-8810 says management evaluates only the IT general controls necessary for the proper operation of controls that address financial reporting risks. IT and platform engineering own the platform, the deployment path and the access model. Internal audit reviews the control design and tests whether it works before the external auditor relies on it. Security or identity teams often own role assignments and access reviews. Agree on these owners in writing at the start, since a missing approver in one of these groups is a common cause of rework.
How long does a SOX flag change control project take?
Duration depends on the fixed scope, not on a generic estimate. The main variables are the number of flag-controlled systems in scope, whether you need a new platform or a migration from an existing vendor, the number of approval and integration points, and how much historical evidence must be reconstructed. Most engagements are fixed-scope, so the scope, deliverables and timeline are agreed in writing before work begins. Ask for a plan that separates design, build, a parallel run where controls operate but are not yet relied on, and evidence sampling, since that is where audit readiness is usually proven. Ask the partner to show which milestones depend on your teams.
Does a self-hosted flag platform change how the audit works?
Self-hosting does not change the auditor's standard. Under the SEC's guidance, management evaluates whether the controls operate, and the auditor tests them under PCAOB AS 2201 and AS 2110. What self-hosting changes is who controls the evidence. Logs, change records and access reviews sit in your environment, so you must show that they are complete, retained and protected from unauthorized change. The auditor will ask how you know the logs are complete, which is a design question for your infrastructure. Confirm with your auditor which evidence sources they accept before you decide where logs are stored and retained.
Which flag changes are in scope for SOX ITGC testing?
Start from financial reporting risk, not from the flag tool. A flag change is in scope when it can alter how a financially relevant process, calculation or data flow behaves, such as pricing logic, revenue recognition, payment routing or reconciliation jobs. Changes to purely cosmetic or experimental features usually fall outside the scope, though you should document why. Management must decide this for each system, and the decision should be recorded. Ask your auditor to review the scoping memo before you build controls around the wrong population.
What should we check in a partner's proposal before signing?
Check that the proposal names the edition and licence obligations, the hosting model, the systems and flags in scope, and the evidence the partner will produce. Ask who approves the control design and who signs off the testing. Confirm that the partner prepares controls and evidence for assessment but does not issue audit reports or attestations, since independent auditors do that. Ask how support continues after go-live and whether ongoing testing or upgrades are covered by a separate retainer. DeployOpen plans, implements and documents self-hosted platforms in your own infrastructure and prepares evidence for assessments, and its engagements are fixed-scope with written scope, deliverables and timelines.
Does the SEC's 2020 estimate of audit savings apply to our flag controls?
Only in a limited way. The SEC estimated in 2020 that an issuer newly exempt from the Section 404(b) auditor attestation would save about $210,000 per year on average, roughly $110,000 in audit fees and $100,000 in other costs (Release 34-88365). That estimate concerns the auditor attestation requirement for smaller issuers, not the cost of building flag controls. Whether your company is subject to the attestation depends on its filer status, so confirm that status with your counsel and auditor before using the figure in a budget.
How DeployOpen scopes flag change controls for SOX
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source feature flag platforms inside the client's own infrastructure. For SOX IT general controls, the work starts with agreeing which flag changes count as production changes, then builds approval, access and logging controls and the evidence an auditor will test.
How we scope
- Agree in writing which flag environments, projects and flag types fall inside the change management scope
- Map each flag change class to the financially relevant systems it can affect, with the business owner named
- Confirm which platform edition supplies change requests, approvals, roles and audit logs before design starts
- Record the fixed deliverables, timelines and exclusions in the written scope before any work begins
How we build
- Configure role-based access so flag creators, approvers and production deployers hold separate permissions
- Set up approval workflows for production flag changes, with the approver recorded against each change
- Harden the self-hosted deployment and export audit logs to retention storage that the client controls
- Test the controls with sample changes to confirm the approval and logging behave as the design describes
How we hand over
- Document the change procedure, role matrix, approval rules and evidence locations for the client's control owners
- Provide runbooks for emergency kill switches, including who may use them and how each use is recorded
- Prepare an evidence pack that shows where auditors can find change records, approvals and access reviews
- Deliver knowledge transfer so the client's own staff can operate and explain the controls
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after go-live
- Review control changes whenever the platform is upgraded or the scope of financially relevant flags changes
- Keep the evidence process current with periodic checks that approvals and logs still operate as documented
- Coordinate with the client's internal audit and external auditors on requests for control documentation
