Feature flags and SOC 2 change management

Auditors sample the change tickets that authorize production flag changes and check that each sampled flag change traces back to an approved request. The flag platform does not create these tickets, your issue tracker or ITSM system does. Under the AICPA's 2017 Trust Services Criteria, change management sits in the CC8 series, so the ticket is the first record to match. Require every production toggle, targeting edit and rollout change to reference a ticket ID, and record that ID in the flag change comment or description field so the platform and tracker can be cross-checked. Export tickets with requester, approver, status history, timestamps and linked change. Confirm with your auditor which change population they will select from and how they define a production change for flags.

The approval record shows who reviewed a specific flag change, when they approved it, and what they approved. On self-hosted GrowthBook, the approval workflows that gate changes are listed on its pricing page as part of the self-hosted Enterprise edition, not the free Open Source plan. On self-hosted Unleash, change requests are listed as an Enterprise feature in its OSS comparison. If you run an edition without native approvals, the approval evidence sits in your ticket workflow, and the auditor will expect the approver in that ticket to match the person who made the change. Export the approval history with approver identity, timestamp and the change under review. Confirm in writing which approval features your chosen edition includes before you design the control.

An access review export is a list of every account with access to the flag platform, the role each account holds, and the projects or environments that role covers, reviewed by an owner at the cadence your policy sets. Identity should come from your identity provider through SSO and SCIM provisioning, so that leavers are removed centrally. Both GrowthBook and Unleash list SSO and SCIM in their Enterprise editions, so confirm that your chosen tier includes them before you rely on them. Export the user list, role assignments and last-login data if the platform records it, then have the reviewer sign off each row with the decision taken. Keep the signed review alongside the export. Confirm with the platform vendor which fields the export actually contains.

Role assignment history shows who granted, changed or removed a role, when it happened and who authorized it. A platform usually shows current roles only, so the history has to come from logs, the identity provider or your ticket trail. On Unleash Open Source, roles are basic and the instance is limited to 1 project and 2 environments, so the role model is simple to export. Unleash Enterprise adds project and custom roles, user groups and SCIM, and GrowthBook's self-hosted Enterprise edition adds advanced permissioning. More granular roles produce more assignments to test. Export role snapshots on a schedule, keep the change records that authorized each assignment, and confirm with the vendor whether role changes are written to the audit log and in what detail.

Promotion records show that a flag configuration tested in a lower environment was moved to production under an approved change. Unleash's import and export moves flag configurations as JSON between environments or between instances, so the exported file is the core artifact. Segments and custom strategies are exported only as references, which means they must exist in the target before the import, and the auditor will ask how that dependency was checked. Retain the exported JSON, its source and target, the ticket it served, the person who ran the import and the time it ran. GrowthBook's promotion behavior depends on your setup and version, so confirm how it records cross-environment moves before you write the procedure. Store exports in controlled storage with restricted write access.

Flag change history should record each change, the flag, the environment, the previous and new values, the targeting rules and rollout percentages, the actor and the timestamp. This is the record an auditor uses to test whether a sampled change matches its ticket. Ask each vendor which fields its audit log captures for flags, segments and environments, and whether that log is available in the edition you choose. Where the log is limited, the database becomes the source of record: GrowthBook stores metadata in MongoDB or a compatible database, and Unleash uses PostgreSQL 15 or later. Exporting directly from the database is possible, but it needs a tested query, a documented schema and a note of who ran it. Test the export against a sample change before the audit period starts.

Retention is set by your policy and by the examination period, not by a period this page can state. For a SOC 2 Type 2 report, the auditor tests operating effectiveness over a period, so logs must cover that whole period, and gaps in the record will show up as exceptions. Ship flag platform logs, identity logs and export files to a central log store with write protection and restricted access, so that the platform team cannot alter the evidence it produces. Define the retention period in writing, apply it to the log store and the export archive, and confirm the required length with your auditor before you finalize it. Test a restore of one archived export so you know the evidence is readable when it is requested.

Your team can produce this evidence if it owns the ticket workflow, the identity provider, the platform configuration and the log store. DeployOpen plans, implements, configures, documents and supports self-hosted open-source platforms in your own infrastructure, and it prepares systems, controls and evidence for compliance assessments. It does not issue audit reports or attestations, and independent auditors make that determination. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope. The effort depends on the number of environments, the edition you select, how many approval paths you need and how much evidence automation you build. Ask DeployOpen to define which evidence it will produce, which evidence your team keeps, and who signs each record.

The main drivers are the edition you run, the number of environments and projects, how many systems the flag changes must be linked to, and how mature your existing SOC 2 program already is. Self-hosted Unleash Open Source is limited to 1 project and 2 environments, and GrowthBook's self-hosted Open Source plan has 1 project, while the Enterprise editions add the approval, role and change request features that most change management criteria depend on. Each additional environment, integration to a ticketing system and identity provider adds configuration, testing and documentation work. Costs fall into two groups: a one-time build of roles, approval paths, logging and evidence procedures, and recurring work to keep them running, such as access reviews and version upgrades. Ask any partner for a written scope that lists editions, environments, integrations and evidence deliverables, then a quote built from that scope.

A Type 2 report covers operating effectiveness over a period, so the auditor needs the controls to have run for that whole period before any sample is drawn. The period length is agreed between your organization and the CPA firm, and the controls must be stable during it, so changes to approval or access design restart the clock for the affected controls. In practice, this means the approval workflow, role model and log retention should be settled and operating before the observation window opens. Confirm the observation period, the sample sizes and the evidence formats with your auditor in writing before you set the rollout date. A Type 1 report, which covers design as of a date, can come earlier and is a useful check on the design first.

Your team owns the decisions that the auditor will test, so it must supply them before any build starts. The main inputs are:

• A named owner for each flag category, such as release, kill switch and experiment, with the approvers and their backups.
• The system description and the list of systems in scope, which the management description must match.
• Access to your identity provider, ticketing system, CI/CD pipeline and log destination for configuration and testing.
• Written change policies that define when a flag toggle counts as a production change.
• Named people to run quarterly access reviews and to sign off the evidence.

The platform implementation can produce the configuration, but management must still assert that the controls operate as described.

Yes, if your team has the skills to configure the platform, write the procedures and maintain the evidence. Many teams do it internally, and the SOC 2 criteria do not prescribe specific tools. The work to plan includes mapping flag changes to the change management criteria, setting approval and segregation of duties, configuring roles and audit logs, and deciding how evidence is exported and retained. A partner is most useful when you need a fixed-scope build of the self-hosted environment, testing of role and approval paths, or documentation an auditor can sample. Compare the internal effort against the cost of a written scope, and check whether your current edition supports the approval and role features the design depends on.

A Type 1 report describes the system and whether the controls were suitably designed as of a specific date. A Type 2 report adds an opinion on whether those controls operated effectively across a period. For flag controls, Type 1 tests whether your approval paths, roles, logs and change definitions exist and fit the criteria, while Type 2 tests whether each flag change went through them over time. A Type 2 needs consistent evidence, such as approval records, role assignments and log extracts, for every sampled change. Design weaknesses found in a Type 1 are cheaper to fix before the observation window opens. Confirm with your CPA firm which report type and period it expects.

No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. A SOC 2 report comes from an independent CPA firm after its examination. DeployOpen's role is to help plan and implement the self-hosted platform configuration, document the control procedures and set up the evidence your auditor will request, within a fixed scope agreed in writing. Management remains responsible for the description of the system and for the representations made to the auditor. Ask your CPA firm early which evidence formats it accepts so the work matches its sampling approach.

Flag changes most often map to the common criteria for change management and logical access. The change management criterion covers how changes to infrastructure, data, software and procedures are authorized, designed, tested and approved. Logical access criteria cover who can create, edit and approve flags and how those rights are granted and removed. System operations criteria cover monitoring and incident response when a flag causes a problem. The points of focus under each criterion help you design these controls, but they are not separate requirements and not every point needs to be addressed. Map each flag control to a criterion in your control matrix, and confirm the mapping with your auditor before testing starts.