[PeterStuer]

I have worked on highly regulated areas in finance (risk). Compliance is a highly creative art, often requiring lots of out-of-the-box thinking and non-obvious solutions. The people I found worst at this were IT. They tend to over-interpret regulation, and super-restrict beyond what is needed for actual de-facto compliance.

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.

[davedx]

Ha. I've worked in a fairly strongly regulated sector (energy, in the Netherlands), where I collaborated closely with our head of compliance, and she heavily over-interpreted the regulations while I often tried to find more pragmatic solutions.

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.

[jval43]

I've found two things to matter:

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.

[treszkai]

I'd also add a willingness to follow the (perceived) intent of the rules as opposed to gaming the letter of the rule. An experienced folk might say, "yeah it won't matter legally", and continue with "but it will matter to me because this rule is in place for this-and-that reason".

[notarobot123]

scruples are also often a surface of friction that get in the way of business objectives.

[Markstar]

It's not even limited to SWE - there are so many regulations in almost every trade (which sometimes contradict each other) that it often eventually boils down to your experience and your decision which rule to follow and which to 'bend' (for example in "traditional" architecture there are so many rules that the building authority itself has to compromise on following the law by the book).

[thewebguyd]

> IT. They tend to over-interpret regulation, and super-restrict beyond what is needed for actual de-facto compliance.

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.

[antonvs]

> IT. They tend to over-interpret regulation, and super-restrict beyond what is needed for actual de-facto compliance.

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.

[VonGallifrey]

> But a company that does that is basically delegating both compliance and legal functions to IT. No sane company does that.

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.

[thewebguyd]

> But a company that does that is basically delegating both compliance and legal functions to IT

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.

[mlinhares]

That's actually pretty important, if you're an eng doing compliance work and you don't have legal counsel working side by wide with you you might be putting yourself up for legal troubles down the line. I'm glad I can always rely on legal do do their job here when doing this kind of work, I wouldn't want to do work like this just out of my ass.

[DaedalusII]

perfect IT response

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

[dumah]

Regulators don’t want to provide arbitrarily detail into their interpretation or likely judgements on issues that may come up for many reasons, good and bad.

One good one is that providing concrete razors for compliant and non-compliant behavior accelerates the gaming of the rules.

[fragmede]

> compensating controls

How to say you deal with PCI compliance without saying you steal with PCi compliance.

[mgh95]

Compensating controls also come up in the context of BSA/AML.

[ValtteriL]

Also in IEC 62443

[mgh95]

Also in OFAC compliance. It just comes up in a lot of places where workflows are compliance heavy.

[hparadiz]

It's cause IT never has to live with the consequences of their decisions. Who cares if the other department keeps bleeding talent because you twisted the knobs so hard no one wants to work in your system?

[JimBlackwood]

Sounds like communication between departments sucks. If IT develops for them, you’d expect there to be a feedback loop?

[hparadiz]

Yes. Exactly. This is not a reflection of where I am now in any way shape or form. Just my observation of previous places I've worked.

[lmz]

Why would they care? They take the blame when it gets hacked, but don't really get any upside for bending the rules to make people work easier. CYA rule-following is just to be expected.

[raducu]

> he people I found worst at this were IT.

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.

[arethuza]

I remember working with a corporate customer whose in house architecture team was so difficult to work with that I joked that they could be replaced by a rule in their email system that simply replied "No" as the message if I ever emailed them.

[ziml77]

That was my experience too. Legal wanted things locked down hard. IT was more than happy to make things easier for users as long as legal wasn't getting in the way. Usually meant the systems were simpler too if we had fewer rules and controls to enforce.

[fireflash38]

Auditing is assumption of blame or responsibility to another party.

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.

[CSSer]

I don’t think you’re going to find a consensus on this because it really just comes down to the quality of the employees in each discipline. Actions speak louder than words. I’ve seen the IT people GP is describing. I’ve also seen yours. In GP’s scenario, they often even mean well but are very overwhelmed because they’ve come to exist in a space where _everything is IT_ because no one else is remotely qualified to fill the specialty gap. When I found myself in your scenario, the opposite was true and it completely matched what you described.

[protocolture]

I once worked on a data compliance job, and the auditor would fail everything he possibly could. He was there for data destruction compliance, but like many such people, he came from an engineering background. He would complain about everything. Gaps between pallets. OHS. Whatever he could to justify his decisions. He never found a bit on a disk out of place and he still made our lives hell. Failure for the floor didnt feel solid enough. Failure because he didnt feel comfortable in a warehouse environment. And when the management had had enough and decided to refuse him entry and ask for someone else, we had to hold ourselves to an even higher standard to compensate.

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.

[jayd16]

Who gets in trouble if it turns out you are actually held to the literal rule?

[PeterStuer]

Contrary to what you indicate rules are not declared in a vacuum, for people to read and then algorithmically 'implement'. There are many ways to interpret regulation, and there will be both accompanying clarifications, as well as compliance departments negotiating with regulators on what is an acceptable and sufficient compliance action. Then there furthermore is a risk that will be calculated vs the cost and opportunity costs etc.

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.

[logicalmind]

I also work in finance and my recent experience with regulators is really discouraging. DOGE wiped out a large amount of the regulators in government. It seems like most of the regulators remaining are the inexperienced and low tenure. Within the past few months we've attempted to roll out new financial products. When we attempt to send our proposal to them, they can't even tell us who we're supposed to send it to.

It doesn't feel like we're living in the same world of regulation that existed prior to DOGE.

[throwaway2037]

    > I also work in finance... DOGE wiped out a large amount of the regulators in government.

I found an insanely detailed Wiki page about all of the gov't divisions affected by DOGE: https://en.wikipedia.org/wiki/US_federal_agencies_targeted_b...

However, I don't see anything about finance there. I'm confused by your comment. Can you provide more specifics?

[logicalmind]

Not sure why it's not covered in that wiki article, but I'm specifically referencing the FDIC and related agencies. They have been so decimated by DOGE that it is possible that multiple of those related agencies will be consolidated into one (FDIC, NCUA, OCC, etc.).

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.

[jimbokun]

So the DOGE geniuses failed to remove the regulations they allegedly thought were hampering legitimate businesses, while removing the people capable of verifying whether or not your business is in compliance.

What a win!

[jrflowers]

They wiped out anybody that was hampering their businesses. Leaving the rest as an impossible barrier to entry for everybody else is a feature, not a bug.

[jayd16]

The point was about who is on the hook and why they might be less permissive.

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".

[PeterStuer]

'The company' would be on the hook. Inside, it might be the compliance team that signed off on the solution, but it usually is not the sort of blame game at that point. I'm not saying these scapegoat trails do not exist, but they are far less common than you would imagine if you only read about them in the press.

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.

[rectang]

I am skeptical that developers who implement a non-compliant solution that gets a company in trouble get off scot-free.

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.

[fauigerzigerk]

>I am skeptical that developers who implement a non-compliant solution that gets a company in trouble get off scot-free.

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.

[kanbankaren]

> There are many ways to interpret regulation,

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.

[habinero]

> Then the rules should enumerate all the ways

It's nice to want things, but rules are much squishier in real life. There's rarely any truly bright line.

[patrulek]

It isnt programmers fault though.

[PeterStuer]

"you come across as if programmers don't know what they are doing"

Is neither what I said nor believe.

[scott_w]

That's why you work with your Legal/Compliance Team to make sure you stay in line. They can explain when a rule applies and when it doesn't. This needs the engineering side to be able to explain what's happening, and translate it into the business process as closely as possible, and the legal side to be able to apply the law to the case.

[tsunamifury]

If you think rules are literal than you aren’t aware how the world works.

There’s a reason it’s called “judgement”

[rectang]

In your world, do subordinates ever get scapegoated for bending the rules at a boss's behest?

[jayd16]

...And that judgement could take them literally. So what is your point?

My point was simply that it's easy to scoff at someone else being careful if it's their neck and not yours.

[parineum]

They could but they don't. That's pretty much the whole job. You can also appeal decisions to a more reasonable party if you draw RobotJudge3000 for your trial

[patrulek]

> mistakes as the programmers: taking 'rules' literally

Isnt it how we make stable, deterministic and predictable system? How do you want to create one with ambiguous rules?

[wanderlust123]

It’s not a highly creative art at all, genuinely don’t get this weird compliance glazing here.