Every time a written control becomes a check in a codebase, somebody made a judgement call. Usually three or four. That judgement is the actual artefact of the work, and in most repositories I have looked at, it exists nowhere.
The control says a setting must be enforced. Fine. Your code has to decide which hosts count as in scope. It has to decide what enforced means on a platform that offers three different mechanisms for it, two of which the vendor considers equivalent and one of which the auditor may not. It has to decide whether the vendor's own shipped defaults constitute a legitimate deviation or a finding. Those are three interpretations. Each can be defended. None of them appear anywhere in the benchmark.
Then someone leaves, and the interpretation leaves with them.
Write it down next to the check
Not in a wiki. Not in the ticket where it was argued out. In the repository, beside the code, in prose: what the control says, what we decided it means here, and why we decided that.
When an auditor asks why a particular system passes, the answer should be a file you can open, not a conversation with whoever happened to write it. The first time I sat in a review and could point at a paragraph instead of reconstructing my reasoning from memory in front of an audience, I understood why this was worth the twenty minutes.
It is also the only defence against a specific slow failure. An undocumented check is a check nobody dares modify. It stays in the suite forever, gradually drifting out of correctness, protected by exactly the fear that should have prompted someone to fix it.
Version the reading, not just the code
When a benchmark updates, the question everyone asks is whether the code changed. That is the less interesting question.
The interesting one is whether our reading of it changed — whether a rule we had interpreted narrowly is now unambiguously broader, or whether an exception we granted three years ago is no longer contemplated by the text. Those are different events from a code change and they deserve a different kind of review, with different people in the room.
Compliance as code is a good idea. What makes it honest is admitting that the code is an opinion about the prose, held by a specific engineer, on a specific date, for reasons that made sense at the time. Write the opinion down. It is the part that ages.