When a written control becomes a check in a codebase, somebody made a judgement call. Usually several. That judgement is the actual artefact, and it is almost never recorded.
The control says a setting must be enforced. Your code decides which hosts count, what enforced means when the platform offers three mechanisms, and which of the vendor's own defaults constitute a legitimate deviation. All three are interpretations. All three can be defensible. None of them are in the benchmark.
Write the interpretation down
Next to the check, in the repository, in prose. What the control says, what you decided it means here, and why. When an auditor asks why a system passes, the answer should be a file, not a conversation with whoever wrote it.
This is also how you survive staff turnover. An undocumented check is a check nobody will dare change, which means it will drift out of correctness and stay in the suite forever.
Version the interpretation, not just the code
When the benchmark updates, the interesting question is not "did the code change" but "did our reading of it change". Those are different events and they deserve different reviews.