[kevin_nisbet]

And the way they verify you are doing what you say you are doing is by asking you to provide evidence, which is usually pretty easy to demonstrate that a policy was followed once or twice, a lot harder for them to pick up consistency issues or exceptions.

[randerson]

I've had SOC2 auditors choose a random commit from our GitHub history, then ask to see the associated Jira ticket, logs from the build and deployment, etc. Hard to reliably pass an audit if you don't know which changes they'll drill down into.

They also asked for proof of system-enforced processes (e.g. GitHub branch protection rules and the setting for enforcing peer review for each change) which were basically proof of consistency.

[tptacek]

They do that because in the DRL process you specified a change management process involving Github and Jira. If you specified a different process (for instance, Post-It notes applied to the bathroom wall), they would randomly ask for evidence about those Post-It notes.

That's what we're talking about when we say virtually any tool you can come up with will satisfy "vulnerability scans". For Cloudflare, it was nmap. I think they're right about this.

[akerl_]

An example of what the parent commenter meant is more like:

1. You write a DRL that says “we do a disaster recovery test annually to ensure that we can restore a production backup”.

2. It takes you 20 tries in 2026 to do a successful restore because your find out the first 19 times that your backup is broken and incomplete.

3. You never have to mention the first 19 tries to the auditors when you prove you did do a successful DR restore.