My hypothetical universe is "I believe GitHub is too big to fail and want to spend as little resources to please the auditor as is reasonably possible without resorting to fraud".
So really what I'm asking is "how strict are these audits really?"
Github is owned by Microsoft so I'm assuming, maybe incorrectly, that they're well funded.
Internal audits are always subject to gaps, but if the stated issue is correct "a load balancer config change gone pear shaped" an audit wouldn't have caught that necessarily.
Unless the audit wants to test their change control, deployment methods, and redundancy.
Are they changing all of their load balancers all at once? Seems non optimal.
Maybe change only one at a time, or a small batch.
Are they propagating load balancer changes from a canary to production without vetting it's good?
Or did they vet it and they were wrong - some difference in their canary or analysis had a short coming?
And even if all of that was A-OK why did a mistake (and we all make mistakes) not get reverted quickly?
Were there insufficient internal controls to revert small mistakes and keep them from becoming site wide outages? And so on.
I suspect these kinds of discussions are happening. Or, maybe not. Who knows?
It's a 3rd party, and even if your whole organization's life depends on it you only know what they tell you.
So really what I'm asking is "how strict are these audits really?"