Is Your Relationship Status with SOX “It’s Complicated”?

I would imagine those of us who have been in the technology fields for a while would classify our relationship with SOX as: “It’s complicated.”

After 20 years, the Sarbanes-Oxley Act of 2002 (SOX) is still one of the overarching compliance demands that all public companies face. Interestingly, the creation of SOX was in response to various problems associated with the collapse of a single company, Enron. That collapse is legendary — Enron’s dramatic downfall has been the subject of many books and movies. It caused Congress to get involved and create the SOX Act, which still requires deciphering operational manuals to understand. The expectation was it’d provide a way for a CEO to sign off on their annual accounting as being accurate and pledge that there was no misrepresentation. Since then, companies have continued with countless endeavors and tons of money to ensure they comply with SOX. Unfortunately, the reality is that SOX has not created any added value.

Instead, it has created immense amounts of work to provide no additional certainty that business management and processes are correct. To prove that point, I will specifically highlight SOX’s technology side. There are primary controls in SOX, such as certifications, which demand that everyone’s access has been authorized, approved, and accurate. When I was an operator in identity, I’d have to handle this every quarter, leading these massive certification exercises. And guess what? They run today precisely like they were twenty years ago when I ran them.

You spool out all this information about accesses, take weeks to put the data together in presentation form, and then the powers that be review it. But the reality is that none of the people signing off on the accuracy and the appropriateness of that access data can read or understand what that access is. There are entitlements, attributes, and a lot of different compilations. So, what ultimately happens is the same thing that has happened every quarter for the past 20 years — the person that’s supposed to authorize that access clicks “yes.” They have no idea whether the access is accurate or not. But off you go; now you’re compliant, right?

The problem is compliance doesn’t equal security. Submission of documents doesn’t mean risk mitigation. SOX becomes an exercise to simply “click the box” followed by the hope that the results are accurate. In reality, the creation of regulations and standards is often void of understanding of how things operate in the real world.

I also don’t believe insiders ever feel threatened by the certification requirements associated with SOX because the conditions don’t really keep bad things from happening. We know this because insider threats, especially third-party access breaches, continue to increase. Regarding outcomes, SOX and other compliance mandates haven’t yielded any positive results regarding cybersecurity losses and threat risk. I’m not saying that compliance is to mitigate those things because many people argue that compliance is a minimum level of quality expected from companies. But I am saying that it’s essential to recognize that you’re spending all your resources and time working on things that don’t result in threat reduction; you’re creating additional work and eating up all of your resources and capacity.

Wouldn’t it be more logical to use those same resources to…

  • …identify third-party identities and access at very granular levels?
  • …make sure that timely and accurate access is available in the moment?
  • …leverage things like privileged access management and third-party access control solutions?

Third-party access control solutions have recently come on the market and can solve these problems. It’s tough to break the cycle, though, because, for the past two decades, everyone has become efficient in blindly accepting the risks associated with third-party compliance requirements. We literally write short forms and hand them to the chain of command where, eventually, someone in the C-suite or even on the board must acknowledge that “Yes, we have no idea who these individual third parties are that we’re interacting with.” A space, by the way, which is booming with companies utilizing large volumes of third parties. But most still accept the risk of a bad outcome because they don’t know how or couldn’t fix the problem themselves.

Now I go back to my main point. Why not spend your effort, time, energy, resources, and dollars on fixing the actual problem, instead of continuing to accept the risk and the belief that when you inevitably are forced to face that bad day, you’ll just absorb the losses?

Compliance has backed itself into the proverbial corner where compliance demands do not yield risk and threat reduction. Compliance demands are just generating work and eating up resources. And we can do one of two things: We can resolve ourselves to this notion that this compliance space will never change, that we will continue to feed the beast. Or we can say, “We’re going to make sure that we meet the compliance requirements by focusing our attention on solving problems. And when we solve those problems, the answers to those compliance questionnaires and assessments and evaluations will be more honest, truthful, and accurate.”

So good luck to everybody in the fight to meet compliance obligations and keep your company safe and secure. It’s a complicated task, but there are ways to do it. And there are certainly lots of organizations you can talk to, and I hope that at some point, that conversation leads you to reach out to SecZetta.


To read more about how your organization can eliminate third-party access SOX audit failures, read SecZetta’s SOX Compliance Use Case. It features the five most common reasons why a traditional third-party identity approach may result in a failed SOX audit and insight on how you can remove the pain and cost of“risk acceptance” before your next SOX audit.

You can watch SecZetta’s Chief Product Officer Richard Bird speak more about compliance by clicking on this video link.

*** This is a Security Bloggers Network syndicated blog from Industry Blog - SecZetta authored by Richard Bird. Read the original post at:

Cloud Workload Resilience PulseMeter

Step 1 of 8

How do you define cloud resiliency for cloud workloads? (Select 3)(Required)