My sibling chomps reply gets it. You need to explain "peer review" or "merge requests" functionality from github, gitlab, what have you. Basically, you have:

My sibling chomps reply gets it. You need to explain "peer review" or "merge requests" functionality from github, gitlab, what have you. Basically, you have: - An Author - Tests - Reviewer(s) - Audit - Robots - Protective Monitoring You should be able to explain that your average developer cannot bypass this, offering you greater assurance than the paper driven process before, and then point holes in the current process such as, people deploying manually can change the deployment after it's signed off. You can also mention that working in this way allows you to alert and triage on all assumed roles that aren't a robot account, meaning nothing that hasn't been reviewed should happen on your production cloud account, for example. Depending on the InfoSec team you might need to present your own risks, such as the CD environment, robot account setup, how they assume roles, the administrators, etc. I've been explaining this stuff to old school InfoSec teams for around 5 years now and have got pretty good at it. As long as they're actually interested in the risks, rather than just exerting control, you should be able to explain it to them.