What the Compliance Framework Actually Enforces
Helio Health is a 400-engineer company under SOX-style change control. It applied a GitLab compliance framework named SOX-IT to 60 projects containing financial reporting code. The framework runs a compliance pipeline with a sign-off job. During an internal audit, the auditor sampled 25 merged merge requests and found four that were merged by the same person who approved them, two projects with force push enabled on the default branch, and three hotfixes pushed directly to the default branch with no pipeline at all. The auditor also found that audit events are retained in GitLab for 30 days and that streaming to the SIEM was configured but never tested. The compliance team believes the framework enforces these controls automatically; the platform team says maintainers can adjust project settings when needed. The company has Ultimate and a group-level security policy project for two of its five top-level groups.
1. Explain what the SOX-IT compliance framework does and does not enforce, and why the auditor's findings are possible even though the framework is applied.
Read the worked answer
A compliance framework is primarily a label attached to projects, plus optional attached configuration such as a compliance pipeline. The label makes projects discoverable and reportable as in scope. The compliance pipeline can run required jobs on merge requests, and it can be configured so the pipeline must succeed. That is a real control, but it is a narrow one: it controls what runs, not who approves, whether force push is allowed, or whether someone can bypass the merge request entirely.
The gaps the auditor found live in project settings and branch rules, not in the framework. Self-approval is governed by merge request approval settings, which must explicitly prohibit the author from approving and may need to prohibit the committer as well. Force push is governed by push rules and protected branch settings. A direct push is possible whenever the protected branch allows maintainers to push, or when branch protection is absent. None of these are switched on by applying a framework.
Audit event retention is a separate issue. GitLab retains audit events for a limited period, and streaming is the mechanism for long-term evidence. Configuring a destination without testing it means the company may have 30 days of evidence and an unknown gap after that. The correct statement to the auditor is that the framework provides scope and a pipeline control, while approval, push, and evidence controls must be configured and monitored separately.
2. Design a 60-day remediation that closes the four control gaps. Prioritize changes that cannot be undone by a project maintainer.
Read the worked answer
Days 1 to 15: branch and push controls. Apply group-level push rules that reject force push and branch deletion on default branches, and enable protected branches with separate roles for push and merge. Remove direct push rights from maintainers on the 60 SOX-IT projects; allow direct push only through a documented break-glass role that triggers an audit event. Turn on merge request approval settings: prevent author self-approval, prevent committer approval, require at least one approval, and reset approvals when new commits are pushed.
Days 15 to 35: policy enforcement. Extend the security policy project to all five top-level groups. Add merge request approval policies requiring a security or compliance approver for changes to financial reporting code. Where the compliance pipeline is used, make it required rather than advisory and protect the pipeline configuration in a separate project that maintainers cannot edit.
Days 35 to 50: evidence. Test audit event streaming end to end with a synthetic event and confirm arrival in the SIEM. Set retention in the SIEM to at least the audit period. Export protected branch settings and approval settings monthly through the API and store them as evidence.
Days 50 to 60: detection and verification. Alert on any change to protected branch settings, push rules, or approval settings. Sample 25 merged MRs again and verify four-eyes approval and pipeline execution. Publish a break-glass procedure with retrospective review, because a control that blocks emergency fixes without an exception path will be bypassed.
3. What evidence should be handed to the auditor, and what residual risk remains after remediation?
Read the worked answer
Hand over four evidence sets. First, configuration evidence: a dated export of protected branch settings, push rules, merge request approval settings, and the compliance framework assignment for each of the 60 projects. Second, transaction evidence: for a sample of merged MRs, the approval records showing approver identity and timestamp, the pipeline ID and result, and the merge commit. Third, policy evidence: the versioned policy YAML and the compliance pipeline definition, with commit history showing when each control took effect. Fourth, monitoring evidence: SIEM ingestion confirmation, alert rules for configuration changes, and audit events for any break-glass pushes.
Residual risk remains. Administrators can still change group settings, so the monitoring and alerting matter as much as the initial configuration. Audit events do not capture every read operation, and repository clones are not individually logged, so the auditor should understand that evidence proves change control, not full data access history. Break-glass pushes are a deliberate exception; they are defensible only with retrospective review and a time limit. Finally, the compliance framework does not cover projects added to the group after remediation, so pair it with a periodic scope review that detects new financial reporting projects and applies the framework automatically.