mirror of
https://github.com/Unleash/unleash.git
synced 2025-10-27 11:02:16 +01:00
33 lines
6.6 KiB
Plaintext
33 lines
6.6 KiB
Plaintext
---
|
|
title: SOC2 compliance for feature flags
|
|
description: 'SOC2-compliant feature flags at scale with Unleash.'
|
|
---
|
|
|
|
# SOC2 compliance
|
|
|
|
## Overview
|
|
|
|
To get SOC2 certified and maintain your compliance, you must ensure that any system you integrate with, including feature flagging solutions, adhere to the same compliance standards. Using a homegrown or third-party feature flagging system without SOC2 compliance can compromise your certification and introduce unnecessary risks.
|
|
|
|
This guide provides an overview of how [Unleash Enterprise](https://www.getunleash.io/pricing) features align with SOC2 Type II controls, helping your organization meet its compliance requirements.
|
|
|
|
|
|
## How Unleash features map to SOC2 Type II controls
|
|
|
|
| SOC2 Type II Control | Control Description | Unleash Feature |
|
|
|---------------------------------------------|---------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| CC 2.1, CC 7.2 Log management utilized | The company utilizes a log management tool to identify events that may have a potential impact on the company's ability to achieve its security objectives. | [Event log](/reference/events) and [login history](/reference/login-history) provide access to all configuration change and access logs. |
|
|
| CC 2.2, CC 5.3 Roles and responsibilities specified | Roles and responsibilities for the design, development, implementation, operation, maintenance, and monitoring of information security controls are formally assigned in job descriptions and/or the Roles and Responsibilities policy. | Unleash provides [role-based access control](/reference/rbac). |
|
|
| CC 2.2 System changes communicated | The company communicates system changes to authorized internal users. | Admins in Unleash can configure [banners](/reference/banners) that can display message for all users in the Unleash Admin UI. |
|
|
| CC 3.2, CC 7.5, CC 9.1 Continuity and disaster recovery plans tested | The company has a documented business continuity/disaster recovery (BC/DR) plan and tests it at least annually. | Unleash provides a business continuity disaster recovery (BCDR) policy available to customers in the Trust Center, and annual test results upon request. |
|
|
| CC 3.4, CC 7.1 Configuration management system established | The company has a configuration management procedure in place to ensure that system configurations are deployed consistently throughout the environment. | [Change Requests](/reference/change-requests) supports 4-eyes approval workflows for changes. |
|
|
| CC 3.4, CC 4.1, CC 7.2, CC 8.1 Penetration testing performed | The company's penetration testing is performed at least annually. A remediation plan is developed and changes are implemented to remediate vulnerabilities in accordance with SLAs. | Unleash provides annual penetration test results to customers in the Trust Center, performed by an external auditor. |
|
|
| CC 5.3, CC 7.1, CC 8.1 Change management procedures enforced | Change management procedures are enforced. | Unleash supports defining custom roles with configurable permissions in each environment. [Change Requests](/reference/change-requests) supports a 4-eyes approval workflow for changes. |
|
|
| CC 6.1, CC 8.1 Production deployment and application access restricted | The company restricts access to migrate changes to production to authorized personnel. | Unleash supports defining custom roles with configurable permissions in each environment. [Change Requests](/reference/change-requests) supports a 4-eyes approval workflow for changes. |
|
|
| CC 6.1 Unique account authentication enforced | The company requires authentication to systems and applications to use unique username and password or authorized Secure Socket Shell (SSH) keys. | Unleash supports both username/password authentication, as well as [single sign-on](/reference/sso). In addition, the [SCIM integration](/reference/scim) facilitates user account provisioning. |
|
|
| CC 6.1 Password policy enforced | The company requires passwords for in-scope system components to be configured according to the company's policy. | Unleash has [password strength requirements](/using-unleash/deploy/securing-unleash#password-requirements) for all users using username/password authentication. |
|
|
| CC 6.1, CC 6.6 Remote access MFA enforced | The company's production systems can only be remotely accessed by authorized employees possessing a valid multi-factor authentication (MFA) method. | You can enable MFA through your identity provider, such as Okta or Microsoft Entra ID, after implementing [single sign-on](/reference/sso). |
|
|
| CC 6.1, CC 6.6 Remote access encrypted and enforced | The company's production systems can only be remotely accessed by authorized employees via an approved encrypted connection. | Unleash is secured by enforcing TLS 1.2. |
|
|
| CC 6.7 Data transmission encrypted | The company uses secure data transmission protocols to encrypt confidential and sensitive data when transmitted over public networks. | Unleash is secured by enforcing TLS 1.2. |
|
|
| SD SOC 2 System Description | The company has completed a description of its systems for Section III of the audit report. | This documentation is available in the SOC 2 report in the Trust Center. The report is performed by an external auditor and renewed annually. |
|