Transcript:
This podcast was transcribed through a third-party application. Please disregard any misrepresentations.
Mark Eckerle:
Hello listeners, welcome to this episode of Cryptonomix. Before we jump into today’s discussion, please keep in mind this recording is for general education and is not intended to constitute investment advice. Any opinions expressed are those of the participants and do not necessarily represent those of Withum. Hello everyone, and welcome back to another episode of Cryptonomix, brought to you by Withum. I’m your host, Mark Eckerle, and today I welcome to the show my colleague Anurag Sharma, who is a partner here at WithumSmith+Brown, and leads the System and Process, Assurance and Services Practice with a specialization in systems and organization controls work. Anurag, welcome to the show today.
Anurag Sharma:
Thanks for having me here, Mark.
Mark Eckerle:
Awesome. Awesome. I wanna start today with, before we dive into what is a SOC and the different types of reports, talk to us a little bit about your background and how you got into this service industry.
Anurag Sharma:
Uh, sure, Mark. So my background is more information technology, information security and assurance. Have been in the industry for over 22 years, 18 of which has been with Withum. So I’m a long time Withumer, right? And I was always interested in risks when it comes to processes, right? How can organizations address the risks? And I think that was the initial driver for me to get into this field. And the more I spent time here, I realized this is definitely my calling. So within the firm and I lead our system and process assurance group and of course, right, SOC 1, SOC 2 Audit, SOC for cybersecurity audits. These are some of the services that my team provides and it gives me this opportunity to go use the technical background that I have, right? And look for those risks and see how organizations small and big are taking steps to try and address those risks and not a boring day.
Mark Eckerle:
Yeah. And it really impacts all types of companies, right? It’s not really, this model fits one size. Every company should really be aware of how this could impact their risks, their controls and control environment. So, that’s where I kinda wanna start and dive into right from the top, right? Like what’s, what is a SOC report? Let’s start off with breaking down the types of SOC 1, SOC 2, SOC 3 and then there’s different types within there. Type one, type two. So there’s a lot of moving parts and I know, right? For the general user or the general audience, what’s the different type, which one would be most important? Cause each one kind of fits a little bit differently. So if you could talk to us about the different SOC reports and then the types as well.
Anurag Sharma:
Sure. So, even before getting into the SOC report, if you talk a little bit about what was the need for these kinds of reports at all, right? And we go back 20, 25 years, that was the beginning when organizations started moving services outside, started leveraging outsourced vendors in order to provide, you know, to help them with one or more of their functions, which historically were all done in-house. So to give you an example, I don’t think we would even remember, but there was a time when payroll was being processed in-house, right? In organizations. And fast forward 20, 25 years, and now I think majority of companies doesn’t matter what size, big or small is using one or the other payroll service providers. So when, when that process started the industry and customers realized that, hey, now we are not dealing with just one company, but we are dealing with the company and some of the service providers that the company might be using in order to deliver its service.
Anurag Sharma:
And that increased or brought in the whole concept of third party risk, right? Now you’re not just talking about your data risks associated with your processes, now you’re talking about risks associated with other entities who might have access to your data, are processing your data and can actually impact your overall risk posture. And there wasn’t an easy solution to measure that, to manage that pre SOC days, right? There used to be an examination called SaaS 70, which was promulgated by the AICPA initially. And organizations would use SaaS 70 as the go-to standard in order to get that assurance right? And it was only in 2010, 2011 that they realized that SaaS 70 doesn’t help with all types of risks. And so they came, AICPA came up with the SOC standards, right? So the system and organization control standards promulgated by AICPA and primarily focuses on service organizations.
Anurag Sharma:
So you have SOC for service organizations, and I think that’s what you were referring to when you talked about SOC 1, SOC 2, SOC 3. And the way they looked at it was, if the service being provided by an organization is going to impact the internal controls or financial reporting of its customers, the ICFR posture of its customers, then the report that would be most relevant to that customer would be a SOC 1 report. So a service provider who’s providing a service, which can, to give you an example, impact the P & L, the balance sheet of their customers. Payroll is a classic example, right? Going back to that, then the most relevant frame, the most relevant standard for that would be SOC 1. And the whole purpose is for an independent CPA firm, like Withum to go in, perform the SOC 1 engagement, issue a report, provide it to the customer and the customer’s financial statement auditors can place a reliance on that report.
Anurag Sharma:
Look at the details, make sure that their overall audit approach and audit risk assessment takes this into consideration, so that is SOC law. The other need that the industry felt was, well, there are other elements of risk management more so, you know, if you’re talking about information security, confidentiality, privacy availability which a SaaS 70 or a SOC 1 Would not be able to address because they are more ICFR focused, which reduces the risk. And that is why the SOC 2 standard, which utilizes the trust services criteria was developed and provided. So, a SOC 2 report in layman’s term focuses on controls that an organization, a service organization would put in place to address, you know, security objectives, confidentiality objectives, privacy objectives, availability objectives, if they’re processing data, processing integrity objectives. So that would be a software report. More often than not, when a CPA firm issues a software report for a customer, it’s the vendor of management folks there of their customers who are more interested in a software report, because that provides them the assurance surrounding – is our data secure with the service organization?
Anurag Sharma:
And what kind of control environment do they have in place in order to put those measures. And both SOC 1 and SOC 2 reports, because of the details in the report and the context required in order to understand the opinion and the conclusions of the report are considered restricted distribution report. So that you cannot, as a customer, if you get your SOC 1 type 2 report issue, you can’t put it on the public website for everybody to download. And that was the reason why the AICPA came up with, and a brief version of a report called SOC 3. A SOC 3 is a general distribution report can actually be put on the website. An organization cannot get a SOC 3 report done without actually going through a SOC 2. So think of SOC 3 as an executive summary of a SOC 2 for a lack of better comparison.
Anurag Sharma:
And so if you do want something that you want to put on your website for everybody to be able to download, then you would go for a SOC 2 type 2 engagement and then ask us auditors to issue a SOC 3 report for you. And the SOC 3 report can be put on the website. It’s a very small report, doesn’t contain any of the sensitive information and details that somebody can misuse in order to try and launch an attack against your organization, but still provides that comfort and assurance to the readers that, hey, this organization has a control environment in place that has been audited by a independent CPA firm and an opinion on the same has been issued. So that at a high level are the most relevant SOC for service organization reports that are in the market. There are a few other unique reports, software, cybersecurity software, supply chain, and there are a few else that are still in works that exist, but we haven’t seen a lot of those in the marketplace yet.
Mark Eckerle:
Yeah, and I think that that’s summary is, is interesting for users to understand the why behind why those reports aren’t public. Right? And I think you hit the nail on the head, right? So a SOC 1 is, again, to, to quickly recap a SOC 1 is for reliance on the controls, particularly as it relates to financial reporting, internal controls around financial reporting. And from my point of view, as an auditor, that’s the place reliance on those controls so that we don’t have to do additional substantive testing. And it proves to your auditors that you have an intact control environment with that service organization. And then the SOC 2 is around certain control objectives that criteria that you mentioned. And then the SOC 3 is particularly just a summary of a SOC 2. And I think when you said SOC 1 and SOC 2 aren’t publicly available reports that you can slap on your website, there is an AICPA called a sticker or a logo that says you are SOC compliant for the general audience if they see that on your website. But to your point, you wouldn’t necessarily want that that report to be public because it discloses your entire control environment. So it opens you up to potential cybersecurity risks and potential hackers, if you will, just because of the material that is outlined in that report.
Anurag Sharma:
Yeah, there is a whole section, whether it’s a SOC 1 or a software report, there is a whole section dedicated to system description. And even though organizations would try and keep it, you know, in plain English, if I’m an astute hacker, there’s enough information there for me to read and figure out, hey, what kind of a tech stack are they using? What kind of a vulnerability they might have? And if I do want to cause harm, leverage that information to design the kind of attack I would want. And that is the reason why you wouldn’t want that to happen. You don’t want that in public information, public realm.
Mark Eckerle:
And then what are, because I have seen it, right, as a SOC 1 type 2 report is the one that we place reliance on. What’s the difference between a type 1 and type 2, and is that applicable to both the SOC 1 and SOC 2? So like, I could have, because then it gets confusing, right? You could have a SOC 1 type 1, a SOC 1, type 2, SOC 2, type 1, a SOC 2, type 2. What are the differences?
Anurag Sharma:
It’s been more than 12, 13 years since the standards came out and we’ve been issuing these reports. And if I don’t have my first cup of coffee in the morning, I make the mistake of calling a type 1 a type 2 a SOC 1 a SOC 2. It’s not unusual. So for people who are not spending eight hours of their day doing this, absolutely confusing. So as I said, SOC 1 and SOC 2 are two different types of reports based on the subject matter, right? ICFR information security. And then both come in both the flavors type 1 and type 2 a type 1 report is a report which is usually issued for a point in time and just focuses on design of controls. So more often than not, organizations would get a type one done during their year one of going down this path because they want to get the first report out as quickly as possible to their customers.
Anurag Sharma:
And the quickest report that you can get issued is a type 1, and it can be a, so one type 1 or a software or a software type 1, a type 2 report is a report that covers not just the design of controls, but also operating effectiveness over a period of time. So usually from year two onwards, you would see organizations providing you a type 2 report, which would run for, you know, anywhere from six to 12 months more offered it’s 12 months on an ongoing basis, right? And because it requires a period of time, if you look at the overall journey and you’re trying to get this for the first time, you add six months of period, you add couple of months for the report to be processed a couple of months before you begin the period for you to get ready. And now you’re looking at at least a 12 month journey for getting to your first type 2, whether it is a SOC 1, type 2, or a SOC 2, type 2. So that is a reason why we see a lot of organizations go for a type 1 and then get the time started clock started so that they can issue a type 2 down the line
Mark Eckerle:
So that, that’s a good thing I wanna call out, right? Cause a lot of times individuals will come to us saying, Hey, a customer came to me for requesting a SOC report. What do I do? I wanna flip it around as quickly as possible. And our immediate response is always, it’s actually impossible to do that, right? Because understanding the time constraints that you just laid out in order to deliver a SOC 1 type 2 or a SOC 2 type 2 report, it must be done over a certain period of time. I wish I could flip it around in two, three weeks and accelerate that timeline, but the inherent nature of the report, it just cannot be done. Can you speak to, I know you mentioned type one’s at a point in time and the SOC 2 or the type 2 is at a over time. Can you talk about the different time runways so that like if I’m a user or a customer and trying to think about, okay, I need to start planning around when it would make sense for my organization to get one of these reports because I want to almost premeditate a customer coming to me to request it so that I don’t have to be playing catch up, essentially, what would that look like in order to make sure I’m staying on track for my organization?
Anurag Sharma:
Sure. And, and before I talk about the runway, let’s also talk about if I put myself in the shoes of the service organization, right? Who wants to undergo a SOC engagement? And if I see why no one wakes up in the morning and thinks, Hey, I want to get a SOC audit done, right? More often than not, it is absolutely driven by the first big customer they’re signing and their vendor management folks are saying, Hey, this is great. We love your service, but before we can onboard you, can you provide us your SOC 1 report? Or can you provide us your SOC 2 report? And that is the driver, even though that is the driver for the initial report. What we are seeing in the industry is that a SOC report has become a defacto standard for vendor management and vendor risk management, which also means that if you’re looking at it from a business development point of view, depending on which service you’re providing, it’s a must have.
Anurag Sharma:
If you don’t have a SOC report and your competition has, that becomes a very difficult sell for you to try and position. So besides the assurance piece, it’s actually a great business development tool. So if you have a SOC report, you can actually wave that in the marketplace and say, Hey, I have it. Maybe my customers don’t have it, and so I am a better partner for you to use my services, right? So there is a big element of that business development process that is always the driver. Now that only works if you have a report that gets issued, which is an unqualified opinion because end of the day it’s an audit opinion. And so you don’t want to rush and get a report issued, and then that has a bunch of exceptions and qualifications because then it loses the value. You will have the report, but you wouldn’t want to give it to your customer because the moment you give it, and if they open and read it, they’ll turn around and say, what is this?
Anurag Sharma:
Right? We don’t want to do business with you. So that brings to the point that you wanna make sure that you have a report where it’s a clean report or minimal to no exceptions. Right? Now, in order to achieve that, you wanna make sure that if you have not done this before, and this is your first time going down the path that you identify any control gaps, you identify any situations that can result in an exception ahead of time, take time to fix it, clean your shop, right? Before you embark on the journey for the audit. And the reason why I’m laying it out this way is because that is the reason why it takes longer. A hypothetical situation can be there is a company which has the best possible control environment in place, all possible security controls in place, but never went through a SOC 2 audit, right?
Anurag Sharma:
If they decide today that I want to get a SOC 2 audit done for a 12 month period ending next month, it’s possible for them to do that. We can look back 11 months, perform the audit, not find exceptions, and they might get a report which is unqualified and give it to the customer 15 years into the marketplace. I’ve yet to come across a company like that and that is the reality, right? Because as I said, right? Very rare to find a company where they’re thinking about doing a SOC and they’ll look at their control environment and they’ll check all the boxes and say, we have everything in this.
Mark Eckerle:
So, I misspoke on, it’s not impossible, it’s just highly unlikely.
Anurag Sharma:
It is a probabilistically rare occurrence where you can say that it’s, you know, it’s possible that we might be able to get you that I have yet to come across a company. So the 99.9% of the companies would fall in a space where they decide, the customer says, we need a SOC report. They start thinking about it. Now they’re trying to figure out how to get there. So the first step they need to do is make sure they find the gaps, fix the gaps, give it couple of months to do that. Simple. Then they would begin the audit period. If they’re looking for a type 2 report, another six months for that minimum, right? You can’t usually, you wouldn’t want to have an audit period less than six months, and then about 45 days from the end of the period to issue the report.
Anurag Sharma:
So you add all of that, you’re looking at 11 months to 12 month runway easy from the day you pick the phone up and call the CPA firm that you would want to begin the journey with. And to that point, the standards do allow you to work with the CPA firm, even in that initial phase under a consulting engagement, right? So not on a test engagement where they can help you identify gaps, right? So that you can go fix those ahead of time and, and then we call that readiness assessment. Different forms would use different terminologies for that gap assessment, but they can do that for you. And then they can, once you’re ready, actually engaged to perform the audit and issue the report.
Mark Eckerle:
So, during that readiness assessment, it’s almost like we as the audit firm coming in, are taking a quick peek behind the curtain to make sure you would pass a SOC report, making sure that those gaps were filled, like you mentioned, making sure the control environment is up to par before we dive in for testing and before that actual six month window or whatever it may be, kind of commences.
Anurag Sharma:
That is correct. So the couple of things that are done during the readiness assessment phase and are key is, under the consulting engagement, the auditors would look at your existing set of controls, see is it sufficient to meet the objectives for a SOC 1, or the criteria for a SOC 2 that you’re trying to meet. And if they feel that there are gaps there, there are missing controls there, they’ll bring that up and say, Hey, we think you don’t have enough controls to support this criteria. You may want to look at additional controls, right? So provide you that feedback upfront. I don’t want to use the term pre-audit, but it is kind of a pre-audit engagement, right? That we are trying to look at things, letting you know that these are the things that if we find during the audit period can, will result in an exception or some sort of a qualification and giving the clients an opportunity to fix it before they begin the audit period.
Anurag Sharma:
And because you’ll find gaps, you cannot look back and include that period in your audit period, right? Because the moment you look back 11 months, you’ll see all of those control gaps would be within the period would be reportable, would result in exceptions and potential qualification of opinion. Hence, you know, year one, you don’t want to look back, you always want to fix things, start your time from time zero, go forward from there looking forward. And that means a 12 month, make sure you have a 12 month runway before you can get your first type 2 report on it.
Mark Eckerle:
Okay. And then I think that’s a good segue into my next point around, so as an organization, how would I typically prepare for this type of engagement? And what are some common challenges that you’ve seen companies face and specifically digital asset or crypto companies, right? If we can make this applicable, I’m sure it’s gonna be something that’s likely across the board to a lot of the tech clients that we work with. But I’m curious if there’s any crypto specific ones, almost common pitfalls, common challenges that you see from an organization’s point of view.
Anurag Sharma:
Sure. So as I said, right, depending on the service the company’s providing, they might look at going down the path of SOC 1, or they might look at going down the path of SOC 2, or they might look at going down the path of both SOC 1 and SOC 2. We have customers in the crypto space who get both a SOC 1 type 2 and a SOC 2, type 2 audit done because both of those reports are used by different users, right? So SOC 1, type 2 would be given to the auditors of the crypto companies clients. And the SOC 2, type 2 would be used by the risk management folks because they are more interested and keen on getting assurance surrounding security. So let’s, to make it easy, take one example. Let’s think of SOC 2. So if there’s a company that wants to go down the path of SOC 2, our experience has been that the SOC 2 framework and the trust services criteria that they’ll need to have controls to meet the criteria for has criteria elements that can be bucketed in two buckets.
Anurag Sharma:
You have technical elements, and then you have, COSO elements, which are more high level corporate governance elements, right? When it comes to the technical elements. And the technical elements would include areas like logical security aid, you know, multifactor authentication, encryption, password strengths, firewalls, intrusion systems, antiviruses, the CSOs are the people who are in charge of security in any organization get that because that’s their day-to-day bread and butter. And because of the industry they are in, right? If they’re in a crypto space, the risk is so high that that is the first thing that they would wanna look at. So, chances are that they would have, if not all, they would have a very good set of controls already in place and operational to address the technical areas of the standard. However, when it comes to the corporate governance piece, that is where we see organizations having gaps during the first cycle.
Anurag Sharma:
And when we talk about organization piece, right? Corporate governance piece, we’re talking about tone at the top, right? Hey, do you have a high level risk management policy in place? How do you take care of securities? Do you have committees to monitor the overall environment on a periodic basis? How do you escalate things up the chain, right? From a monitoring point of view, hiring policies, how do you hire people? Do you hire people who understand security? And, you know, associated areas? I call those corporate governance or software areas. And this is especially for a small or medium sized company who’s just getting started and as you know, going a hundred miles an hour trying to keep the business up, making sure it is secure more often than not, take the eye off the ball when it comes to corporate government. So that is the biggest challenge to try and make sure that they have requisite controls in place in order to be able to get to where they need to. Having said that, those are areas which are, believe it or not, easy to fix. Because when it comes for corporate governance, there are a lot of policy procedure driven controls, and it requires monitoring in the form of some cadence for meetings, right? Hey, quarterly meeting to monitor stuff, things like that. So those are things that can be instituted easily. You’re not looking at, you know, a big sticker shock because you need to go deploy a particular technology in order to improve your security posture.
Mark Eckerle:
It’s getting the time available to apply to those different initiatives where you mentioned like when you have a smaller team, smaller startup, those aren’t high priority at that time, right? We’re focusing on growth, business strategy, operations, all that stuff. So like you said, it’s an easy fix. It’s just one of those things that’s dedicating time and making sure it’s the right individuals in the right place and the right controls are designed
Anurag Sharma:
Right. And the other thing that I have seen working with companies of all sizes, right? That we service at Withum, and by the way, some of the smaller size companies are like a four, five member startup, right? And trying to embark on a journey for SOC 2 and have gone through the journey successfully. One thing which I always tell our customers, especially if you’re planning to go down this path, is there are so many frameworks in the industry, PCIDSS, IOS 27001, which a lot of those are checklist driven compliance. Like, hey, implement this 150 things, and you are done. A SOC standard, specifically a SOC 2 and more. So actually a SOC 1 is very different in that case, because this is a framework designed to meet the needs of a small company or a multinational with multiple locations, Fortune 50 company.
Anurag Sharma:
So the way they’ve achieved that is they’ve defined the criteria that you need to meet. They are not prescribing controls that you need to implement to meet the criteria. And it leaves it to the management of the service organization to decide what kind of controls would they be implementing to meet that criteria. And then as an auditor, when we go in and perform the audit, it is our job to make sure that that is sufficient. Do we agree with management’s conclusion that that is sufficient in order to meet that particular objective or criteria? And so, going back to readiness assessment, that is where a lot of our customers see the value, where they would think, Hey, this control is sufficient to meet the criteria, and we’ll come back and say, no, I think you need to look at a few other controls, because these are the risks that are still not being addressed by the controls.
Anurag Sharma:
On the other side, we can provide guidance on rightsizing a control. So if, if you are a 50,000 employee Fortune 50 company, the way you would implement a control for logical security and the type of controls would be very different than if you’re a five member startup. And we can provide some guidance based on our knowledge of the industry to say, Hey, this is how you should rightsize the control in order to meet the particular criteria that you’re trying to achieve. And that makes the journey easy, right? I wouldn’t say it’s very easy, but it definitely makes the journey easy because now you’re not trying to do a hundred different things because you saw them in some checklist.
Mark Eckerle:
And anything particular to digital asset companies that you’ve experienced? And is there any, I guess, complex challenges that you’ve come across as it relates to digital assets and SOC reports or companies in this space? Or like I said, kind of at the top, is it similar to just other companies that have SOC reports, right? They all face similar challenges.
Anurag Sharma:
So very interesting question. The way I look at a SOC standard and the way it is applicable to a company, right? If a company has a lot of manual processes and not a very complex environment, then trying to meet those objectives and criteria is a little simple because the nature of your controls would be simple. The risks are simple. The moment the underlying infrastructure that you’re using to deliver the service becomes complex. The risks become complex. You’re talking of more risks and the type of controls that you need to implement definitely jump up a notch. So when I talk about crypto companies, digital asset companies, if I put them in a spectrum of complexity, they go off the charts, right?
Anurag Sharma:
So needless to say, the environment is complex, the risks are absolutely complex, right? And then after that, the headlines that we see right on, Hey, somebody lost, millions of dollars of tokens got stolen. The threats are really, again, very different than threats to the other industries. So that definitely adds a lot of complexity to the overall process when it comes to controls. There are areas where implementing controls, testing controls as an auditor is definitely challenging, especially in the whole wallet management, key management area, but right, it’s very, very unique to this space. It’s very unique to this industry. So making sure that you can design and implement controls that would help you address a lot of the risks. And for an auditor to be able to go in and perform procedures to confirm that those controls are in place is very different than any other industry.
Mark Eckerle:
So understanding digital asset companies are probably on the higher side, which I fully suspected just based on the nature of their industry, the nature of the assets. I do suspect that many companies, right, when you’re dealing with digital assets, already have some type of controls in place, whether that’s meeting the standards of a SOC report and a SOC engagement, different story, but it’s not flying by the edge of your seat just based on the inherent nature of digital assets, right? You gotta make sure your environment is up to par. I am curious, is there any lanes or sub-verticals within crypto, right? So types of companies that a SOC report could be more relevant to, right? So I’m thinking mining companies are stakers or wallet providers almost, right? That are third party custodians, exchanges, token issuers or, or companies that are building their own network and or platform, right? Maybe a layer two blockchain on top of Ethereum or top of Bitcoin. Does a SOC report apply to all of these types of engagements? Is there one that it makes more relevant to kind of just throwing that out there to see if it makes more sense for certain companies within the space?
Anurag Sharma:
Sure. Any other industry, I think there are examples within other industries where, hey, SOC is only relevant for a particular set of service providers within that industry and not to others. Now, when it comes to digital assets or crypto space, I think that difference disappears. I have seen companies in the space exchanges, right? Of course, custodians, miners, everybody having a very, very big need for SOC be it a combination of SOC 1 or SOC 2 are both simply because no one is operating in silo. So even if their customer is not requiring a SOC, they have a partner. And as a result of that, their third party partners, third party risk management requirements requires them to have a SOC. So either directly or indirectly accompanying this space has a need of one or the other type of SOC report. And it is also acting as a big differentiator, as I said, right? So the other thing that we are seeing is for smaller service providers who do not have a SOC report, find themselves at a big disadvantage as compared to somebody else in the space who has a SOC report. And again, after that, the whole risk associated with the industry and now, you know, that definitely makes the environment a little more challenging.
Mark Eckerle:
Yeah, I could definitely see, right, from a user’s point of view, if I’m holding my assets at a third party as opposed to my own personal cold storage, that would be one of the first questions I ask is around, do you have a SOC report, right? As if I was an institution, not the general retail customer.
Anurag Sharma:
Believe it or not, as a general customer, right? If I need to go just to open an account on an exchange, I definitely go in the section where they talk about what our security practices are to see if they mention SOC or not. And not just for digital assets company, for any other company. Just the other day I wanted to open a personal finance account and I was looking at various options. And the two that I shortlisted, one had a SOC 2 report that they were getting done every year, the other didn’t. And it was a very easy choice for me to make. So even in the retail industry, we are seeing customers getting educated and bringing this into concentration, right? And rightly so.
Mark Eckerle:
Good. Good. I think my, my final question to really cap off our great discussion here is around management’s takeaway from this, right? So outside of what we talked about where I’m doing it for customers, and I’m doing it business development point of view to grow business, is there any benefits that you’ve seen or that management can take out of this process of going through this exercise, right? Obviously increasing your control environment to make sure when you’re going through that readiness assessment, you’re checking all the boxes and you are prepared. But is there any impact this could have on an organization’s overall risk management strategy? And, and how the takeaways from the SOC report can be fully integrated into an organization, I guess, is there any, I just wanna make sure when we’re talking about this, clients understand or prospects, whoever understand how to get the most out of this report.
Anurag Sharma:
So believe it or not, the biggest feedback I get from our customers when we are working with them throughout the journey, and this is from the CTOs. The CFOs, right? And sometimes the CEOs, depending on the size of the organization, is the biggest value they get is the business process that like they never knew what they never knew about their environment. And they are happy that, hey, we could bring up and discuss what can go wrong scenarios as a part of that initial assessment and then figure out, oh, all I need to do is this and that can fix that scenario. Let’s go do it, and now I can sleep a little better, right? I mean, you can’t, right? If you’re in this space, you will always have risks, but they see a lot of value come out of that initial business process discussions identifying what can go wrong.
Anurag Sharma:
They’re like, we never thought of it. And rightly so. When you are inside the organization, when you’re embedded in that business process, you don’t think of how I can break this process. You are thinking about how can I make sure it just keeps on working? And when we go in from outside, we are like, okay, this is great. It is working, but what happens if in this scenario? What happens in this scenario? What happens in this scenario? And that is when they’re forced to think, you’re right, it’s possible. Let’s go address and tweak the process to take care of that. Let’s go address, tweak the process to take care of this. So there are some of these difficult conversations that organizations never had because they never had to. And we, as an auditor coming from outside, our consultant, coming from outside, are now forcing those conversations, those tough conversations.
Anurag Sharma:
The biggest conversation we always have is segregation of duties, right? We would go into an organization, and if you’re looking at SOC and we change management, and we’ll say, oh, you have so and so person who has keys to the kingdom. If he wants, he can go make whatever change he wants in the organization. And that can pretty much bring your system down to its knees. Maybe nobody thought about it. Maybe people thought about it but never brought it up. For whatever reason, we don’t shy away. We bring that up and then it becomes a discussion, okay, let’s figure out how can we eliminate this single person risk institute controls that would help make the process more robust. And I think that’s the biggest value that comes out of the system. Of course, you’ll get a report, of course you’ll use it for business development processes, give it to your customers and make it happy. But overall, the maturity of your control environment is what improves when you go through this journey.
Mark Eckerle:
And seeing the what can go wrong, right? Talking about, Hey, I know you, I think you hit the nail on the head. It’s, Hey, you have a great process in place and here’s what you do. You’re making sure just continually that it’s working. But what if these five things pop up? What’s the response? What’s in place? I think that, right? It’s always getting more brains in the room thinking about how things can be done better as opposed to just continually doing the same thing day in and day out. But no, that was great. I appreciate all our discussion points today. I think we had some great examples I think you talked through in layman’s terms, right? Because like you said, this can be on the surface confusing. So I think we dove in on each report and how it’s applicable to different companies. I appreciate the time today. Thank you for joining us. Folks. You can go to withumm.com to learn more about Anurag and his practice and the different services that we offer here at ham. But thank you for joining the show today.
Anurag Sharma:
Thank you. Thanks for having me, Mark.
Mark Eckerle:
Of course. Awesome. That wraps up another episode of Cryptonomix. All views expressed in this podcast by Mark Eckerle or his guests are solely their opinions and do not reflect the opinion of Withum. This podcast is for informational purposes only.
