SOC 2: How Feature Flags Can Help Achieve Compliance

Feature flags long existed in a gray area for compliance. Because toggling a flag doesn’t require a code deployment or a server restart, engineering teams often treated them as exempt from the rigorous change management policies applied to code commits.

Regulators and auditors now consider this view outdated and dangerous for your SOC 2 attestation. A feature flag that alters system behavior, grants access, or exposes new functionality acts as a production change. If you cannot prove to an auditor who toggled a flag, when they did it, and who approved it, you have a gap in your control environment.

However, when managed correctly, feature flags shift from being a compliance liability to a compliance asset. They provide granular audit trails, precise access control, and instant remediation capabilities that are often superior to traditional deployment rollback procedures. This article explores how to align feature flagging strategies with SOC 2 requirements, specifically focusing on change management, access control, and auditability.

TL;DR

• Treat feature flag configurations as production code changes that require authorization and evidence of testing.
• SOC 2 Type II audits require proof of operating effectiveness over time, meaning you need searchable, exportable history of every flag interaction.
• Segregation of duties applies to flags; the person creating a flag should not necessarily have the permission to toggle it in production without approval.
• Local evaluation of feature flags keeps PII within your own infrastructure, simplifying the Privacy criteria of SOC 2.
• Kill switches serve as documented disaster recovery mechanisms, satisfying availability controls.

The intersection of feature management and SOC 2

SOC 2 is not a certification with a rigid checklist; it is an attestation report where an independent auditor evaluates your internal controls against the AICPA’s Trust Services Criteria (TSC). While there are five criteria, the Security criterion is mandatory, and it heavily scrutinizes how you manage changes to your system.

Feature flags touch several critical Common Criteria (CC) within the SOC 2 framework:

1. Change Management (CC8.1): How do you authorize and test changes?
2. Logical Access (CC6.1): Who has permission to make changes?
3. System Operations (CC7.2): How do you monitor and respond to anomalies?

If your feature flags are stored in a database and updated via manual SQL queries or a config file without version control, satisfying these criteria becomes difficult. You lack the “who, what, when” evidence required for a Type II audit, which looks at the effectiveness of controls over a period of time (usually 6–12 months).

Meeting change management controls (CC8.1)

Change management is arguably the most scrutinized section of a SOC 2 audit for engineering teams. The core requirement is that changes to the system are authorized, tested, and approved prior to implementation.

The “four-eyes” principle for flags

In strict compliance environments, a single developer should rarely have the power to push code to production without peer review. Similar logic applies to feature flags. If a developer can toggle a flag affecting 100% of users without oversight, you have bypassed your change management policy.

To satisfy CC8.1, you should implement approval workflows for your feature flags. This is often referred to as the “four-eyes principle” (at least two people must be involved in the change execution). In a feature management platform, this looks like a standardized change request workflow:

1. A developer drafts a change to a flag (e.g., increasing a rollout from 10% to 50%).
2. The system blocks the change from applying immediately.
3. A peer or release manager reviews the request, checks the configured strategy, and approves it.
4. The system logs the approval and the subsequent application of the change.

The resulting process generates the exact evidence artifact an auditor needs: a timestamped record linking the change to an approval.

Testing and environment progression

Auditors will ask for evidence that changes were tested before impacting production. Feature flags can actually strengthen your position here through environment segmentation.

Instead of claiming you tested a feature locally, you can demonstrate a progression strategy. You can show that new-checkout-flow was enabled in the “Development” environment on Monday, validated in “Staging” on Tuesday, and only enabled in “Production” on Wednesday.

By maintaining distinct environments (Dev, Stage, Prod) within your flagging system, you create a verifiable audit trail of lifecycle management. The segmentation proves that configuration changes follow the same rigorous path as binary code deployments.

Controlling logical access (CC6.1)

The principle of least privilege is central to SOC 2. Not every engineer needs write access to every feature flag in the production environment.

Role-Based Access Control (RBAC)

If you rely on a homegrown feature flag solution or a simple config file, access control is usually binary: you either have access to the repository/database or you don’t. Binary permission models rarely satisfy enterprise compliance.

You need a system that supports granular Role-Based Access Control (RBAC). A new developer might need “Read” access to production flags to debug issues but should be restricted from toggling them. A Product Manager might need permission to toggle specific operational flags but should be blocked from archiving or deleting flags.

Effective RBAC for compliance involves:

• Project-level scopes: Restricting users to specific projects (e.g., the billing team only touches billing flags).
• Environment-level permissions: Granting write access in staging but read-only access in production.
• Service accounts: Ensuring automated scripts (like CI/CD pipelines) use specific API tokens rather than shared user credentials.

Identity management and offboarding

When an employee leaves the company, their access to production systems must be revoked immediately. This is a common failure point in audits.

Integrating your feature flag system with your Single Sign-On (SSO) provider (like Okta, Google Workspace, or Azure AD) ensures that access is centrally managed. When a user is deprovisioned in the identity provider, they automatically lose access to the flagging platform. Automated deprovisioning serves as a strong control that auditors look for under CC6.1.

Audit trails and system operations (CC7.2)

For a SOC 2 Type II audit, having a process isn’t enough; you need to prove the process was followed consistently over time. Evidence collection often becomes a burden for engineering teams.

The indelible audit log

Every interaction with a feature flag system serves as a potential piece of evidence. Your system must maintain an immutable history of events. A detailed Event Log should answer:

• Who made the change? (User ID and email)
• What specific configuration changed? (Diff of the JSON/YAML config)
• When did it happen? (UTC timestamp)
• Where did it happen? (Project and Environment)

An auditor might pick a random sample of five production changes from the last year and ask you to provide the documentation for them. If your audit logs are searchable and exportable, this request takes minutes. If you are parsing raw server logs or git commits, it can take days.

Incident response and availability

Availability (CC9) is an optional trust service criterion, but it is relevant for most SaaS platforms. You must demonstrate how you minimize downtime and recover from failures.

You can use feature flags as instant kill switches. If a new deployment causes error rates to spike, disabling the feature flag is significantly faster than rolling back a full container deployment or database migration.

Documenting this capability counts as a disaster recovery control. You can demonstrate that your Mean Time to Recovery (MTTR) is reduced because your primary response mechanism involves toggling a flag rather than re-deploying artifacts.

The privacy advantage: Local evaluation

SOC 2 also covers the Privacy criterion. If you collect or process personal data, you must protect it from unauthorized access, including from your vendors.

Many feature flag providers require you to send user attributes (email, user ID, location) to their cloud so they can evaluate whether a user should see a feature. This transmits PII outside your trust boundary, complicating your data privacy compliance.

Architecture plays a significant role here. With a privacy-first architecture, feature flags are evaluated locally within your application rather than on external servers. The central server sends the rules to your application, and your application evaluates those rules against the user data in memory using the client SDK. Local evaluation ensures your users’ sensitive data never leaves your infrastructure, significantly reducing your compliance scope and third-party risk.

Managing stale flags as compliance risks

Every active flag in a codebase represents a conditional logic path that must be tested and maintained. Stale flags, those that have been fully rolled out but never removed, create unmanaged code paths that can be triggered accidentally, reviving legacy code that may no longer be secure or compliant.

To satisfy the risk assessment criteria (CC3.2), teams should categorize flags by their intended lifespan. Release flags should have a short lifecycle (days to weeks), while operational flags (like permissions or circuit breakers) may be permanent. Your governance program should include a process for identifying and retiring stale feature flags. Documenting this classification and retirement process proves to auditors that you’re proactively managing configuration complexity rather than letting it accumulate indefinitely.

Artifacts auditors expect to see

During a Type II audit, the auditor will request specific evidence to validate your controls. Being able to produce these artifacts immediately builds credibility and speeds up the review process. Standard requests include:

• Population examples: A list of all feature flags that were toggled in the production environment during the observation period.
• Sample testing: For a random selection of 5-10 changes, the auditor will ask for screenshots or logs showing the change request, the approval timestamp, and the user ID of the approver.
• Access review logs: Records showing that user permissions were reviewed quarterly and that access was revoked for employees who left the organization.

Modern feature management platforms can often export these logs directly to CSV or JSON formats. Centralizing this data ensures you are not scrambling to parse unstructured application logs when an audit request arrives.

Governance as an engineering asset

Compliance protocols often appear as bureaucratic hurdles that slow down engineering, but the controls required for SOC 2 (access control, auditability, and change management) align closely with the needs of high-performing teams.

Formalizing feature flag usage satisfies auditor requirements for control while preserving developer velocity, effectively replacing slow manual deployment gates with fast, auditable configuration changes. By implementing governance layers that include approval workflows, granular permissions, and privacy-focused evaluation, platforms like Unleash help organizations demonstrate that their feature management practice is secure, compliant, and ready for enterprise scale.

FAQs about SOC 2 compliance and feature flags

Do feature flag changes count as production code changes for SOC 2?

Yes, auditors consider feature flag changes to be production configuration changes because they alter the behavior of the system for end users. To meet compliance standards, these changes require the same level of authorization, testing, and auditability as a traditional code deployment.

How do I provide evidence of feature flag changes for a Type II audit?

You must provide a reliable audit log that covers the entire audit period. This log should be immutable and exportable, detailing exactly who made a change, when it occurred, what the value was before and after the change, and who approved the request.

Can I use feature flags if I have a strict “separation of duties” policy?

Yes, but you must use a platform that supports Role-Based Access Control (RBAC). You can configure permissions so that developers can create flags and toggle them in non-production environments, while only authorized release managers or team leads have permission to toggle flags in the production environment.

How long should I retain feature flag audit logs for compliance?

Most SOC 2 attestation periods cover 6 to 12 months, so you should retain logs for at least one year. Ideally, your feature management system should allow you to export these logs to your own data warehouse or SIEM for indefinite retention to meet broader regulatory requirements.

Does using a feature flag service violate SOC 2 privacy criteria?

It depends on the architecture of the service. If the vendor requires you to send user PII to their cloud for evaluation, it increases third-party risk and compliance scope. Using a solution with local evaluation ensures user data remains within your infrastructure, simplifying privacy compliance.