Published on: August 27, 2026
12 min read
Use GitLab custom compliance framework templates to enforce SOC 2 and more, monitor adherence continuously, and cut audit prep from weeks to clicks.
Compliance is the part of software delivery that everyone agrees is important, yet nobody enjoys. It often lives in spreadsheets, screenshots, and the quiet dread of an upcoming audit. GitLab's custom compliance frameworks work differently. Instead of documenting what should be true about your projects, you define the controls once and let the platform continuously verify what is true.
In this article, you'll learn why compliance adherence matters, how to stand up a SOC 2 framework in minutes using a template, how to monitor adherence on an ongoing basis, how to enforce compliance with policies, and which standards already ship as ready-to-use templates. You'll also get a look at where AI-specific compliance templates are heading. You can watch the video below to see it in action:
Tier note: Compliance frameworks are available in Premium and Ultimate. Framework requirements and controls, the checks that power adherence reporting and the compliance status report, require Ultimate. Everything here applies to GitLab.com, GitLab Self-Managed, and GitLab Dedicated.
Regulatory and contractual obligations like SOC 2, ISO 27001, PCI DSS, and FedRAMP exist because customers, partners, and regulators need assurance that your software is built and shipped responsibly. Falling short isn't just a paperwork problem. It can block deals, trigger fines, delay product launches, and erode trust. Compliance also isn't a one-time event. A project that was compliant at audit time can drift the moment someone disables a scanner, removes branch protection, or merges without the required approvals.
Custom compliance frameworks are designed to close that gap. A compliance framework in GitLab is a label you create on a top-level group to identify projects that carry specific compliance obligations or need extra oversight. On its own that label provides organization and visibility. In Ultimate, a framework can also carry requirements made up of controls, which are automated checks against the configuration and behavior of every project the framework is applied to.
Instead of asking an engineer to confirm that static application security testing (SAST) is running, that the default branch is protected, and that merge requests need two approvals, GitLab evaluates those conditions for you on a schedule and whenever relevant project settings change. Compliance stops being a snapshot you assemble before an audit and becomes something you can watch year-round. Frameworks are created on the top-level group and inherited by all subgroups and projects beneath it. You can apply up to 20 frameworks to a single project when it needs to satisfy several standards at once.
This changes the day-to-day effort in a few ways. Compliance moves left into the development workflow, audit preparation becomes a matter of exporting a report rather than reconstructing evidence, and consistency is enforced by the platform rather than by good intentions.
Building a framework by hand means defining every requirement and every control one at a time. For a standard like SOC 2 that maps to many controls, that's repetitive and error-prone. Templates solve this by giving you a complete, predefined framework, with the name, description, color, requirements, and controls all configured, and that you can adopt in a single step.
The Compliance Adherence Templates
project
hosts a library of these frameworks as JSON files, and soc2.json
is one of them.
There are two ways to get a template into your group.
You can create a framework directly from a built-in template without leaving the UI:
Your framework is created and will be applied to the groups/projects you selected.
If you're on a GitLab version without the in-product template picker, or you want to keep the template under version control and tweak it first, import the JSON directly:
soc2.json
.soc2.json
file from your local system.A framework only does something once it's attached to projects. Make sure you apply this framework to the groups/projects where it will be used.
Note: Imports fail with an Unable to determine the correct upload URL
error if a framework with the same name already exists. Rename or remove the existing one first.
You can also edit the newly created framework as well as apply it to additional groups/projects:
If you want every new project in the group to inherit SOC 2 automatically, set the framework as the group default in the Basic information section. The framework will then be applied to all newly created and imported projects going forward.
Once applied, the SOC 2 framework maps GitLab controls to the relevant Trust Services Criteria. A few highlights:
| SOC 2 criterion | What it covers | GitLab controls applied |
|---|---|---|
| CC3.2 | Identifying vulnerabilities in system components | Dependency scanning, container scanning, DAST, API security running |
| CC5.1 | Segregation of duties | At least two approvals; author and committer approvals forbidden; approval rules locked from editing |
| CC6.6 | Protecting authentication credentials in transit | Secret detection running |
| CC6.8 | Detecting unauthorized or malicious software changes | Default branch protected |
| CC7.1 | Detecting new vulnerabilities through scanning | Dependency, container, SAST, DAST, and API security scanning running |
| CC8.1 | Authorizing, testing, and approving changes | SAST, DAST, secret detection running; default branch protected; at least two approvals |
After the framework is applied to a project, GitLab runs a compliance scan and begins reporting on whether each control passes. No manual evidence gathering required.
Applying a framework is only half the value. The other half is knowing, at any moment, where you stand. That's the job of the compliance status report (Ultimate), found in your top-level group under Secure > Compliance center > Status.
The report surfaces the most recent instances where projects do and do not adhere to a framework's controls, so you can spot and close gaps fast. Each row tells you:
You can filter by project, framework, or requirement, jump straight into a project's compliance detail view, and export the whole report (delivered to your inbox as an attachment) when an auditor asks for evidence.
Behind the scenes, scans that refresh the report are triggered automatically when a framework is added to a project, when an associated framework's requirements change, and on a recurring 12-hour schedule. Results typically appear five to ten minutes after a scan runs. This means compliance drift becomes visible within hours rather than at the next annual audit. To view the report, you'll need to be an administrator, or have the Security Manager or Owner role for the group.
Reporting tells you when something is wrong. Policies stop the wrong thing from happening in the first place. This is where compliance frameworks move from observation to enforcement, and it's an Ultimate capability tied to the framework label.
A compliance framework can act as the scope for Security policies. Scan execution policies, Pipeline execution policies, and merge request approval policies can be scoped to a compliance framework, so every project carrying that label automatically inherits them. For example, you can require that SAST, secret detection, and dependency scanning run on the default branch, and require approval from a designated security team before a merge request that introduces new critical vulnerabilities can be merged. Because the policy is bound to the framework rather than to individual projects, adding a new project to the framework instantly brings it under the same guardrails.
The pieces work together. The framework defines the obligation, controls and the status report measure adherence, and policies and compliance pipelines enforce the behavior. You're not just documenting that SOC 2 requires two approvals and running scanners. You're making it difficult to ship anything that violates those requirements. When a control fails, the status report flags it. When a policy is in place, the non-compliant change is blocked before it merges.
GitLab ships a growing library of predefined framework templates in the Compliance Adherence Templates project, each mapping a recognized standard to GitLab controls. As of publication, these include:
| Standard | Template file |
|---|---|
| CIS Critical Security Controls v8.1 | cis_csc_v8-1.json |
| CSA Cloud Controls Matrix v4 | csa_ccm_v4.json |
| Cyber Essentials | cyber_essentials.json |
| DORA (Digital Operational Resilience Act) | dora.json |
| FedRAMP Low / Moderate / High (Rev 5) | fedramp_low_r5.json , fedramp_moderate_r5.json , fedramp_high_r5.json |
| IRAP Official / Protected / Secret / Top Secret | irap_official.json , irap_protected.json , irap_secret.json , irap_top_secret.json |
| ISMAP | ismap.json |
| ISO 27001:2022 | iso_27001:2022.json |
| NIS 2 | nis_2.json |
| NIST 800-53 Rev 5 | nist_800-53_r5.json |
| NIST 800-171 Rev 3 (CMMC) | nist_800-171_r3_cmmc.json |
| NIST CSF 2.0 | nist_csf_2.json |
| NIST SP 800-218 (SSDF) | nist_800-218_v1-1.json |
| PCI DSS v4.0.1 | pci_dss_v4-0-1.json |
| SOC 2 | soc2.json |
| TISAX | tisax.json |
Each template's exact requirement-to-control mapping is documented in the compliance
standards
reference. You can import any of them as-is, or use them as a starting point. Export a framework as
JSON, adjust the requirements and controls to match your organization's interpretation of a
standard, and re-import. The JSON schema is straightforward. A framework has a name
,
description
, color
, and an array of requirements
, each with its own controls
and evaluation
expression
. That makes templates easy to keep in version control and share across groups.
The compliance standards covered today were largely written for traditional software. As organizations embed AI into their products and their own development workflows, a new class of obligations is emerging around governing how AI systems are built, approved, and monitored. Examples include the EU AI Act, ISO/IEC 42001, and the NIST AI Risk Management Framework.
GitLab is exploring AI governance compliance templates (Epic #16808, with planning tracked in Work item #22336) to extend the same template-driven model into this space. The intent is to let teams adopt an AI-governance framework as easily as they adopt SOC 2 today, with predefined requirements and controls that map to AI-specific obligations, applied to the projects that build or deploy AI capabilities, and surfaced through the same compliance status report.
It's worth keeping one distinction in mind. Compliance is the state of meeting a defined set of requirements, while governance is the ongoing capability to keep AI systems compliant as both the systems and the rules evolve. GitLab's broader direction pairs AI-assisted detection with human-in-the-loop approval and auditable, policy-based enforcement, so AI findings inform decisions but accountable humans and measurable controls still gate what ships. AI-specific templates would be the onramp, giving you a fast way to encode emerging AI requirements into the same framework, control, status report, and policy machinery you're already using for everything else.
Custom compliance frameworks let you define your obligations once and have GitLab continuously verify them. Templates take the manual setup out of getting started, so a SOC 2 framework is a few clicks or a single JSON import away. The compliance status report keeps adherence visible on a 12-hour cadence, and security policies plus compliance pipelines turn that visibility into enforcement. With a library of standards already available and AI-specific templates on the horizon, the path from "we should be compliant" to "we can prove we are, continuously" is shorter than it's ever been.
Learn more with our compliance frameworks documentation and try the custom compliance frameworks click-through demo.
This blog post contains "forward‑looking statements" within the meaning of Section 27A of the Securities Act of 1933, as amended, and Section 21E of the Securities Exchange Act of 1934. Although we believe that the expectations reflected in these statements are reasonable, they are subject to known and unknown risks, uncertainties, assumptions and other factors that may cause actual results or outcomes to differ materially. Further information on these risks and other factors is included under the caption "Risk Factors" in our filings with the SEC. We do not undertake any obligation to update or revise these statements after the date of this blog post, except as required by law.
Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.
Share your feedbackStart building faster today
See what your team can do with the intelligent orchestration platform for DevSecOps.
Facts Only
* GitLab offers custom compliance framework templates for standards including SOC 2, ISO 27001, PCI DSS, and FedRAMP.
* Compliance frameworks are available in Premium and Ultimate tiers.
* Framework requirements, controls, and the compliance status report require the Ultimate tier.
* Templates are hosted as JSON files in the Compliance Adherence Templates project.
* Frameworks can be created via an in-product template picker or by importing JSON files.
* GitLab evaluates project configurations on a 12-hour recurring schedule and upon setting changes.
* The compliance status report identifies adherence or non-adherence to controls at the top-level group.
* Compliance frameworks can scope Security policies, including scan execution and merge request approval policies.
* Up to 20 frameworks can be applied to a single project.
* AI governance templates are currently in the planning stage (Epic #16808).
* The product is available for GitLab.com, GitLab Self-Managed, and GitLab Dedicated.
Executive Summary
Software delivery compliance often relies on manual documentation and point-in-time audits, creating a gap where projects can drift into non-compliance between reviews. To address this, an automated system allows organizations to define controls once at a group level and continuously verify them across all inherited projects. By utilizing predefined templates for standards like SOC 2, teams can replace manual evidence gathering with automated scans that monitor settings—such as branch protection and mandatory approvals—on a 12-hour cycle.
This approach shifts compliance from a retrospective administrative burden to an active part of the development workflow. Beyond monitoring, these frameworks enable the enforcement of security policies, ensuring that non-compliant changes are blocked before they are merged. While current templates cover established regulatory and contractual obligations, there is an active transition toward AI governance to address emerging requirements like the EU AI Act. This evolution aims to maintain human accountability through policy-based enforcement while leveraging AI-assisted detection.
Full Take
The strongest version of this narrative is that the "compliance tax"—the friction and dread associated with audits—can be engineered away. By turning legal and regulatory requirements into code (JSON templates) and automated checks, the burden of proof shifts from the human engineer to the platform.
However, this is a classic vendor advertorial. It employs a "Fear Appeal" by framing compliance as a source of "quiet dread" and a potential deal-blocker, then immediately presents its own Ultimate-tier features as the singular resolution. It utilizes an "Authority Game" by mapping its product features directly to Trust Services Criteria and other global standards, suggesting that adopting the tool is synonymous with achieving the standard itself. This creates a subtle but dangerous conflation: the tool's "pass" mark is presented as a proxy for actual regulatory adherence.
The underlying paradigm is the "platformization of governance." The assumption is that compliance is a technical configuration problem rather than a cultural or procedural one. While this increases efficiency, the second-order consequence is a potential erosion of critical thinking; when "green checkmarks" in a dashboard become the primary evidence of security, the human capacity for nuanced risk assessment may atrophy.
Patterns detected: ARC-0013 Fear Appeal, ARC-0031 Authority Game
Root Cause: The narrative is driven by the "DevSecOps" paradigm, which seeks to merge traditionally separate silos (Development, Security, and Compliance) into a single automated pipeline.
Counterstrike Scan: A coordinated campaign would use this narrative to lock enterprises into a specific ecosystem by making the cost of switching platforms equal to the cost of rebuilding their entire regulatory audit trail. The actual content aligns with this vendor-lock-in pattern.
Bridge Questions:
1. If a tool automates the "evidence," who audits the tool's logic to ensure it accurately reflects the legal requirement?
2. Does the automation of compliance encourage a "checkbox mentality" that ignores risks not captured by the JSON template?
3. How does the transition to AI governance change the definition of "accountability" when the enforcement is automated?
Sentinel — Human
The text reads like well-researched technical marketing content blending established regulatory concepts with a specific software product's feature set, demonstrating high contextual understanding rather than pure synthetic generation.