4 ms·

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

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.

jayd16 4mo ago
Who gets in trouble if it turns out you are actually held to the literal rule?
- tsunamifury 4mo ago
  If you think rules are literal than you aren’t aware how the world works. There’s a reason it’s called “judgement”
  - jayd16 4mo ago
    ...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 4mo ago
      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
  - deleted 4mo ago
    [deleted]
  - rectang 4mo ago
    In your world, do subordinates ever get scapegoated for bending the rules at a boss's behest?
- scott_w 4mo ago
  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.
- PeterStuer 4mo ago
  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.
  - jayd16 4mo ago
    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 4mo ago
      '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 4mo ago
        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.
thewebguyd 4mo ago
> 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.
- hparadiz 4mo ago
  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 4mo ago
    Sounds like communication between departments sucks. If IT develops for them, you’d expect there to be a feedback loop?
    - hparadiz 4mo ago
      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 4mo ago
    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.
- antonvs 4mo ago
  > 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.
davedx 4mo ago
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 4mo ago
  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.
  - notarobot123 4mo ago
    scruples are also often a surface of friction that get in the way of business objectives.
  - treszkai 4mo ago
    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".
- Markstar 4mo ago
  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).
raducu 4mo ago
> 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.
- CSSer 4mo ago
  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.
- fireflash38 4mo ago
  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.
- ziml77 4mo ago
  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.
- arethuza 4mo ago
  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.
protocolture 4mo ago
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.
wanderlust123 4mo ago
It’s not a highly creative art at all, genuinely don’t get this weird compliance glazing here.
patrulek 4mo ago
> 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?

jayd16 4mo ago

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

tsunamifury 4mo ago
If you think rules are literal than you aren’t aware how the world works. There’s a reason it’s called “judgement”
- jayd16 4mo ago
  ...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 4mo ago
    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
- deleted 4mo ago
  [deleted]
- rectang 4mo ago
  In your world, do subordinates ever get scapegoated for bending the rules at a boss's behest?
scott_w 4mo ago
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.
PeterStuer 4mo ago
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.
- jayd16 4mo ago
  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 4mo ago
    '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 4mo ago
      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.

thewebguyd 4mo ago

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

hparadiz 4mo ago
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 4mo ago
  Sounds like communication between departments sucks. If IT develops for them, you’d expect there to be a feedback loop?
  - hparadiz 4mo ago
    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 4mo ago
  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.
antonvs 4mo ago
> 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.

davedx 4mo ago

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 4mo ago
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.
- notarobot123 4mo ago
  scruples are also often a surface of friction that get in the way of business objectives.
- treszkai 4mo ago
  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".
Markstar 4mo ago
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).

raducu 4mo ago

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

CSSer 4mo ago
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.
fireflash38 4mo ago
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.
ziml77 4mo ago
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.
arethuza 4mo ago
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.

protocolture 4mo ago

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.

wanderlust123 4mo ago

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

patrulek 4mo ago

> 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?