Hacker News Reader

I currently work in Tech Strategy at a Big 4 - the reason why Big 4s want to roll it back is because over the last few years, their revenue in audit is steadily decreasing. Especially with automated tools, outsourcing, RPA taking over and making a lot of the grunt work significantly cheaper. At the same time, the consulting revenues are significantly going up. SOX limits the scope of work the Big 4 can execute at firms they audit (nothing related to financially significant systems etc.). The best client relationships are with the firms the Big 4 audit! Hence, the push!

The good ol' "channel 1" versus "channel 2" conflict, or whatever it's called nowadays.

Basically Big 4 "have to" audit but what they really want is to offer consulting services. There's a huge conflict of interest regarding these two parts and every few decades the Big 4 are forced to spin off consulting divisions. Not that stops them from trying again :)

Isn't this why Sarbanes-Oxley was introduced to begin with? Auditors getting too cozy with the companies they are meant to be impartially auditing, because most of their revenue actually comes from consulting.

The book The Number talks about this quite a bit: https://www.amazon.com/Number-Quarterly-Earnings-Corrupted-C...

This. I'm a former Big Four auditor, and I can tell you that the consulting-auditing dichotomy is very clear in the industry. Auditing is on the downswing revenue-wise, and consulting will always rake in the dough. My issue is that the consulting relationships (and the big money they bring in) will necessarily impact the independence of the auditors, which is one of the main reasons there is the whole 'Channel 1' - 'Channel 2' split in the first place, and the major reason SOx passed. The Enron debacle was almost entirely because of the fact that Arthur Andersen didn't want to lose out on the major consulting revenue they made from Enron, but were pressured to fudge audit findings or they would lose that client for everything. SOx was an absolute b*h to implement and deal with on the audit and client side, but it made perfect sense from a regulatory perspective. Still, when the clients are paying for their own audits, that's its own ethical issue.

tldr; It's complicated.

I've seen some very strange things done in the name of SOX compliance. I was involved in the potential acquisition in the UK of a subsidiary of a US public company and they used to print out their AD group memberships (as screenshots) and have someone sign (wet sign - with a pen!) the printouts every week/month.

When I asked whether SOX compliance really required this they basically said they didn't really know but had to play safe as the regulations were just so vague.

Reminds me a little of the medical device industry. We do a lot of things that from an engineering perspective result in worse products but since nobody understands the regulations fully we do them. Until a new guy comes in, re-reads the rules and says we can do it differently now.

If you think SOX is bad try finding someone to tell you exactly what you need to do to be ITAR compliant!

I work in the biotech industry and it's the exact same way. We have legions of lawyers who try and decipher the regulations.

A great example is price reporting to the gov't. You're supposed to report your net price across all sales to CMS on a quarterly basis. Problem is, the regulations are so vague that it falls on companies as to how to interpret them. Naturally, companies err on the conservative side (at least most of them). My old company probably had 20 FTE's dedicated to this one regulation.

And if you reach out to the regulatory body for clarification, that's a multi-year process. A great example is the AMP rule (average manufacturer price). I think CMS was supposed to role out the clarification back in 2012, but only finalized it last year. And there are still unanswered questions.

I used to work in the ecommerce space.. along with PCI our security/compliance people made us do lots of vague things with our delivery pipeline with the broad excuse of "SOX compliance"

When asked for the specific rule we had to follow, there was never any response.

My first question is how much of a burden is it really? Are we hearing the squeaky wheels, or is it actually pretty bad?

My second question is how much does it help. It's fine to say that it codifies practices that companies mostly do anyways (and if so, how bad can it be), but it was also a response to some troubling behavior in the market. How many problems does it prevent for the burden it exacts?

> My first question is how much of a burden is it really? Are we hearing the squeaky wheels, or is it actually pretty bad?

It's pretty bad. It was bad enough that we had to hire multiple full time people on our side just to deal with the interactions, people with engineering backgrounds who basically just did paperwork, who could have been doing much more useful things given their knowledge and experience.

> My second question is how much does it help. It's fine to say that it codifies practices that companies mostly do anyways (and if so, how bad can it be), but it was also a response to some troubling behavior in the market. How many problems does it prevent for the burden it exacts?

It's important to remember that there are two aspects to SOX: Operational and financial. I don't have a lot of experience with the financial side, other than to say they have just as much overhead, but perhaps it prevented a lot of things.

But from the operational side, it made us do things in bad ways so that we could show the auditors, and also slowed us down. For example, production access to financial data must be limited so that it can't be modified in production after the transaction but before it gets to the financial systems. Sounds like a good idea, but then when you have an outage, you have to scramble to find multiple people to unlock the access keys and watch over your shoulder while you make fixes on production systems.

Or instead you rearchitect your entire system so that only a few machines are actually handling financial transactions and keeping the rest out of scope.

Either way, it's a huge burden.

Another great example is password rotation. The law demands you have a password rotation policy. It doesn't say what that policy should be. Most auditors have settled on 90 days. Most researchers have shown that forced password rotation is bad. Without SOX, I would just follow the recommendation of the people who actually used science to figure out that password managers are better than password rotation. But with SOX, I either just follow the auditor's redone checklist, or spend a whole bunch of time convincing them that my policy is better than rotation. Either way, a bunch of overhead either for me or for all my coworkers.

> Sounds like a good idea, but then when you have an outage, you have to scramble to find multiple people to unlock the access keys and watch over your shoulder while you make fixes on production systems.

While I can understand that seems like a huge pain for a legitimately acting company, this is exactly the type of thing I would want to see a law like this enact. Sure, it slows down fixes when there are problems, but it sounds like it might have helped with past stuff like the Crazy Eddie fraud[1]. There's likely a spectrum between what happened there and what a respectable company like yours does, and requiring few keys to change this data and oversight while doing so likely helps quite a bit with operational incompetence as well.

> Another great example is password rotation. The law demands you have a password rotation policy. It doesn't say what that policy should be. Most auditors have settled on 90 days.

I've experienced this with PCI Compliance. It's annoying, but you have to realize that there are a lot of people and companies out there that have no idea about proper security, or continuously deprioritize it in favor of some other thing they need to get done. It's never a big deal until it is, then it's a huge deal. Making it mandatory, even if it overshoots a bit and is more cumbersome that it needs to be is beneficial overall because there are a lot of people like I described.

And that's sort of how I see these laws overall. For the people that are already mostly compliant it's burdensome, but if those people and companies are actually 10-20% of the market and the other 80-90% aren't really following best practices and are ripe for problems, whether they be security, management, operational or criminal, then I don't really care if it's somewhat burdensome for those 10-20%. If the companies that are using best practices already are 80-90% or more of the market, then sure, the law might be too burdensome for the benefit it infers (but it might not, depending on how bad the problems it prevents are).

And that's really the crux of the issue. How burdensome the law is to responsible companies is irrelevant without the context of how often it is useful to force the hands of irresponsible companies. How big is the group your company, as a responsible actor, represents? That's the missing information here.

1: https://news.ycombinator.com/item?id=13844316

That's a fair point. I've only ever worked for responsible companies.

If the checklists are actual implementations at the other companies, then yes, maybe there is some value there. But then the law could still be improved to allow a little more leeway for companies that are responsible. I don't know how that would work though.

> But then the law could still be improved to allow a little more leeway for companies that are responsible.

Bad companies already try their darndest to present as responsible, and if they never succeeded there wouldn't have been call for these regs in the first place. I don't think making a determination as to who "is responsible" and loosening requirements makes any sense - Enron and WorldCom would probably have been "responsible".

Better would be to try and align the regulations so that they have minimal friction while people are acting responsibly. Maybe you don't need a key and active oversight to make a change - maybe the change can be logged non-destructively and audit can happen after the fact.

>Another great example is password rotation. The law demands you have a password rotation policy. It doesn't say what that policy should be. Most auditors have settled on 90 days.

This is false. SOX does not require that you have a password rotation policy. It requires that you have a password control policy, which may or may not include password rotation.

Likewise, I've worked at a company whose idea of SOX compliance was mandating a VP to sign off on every code commit, and I've also worked at a company whose idea of SOX compliance was mandating that someone sight off on every code commit. The former had a 90-day password rotation policy, the latter didn't have a rotation policy at all.

In my previous job I was involved with IT of large corp and here is explanation I got:

Yes it is false but SOX does call for strict internal controls on financial information. Which means that password rotation is necessary so that people who are not anymore allowed to access information does not have access to these information any more. Thus password rotation is required.

I and my IT friends could be 100% wrong here but this is how these SOX vague requirements will be translated to IT admins.

I'm a former Big Four auditor, on the financial side, but I worked pretty closely with our tech folks and I'm now in the tech industry. SOx really does have very strict internal control requirements on financial data and how and where it can pass between systems and people, whether technological systems or physical ones. I've worked with clients who used strict password rotation to fit the law, as well as with clients who didn't do this. As long as the policies are clearly spelled out, do not allow those who are no longer supposed to have access to have access, and are consistent across the organization, it's all good. For example, one company I worked with changed passwords to one system only when someone rolled off the team working on it. That happened infrequently, but more than once a year. The policy was clear, written, and consistent, so it fit the internal control criteria.

Really, we'd need to find what are called 'material weaknesses' or 'significant deficiencies' to make us really stop and consider writing up a finding that would be published. 'Material weaknesses' are considered worse, and would likely lead to the possibility of a material misstatement in the financial statements of the firm. Deficiencies are a step below that. If the firm corrects them, we're okay for the most part, unless the weakness was terrible.

> strict internal controls on financial information. Which means that password rotation is necessary so that people who are not anymore allowed to access information does not have access to these information any more

How does rotating a password prevent access? That's access control, not authentication.

Unless it's a shared password, which is a bigger problem.

privileged accounts may become disabled by system policy if the password is not updated after >180 days of expiry

It is pretty bad. The desire to avoid having to deal with SOX compliance has pushed a lot of companies to sell themselves privately rather than IPO. A lot of the restrictions that are imposed make debugging and fixing operational problems a lot harder. Many of the policies that are imposed are actively harmful.

And, sadly, SOX compliance is easily bypassed by bad actors. I'm not convinced that Enron would have been stopped by the regulation. And even if it would have been, after several rounds of regulatory capture like the above, the regulation will be nothing more than another marketing channel for auditing companies.

I would not want to know what my employer spends but I know it takes my team of five plus a director four to six days to get through it all.

the amount of seemingly useless documentation is what irks me . I am sure there is value there but the whole thing comes across as a pointless exercise in compliance with whatever whims they have this year added onto previous requirements

A lot of the additional requirements year on year are driven by mandates from the PCAOB. If the audit firms do not comply then they are hit hard during the PCAOB reviews of their audit files.

The primary issue with onerous regulation is that which is unseen. How many companies and entrepreneurs choose not to act or take risk when faced with a future full of ridiculous regulations. Or perhaps the regs simply codify the business model of the larger players, keeping out smaller competitors.

Some years back I was looking into forming a non-profit to do some donation-funded environmental cleanup (not huge - probably on the order of a few tens of thousands of dollars a year). What I learned is that while SOX doesn't apply to non-profits, there are similar SOX-inspired rules that do. The advice from everyone I talked to at various non-profits about how to get set up: Just drop it. The regs require so much paperwork and oversight that it would easily cost 10x that much in compliance and auditing. If you aren't making a BIG non-profit, it's not worth the trouble any more, the overhead will crush you.

SOX had great intentions but was one of the most poorly implemented regulations ever.

SOX was a law passed in a hurry after a big scandal. It's intention was to allow politicians to be seen to be doing something. The more painful that something is in practice, then the more they are seen to have done something.

SOX as implemented is therefore working just as intended. The trouble is that the intentions were bad in the first place.

Sounds A LOT like how FISMA is implemented. Only you can't find any two auditors who will agree on how to apply these overly complex set of rules.

I don't know enough to be sure of cause-and-effect but there hasn't been any major accounting fraud such as Enron and Worldcom since SOX passed, so that's one point in favor of the regulations.

I mean, this is hilarious if that's the approach you have been taking throughout your career but for anyone else reading this comment it's wholly inaccurate.

I've personally been part of it at two public companies, and my friends have been in many other public companies, and we've all had the same experience. So sure, maybe it's different elsewhere, but amongst the people I know, that's how it works.

You may have been part of it but you clearly do not have a good comprehension of it. In another comment you stated "Another great example is password rotation. The law demands you have a password rotation policy.". This is completely false, Section 404 deals with the adequacy of the company's internal control on financial reporting (ICFR), it does not contain such specific IT mandates or requirements.

As you mentioned, Sarbanes-Oxley is written at a very high level but that is meant to provide flexibility for a wide range of companies and their associated IT systems. It can be implemented badly if neither party truly understand the requirements, which looks to be the case here.

> It can be implemented badly if neither party truly understand the requirements, which looks to be the case here.

On that I totally agree with you. But my main point is that the law is so poorly written, almost no one, including most auditors, don't understand it, and you end up with a lot of "better safe than sorry".

If you're someone who truly understands the law then I applaud you and I wish you were my auditor, but is seems that almost no one is as well informed as you, which is the crux of the problem.

FWIW I've been part of it at two public companies as well, and my experience nicely lines up with yours.

Incredibly vague mandates that result in extremely complex rules and systems. Lots of things being marked as "financially sensitive" even though they weren't at all - because better safe than sorry.

In both instances it quite literally cost the company several employees who were assigned to put the SOX systems in place, because it was so incredibly frustrating (and, well, boring), that they ended up quitting down the road and directly attributing their leaving to SOX compliance.

Can you provide evidence that it is inaccurate?

What has your role and experience been upon which your opinion is based?

What I have seen of SOX compliance when it came in for multiple companies that I was involved. Every time what I saw matches the description pretty closely. The auditor comes in, sees what you are doing, reads the rules, negotiates with you a set of procedures that you can do and in their opinion will bring you in compliance with the rules, then you execute that.

The rules themselves are so vague that what they will be interpreted to mean varies widely by auditor. But the legal requirements for the company are met if the auditor signs off on it, so you do whatever your auditor says to do. Those involved knows that a lot of the created procedures are silly, but the legal problems if you don't go through the charade are quite real, so you have to do them anyways.

That is not to say that real problems aren't regularly uncovered. I'm sure that they are. But there is a tremendous amount of arbitrariness in, "Here is what you need to do to be compliant."

I've had significant experience performing IT Audit for SOX 404 from both an Internal and External perspective.

And your experience is that the procedure arrived at isn't highly arbitrary?

If so, can you explain why your experience is so sharply different from everyone else's?

(Note, internet claims of "I have significant experience" are the same as claims of "I am an expert" - only credible when they come with other evidence from which we can judge expertise.)