Explain to me SOX Compliance


  • I survived the hour long Uno hand

    When we're moving code up to production, I'm being told compliance requires management to sign off on every change. How does that work with continuous integrationdeployment moving changes to prod multiple times a day?


  • FoxDev

    @yamikuronue In theory, management would be included in the process as approvers, and without their approval, builds wouldn't go up. In practice, it sounds like a clusterfuck in the making.


  • Impossible Mission - B

    @yamikuronue said in Explain to me SOX Compliance:

    How does that work with continuous integration moving changes to prod multiple times a day?

    It sounds like the only real answer is "it doesn't." :(




  • I survived the hour long Uno hand

    Our best idea so far is "the team manager works closely with their team and is considered a manager for the purposes of compliance, and they approve things all day every day. meanwhile, directors get a daily digest of change so they can say they were informed."


  • FoxDev

    @yamikuronue There are worse arrangements


  • Garbage Person

    Gate CD to prod. Do it less frequently than "every individual change" and digest them up once or twice a day for your scapegoat to "approve".

    Additionally, make sure every individual change is documented and approved well before it ever makes it into that list.

    It's also worth noting that, at least according to WtfCorp audit tradition, operational software doesn't count so long as it isn't directly handling money or financial data.

    I don't fucking believe them, but eh.


  • And then the murders began.

    @yamikuronue Does continuous integration really require moving to prod multiple times a day? Our CI process has us moving changes to QA/UAT several times a day, but we only do a blessed prod deploy about once a week.


  • I survived the hour long Uno hand

    @unperverted-vixen I misspoke because I was dashing out a message between meetings. We have continuous integration now, but we want to move to continuous deployment. My bad.


  • And then the murders began.

    @yamikuronue That makes more sense. Then I don't have anything better than your best idea so far...


  • :belt_onion:

    @yamikuronue said in Explain to me SOX Compliance:

    I'm being told compliance requires management to sign off on every change. How does that work with continuous integrationdeployment moving changes to prod multiple times a day?

    You just make 1 paperwork request that covers the whole batch and have the manager sign that. It's basically nothing but the CYA papertrail, nowhere have I seen it strictly enforced that you actually implement a control against things happening without being signed off.
    Just that if something does happen without being signed for, and you don't have a damn good reason, you're proper fucked. And if you do have a good reason, you're still in some shit.


  • ♿ (Parody)

    @yamikuronue said in Explain to me SOX Compliance:

    @unperverted-vixen I misspoke because I was dashing out a message between meetings. We have continuous integration now, but we want to move to continuous deployment. My bad.

    Continuous deployment sounds like a bad idea for so many reasons. I'm not a giant fan of SOX, but the idea is that executives need to be responsible for the stuff that happens, which isn't a ridiculous idea. And continuous deployment is really a contradiction of responsible. I suspect you need to pick one or the other.


  • I survived the hour long Uno hand

    @boomzilla What we have now is a ridiculous amount of overhead and signoffs. What they want is going to production with small batches multiple times in a day, with no interference needed once it passes pull request (and code review) -- so long as the tests all pass. I think what we'll end up with is an automated process that ends with the change in a queue waiting for manager sign-off. After sign-off it'll go into a queue to go to prod, with changes on a status board in Operations for them to be aware what's moving when and maybe stop things if they're going to conflict with something else.


  • Garbage Person

    So basically, as long as you have at least one person who didn't create that change and is nominally empowered to say "No" looking at a change and evaluating whether it is appropriate at some point before it goes to production, and you document who that person is, you're good to go.

    That said, :wtf: is your change velocity like that you want to go to production CD?

    WtfFramework, in aggregate, which is to say TWO HUNDRED separate, ill-tested, ill-designed production applications running on top of ONE HUNDRED separate, ill-tested, vaguely-designed framework components on a fleet of 30+ Windows boxes with all the infrastructural complexity that involves only really generates 2 or 3 changes per day.


  • And then the murders began.

    @weng 2-3 changes per application, or across the fleet?

    Our system that sounds like WtfFramework's close cousin will easily have 2-3 changes per day for most of the individual applications. Doing continuous deployment would theoretically be reasonable for us, if we had code review and unit tests. Since we have neither - all the testing is manual - that's not going to happen anytime soon...


  • Garbage Person

    @unperverted-vixen said in Explain to me SOX Compliance:

    @weng 2-3 changes per application, or across the fleet?

    Our system that sounds like WtfFramework's close cousin will easily have 2-3 changes per day for most of the individual applications. Doing continuous deployment would theoretically be reasonable for us, if we had code review and unit tests. Since we have neither - all the testing is manual - that's not going to happen anytime soon...

    2-3 across the entire multiverse.



  • @yamikuronue have you got something like this set up? In theory, having a pause just before the 'deploy to production' step that requires a manager to click a button to approve each build seems like a good way to coordinate something like that. It's something I've been meaning to set up in our build process for while now.


  • I survived the hour long Uno hand

    @weng We have something like 100 IT people, about half of whom are developers working across multiple applications. Our change control meeting is getting to be over an hour sitting going through all the changes slated for our weekly release, and that's with every form just saying "weekly release for X" as the change description.

    @Buddy We didn't enable that feature because we enabled "built every time change is merged into master" functionality from Stash, and we use "deploy plans" to go to various servers on the way up to prod. Currently, only our operations folks can press the button to go to prod, and they only do so if they have a signed CR form. I can't seem to figure out how to get the feature you linked to play nice with the stuff we have set up already.



  • SOX compliance with CD can be done, but it takes care and work. A few years ago a financial firm [where application can move a Billion dollars a day] invested heavily to achieve this. The interesting part is when they dealt with the auditors.

    At first, the auditors wanted to reject everything and claim many violations. Sitting through each one, and looking directly back to the SOX legislation [rather than at any of the many published means of attempting to achieve compliance] was quite enlightening. After a (admittedly painful) first round, subsequent audits were a breeze.

    The key takeaway (at least for me), was be willing to invest and to also have staff (independent of the developers themselves) who are experts on SOX and can provide a correlation document between your process(es) and the legislation.


Log in to reply