Hacker News Reader

Comment by beat | Hacker News Reader

I suspect most of HN hasn't ever worked in a compliance-driven, regulatory environment. They've never had to deal with the possibility of audits by government, insurance, or financial regulators.

This is the world I live in - building pipelines for financial and health care giants. I agree with this article 100%. Not only can continuous delivery provide regulatory compliance consistency, but also more traditional human-bureaucracy approaches cannot provide it. There are too many potential leaky spots, and far too much potential for human error - in particular, people signing off on things they don't understand. And this includes compliance auditors!

View on HN

And when someone asks you for proof that some check that you happen to have automated was run, you get to ask "and how many reams of paper's worth of proof would you like?" instead of saying "umm, uhhh..." and rummaging around trying to figure out what you can send.

I love being able to show the lines of code that say "This code cannot advance to a prod-deployable state if the tests haven't passed, because here's where it gets rejected".

The problem is that you're often showing those lines of code to someone who became an auditor because they're incapable of authoring or even understanding what those lines of code are doing.

Or you're showing them to technical management, architects, etc, who are quite capable of understanding their importance and see how those lines benefit them, the ones on the front lines for compliance issues.

Your snarkiness aside, that’s why it’s important to find an auditor that understands your business. Traditional auditors understand traditional compliance regimes. If you want to use innovative compliance methodology, like relying on infrastructure as code for instance, then you need an auditor who understands those practices.

Take PCI for example. A couple of years ago they released a document called Cloud Computing Guidelines, which was basically guidance for compliance through software defined network and that sort of stuff. As a PCI QSA (auditor), you may not ever need to know about these guidelines, or that they even exist. But if you want to work with business that rely on them then you’ll need to, and if you want to implement them in your organisation, then you’ll need to find a QSA that understands them.

Auditing is a partnership. Truth be told, as an engineer, you can probably get things past the auditor with some judicious lies and by socially engineering some confidence. I don't even think it would be particularly hard.

But I don't envy you when you get caught. The consequences basically open at losing your job and all possible good references from that job, and get progressively worse from there depending on the kind of audit. I don't intend to become more informed about the consequences, personally.

(I've only waded into this world, but my most likely future trajectory is only up, up, up.)

>Not only can continuous delivery provide regulatory compliance consistency, but also more traditional human-bureaucracy approaches cannot provide it.

Ehhh... I work in a regulated environment, and think I disagree. The reason I don't know if I do is because it's really a question of definitions.

By this article, developing with our super-manual bureaucratic compliance process of 15 years ago was CD (and probably further back, I've never had to dig that far in the archives). The things we did in the name of disaster recover, control-ability and traceability fit the provided definition of "deployment pipeline."

At the very same time, I think this article is trying to say our highly automated tool-assisted compliance processes of today are not "continuous compliance" because we have manual stakeholder synchronization gates and quality-enforcing review gates on the way to production.

It’s just been quite a pain to work with many startups who don’t come from such an environment given that we are in a regulated environment.

Totally agree.

Reply on news.ycombinator.com