Governance & Compliance
Governance & Compliance tests how GitLab enforces organizational rules and produces evidence. You need to distinguish frameworks, policies, approval rules, and audit data, and know which layer actually blocks a change.
Frameworks and controls
A compliance framework is a label applied to projects to represent a regulatory or internal standard, such as SOC 2 or ISO 27001. Frameworks can carry compliance requirements and controls, and the compliance center summarizes project status. A framework by itself is metadata: applying it does not run a scanner or require an approval.
Policies
Security policies are the enforcement layer. Scan execution policies require specified scanners to run on a schedule or in pipelines. Merge request approval policies require approvals when defined conditions are met, such as a critical vulnerability or a protected branch. Pipeline execution policies inject CI/CD configuration into project pipelines, which is useful for organization-wide jobs. Policies can be scoped to groups or projects and are managed centrally.
Audit evidence
Audit events record actions such as changing a policy, adding a user, or altering protected branch settings. Top-level group owners can stream audit events to an external destination, but streaming must be configured; events are not pushed anywhere by default. Merge request approval settings, protected branches, and push rules add further controls.
Worked example
A regulated group needs every project to run SAST and require approval for critical findings. An owner creates a group-level scan execution policy that enforces SAST on all projects, then a group-level merge request approval policy that requires one approval when a Critical SAST finding exists. Projects inherit both. The compliance framework is applied for reporting, but the two policies do the enforcement. Audit events capture who changed each policy.
Traps
A compliance framework is not an enforcement mechanism. A project-level approval rule is not the same as a merge request approval policy, and policy scope determines whether a project is covered. Scan execution policies enforce scanning, not approval. Audit event streaming is off until configured. Also check whether a control is evaluated at group or project level; applying a framework to a subgroup does not automatically cover sibling groups.