FeatureSignals
Security

Feature Flag Governance for SOC 2 Compliance

Feature flags touch production configuration, which means they sit squarely inside your compliance boundary. We break down RBAC with per-environment toggle permissions, tamper-evident audit logging with before/after diffs, change approval workflows, SSO with SCIM provisioning, and how to map flag controls to SOC 2 Trust Service Criteria — plus GDPR and HIPAA considerations for regulated teams.

FS
FeatureSignals Security Team
·March 2026·10 min read

Feature Flags Are Production Configuration

Many teams treat feature flags as a developer convenience — a quick toggle to hide incomplete work. But in the eyes of auditors, regulators, and your own security policy, feature flags are production configuration changes. Toggling a flag can expose unfinished features to users, disable critical safeguards, or change application behavior in ways that affect data handling, authentication, and compliance posture. If your SOC 2 scope includes change management — and it almost certainly does — your feature flag system is in scope.

This post maps FeatureSignals' governance controls to SOC 2 Trust Service Criteria (TSC 2017) and provides practical guidance for teams preparing for SOC 2 Type II, ISO 27001, or HIPAA compliance audits.

RBAC with Per-Environment Permissions

FeatureSignals implements role-based access control with environment-level granularity. A developer might have write access to staging flags but read-only access to production. A release manager can toggle flags in production but cannot create new flags. An auditor has read-only access across all environments with full audit log visibility.

  • Organization Owner: Full administrative access. Can manage billing, SSO, and organization-wide settings. SOC 2 mapping: management oversight of access controls.
  • Project Admin: Full access to specific projects. Can manage flags, segments, environments, and project-level settings. SOC 2 mapping: change management authorization.
  • Release Manager: Can toggle flags and adjust targeting rules. Cannot create or delete flags. SOC 2 mapping: separation of duties.
  • Developer: Can create and edit flags in non-production environments. Read-only access to production. SOC 2 mapping: least privilege.
  • Viewer: Read-only access. Suitable for auditors, support teams, and stakeholders who need visibility without modification rights. SOC 2 mapping: monitoring and audit access.

Tamper-Evident Audit Logging

Every change to a feature flag — creation, update, toggle, deletion — generates an immutable audit log entry. Each entry captures the before state, the after state, the user who made the change, the timestamp, the IP address, and the client user agent. Logs are write-once, append-only, and cannot be modified or deleted by any user, including organization owners. This satisfies SOC 2 CC6.1 (logical and physical access controls) and CC7.2 (system monitoring and analysis).

Change Approval Workflows

For regulated environments, FeatureSignals supports mandatory change approval workflows. A flag change in a protected environment (e.g., production) requires approval from a designated approver before it takes effect. The approval is itself audit-logged, creating a complete chain of authorization from request to implementation.

SSO and SCIM Provisioning

FeatureSignals integrates with enterprise identity providers via SAML 2.0 and OpenID Connect. SCIM 2.0 provisioning automatically synchronizes user accounts, group memberships, and role assignments from your IdP. When an engineer leaves the company and their Okta account is deactivated, their FeatureSignals access is automatically revoked within minutes. This satisfies SOC 2 CC6.2 (user access provisioning and deprovisioning).

ℹ️

Info

FeatureSignals Enterprise Edition includes SSO, SCIM, audit log export, and change approval workflows. Community Edition includes basic RBAC and audit logging. SOC 2 compliance requires Enterprise Edition for change approval workflows.