Feature flagging platforms were built to help engineering teams ship faster while reducing risk. But in regulated industries like fintech or healthtech, every change you make with a flag is also a production change, and auditors will always ask about it.

It’s a predictable exercise really. They’ll want to know who toggled the flag, who approved it, what the previous state was, and why it was done in the first place.

At first, they may seem like standard questions, but what they really want to know is whether the changes were made in line with local regulations on data privacy and security, and whether you already have the right governance and controls in place to do that. If your platform of choice can’t answer those questions with a solid evidence trail, you could deal with potential fines and loss of reputation.

In this article, we’ll explain why the use of feature flags in regulated industries is a nuanced use case, and what you need to stay compliant.

Why feature flags are a compliance concern in regulated industries

At its core, a feature flag can change what your users see and how your app behaves without a full-blown code deployment. That’s the whole point of flags, but it’s also where the risk comes in.

Engineering teams usually have change management controls for their deployment pipeline. Code gets reviewed and tested before it reaches production. In some cases, there are clear approval gates at each step, but a feature flag bypasses that pipeline entirely if you haven’t configured approvals for it. You can change production behavior with a simple toggle or API call, and unless your feature flagging platform has its own governance layer, users can make changes that don’t leave an audit trail.

Case in point. In May 2025, a Common Vulnerabilities and Exposure (CVE) was issued against a popular open-source feature flags SDK after researchers found that its discovery endpoint exposed the full list of flag names, descriptions, and default values to unauthenticated requests. It was rated a “medium severity” problem but the issue is that most engineering teams don’t realize how much information these flags contain.

Without the right audit controls and data handling policies, sensitive information leaked through a system that is publicly queryable by design.

That’s why auditors treat flag-related changes as any other production change. For instance, frameworks like SOC 2 require configuration changes to be authorized and documented with evidence of approval.

Governance is not a choice anymore, so your feature flagging platform needs to help you stay compliant.

What are the 5 pillars of compliance for feature flags?

There are five areas that cover what auditors and security reviewers want to know while evaluating changes in your infrastructure. Here’s what they are:

1. Immutable audit trails and evidence

Every flag change in a regulated environment needs a record that captures:

• Who made the change
• When it was made
• What the previous value was
• What value did it change to
• Which environment it affected

That record needs to be immutable, which means that nobody can edit it after the fact. It should also be exportable so you can hand it to an auditor without manually reconstructing it from memory.

The log should also differentiate between different types of actors. For example, it should flag whether a human or a service account made the change by calling the API. Automated actions should be attributed to the platform itself instead of the individual user.

Note: In GrowthBook, the audit log works exactly like this. It records every change and whether a logged-in user, API token, or the app made it. You can export logs as JSON or stream them continuously to tools like Splunk or Datadog via event webhooks, so your flag evidence lands alongside the rest of your change-management data.

2. RBAC and least privilege

Every engineer doesn’t need access to write and deploy to production. A compliant feature flagging platform accounts for this and lets you separate who can propose a change and who can push it live. That’s where role-based access (RBAC) comes in.

At minimum, your platform should support:

• Environment-based access: For example, engineers can toggle freely in staging, but only designated roles publish to production.
• Access based on project level: Sensitive projects (PHI, financial data) get their own access boundary, while a No Access role hides a project entirely from users who shouldn’t see it.
• Identity lifecycle integration: SSO and SCIM tie permissions to your identity provider, so when someone is offboarded, their access is revoked through the same process.
• Token scoping: API tokens and personal access tokens should inherit permissions from the same RBAC model as human users. It shouldn’t allow any shadow permission workflows to override it.

Platforms like GrowthBook draw a hard line here. Role-based access is scoped to the environment, so you can gate it based on the authorization specific team members have. Also, project-level roles can reduce access below a user’s global role, which is how you ring-fence a regulated project without restructuring your entire permission model.

How roles work within GrowthBook:

3. Separation of duties and approval workflows

While RBAC gates access based on role, the roles you designate also help in the approval process. It’s based on the four-eyes principle where the underlying belief is that a single person shouldn’t be able to make huge changes unilaterally. It’s a clear requirement as per SOC 2’s change-control clauses and SOX’s segregation-of-duties rules.

If you’re making major changes to production, one requester and one reviewer should approve them to avoid unnecessary incidents. That said, scope these approvals so you’re not slowing your team down for minor changes.

The goal is to demarcate high-risk projects from low-risk ones and ship fast without breaking things.

In GrowthBook, the “blockSelfApproval” setting blocks every contributor on a revision from approving it, including the author. Each of these requirements is scoped based on the environment and project. In case you use a “break-glass” publish to bypass the gate, it’ll record which control was skipped and who did it.

4. Data residency and PII/PHI handling

The most important question about any feature flag vendor is their platform’s architecture. You need to ask them, “What user data does the system actually receive?”

Typically, feature flagging platforms need access to targeting attributes like user IDs and account data, especially if they evaluate the flag in their own servers. As a result, you have a data-processing relationship which can trigger compliance requirements like GDPR and HIPAA BAA obligations.

Here, there are two layers to consider:

1. Evaluation data: When your SDK checks whether a user should see a feature, where does that check happen? Locally or on the vendor’s servers?
2. Analytics data: Where do flag evaluation events live? Who controls retention? And if a user exercises their GDPR right to erasure, can you run that deletion against your own database, or do you need to file a request with the vendor and wait?

For instance, GrowthBook’s SDK downloads flag definitions and evaluates them locally, in-process against attributes held in your app’s memory. None of these values are sent to the platform, whether in cloud or self-hosted environments. Plus, its warehouse-native approach keeps event data in your warehouse so the retention policies are yours and you can handle your data as you’d like.

5. Automation and AI agent governance

As you integrate AI coding agents into your development process, that’s another layer to consider. In regulated environments, your change management controls should still apply when an AI agent is involved.

For example, if there’s an approval required for a production-related change, the agent should get the same treatment as a human-led deployment would. And every change it makes should be logged and traceable to the exact platform or token that made it.

Platforms like GrowthBook enforce this at the API layers so agents get treated the same way. The audit log differentiates between human sessions and API tokens, so nothing gets misattributed. You can even use Custom Hooks to set up approval gates.

See flags in regulated lending

Read how Upstart, an AI lending marketplace, runs GrowthBook on-premises to protect data privacy while moving faster.

Read the Upstart Story

What compliance requirements do you need to meet for feature flags?

The above five pillars are framework-agnostic. But if you’re looking for specific controls under common regulatory frameworks, here’s what they require:

SOC 2

SOC 2 Type II evaluates how your organization protects customer data and whether your internal controls around security and confidentiality work over time. Here are a few clauses your feature flagging platform needs to satisfy:

• CC8.1 (change management): Your production changes must be authorized, documented, and approved, and the platform needs to produce immutable audit records for every change. The approval workflows should prevent self-approval and should include a commit message or reason field at the time of publishing.
• CC6.1 / CC6.3 (logical access): Access should follow least privilege, with periodic review. It should also have environment-scoped RBAC, project-level isolation, and SSO/SCIM provisioning and deprovisioning.
• CC7.2 (monitoring): You need to detect anomalous or unauthorized changes within the platform. Usually, event webhooks that stream flag changes to your SIEM satisfy this, especially when they’re paired with break-glass evidence like GrowthBook’s bypassedGates field.

HIPAA

HIPAA applies to covered entities and business associates that handle electronic protected health information (ePHI). These areas are critical when you’re using feature flags:

• 164.312 (access and audit controls): Every user needs a unique identity, and every action affecting ePHI needs an audit trail. This means you need SSO-backed authentication, per-user actor attribution in audit logs, and environment-scoped publishing permissions maps.
• PHI minimization: If your flag platform evaluates locally and never receives targeting attributes, the vendor sits outside the PHI data flow entirely. That said, if you’re using self-hosted infrastructure or a warehouse-native architecture for cloud deployments, data never leaves your app.

GDPR

GDPR governs the processing of personal data for European Union (EU) residents. These articles are the most relevant if you’re using a feature flagging platform:

• Data residency and transfers: Where is personal data processed and stored? Ideally, the platform uses local SDK evaluation so that attribute values don’t get transmitted to the vendor. Also, self-hosting in your own region keeps the control plane local.
• Article 17 (right to erasure): Can you delete a subject’s data on request? If your event data lives in your own warehouse, you can request erasure yourself instead of relying on the vendor.
• Article 7 (consent): Are there persisting identifiers before the user consents? Look for opt-in mechanisms where identifiers aren’t stored until consent is granted.

What you need to build an auditor-ready evidence packet for feature flags

When an auditor selects a production flag change from your sample, they’ll ask you to reconstruct the full chain of evidence around it. Here’s what you need to show:

EvidenceWhat to look forWhat changed because of the flag?A full diff showing the previous value and the new value, including targeting rules, rollout percentages, and any conditional logic. There should be an immutable log with the publishing time.Who proposed the change?The identity of the person or service account that created the change, along with the details of every contributor who edited the draft before publication. It should also include a commit message or reason for the change request.Who approved the change?Each reviewer’s identity, their verdict (approved, requested changes, or commented), the timestamp of each verdict, and whether the reviewer was a human session or an API token. Retain stale approvals (where the draft changed after the verdict was given).Where was the log stored?The approval chain should be available in two independent places to corroborate its validity. For example, the revision record stores the review verdicts, while the append-only audit log records the same approvals as separate events with their own timestamps.Was any control bypassed?If an admin used break-glass authority to publish without approval, the log should show which gate was bypassed and under whose authority.Which environment did it affect?The change should be tagged to a specific environment (production, staging, dev) through the SDK connection that served it.Is there an exportable artifact?A timestamped JSON export of the full event stream, which can include a per-flag history API endpoint for programmatic access, or continuous webhook streaming into your SIEM.

What compliance requirements should a feature flagging vendor have?

Here’s what you need to look for to ensure your platform of choice protects you:

Security posture and certifications

• SOC 2 Type II report. Ask for the audit window and any noted exceptions.
• ISO 27001 certificate with the scope statement.
• Most recent penetration test report and remediation status of findings.
• Incident response plan and access control policy.
• Active bug bounty program or responsible disclosure policy.

Data architecture

• Data flow diagram showing what user data the vendor’s system actually receives, where it’s processed, and where it’s stored.
• Whether flag evaluation happens locally inside your application or on the vendor’s servers.
• Where analytics and event data lives, who controls retention, and whether you can execute data deletion requests against your own infrastructure.
• Encryption at rest and in transit for flag payloads and stored credentials.

Access controls and change management

• RBAC with environment-level and project-level scoping.
• SSO and SCIM integration for identity lifecycle management (provisioning and deprovisioning).
• Clear approval workflows with separation of duties.
• Immutable audit logs with actor attribution (human vs. service account vs. system).
• Evidence export via JSON, API, or continuous webhook streaming to your SIEM.

Deployment model

• Self-hosted deployment option and what it requires (infrastructure, database, licensing).
• Support for VPC, VPN, or air-gapped network topologies.
• Whether the self-hosted version and the cloud version share the same codebase and feature set.

Industry-specific requirements (where applicable)

• Healthcare (HIPAA): Will the vendor sign a BAA, and under which deployment model?
• Financial services (SOX): Does the platform enforce segregation of duties over changes that could affect financial reporting? Can you produce evidence of who approved what and whether any controls were bypassed?
• GDPR-regulated organizations: DPA availability, sub-processor list, data transfer mechanism (SCCs), and whether a self-hosted option removes the transfer question entirely.

Note: As of September 2026, GrowthBook holds SOC 2 Type II and adheres to HIPAA, GDPR, and CCPA. Self-hosted deployments are also HIPAA-compliant. You can find more information in our Trust Center.

Why open-source and self-hosted feature flags matter for regulated organizations

We’ve established that you can make sure your feature flagging platform is compliant if it has the five pillars of governance. However, it also raises the question: How much of that architecture can you actually verify?

For a closed-source platform, you’ll have to rely on the vendor’s docs and their word. But with an open-source platform, your engineering and security team can read the source code themselves and decide whether it fits your compliance requirements. It also helps when auditors ask how something was recorded and you can pinpoint the exact path.

That’s one reason GrowthBook was built to be open source and to offer self-hosted deployments if needed. It’s MIT-licensed so you can audit the evaluation logic and governance layers before using it.

Also, if you have strict data residency requirements, the warehouse-native architecture and self-hosted option ensure data never leaves your infrastructure.

Interested in seeing how your organization can stay compliant with GrowthBook? Book a demo, and we’ll show you how the Enterprise version can support you.

Self-host GrowthBook for free

GrowthBook is open source, so you can deploy it in your own infrastructure and keep flag data inside your compliance boundary.

Start Building Free