Version control, review and approval workflows applied to policies and control definitions.
40 min 160 XPSkills: Git, Change management
Policies are source code that happens to be prose
A policy in a shared document has no history you can trust, no review you can prove, and no single copy you can point at. A policy in a repository has all three for free: every change is a diff, every diff has an author, every merge has an approver and a timestamp, and there is exactly one canonical version.
The same is true of control definitions, standards, procedures, IaC guardrails and the code of the automated checks themselves. Once GRC artifacts live in version control, change management stops being a process you document and starts being a property of the tooling.
The goal is not that GRC people learn git. It is that GRC artifacts become reviewable by the same machinery engineering already trusts.
The pull request is the control
Almost every change-management control asks the same four questions: who requested the change, who independently authorised it, was authorisation enforced rather than requested, and can the record be altered afterwards. A protected branch with required reviews answers all four as a by-product of normal work.
Branch protection is the preventive half, it refuses the merge, while the merge commit is the detective and evidentiary half. Note the ordering: without protection, the review is a convention that a hurried engineer can bypass, and a control that can be bypassed at will is not operating.
Four control attributes, all satisfied by artifacts the team already produces.
One source of truth, or none
The most common failure is not technical. Someone exports the policy to a wiki page or a PDF for "easier reading", and from that moment there are two versions. Within a quarter they disagree, and the one the auditor is shown is rarely the one people follow.
Pick the repository as the source of truth and make every other surface a generated, read-only rendering of it. If the wiki cannot be generated, delete the wiki page and link to the repo. Divergence between copies is drift, and drift is what turns a passing control into a finding.
What the repo cannot prove
Version control is a change record, not an operating record. It shows that a policy was approved on a date; it does not show that the access review described in that policy ever happened. Design effectiveness lives in the repo. Operating effectiveness lives in the run logs of the control itself.
Two more caveats. Commit metadata is trivially forgeable unless commits are signed, so a high-assurance environment enables commit signing and requires it at the branch. And history rewriting, force-pushing over the branch, silently destroys the trail, which is exactly why the setting that forbids it matters as much as the review requirement.
Bring run evidence from somewhere else. The repo will not supply it.
Tasks
Answers are graded on the server: the answer key never reaches your browser.
Task 1: The history that got tidied
Scenario sim+55 XP
Name the operation that destroyed the trail, then the setting that would have refused it.
Incident brief
The auditor samples three policy changes from March. Two reconcile perfectly. The third, a change to the encryption standard, appears in the current file but there is no commit that introduced it, and the merge commit the team cites has a different diff than expected.
The engineer explains cheerfully: "I rebased and force-pushed main in April to clean up some messy commits. Nothing was lost, the final content is identical."
The repository has required reviews enabled. It does not have the adjacent setting enabled.
Term bank, not all of these are right
force pushbranch protectionrebasesquash mergecommit signingcode owners
1.1Name the operation that destroyed the March trail. (two words)
1.2Name the repository setting that would have refused it. (two words)
Task 2: Two policies, one company
Scenario sim+55 XP
Name the property the repo should hold, then the failure the wiki copy created.
Incident brief
Policies live in a git repo, reviewed by pull request. Six months ago someone pasted them into Confluence "so non-engineers can read them", and the onboarding checklist links to Confluence.
The auditor requests the access review policy. The team sends the repo version, which requires quarterly reviews. Interviews with two managers describe a semi-annual cadence, which is what the Confluence page says, edited in August by someone who is no longer at the company.
Both documents are internally consistent. Both are titled "Access Review Policy v3".
Term bank, not all of these are right
source of truthdriftversioningshadow itexceptionchange management
2.1Name the property the repository must hold exclusively. (three words)
2.2Name what happened between the two copies. (one word)
Task 3: The repo is not the run log
Scenario sim+50 XP
Name what the repo evidences, then what the auditor still lacks.
Incident brief
Northwind's control states that quarterly access reviews are performed. For evidence the team submits the repository: the policy file, its approval history, the reviewed pull request that defined the control, and the source of the script that generates the review spreadsheet.
The auditor accepts all of it and then issues an exception anyway. The engineer objects: "Everything is version-controlled and approved: this is stronger evidence than any screenshot."
The script exists in the repo. It has never been scheduled.
"We already have change control: every change has a Jira ticket, and the tech lead approves his own PRs because he wrote the code and knows it best."
A ticket is a record of intent; branch protection is the enforcement. Write the repository governance record so the review requirement is enforced by the platform and evidenced by its API.
Repository facts
repo: acme/platform default branch: main
Current state: protection disabled, 41 direct pushes to main
last quarter, CODEOWNERS file absent, one reviewer who is
usually the author.
Evidence sources available: github-api | jira-api | confluence
Conventional CODEOWNERS location: .github/CODEOWNERS
Six pull requests are open against the controls repository. Your colleague wants them all merged before the release freeze this evening.
Accept the ones that preserve the provenance the repo exists to provide. Reject the ones that break the audit trail, bypass review, or bundle unrelated change into a control edit.
Verdicts are accept or reject. Every rejection needs one reason code from: no-independent-review | breaks-provenance | scope-creep.
Open pull requests
G-1 Adds control AC-07 with owner, frequency and assertion. One reviewer approved. Signed commit.
G-2 Edits the assertion on AC-02. Author approved their own PR to hit the freeze.
G-3 Fixes a typo in a control description. Unsigned commit from a personal address not in the org.
G-4 Updates the evidence query on AC-04 and, in the same PR, rewrites the CI workflow permissions.
G-5 Force-push that rewrites six months of history on main to "tidy up" the log.
G-6 Retires control AC-09 with a deprecation note, linked ticket and one independent approval.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Checks
Every line in the fixture carries a verdict
Accept and reject land on the right lines
Each rejection cites a valid reason code
Next on your path · Automation & Code
Controls as Data
Model a control catalog in YAML/JSON and OSCAL so it can be queried, diffed and tested.
