How to automate ITGCs
Technology and applications are part of almost every business process in the enterprise today. From the finance department to marketing, businesses depend on technology solutions to help them run. But technology doesn’t come without risks, and that’s where IT General Controls (ITGC) come into play.
The aim of this session is to help you understand:
· What are ITGCs and their role in risk mitigation
· How ITGCs relate to segregation of duties and sensitive access risk
· What is their purpose as they relate to ERP
· The significance of change management in responsibility and role definitions
· How to strengthen ITGCs
· The benefits of automation and the use of access control software
· Case Studies
Join our thought leaders Paul Haley and Adil Khan as they discuss how to ensure security and effectively govern your business.
Transcript
Emma - Good afternoon, and welcome to today's session, “How to Mitigate Risk With ITGCs and the Power of Automation.” It's great to see so many people here today, so thanks for joining us for what will be a very insightful session. Just a few housekeeping items before we do get started. The session will be recorded for on demand viewing, and we would love you to participate in the session, so if you have any questions, then feel free to pop them across the control panel, and we'll get to those at the end of the session. I am delighted to be joined by Paul Haley, industry veteran, and SafePaaS CEO Adil Khan, both experts in the ITGC world. A big welcome to you both. So without further ado, let's dive right in.
Paul - Thank you Adil and Emma from SafePaaS for providing this platform to talk about a few things I'm passionate about, in the SOX and IT space and a big thanks to all of you for taking the time out of your busy schedules to join us here. My name is Paul Haley and I've been an IT professional for over two decades working in SOX compliance and leading public companies through SOX 404 audit. And today's webinar, from my perspective, as a leader in the IT world.
Emma - Adil, do you want introduce yourself?
Adil - Sure, Adil Khan SafePaaS CEO, I'm here to share our experiences with our customers that provide us with great insight on how to streamline ITGCs, which is a key element, as you'll hear today, of your overall financial controls framework.
Emma - Thanks , Paul. Alright, well, let's dive right in!
Paul - Great, so what are ITGCs and how do these controls mitigate risks? In essence, while SOX itself doesn't prescribe specific ITGCs, it mandates that companies establish and maintain effective internal controls over financial reporting, of which ITGCs form a crucial part, to ensure the accuracy and reliability of financial reporting. The specifics of ITGCs are typically left to industry standards and best practices, and companies must ensure their ITGCs support the broader objectives of maintaining reliable financial reporting as stipulated by SOX. So, let's break it down. ITGCs covers many areas and for today's purposes, we will cover access controls, segregation of duties, and sensitive access, as well as change management. Access controls are our gatekeepers, ensuring only authorized user access, specific data, and systems keeping out unauthorizered meddling. Segregation of duties controls and sensitive access is about checks and balances and reducing the chance of unwanted changes to applications, making sure tasks are divided among different individuals or departments to prevent conflicts of interest and errors. Change management controls govern a process of IT system changes, making sure they're properly authorized and documented, tested, and minimizing risks associated with these changes. And last, but not least, the policies and procedures. They ensure controls align with our risk appetite and management acceptable risk assertions, maintaining harmony and compliance.
Emma - Adil, do you want to add anything?
Adil - Yeah. So, I think, as Paul, you said, it's not necessarily part of the compliance, but what we see from our customers and their auditors as part of their annual audit, as part of the scope, is that these controls are thoroughly tested to provide assurances to management, and, ultimately to the market that as most customers operate their business on business applications these days. Controls within those business applications are definitely in scope. Often customers call those, “SOX” applications. This would be like your ERP systems, your provisioning systems, IT service management systems (ITSM), and other IT systems that feed into your main general ledger. One of the things we'll talk about today is, how do we make that easy on you? Because it, it's easy to do a three-way match test on paper, pull out 25 POs against the receipts and invoices, but it's harder when you're a spread out enterprise with thousands of transactions daily, and lack of access to verify those controls. So we'll talk more about that.
Paul - That's a good point Adil and that's, that kind of, built into the next topic of the concept of segregation of duties and why it’s important.
Adil - Yeah.
Paul - Let’s get straight to the point. Sensitive data, critical systems, and key applications are the lifeblood of our operations. Protecting them is, it's really non- negotiable. Sensitive access controls act as our first line of defense, and they ensure that only authorized personnel can access our most valuable assets. This shield against unauthorized entry is fundamental to maintaining the security and confidentiality of our data. The segregation of duties is about balance and accountability by ensuring that no single individual holds conflicting responsibilities, such as initiating and approving transactions, we're creating a system of checks and balances. This not only reduces the risk of errors, but, also, minimizes the potential for fraud or misuse of authority within our organization. And beyond compliance check boxes, These controls are the bedrock of our resilience strategy to help us meet regulatory requirements by fortifying our operations against internal vulnerabilities and external threats. Their impact goes far beyond mere compliance with the backbone of our security and operational efficiencies.
So how can ITGCs help in identifying and preventing SOD conflicts, ITGCs - they're indispensable in uncovering and mitigating sensitive access and segregation of duties conflicts within our operational infrastructure. And if we dive deeper into how these controls specifically safeguard our operations against these conflicts, we will find that they act as the structural framework governing our control mechanisms they establish the groundwork for precise delineation of user access rights and the allocation of responsibilities within our IT systems. Then, at the heart of this lies access management. We can enforce strict rule based or better policy based access, ensuring that user permissions align precisely what their roles, and this particular control will help flag potential SA and SoD conflicts where overlapping authorizations, might create risks. We have additional strength within continuous monitoring and reporting mechanisms within ITGCs. And these tools provide a watchful eye of your user activities and permissions promptly identifying instances of conflicting duties crucial in flagging potential SoD. conflicts for Immediate resolution. And we can't forget about automation. The game changer in this scenario, ITGCs streamline access requests workflows, swiftly identifying and resolving SoD conflicts and thereby reducing our exposure to associated risks.
Segregation controls. These controls ensure the critical tasks are distributed among different entities preventing a single individual from holding conflicting responsibilities. This proactive measure is pivotal and maintaining conflicts from rising in the first place.
Next we have implementing controls for sensitive access. For example, privileged accounts. Privileged accounts, they are the gatekeepers of our critical systems data, they demand meticulous attention. Establishing controls begins with access governance, a structured approach to manage, and monitor privileged access across our IT landscape.
Access governance relies on robust identity and access management protocols. It's about defining, managing and auditing access rights, ensuring only authorized users hold the keys to these privileged accounts.
Role based and policy based access controls form the crux, it's the mechanism defining access based on roles or policy, limiting permissions to what's necessary and curbing the risks of excessive access that could lead to security breaches.
Least privilege principle is about providing the absolute minimum necessary access to perform tasks, minimizing the potential impact of compromised accounts or human error.
Then we've got critical access reviews and recertifications. These are periodic reviews of privileged access ensuring that they are in alignment with our change management and changing roles and responsibilities, keeping a tight rein on these types of accounts and who holds the keys and the ability to use them.
We also have audit trails. I'm sure you're all familiar with that, with the ability to track all activities within privileged accounts, offering transparency and accountability.
An indispensable asset during audits and investigations.
Then finally, segregation of duties in privileged access is paramount. Ensuring that no single person is able to do things above what their role or what the policy states they should be able to complete for their aligned business process.
Shall we move on to how ITGCs help in configuration controls?
Adil - Before you move into configuration, I think you've covered quite a bit of really interesting topics. I'd like to just make a couple of comments, if that's OK. So I think it's starting with the concept of segregation of duties. How do you, if you're new to this topic, most of you that are attending this have some knowledge of it, so I'm not going to dive into it any deeper. We have quite a bit of content on our website. And Paul certainly is a subject matter expert to reach out to. But, one of the things I wanted to mention is how customers are challenged today. Many of our customers use our products to control risk, access risk, access governance in their areas. The challenges I'm seeing today in SoD is around the ability to handle the remediation aspect of SoD - being able to review the conflicts on a periodic basis. So you start, whether you're doing it manually or on spreadsheets or a home-grown system or something like SafePaaS, that's a more modern way of doing it. Defining the rules is very important. And one of the things that we've talked about in our last newsletter, for example, is the ability to review those. So as our customers are getting more digital, they're moving to digital platforms, the need for having a periodic review of privileges that are changing over a period of time let's say quarterly, semi-annually, or annually depending on your frequency of risk assessment. You’ve got to look at that stuff. Because you may have defined, we have customers that have been using the same set of rules for 10 years, and on premise, there's somewhat, of a control you have with your on premise customer. But as your customers, and you are adopting more cloud platforms, that becomes more challenging, because your releases are happening more frequently. Many times, these are newer products that the vendor has generated to provide value in the new digital platform. So, you're being asked to essentially look at those privileges more often. And if you miss those, what with the bar that the PCAOB has raised on the external auditors they will look at this, and this could turn into a finding. So, if you're an auditor, or if you're involved in IT security, or compliance, one suggestion I have for you today is that, take a look, it’s year end, you're thinking about your plan for next year, calendar year 2024. So, think about what processes you want to put in place to ensure that those privileges are reviewed whether you're Oracle, SAP, Workday, Microsoft, whatever your ERP is, all of these vendors are introducing new functionality, new cloud capabilities. Be sure to look at that and revise those controls to meet your requirements. So, that's the one thing I wanted to mention.
Also for remediation and prevention. What kind of ITGC controls would help you do that? Most organizations already have some good controls. They're just not integrated in many cases what I'm finding. For example, many customers will have a service ticket system like whether ServiceNow, Jera, or something, where the request starts. However, that request is not tested for SoD, because these systems weren't built to do policy based access governance like we do. So, you have to integrate them, or do it manually. Somehow, you have to do it. But the recommendation from us, what we've seen for our customers. People that have adopted this preventive approach, that's on the second pillar here as part of their ITGC automation really reduces, not only the risk to the business, which is obviously the number one priority, but also the fatigue in the business of having to get on this treadmill effect every quarter every six months, and reactively go in and monitor and correct SoD conflicts that tools like SafePaaS and others report. So SafePaaS has some capabilities in that area that'll help you prevent the risk, whether you're using SafePaaS, or using a third party system for provisioning. So you'll be able to prevent that risk from materializing within the organization.
I'll just add a couple of recent developments this year that might be helpful in the planning for the folks next year. Go ahead, Paul.
Paul - And from an IT perspective, meeting SOX compliance with things like access that is creating segregation of duties conflicts, or sensitive access violations. It's a really good idea to have a process and procedure in place that identifies those that are going to create those types of violations prior to moving those changes into your live environments. That's one. So that process and procedure. Two a regular review of what those access definitions are. If you're on Oracle, what are your role and responsibility definitions? What are their risk ratings? Are they still appropriate for their maps business processes with all of the access that they have? Doing a regular review of that, is really important as well.
Adil - Yeah, maybe I can add some examples there, too. So one of the things that configuration request often originates in some other system. You’ve added a new business unit, you've creating a new hierarchy of approvers. And so there's a ticket again, in some kind of a ticketing system that gets generated, and then that change is executed by, let's say, your support team or your third-party managed service provider, shared service IT, whatever the case may be. Then that change is then reviewed at the end of a period, whether that change was valid or not. And it's a very tedious process to do that ITGC configuration controls manually. One of the things that we have seen our customers do in SafePaaS is our ability to monitor for those changes, and then attach, send the request of the change. So, let's say somebody changed the approval hierarchy from 10,000 to 100,000 and that was what the request was, but the person that approved it, may not know the request that was made. So, taking that ticket information, or whatever the initiation was, attaching it to the request and showing exactly what the change was. Who, what, when, where, the change was made. Then providing that report, we call it a Change Tracker report to the to the compliance folks, to the control owners, to the auditors, ultimately. So they can see that all your changes, ITGC controls that are in place for your change management are effective. right without you having to do spot checking and finding that some changes went in unapproved. So this goes to that concept of zero trust at a broad level, and specifically, it automates all of your changes in your enterprise applications that ultimately, enable financial reporting and therefore, the risk. That's something, another tip that I'd like to leave you with today, that consider as you go into New Year. Automating some of those change requests and the reconciliation of those change requests versus the actual changes in the business applications to prevent surprises that can lead to findings in an audit.
Emma - Great inside there Adil. Let's move on to what are ITGC objectives to control ERP risks?
Paul - So we've got a number of objectives, and they're all kind of very inter-related objectives to meet to overall control risks.
We’ve got regulatory compliance. That's mainly aligned with Sarbanes Oxley, It’s about maintaining Transparency, and Integrity and the Financial Reporting. I'm sure most of you are familiar with SOX, and if you're not, that's about maintaining internal controls over financial reporting. It doesn't tell you what to do. It tells you that you need to do it.
We've got financial reporting, and ITGCs and their objectives within financial reporting is making sure that inputs and outputs and processing are taken care of properly. That impacts the financial statement and financial reporting.
We've got reliability of data, and that's along the lines of your application configuration from processing as well. If the data's not clean, and you have changes to configurations within your application that alter the way that your application is processing data or perform calculations, or the ability to conduct fraud, how you calculate revenue, all of that stuff is controlled mainly within your applications. And so having a strong ITGC around how your application is, calculating data and providing data is important.
We've got configuration management, which Adil just provided some excellent tips on for how you manage that entire process. And it's basically through a change management process. It does a number of things from an organization perspective, your configuration management, and change management around that, ensures that you go through a standard process every time a changes initiated into the system, typically known as the software development life cycle.
Once you have that in place, the artifacts that you produce along the way are really important, not only from mitigating risk within the organization, approvals, testing.
But also you to want after you release these changes into a live environment, how do you measure the success of those changes. Those artifacts, audit are what the auditors will use to ensure that your changes were appropriate to the system. And they'll look for those artifacts:
They'll look for:
Who requested the change?
Why did they request the change?
Who are the stakeholders who approved the change?
Who made the change?
Who moved it into production?
Was it tested?
What were the test results?
How do you know that it tested completely?
Now, all these questions come about when they look at these types of change records for configuration management.
We've got control privileged access, and that's really around sensitive access controls. Those are the accounts that have access to do changes to your configurations within your applications. They have access to create and update standing data within your application, and access to directly impact financial statements. So, things like, I can enter supplier data, including banking details would be would be privileged access.
I can’t affect the way an AR transaction creates accounting within the system.
I can’t create users and assign an access. All of those are our privileged access and having strong sensitive access controls and an ITGC around that is, is important.
Then we have control for cybersecurity. And that's a broader scope of, outside of the application, and more on who has the ability to gain access into your systems. And that's held through a number of different controls and through tests and through audit.
Emma - Great insight there. You want to add anything to them?
Adil - Yeah. This is a very broad picture of ITGC objectives. You can see that attaches to every element of enterprise systems, ERP systems, everything from financial reporting and compliance etc… So in just the limited time we have I'll drill down into one area where we've heard more questions in other areas, and that's privileged access on the right side of this chart. So and it's kind of related to cybersecurity. As you know the concerns around cybersecurity have increased with hybrid work, remote work, the new way of how we work today. We've seen an increased interest in managing the privileged users, and we need users to be able to support our systems. Administrators, for example, that do the caring and feeding of these massive ERP systems, which we rely on to produce financial results. So, we introduced something this here, to the market as a result of the demand, called Unified Privileged Access Management.
And what we were finding is, as Paul said earlier, that most of the time we're focused on the application, and we do a really good job from what our customers, tell us, controlling application access. But, in the past, we haven't really had a lot of need to go below that layer. But this year, we have had a significant demand from the market, what they're getting from their auditors. And if you follow the new NIST guidelines etc…even though you may be on the cloud, let's say, using Oracle Cloud, or AWS or whatever, there's still an OS underneath that and there is I'm pretty sure an operating system and a database also in your control. If you're a complete SaaS application, it's not so, but most customers are in a hybrid world today. So they have some level of OS, and network and a database that's still available to them to be able to do reporting and specific to their industry or their business model. So that has become a big risk because that's what's being exploited by the cybercriminals. They're finding ways into that loop and then from there, getting access to, whether it's bank accounts or customers, privilege information. And so, access elevation, and access restriction - least privilege. I think Paul said earlier as well has become a really important part.
So what we have done is, given our customers, the ability to, through a single dashboard, be able to go down and look at privilege access rates across the stack, tech stack - All the way from network OS to the top application, even BI tools. Some BI tools can be used to extract information that's restricted, your data privacy policies. We can even now offer our customers the ability to determine who ran a query, a simple SQL query on a database. So that's been something that has been very challenging for our customers to how to determine if somebody viewed someone's social security information or payroll information. So, not only from a GDPR perspective, which is one of the compliance areas that we're helping our customers improve, but also from a financial risk perspective. So, if you need more information on privileged access management, we have some good blogs on our site. Please take a look at it or reach out to experts like Paul. And Emma can also guide you into our organization where to get that knowledge. So, I'll leave you at this as you think about next year please take a look at your privilege access management process today and if it's just basically using off the shelf tools to do the checkbox that's not sufficient anymore, you really need to drill into, what are these privileged users doing, What rights they have when are they given those rights. When are they taken away? How do we know what the red flags are if somebody's abusing that privilege? So there's a lot more to it than what the data sheets of niche vendors in the market tell you about checking the box. Because if you just check the box and you still have a problem, it ends up that your company's in the paper for the wrong reason. And that's a reputational risk you don't want to take on next year.
Emma - Absolutely not no. So let's move on and talk about how does effective ITGC govern the ERP life cycle management Paul?
Paul - The important roles and responsibilities. Documenting roles and responsibilities, it ensures operational efficiencies, as well as transparency and accountability. And here's why it's so crucial. Think of it as a roadmap within the ERP landscape, clear documentation of roles and shows everyone knows their responsibilities. Reducing confusion, boosting efficiency, it's like having a blueprint for who does what, preventing overlaps with gaps and duties. This documentation is more than just a guideline. It's a powerful tool for controlling risk. By precisely defining roles we ensure the task is spread among different people, minimizing the chances of fraud or errors.
Access control becomes precise. Documenting roles ensures individuals have the right access levels they need for their specific ERP responsibility is a crucial step in preventing unauthorized access or misuse of privileges.
And when changes occur. Well-documented rules make changing and managing smoother. Any alterations and responsibilities or access levels can be handled, authorized and tracked, reducing the risks associated with role changes. And when it comes to compliance, this documentation is gold. Regulators and auditors often look into these documents, as I previously mentioned, to ensure we're following the rules. It’s about governance and meeting regulatory standards, mitigating the risks of non- compliance.
And it's not just about rules and audits. Clear roles make training easier and ensure smooth transitions when roles change is about keeping the ship sailing smoothly
Adil – We have discussed the change configuration changes earlier in the session. I wanted to pick up on the roles. I think, you said some key things, that, again, in my experience from the field, talking to lots of customers, on a daily basis, is that role design has become significantly more important and challenging at the same time as our customers, have adopted new digital platforms, especially the cloud platforms, from key vendors, like Oracle, SAP, and Workday. So what we're seeing is, roles have changed quite a bit. It's not just about a role that consists of permissions and those permissions are made up of the responsibilities granted to you, to an employee, as a user in the ERP system. For example, I work a lot with our Oracle customers, so, there's a concept of security context where you may have a role called Payables Manager that is available to you, let’s say in Dallas, Texas where I live. But it may not be available to Emma in Spain where she lives, Valencia, Spain. And it's the same role, but the way these modern ERP systems control that is by providing overriding attributes or authorizations. Data security has become, as we talked a minute ago, it's really important. So roles by themselves don't tell the full picture. And also there's a concept of inheritance in most modern systems today, going back to the ancy Standards that were established for RBAC I mean, role based access controls. So, you will see that the same role in Oracle ERP Cloud, for example, has different security contexts, different data, authorization, and we’re seeing in some applications down to field level as well. It's getting more complex.
So, how do you track changes? Because what's going to happen is, your cloud vendor will apply some releases once a quarter or however often they do that, and that will introduce new privileges to those duty roles as an example of Oracle, Oracle Cloud. Even though you have built custom roles on top of that, your roles will inherit those duty roles and therefore now you have to deal with those changes. So, how do you track changes?
SafePaaS to help our customers has dedicated an entire product suite called AccessPaaS. As part of that we have introduced Enterprise Roles Manager which is something that our customers are benefiting from, because it not only tracks the changes that are coming into your cloud applications, on a periodic basis, and gives the ability and alerts to your compliance, IT, and business folks to look at those changes because of supplier is introduced into an expense role that was never intended. You can catch that and prevent that from happening by removing that privilege or fixing the duty role underneath before it becomes a huge issue, or it materializes into a real risk, or someone is now able to change a supplier bank account and commit fraud.
So, my point is that roles tracking is something you should look at very closely in 2024 and see if you can either manually, if your volume orders are low, start tracking that, using home-grown reports, or if you're, you find it complex we can show you a more streamlined approach within SafePaaS through our product Roles Manager, that'll enable you to essentially see the changes before and after. And then, also, when you apply changes, you can simulate what impact that would have on my policies. As Emma said, we're a policy-based system, so everything in SafePaaS will be driven off your policies, even though your roles may change, your policies are a constant. If you don't find people that create suppliers to pay those suppliers, that policy is a policy whether you use on premise software, in Cloud ERP or anything in between. So, we apply that universal policy globally across your enterprise, identify all those risks. So, not only we do that detectively, with detective control. But also, you want to prevent that because we want our customers to focus more on what they do to earn their success in the market and less time on these compliance and regulatory problems that distract them from their mission. So, we take on that burden by giving you roles information that'll help you identify when changes are occurring to those roles, and then also prevent any changes that will introduce new risk into the enterprise.
I have a client that reported over, I think, over a million violations, off a single role that got changed. This company is global. They have over 100 locations worldwide where they operate. And one day, some new CEO came in, and he wanted the company to be more customer service oriented, more customer focused. So, they had a privilege where every user in their customer service organization, and across the organization, could see customer service levels through an order entry screen. And there was excitement of making this customer visible to all the employees in the company, which was a mandate from the top down, they ended up giving everybody the ability to change credit limits on the customer order records, which was not the intent. So, this became a massive problem for this company. Luckily, they were able to resolve that very quickly, because SafePaaS caught that, and they were able to quickly make the change and prevent that from becoming a real problem where, if I'm an order entry clerk, I can ship anything I want to customer because now I can change the credit limit. This is an example of a disaster that can occur without good controls in place. And as you think about next year’s planning and where to invest your time to prevent findings and painful, long evenings of work, consider monitoring and tracking your roles through an automated solution.
Emma - Great Insight Adil again, Paul, you want to continue?
Paul - Yeah. I just wanted to add onto what Adil’s mention about patching and about the security vulnerabilities that come in for changes to roles and responsibilities. As part of your change management process, having a good GRC procedure in place for checking for violations of your SoD and sensitive access rule library during the change management process, prior to releasing those changes and patching in production really helps bring down potential SoD violations being created in the system once you go live. So even if you have your live environment where you're constantly monitoring for these types of violations, whether it's preventive based off of your user provisioning process, or if it's detective based off of monitoring for violations after user provisioning happens. By doing these types of checks before your changes make it into your live environment, you prevent new violations from being created from your changed responsibilities or roles.
Adil - Good point.
Paul - But that leaves us with, where did I leave off here? Challenges posed by changes in an organization’s structure or technology landscape. You’ve covered a lot of this. Some of what we'll talk about in our previous slides, but I'll just talk about a few things here where we're talking about changes in structure. We're not just moving things around on an org chart. We're talking about reshaping roles, responsibilities workflows. And this can trigger a cascade of challenges, especially in the IT domain.
So, talking about the tech landscape. Technology, is driving our operations. It’s the engine. When we upgrade our systems, introduce new software or even shift to cloud- based solutions, it's a game changer for an organization. Integrating these changes seamlessly is not easy. It's like a walk in the park, which all incredibly complex puzzle, where every piece really needs to fit perfectly. Changes in tech, they bring your own set of challenges. Legacy systems might not sync smoothly with platforms. Compatibility issues, data migration issues, and we also have to address training as well.
Every organization has changes, structural changes. It’s not if, it’s when. When we restructure, whether it's through a merger, acquisition or just a shift in departments it’s like re-arranging the furniture in a room and suddenly we see things like roles evolved, reporting lines, who reports to who - they tend to shift. And teams need to adjust. These changes they often target the heartstrings of IT governance and control. So if you can imagine changing your car's engine while it's still running. And it's a bit of a balancing act. Ensuring operations keep rolling along while we e adapt to new structures or tech landscapes.
From an audit perspective, these changes can be a minefield. It's about maintaining and ensuring compliance, and that's a whirlwind of alterations. Auditors - they want to see that we're, not just keeping up, but we're also that our governance remains intact despite the chaos.
And we can't forget about commercial side. When we navigate these changes smoothly, it’s an opportunity to innovate, and optimize, and stay ahead of the dynamic market.
Emma - I think, in the interest of time, I think I'm going to skip over the next few slides, and if anybody does want a copy of the deck, please feel free to reach out to me, and I can share that with you. I think it's always good to share a case study, a real life, real-world examples of how organizations are doing ITGCs and automating ITGCs. So, Adil if you want to walk us through the case study, and then, in the interest of time, I think we'll go on to Q&A, because we have had some questions come in. Does that sound OK?
Adil - Yeah, that sounds great. I think we've covered most of them important topics, and the slides can cover the rest. So yeah, thanks Emma for bringing up the case study. This is an example of a client that we're working closely with and some of the examples I use in the past might apply to them as well.
They have an on-premise ERP system, which is the E-Business Suite, as well as a cloud version, they're migrating to cloud, and it's a multi-year initiative. Customer has hundreds of applications. We have identified 14 as really important for financial reporting. They use ServiceNow for their ticketing system, and they also have an IDM system, SailPoint for provisioning users into these applications.
As part of our overall transformation and controls improvement initiative, we looked at their environment and came up with some initiatives to help improve the controls.
The challenges were that they were not getting the visibility, the compliance folks came to us and said, and, in fact, internal audit folks came to us before compliance and said, “We need some way of being able to drill down into the privilege level information, because external auditors are looking for that information.”
So, instead of saying, payables manager, as a role shouldn’t should not have access to general ledger financial manager. That’s the level most of us can intuitively think about that. Like, from payables, you can put a liability and you can reverse it through a general ledger access. So, most companies are doing that today, but the challenge is, it doesn't tell you what's all beneath that role down to the privilege level. So, if you're, let's say an Oracle customer, an E-Business customer, that will be the function level access, if you're an SAP customer, T-code level, or object authorization level. So that's where the fine grain was lacking and, therefore, even though it was a good place to be, it just wasn't meeting the governance requirements, mandated by the management. Complex organization with 100 plus countries - enterprise customers. Lots of different ways of provisioning users. People just send e-mails because they're high up in the organization, and subordinate access gets approved. Others use more formal process in ServiceNow where they log a ticket and then, they go through the life cycle approval granted access.
Others use SailPoint where SailPoint auto provisions access, along with some manual steps you have to do with that.
Also, from an access certification perspective, there were leveraging their current access tools to certify access. And a number of challenges occur when you do that. So, first of all, the question is who should approve access? Many times, the answer is the person that approved access – that seems like a logical way. But if the knowledge about who approved access is not there, that becomes an issue. So, then what? The second challenge they had was, OK, if I approve access at the catalog level, which is the case in many of the provisioning systems out there, they will take number of your finance managers, responsibilities, or roles, combine them to into an abstract role and say, finance and finance manager level one gets access to payables inquiry, GL, fixed assets, these specific roles and responsibilities. And they catalog that as one, which makes it easier. It's a good idea but the challenges come when it comes to certifying that role and continue recertifying that role. The challenge is it doesn't represent the actual privileges, so again, it's not fine grained. So, what was happening is they were ending up with findings where the approver did not know that by granting a finance manager role as an example, they were also giving access to diverse journal entries, which was a no-no.
And they never knew how to take that out, because they never looked at that. So that was a challenge. I'll talk about a solution in just a second. That was a big challenge.
And then, these systems were not integrated, because integration is costly, and most applications leave that to the customer. The burden is on the customer.
“Hey, we'll give you our software, but if you want to integrate with some other software, that's your problem.” So, that created a nightmare of orchestration. Because now you have access orchestration of challenges fragmented. And nobody knows who has what access. And it's all done. I mean, it’s a well-run company. So you have an army of people through your third party managed service provider, your own folks, that are literally going through this process on a monthly, quarterly basis. And dedicated.
And you can imagine the cost of a company of this size. So it's, you can't count, on one hand the number of people that are involved and just making sure that somehow the company's maintaining that, and at the end of the day, you end up with mistakes, humans aren't perfect.
So, this is where SafePaaS offers automation of controls across the enterprise, around applications and IT general controls. Sometimes they're called, ITACs IT applications controls, segregation of duties. ITGCs to me, it's all about governing the business.
And so, we applied the policies and the good news is these companies are well managed. They have good policies and good intentions, it's just that those policies are not spelled out at the level where they can prevent risk.
For example, policy of creating supplier, not paying supplier is important for segregation of duties, but how do you really represent that policy into a system so that it can detect violations. And that's where we came in. We mapped their high-level business policies down to the fine grain level, that's what SafePaaS supports. We looked at their change control, configuration change management process, and mapped that again down to individual applications. We looked at their service request systems and mapped that into SafePaaS, so that tickets could flow within, back and forth, and since we have these standard APIs, there is no integration on top of the basic testing you would do with anything you deploy as part of your user acceptance testing.
So, with that integration in place, now we have created a centralized orchestration for the organization, where all of these fragments of access risks are controlled within SafePaaS. And SafePaaS is system of audit, for this organization, where the customer can monitor segregation of duty risks throughout the life cycle management, if you will.
They can receive information about requests from the provisioning tools like SailPoint ServiceNow, and then send back information through a post API, where we can inform the systems to maybe terminate someone's access because we have the fine grained information. One of the benefits that came out of this specifically was the ability for that approver that initially approve the request at the catalog level. So, I had my example of Finance Manager, approved that at the finance manager level now. We can, we can display that information, because that's helpful. It's augmented information.
But we also are able to side-by-side show, OK, when you approve this access, what you really are approving is that payables inquiry, general ledger, and fixed assets, as an entitlement or a role, depending on what you want to call it. So, now, that person that's responsible for control, or finance, can see the details and make a decision, whether, at a fine grain level, whether, we leave that user with all this access, or, was this a one-off access given to them because we were in, you know, in a situation where we didn't have enough staff or we were doing manual controls, who do reconciliations which we want to get rid of. Or we just had a system problem that somebody needed temporary elevated access as a privileged access I talked about earlier.
The decision maker becomes much more informed when determining whether the certain user should continue to have access to these privileges elevated privileges in the organization that can possibly lead to not only financial misstatement risk, but also waste, fraud, other bottlenecks in the organization. So that's been a big success for us, and that's something I want to share with you, because if you are struggling with that, think about including that in your plans for next year. And reach out to us and Paul to help you guide through that process and follow the best practices.
Same thing with being able to audit across the SOX applications globally. So, some of these applications, as I mentioned earlier, I'll talk about roles a little bit, And then we'll wrap up. We're almost out of time. So, being able to perform certifications across the globe based on the security context within each of the markets, based on the roles, and managing those roles. So the roles themselves are correct. That was a big win for us here.
And then, finally, just the audit process, itself. So, you may have seen some, our newsletters talk about audit analytics. So, the auditors still will demand evidence, independent evidence of everything. So, to enable the auditors to get that information themselves. Instead of chasing IT, they're able to get their own portal, whether you're an external or internal auditor where you can see the effectiveness of the controls, by pulling out these audit reports that match the provision request, the certification against the actual access user has to have that independent evidence that the business is operating controlled effectively. So, I'll finish on that. Thanks for the opportunity to share, to listen to us. And, Paul, I'd like you to let me take on and help us close the meeting.
Paul - Yes, just to add, on a few points to what you just discussed, so I've seen a number of organizations with similar challenges on the access provisioning, and having read information. It's a big challenge to a lot of organizations. Especially in, need of solidarity role, perspectives, provisioning, multiple entitlements. Thanks for expanding on that some really good information.
Emma - We have a couple of minutes left, so I'm just going to get one quick question before we wrap up. We did have another case study, but I think we'll have to organize another session to go through that case study. There's lots of stuff to talk about. So, I think we're just going to wrap up. I'm trying to be very brief here because we don't have a lot of time left…
So, question, how long does it take to achieve SOX ITGC compliance in a nutshell?
Paul - It can vary significantly based on several factors, and that's the complexity of an organization's IT environment, the maturity of their existing controls, the readiness and process systems. It's a continuous effort, and it involves multiple stages. You have your first stage assessment and gap analysis. And this is the stage that involves evaluating your existing IT environment gaps, and controls, and understand requirements, compliance. And just depending on the size and complexity of the organization, this could take months, it could take weeks if the smaller things are ok. But it takes months to achieve, just the assessment gap analysis piece. You move on from there to remediation and implementation. So much at gaps are identified, and we need to be able to implement the necessary changes, establish enhanced controls, develop documentation to meet your SOX compliance standards, and this can take up to a year, months to a year. Again, lot of variance here, depending on what's required to change. Then, testing and validation. So, after you're done and you've implemented the controls, then you need to go through and test and validate to ensure that the controls are operating effectively. And this is, once you start this, this should really be an ongoing thing. So once you've established your controls in place, they should have a testing iteration. Is this something that you test weekly, monthly, by transaction? Quarterly review? How often are you testing the effectiveness of the control? A lot of factors there, including criticality. Then you move on to sustainment and ongoing compliance. Then, as I just said, it's, you can move into a continuous monitoring update maintenance of controls. This is, involves regular reviews and adjustments as needed, and it's really, it's a collaboration between your control owner, the people who participate in your business process, internal audit and IT as well. So, it could take months, it could take years, and it depends on how mature your organization is. How mature your controls are, how effective they are, how complete they are, how many captured identified.
Emma - A final word from you Adil, before we wrap up.
Adil - I mean, I'm here to help you guys accelerate the process that Paul outlined, to squeeze out any inefficiencies and automate that. So, we're here to help you.
Emma - So, yes, we have run out of time. So I think we'll arrange another session early in the in the new year. So, I'd just like to say a huge thank you to both our speakers today. Paul, Adil, thank you for sharing your knowledge and insight with our audience today. Thank you to everyone who joined us. Paul and Adil all both available, to, you know, to continue the conversation, so, please, do reach out, if you would like a complimentary discussion, so, thank you, and have a great day.