I think adherence to regulation and compliance is nothing to do with whether you're a SWE, a risk officer, or C-level, and everything to do with your own principles, ethics, professional attitude, and pragmatism.
1. experience, i.e. knowing why and how a rule matters (in general, but also to auditors)
2. willingness to think
If these aren't present, you get overly restrictive compliance that at the same time accomplishes nothing.
IME this is less the fault of IT and more so bad auditors that won't consider, or just don't understand, what compensating controls are. If it doesn't meet their little checklist exactly, they fail the audit.
This is such a nonsensical claim. If a company is asking someone from IT to read the regulations and implement them, then obviously you’re going to get something that conforms to the written specification they were provided.
But a company that does that is basically delegating both compliance and legal functions to IT. No sane company does that.
regulation are written ambiguously and the specifications do not match the industry
I have even seen regulators refuse to specific legislated laws because "thats not what the government meant", giving a company the choice of following the law and being fined, or breaking the law to please the regulatory agency
One good one is that providing concrete razors for compliant and non-compliant behavior accelerates the gaming of the rules.
I was a Software Dev in a small (but fully regulated and licensed) stock exchange. We used to have guidance from legal experts, market experts, and traders, but in the last project I worked on, they just dumped 300 pages of laws and regulations on my desk and asked me what needed to be done. Why? Because the experts we used to have were either fired or left. Along with any product managers. I guess company leadership thought they were no longer needed.
Insane is right. I told them that this is not how it is supposed to work. I can't tell them what needs to be done. I am not a legal expert who can just interpret these regulations.
I was forced out of the company after that, but honestly, no one would want to work in such an environment anyway.
This actually happens scarily often, especially in smaller companies. No F500 is doing this, but there are tons of "mid market" sized non-tech companies (think 80 to 150 employees in size) that basically rely on the IT department of 1 or 2 people, or an MSSP for pretty much everything. No legal team, maybe an attorney they consult with once or twice a year if you're lucky.
How to say you deal with PCI compliance without saying you steal with PCi compliance.
My experience as IT in modern banks was the opposite. The legal department were absolute assholes when it came to software features. And I'm talking absolutely 100% ok features, like paying your bills from the banking application.
The least fun, trigger happy, cover their buts people I've ever seen.
Like all they could ever say was NO. I guess they were heavily incentivized to just say NO to everything.
They are incentivized to strike the best balance of certifying (who wants to go to a place that never certifies) and validity (rubber stamp mills reflect the blame).
Yes, it is meant to be adversarial, to a point.
As an enterprise architect, these are all part of the meetings you have with compliance when you are working on major projects. I have had the privilege of working with some excellent compliance officers, and they are the opposite of the nay-saying caricature that is often painted of them. I found these people to be extremely creative and helpful, working together towards solutions rather than stalling or nixing viable progress.
It doesn't feel like we're living in the same world of regulation that existed prior to DOGE.
What a win!
> I also work in finance... DOGE wiped out a large amount of the regulators in government.
However, I don't see anything about finance there. I'm confused by your comment. Can you provide more specifics?
I can't go into too much detail, but for a financial institution to offer certain financial products, you have to submit a proposal to one of the above regulatory bodies to get their approval. We were attempting to do just that and we couldn't even find the proper person at the given agency who should be receiving said proposal. It was even rumored that regulatory agency who would normally review such proposals didn't have the staff to review them. And the review would be done by an entirely different group of regulators who have not done such things historically.
Additionally, these agencies do regular exams of financial institutions to ensure they are complying with regulations and handling fraud properly. These cuts have led to those exams either not happening, or happening at a fraction of the depth they had been previously.
I'm not implying anything else. I used your own "literal" wording to refer to the "more strict than yours" interpretation.
I suppose I should have used scare quotes around "literal".
Company politics, feudal wars, fiefdom protections, backstabbing and outright sabotaging, now there's a daily occurrence and many minions are cannon fodder in those skirmishes, but they usually stay clear of regulatory issues minefields.
If the company you work for actually had such a no-fault culture, I doubt you'd be criticizing programmers so aggressively for being sticklers, but would instead be trying to understand and account for the systemic factors (including human factors) behind their behavior.
I don't see why developers should be in trouble. Developers don't make unilateral decisions on non-trivial compliance matters. A finding of non-compliance at a financial institution would typically be the result of an investigation, a disagreement with the regulator or a court ruling. It would come years after the organisation as a whole decided to adopt the interpretation in question.
Engineers are not shielded by their implementer role if they participate in illegal activity. James Robert Liang was a rank-and-file engineer for Volkswagen and he got jailed for his role the VW emissions scandal[1].
No matter how much an enterprise architect or compliance officer promises "it'll be fine" to the developer, the developer needs documented CYA. An enlightened organization would perhaps find ways to expedite that CYA documentation rather than demonizing programmers as a class.
[1] https://apnews.com/general-news-988ea2ae45694b37b320e68cefe3...
Liang got prison time because he _did understand_ that the engine wasn't compliant with regulations and chose to build the system to falsify the emissions output during tests anyway. He was not a scapegoat.
"On 9 September 2016, James Robert Liang, a Volkswagen engineer working at Volkswagen's testing facility in Oxnard, California, admitted as part of a plea deal with the US Department of Justice that the defeat device had been purposely installed in US vehicles with the knowledge of his engineering team: 'Liang admitted that beginning in about 2006, he and his co-conspirators started to design a new "EA 189" diesel engine for sale in the United States. ... When he and his co-conspirators realized that they could not design a diesel engine that would meet the stricter US emissions standards, they designed and implemented [the defeat device] software.'" from https://en.wikipedia.org/wiki/Volkswagen_emissions_scandal
"decisions which they don't understand to be compliant" = "decisions which they don't believe to be compliant"
In other words, they understand that the decisions are not compliant. There's no contradiction with what you said.
Complain about them, denigrate them, upbraid them for performing analysis outside their primary expertise, fire and replace them.... none of that changes the incentive structure that shunts people in the implementation role towards conservatism out of a perceived need for self-preservation.
a) Engineers don't know and cannot be expected to know whether what they are being asked to implement complies with all regulations. This is completely normal.
b) Engineers know or can be expected to know based on their expertise that they are being asked to cheat. That's when they are on the hook.
VW was a case of (b). It was clear-cut criminal behaviour on a very technical level. But that's not what typically happens in financial services and many other domains.
But if your point is merely that engineers are not automatically in the clear just because someone higher up told them what to do then I agree with you.
Then the rules should enumerate all the ways. From your posts, you come across as if programmers don't know what they are doing which is insulting to those who work in mission critical industries like aviation where a programmer could be criminally charged if he/she didn't implement the specs STRICTLY.
Is neither what I said nor believe.
It's nice to want things, but rules are much squishier in real life. There's rarely any truly bright line.
There’s a reason it’s called “judgement”
My point was simply that it's easy to scoff at someone else being careful if it's their neck and not yours.
Later I worked in a role, attempting to achieve PCI compliance. The Auditor was a really nice guy, but there was always a short list of 10 things that he wasn't quite happy with. We kept increasing the scope of compliance to keep up with him. Everyone talked about him (Semi famous local celebrity security consultant/researcher/lecturer) and claimed that if we just stuck it out we would be super duper compliant and basically unassailable. Except that it never ended. Went 12 months with the guy. Then they just stopped paying his bills and brought in another auditing firm. Compliant immediately. You never know in a situation like that whether we were actually compliant or if there was graft. But we got there. Knowing that organisation I lean towards graft. They then failed their first audit after achieving compliance.
I have done a few PCI compliance operations since. And what I have found that you cant control for the auditor, so what good IT management does, is make every single requirement completely unassailable. If you cant write a very obvious compensating control in 5 sentences, then you just move heaven and earth to comply with the letter of the requirement (even if the project to become compliant, is itself a compensating control for a while). If you get an over achieving auditor, you wont spend 200 billable hours arguing about compensating controls. If you have a shit auditor, you know you are compliant even if they aren't being as thorough as they could possibly be. Its the only ethical way to navigate the situation.
My guess is the model makes the same mistakes as the programmers: taking 'rules' literally, unaware of sectoral joint understanding, validated interpretations and habits. (btw. this is often on the non-tech side also a difference between regulatory and legal. The former are much more result oriented while the latter are primarily risk averse.