Custom Roles, Data Security Policies and Privileges

Presented by ERP Risk Advisors and SafePaaS.

You've decided to customize security roles to provide specific access to your users, but there is the security console, job roles, duty roles, privileges, data security policies, aggregate privileges. With so much to know and understand, where do you start? Have they given you a thousand-piece puzzle with no picture to look at for help? After creating a few roles, things just don't work quite the way you expected, how can you find the missing piece? This presentation will go over the Security Console and how to review the seeded roles to understand where to start. It will give you a bigger picture to help you put your puzzle together with a few tips and tricks from lessons learned.

This session will help you understand:

What are roles?
What is role design/redesign?
When do you need to redesign roles?
An approach to role redesign
Benefits of role design
Review the Security Console, what's all there and how you can use it to your benefit
Data Security Policies and how they work

TRANSCRIPT

Emma: Hello everybody, and welcome to today's session, “Custom Roles, Data Security Policies, Privileges, Oh, My!

So, my name's Emma and I'm on the marketing team here at SafePaaS. And I'm thrilled to be joined by Donna Curtis from ERP Risk Advisors and Adil Khan, CEO here at SafePaaS. So just a few housekeeping items before we get started.

The session will be recorded for on demand viewing, after the session, and if you do have any questions, we've already had some really great questions come in. If you do have any questions, then pop those in the control panel, we'll get to Q and A at the end of the session.

So, let's get started with the session, which is why you are all here today. So, this is just a quick agenda of what we will be covering everything from the basics what are roles and role redesign. Going into the nitty gritty details of roles and definitions, security console, lessons learned and then an approach to role design at the end.

So, let's dig in. Adil?

Adil: Yeah. Thanks, everybody for attending this very important session on role design. So, what are the roles? I mean, it sounds like an obvious question. Today, most of us that use any kind of system, we get roles assigned to us, and that gives us the privileges to perform our duties on whatever application we use, NetSuite, Oracle, Cloud ERP, or, Salesforce. So that's how we do work today in the modern world. That's what they call the digital transformation.

So, this is essentially our job definition online, it is who we are, It's our profile online.

I'm hearing a lot of different ways of describing it. But it's very different than, you know, Henry Ford’s Assembly line 100+ years ago, where you could essentially give people roles by putting them on the assembly line, you can visually see what they were doing. And so the people that painted the cars black that Henry Ford talked about. They would not go and start rebuilding the engines or building the engines. It's gotten a lot of complicated. Since then, we have these ERP systems with thousands of privileges, and now with more modern systems that Donna is going to talk about, like Cloud ERP. You also have this concept of inherited privileges, which is fantastic and flexible, and it gives us the ability to really get the most out of our organization, our workforce. But what that also means is a careful design of roles and responsibilities and entitlements and privileges. It has become more important, combined with this stampede to Cloud for value that it creates for our customers and our businesses.

So, unfortunately, what we are seeing in the market, and then I look forward to Donna's insight into this in more detail, is that the application vendors that send the application there are sending it like you get a packet from an IKEA store where you have to basically build it. So we're seeing the same thing with roles. How to take a bunch of pieces then turn that into a table or a chair. It is your responsibility. Sometimes the fine print is not clear to people, and that's what we'll talk today and what we can do to help you with that. But, that creates a certain backlog and burden on our customers, because seeded roles essentially give you access to everything. We used to call that keys to the kingdom 20 years ago when I started in this business of helping customers improve their controls and security in their ERP systems.

Also, what you see on top of that is in the cloud that's unique to Cloud, that implementors people that help you deploy these applications. Because cloud is quick, you don’t have to install software, they're getting quite a bit of privileges that may not be needed, like access to suppliers and so forth. Sometimes, that's intentionally given just so you can get the project done faster and sometimes it’s an unintended consequence of something else you've given them. But it's creating a significant burden on our customers, because now they have to go and explain to the auditor, why did somebody from Accenture just to pick on one example, have access to create suppliers in a customer account while they were implementing in the production instance. We have found about non prod, but in production, so seeded roles have become even morphed into something a little more complex because of these newer technologies in the cloud that provide inheritance of roles, duty roles, job roles, and different types of roles that can get pretty messy if you don't really understand and have technology to manage it.

And then the way the cloud is being implemented makes it extra hard when for your consultants that implement the products for you, like automate your process. Let's say, procure to pay process, have access that you may not expect them to have because there's also this concept of managed services in the cloud where customers are saying, look, since we don't want to mess with technology, we want to go build furniture or cars, or whatever they do, we don't really care how this is configured. Just make sure that we can get the cars and the furniture out the door, and  then meet our customer, and make our customer happy. Customers are becoming more difficult to manage, customers are expecting more from your organization. So, that's where role design comes in.

And so, role design basically means to understand the jobs that are involved. In other words, privileges that are required to do, perform your job optimally. Your duties and responsibilities and then make sure that they tie back to your objective of your company. So there is a governance aspect to all of this. You’re governing an enterprise and what's the aspect these roles would be assigned so you are complying with your internal policies, your processes are optimized and your compliance. Don't forget about compliance because we also live in the SOX world. It's only getting harder for auditors to complete successful audit because of the bar that PCAOB is raising on external auditors, which is trickling down to all of us.

So, the role design sometimes also means remediation work, which we'll talk a little bit at the end, after Donna’s presentation. How to make sure that you can do that efficiently, effectively so there’s a sustainable side to the Oracle cloud as well. So, I look forward to hearing from you, Donna, on what you're seeing latest, because you're in the field every day helping customers. So, this is where I'll turn it over to you.

Donna: Cool. Well, thanks everybody. We didn't really do introductions a little bit, but I just wanted to let you know who I am. So, my name is Donna Curtis and I work with ERP Risk Advisors, And I've been working in the Oracle world since 1987 so aging myself just a little bit. I've been working in cloud for about 7 years now, and predominantly in the security design aspect of it. So, in the governance, in the GRC area, as well, but in the design. So, this is my baby, this is my area of expertise. I've done a few, quite a few presentations at the different OATUG Ascend conferences collaborations at different conferences, so maybe you've heard of me or seen me or come to one of my other presentations but this is an area I enjoy talking about because it's so confusing. There's a lot of information here, so we're going to go quickly because we don't have a lot of time, and we're going to try to get to some of the questions as well.

So, before we really get into it, I want to make sure that we all are using the same definitions. I don't know how many times we've talked to somebody, and we think they understand what we're saying, and we understand what they're saying, and come to find out down the road, that, what we said, they didn't, they took it in a different way in what they said, we took differently. And, so, we were not on the same page, when we were talking. That happens in Oracle, all the time.

Even, people that are going from Oracle, to Oracle, Oracle EBS, and Oracle Cloud are not the same. They may use the same words, the same verbiage, but they don't mean the same things. So, just to make sure that we're all on the same page going forward, I'm going to go through some definitions so we all understand what these things mean as we go forward.

So, a privilege. Privileges in Oracle because Oracle likes to really confuse people, they're also called Functional Security Policies and entitlements, three different ways to say the exact same thing, which is why it is so confusing.

Anyway, a privilege is the lowest level of the process. It is the edit, the create, the cancel, the submit, the function, the reports, that is what grants you the ability to do everything, to open a form, to run a process, to do anything, that is your privilege - the lowest level.

In financials and supply chain processes, everything are driven by privileges. It’s the way it works. It’s driven by privileges.

Go on to the next.

So, then they take these privileges, and they blew them up and they called them an aggregate privilege, a super privilege. This is a privilege that has a privilege below it.

So, it is a privilege that contains privileges. Kind of a crazy thing. I'm not sure why they did it. It can't be customized. You have to use it as it is. It can’t be broken up. It is exactly the way it is. You put it in the hierarchy area of the role. Same kind of a place where you would put a duty role. In financials, the only kind of aggregate privileges that they have are used for period close to only area I've seen so far, in financials where it's used. I mean, I haven't seen it used much in supply chain at all, but in the HCM Area and HR, it's used all over the place for almost everything.

I'm not exactly sure why they did it that way but, that's the way they did it. So, the way role design happens for HCM versus financials is completely different. So, I'm going to try to hit a little bit on both pieces of it, but there's quite a bit of difference there.

So, those are your privileges and aggregate privileges. Then you have duty roles.

Now, a duty role is basically a grouping of privileges. Usually, it's associated to a specific process. So, for example, you may have a duty role called invoice creation, invoice creation, or invoice processing, And that duty role would contain privileges below it, such as, create an invoice, edit an invoice, validate invoices, run an invoice register process. It's those kind of privileges you would have underneath, because they're all associated to the invoice creation process or the invoice processing. So they typically are all associated to the same type of process.

Duty Roles can contain other duty roles. So, you can have a duty role inside of a Duty Role. You can have aggregate privileges inside of duty roles. There's no limit to the number of duty roles you can use. You can create, you can tie together. You can have it as convoluted, as flat as however you want to have it. There's no rhyme or reason to how that has to be, but the biggest thing about a duty role is you cannot provision or grant a duty role to a user. So, a duty role cannot be given to a user. That's where the line in the sand is kind of drawn.

So go on to the next.

A job role. This is what's granted to the user. This is the top level. This contains duty roles. It can contain an aggregate privilege. It can contain regular privileges. It can contain other job roles. You can tie just about anything to a job role. It can be very large. It can be tiny. You can have a job role that has one privilege in it, just to be able to do one tiny process. There's no reason away, or any, there's no note, but it's the word I'm trying to come up with. You can do anything you want with a job role. There's really no limits to what you want to do with the job role.

And they created a new category of job role called abstract job role. And this is comparable to a basic job role. It's pretty much the same, but it's used in a more generic way. It's really just a category of job role that is different. It also contains duty roles, aggregate privileges, other job roles. It's exactly the same when it comes to a job role.

The main difference is how it is used. It's used in a more generic way, in that job roles are typically given, and put together as similar to a position type, of a role. So, you have a person who is let’s say on the AP side, they're an invoice specialist, they create invoices. Maybe they work payments. They're working in the accounts payable department. They would have a job role that is associated to their position. Where as an abstract job role, is not associate to any type of a position. It is just a role that anyone in the whole company can use comparable said, such as an employee, job role, a line manager, job role. That seeded role is associated to somebody who works, who has direct reports underneath them and they manage those people. So it's some role that may be associated to creating expense reports, or something that is not associated to a position or a specific department in the company. It's anything it could be used for anyone, It is, that's the difference between the two. So really, it's just a different category or type of a job role.

They have to make it complicated, so they have to break all these things up into so many different categories, OK, go on to the next.

So then, inside of these job roles, they created these things called data security policies. These are in the duty roles, and the job roles only. They specify a detailed level, what the role can access, for what data. So, it's not like, we're going get to data access for users, that's the next section. It's not saying, this role can access this business unit - telling you what data it can access, you’re saying of this role has, is giving them the ability to access a business unit, the ability to access an asset book, the ability to access a sub ledger. And you can lock down that sub ledger to say, this role can only see payable sub ledger. Or this role can only see the accounts receivable sub leger, or purchasing, or an asset book sub ledger for assets, you can lock it down specifically to that.

So in financials, it gives you the ability to have access to a business unit or an asset book. In HCM, it provides much more granular. What it does is it allows you to what you can do inside of a form. So, you may have a privilege that says, Manage Users, which gives you the ability to open up the user's form, and  and select an employee, a user to view. But the data security policies tells you can view that user, or you can view the address or view their compensation statement, or I can edit the user, I can edit their address. I can edit their compensation statement, so the data security policies in HCM, grant things similar to what a privilege would. It grants the, What, I can view, what I can manage, what I can report on, it's much more, much more granular down at that level.

So, that's why I say they're so different, creating roles for financials versus HCM, specifically, in the data security policy area.

Then, you have the data access for users. This is only used on the, in the financials and supply chain area. Not used for HR at all. This is where you say, I have a user. So, Jane Doe, and a job role of accounts payable specialist, has access to a specific business unit.

She can see the business unit for Americas. Or, Jane Doe can see the cost accounting for cost Org one. You're giving them access to a specific piece of data that they can access.

The role gives them access to the forms and the functions and what they can do with the data, but this form gives them access to what data they have access to.

There is a bug. We considered a bug. Oracle says it's standard functionality, but you tell me what you think when I explain it to you. If I give somebody access to, we'll say General Ledger, and we say, they have access to view the General Ledger for Americas, but they have access to transact the General Ledger for Europe. So they can we want them to be able to view what's happening in the Americas. But we want them to transact for Europe. So we've given them a GL view only role with the security context of data access and leger for Americas and a general accounting view or general accountant type role with that ledger or data access for Europe. Now they have view only on one and transact on the other.

They go into the system, and they try to create a journal or such. They now have access to create journals in both America's and Europe, because the system does not see the fact, that they can only view only on one, and transact on the other, the transact trumps the view only. And now they have access to transact in both. So it's only module specific. So if I did the same thing in AP, and I said, you can view only on one business unit and transact, and another business unit. You would have access to transact in both business units.

It's only within a specific module, So in AP or AR, or however you work, and if you try to do a view in one, and a transact, and another to transact, will overwrite, and you'll have access to transact in both, or all, or whatever. So to me, that's a bug, because if I give you one role, and I give you data access for that role, you should be able to do what I said you should be able to do only in that, in that data, for that data, you shouldn’t be able to transact and the other data, but they say, that's how it was meant to be. And they consider that to be standard functionality. So they have no intention, at this point of changing that, even though we've asked to have it changed. So you tell me, you think that's a bug. Or do you think that's the way it should work?

Adil: Big bug. Big bug. Yeah. Big bug. Anyway.

Donna: So next. OK, so then, because I said data access for users is not for HR. That's only for financials and supply chain. We now have data roles. This is what happens on the HR side. So, for HR, and abstract roles for such as, like, employee and line manager and those type things, you have security profiles. So you have a person's security profile, which says, these are the people that you have access to. You have a country security profile that says, this is the country you can have access to. They have documents. These are only the documents that you can have access to payroll for recruiting. They have candidates. They have different recruiting areas, Different things like that. They are separated out.

And you have a role, and you say this role Job role. I'm tying this, these profiles to them. So, I create a data rule that says, This role has access to see these people in this country, and this payroll this and you tie that together, and it's called the Data Role.

So, I can have an HR analyst type of a role that has access to view certain forms and functions and pieces of information in the role. And, I can say, it's only access to Canada, and only people in certain departments, and only certain payroll areas. And that's this role, that's data access, data role, for Canada. And then I can use the exact same role. Job role, same role, same forms, same functions, and create a new data role that says, they can only see the country of the United States, and a different department and a different payroll. And I call that the role for US. So I can use the same role multiple times, because the role grants, the forms, and the functions, and the processes and things it can do, it can function. But the data role tells you who, and what, and the countries, and the legislative data, and the payroll, what data  it can work against.

Then you give that data role to the user. So you're giving that role, It becomes a role, I'd like a job role, but it's the job role in the data role together in one piece, and that's what goes to the user. So, it's done a little bit differently, and that's why the role designed for HR is so different from role design for financials and supply chain, it's really quite different.

OK, let's go on to the next, OK, so, let me show you a picture because a picture, they say is, is worth a thousand words. So, if we're looking at the general accounting, manager seeded role. This role is made up of duty roles with other duty roles. So you see the green Rs and the pink Ss, The Rs are other roles, those are other duty roles.

The Ss, they call them predefined roles. Those are like OBI roles, those are roles that are associated to reporting. You cannot customize those. That's why they call them predefined. They're predefined. You cannot change them.

So, all of the green R's, wherever you see a little black arrow coming off of it, that means there's another duty role inside of that. So, if you were to expand it, it would blow up to be bigger.

So, this job role, General Accounting Manager, also has the job role General Accountant inside of it. It inherits another job role. This is where you have a job role inside of a job role.

So, if I gave provision someone, the general accounting manager, I am by rights, provisioning them, both the General Accounting Manager and the General Accountant job role because it's, it's inherited. It's inside of it.

So then, we have a duty role called period close management, and there's a little arrow over there. Think the arrow might be off just a little bit. Anyway, if we blow up that duty role -period close management role.

Go to the next screen.

This is what it looks like when you blow that up. You have more predefined roles or other OBI roles that you can't customize, that's why they're predefined.

The P's are the privileges. So, it's made up of privileges, and the A is an aggregate privilege. This is where we have that period close piece that I was talking about how in financials, you have an aggregate privilege of period close.

So, this is what a picture looks like of the duty role that has other duty roles and privileges and an aggregate privilege, So that's kind of what that, look what the picture looks like of a duty role.

Go on to the next.

Those are our definitions, so you kind of understand where we're going, Where all this is put together at and it all is contained is in the Security Console That's our sandbox, our playground per se for roles and role design. So, this gives you access to everything, creating, editing, copying, viewing, anything you need to know about a role. You just need to ask the question correctly. Oracle is really good about giving you a lot of information if you ask it right, that's where the issue is.

So the Roles tab, when you first come in is made up of a lot of pieces, and we're going to go through some of these really quickly. To give you some information. Search format is, number one, where you get, where you have the ability to just search.

You have your search text box, 2. 3 is your button, to create a role, We typically like to copy. And I'll explain later why copying is better than creating from scratch, but you can create from scratch. There's nothing to stop you from doing that. 4 is your compare button where you have the ability to compare duty roles and compare job roles. 5 is your show graph. That's where you go from list view here to the pictures where I have the pictures showed, that's where you can see the picture at. 6 is your expand toward. So this expand toward area, and number 7 the show drop-down. These two, we work together quite a bit, and we'll use those a lot in showing you some different things. And then, 8 is your export to Excel. You can export anything that you see in here to Excel and manipulate it and look at it and review it, but realize that what you're exporting is only what's on your screen. So if you filter it, or you move things, or you change things to look at certain things, you're only going to get what your screen shows. So if you filter it, you're going to get the filtered information.

Next, so your search format, number one, allows you to narrow your search to what you're looking for. Job roles, Duty roles, abstract roles, other roles, privileges, an aggregate privileges, is the default. You can look by user, but users are not defaulted. You have to drop the arrow down and check the user's box in order to put a user in the search text box to look for what a user has access to. So, you can search by user. But you have to select it. Because it's not defaulted in.

And you have your search text box, and this is how you put what you're looking for in to get the information to show up in your criteria. You can put a piece of the information in. You can start typing. I could put Accountant, or start typing accountant, and things that had accountant in it would start to pop up for me, so you can use it however you need to, to start, just search for what you're looking for.

They expand towards drop-down, allows you to change what you're looking for. This works with the Show drop-down. Privileges is the default, but if you drop that down, you have access to see users. Also, those are the two choices here is privileges and users.

OK, go on to the next. Create Role button, allows you to create a duty role or a job role from scratch.

Compare, this allows you to compare duty roles or job roles, and you're comparing privileges. You're comparing data security policies and the inherited roles between the two. However, however you like, you can compare them.

The show graph picture allows you to change from a list view to the graphical view, and it depends on what you're looking for. So, if you're looking at the privileges and the roles and you go to graphical view, you're going to see the picture like what I showed you earlier on the slides.

If you have users selected, because you're looking at, I'm aware used, or the users of people who have access to, to the roles, you're going to see a picture of the users, not a picture of the roles with privileges. So, what you have on your screen, And you go to graphical, you're going see a picture based on what you have selected.

The Show drop-down allows you to change what you're looking at, and this works with the expand towards roles is the default, but you can drop it down and select privileges, or users as well, depending upon what you want to see, and then you have Export to Excel to export whatever's on the form.

Next, OK. Now we're going to start looking at the expand toward and the show and how they work together, because this is how you're going to see, whatever it is you're looking for on the form. The default is privileges and roles in the expand toward in the show. So, we have selected at the top is general accountant. That's a job role. So, depending upon what you select, and we're just going go forward with this job role in here, it's going to be what you see.

So, when you expand towards privileges and roles, what you're going to see on your screen are the roles that are in this job role. You're going to see, the first is the first section below, under role name are the Duty Roles, or aggregate privileges that are in this, and you've got your code, the inheritance, you're going to see how it's in this role, what it's inherited by, and the code associated.

So, you're going see roles and how they're inherited, go to the next one.

If we drop down the Show to Privileges, so, you have privileges and privileges, you're now going to see a list of all of the privileges that are in this Job role. So, you see the privileges, the Code, the description .This is the description of the privilege. How it's in here, so the inherited. So, you see where that privilege exists inside of this job role. Then the code. Now, one of the questions someone asked earlier at the beginning is, how do you know what the privileges mean because the names are confusing, and they don't necessarily always make sense.

Sometimes, you'll have a privilege that says, just for example, check funds. And the description says, check funds. Well, that doesn't tell you what it does. There's really no perfect way to find out what it does. There's documents out there in the docs dot oracle dot com. Docs.Oracle.com That website, docs dot oracle dot com, we'll get you to the document area where you can select financials or whichever area you want to go into. Each area has a section under their books where they have the administration in the security area. They have security reference documents. In those security reference documents are all of the roles, seeded roles for that area. So if you pick Financials, you're going get the Security Reference documents for financials, it's going to have all of the financial seeded role and all of them are broken up into every single duty role in that job role, Every privilege in every duty role, and a little bit of information about what it does. So, that is going to be the best way to find out what's in it, what you can do, how you can do it Other than that, it's just a matter of testing to try to figure out what it does. There's really no better way, OK, so let's go on.

So, then, they work together, dependent upon what you're looking for. So, the top box, when we when we select users, and Roles in the expand toward it and Show, the top box is a job, has the general accounting job in it. When we select users and roles for that one, it's going to show that in it, where we're looking at the general accountant. So, the general accountant is inside of the general accounting manager.

So, it's kind of you showing you where it’s used. Where is this used? If it was a job role that had a general accounting manager was selected at the top. Instead, it would just have general accounting manager below with nothing in the inherited, because it's not used anywhere but itself. But I wanted to show you if it was a job role that was inside of another job role, you can see the where used and it shows the other job role.

If you select a privilege, so the second box is a privilege, import purchase order, That's a privilege, and you're selecting users and roles. This is a where used of where that privilege is. The first column is showing you the role it's used in, whether it's a duty role or a job role - It's going to show you that. And the inherited shows you where it's in.

So, the procurement integration specialist is inside of the integration specialist role.

The procurement integration specialist role down below it, where it's blank, on the inherited role name, it's inside that role by itself as well, with nothing else.

So it's its own job role, but the job roles inside of another job role, up above it. So it kind of shows you a little bit about where things are. You have a buyer role that's inside of category manager role. Buyer roles is also inside procurement manager role, so you can kind of see how they like to nest jobs inside of jobs.

So, basically, it's a where used go onto the next one, and you drop the showdown to users as well. Sure, have users or end users.

This is a who's got it?

This is going to show you the people. People that have it and how they have it So if they just have it based on the regular role, They have, Show, full name and assigned. If they have it because it's inside of another role, It'll show exactly how they happened.

So, it really depends on what, what you have selected on, how you're going to see it.

If you go to the next screen, and you're going get this, because they'll give you this, this slide presentation.

So, the expand toward will show you if it's a duty role or a job role selected, cares that each of the expand towards, and what it shows, what you get, if it's a privilege selected, here's the different pieces the way you could have it selected and what you're going to see. So, this kind of helps you to see what, based on what you want to see, what you want to look for. This is what you need to have it selected at to determine what you want to see.

So, that's the console.

So, then, I want to spend a little bit of time on data security policies, because these guys are crazy. So, for financials, like we said it grants a role or access to a business unit.

Before it before I go on, are there any other questions that came Emma, other than the ones that came before and should we stop and answer those real quickly?

Emma: Just one, can you talk a little bit more about inherited roles and how to manage them?

Donna: OK, so inherited roles are job roles that are inside of another job. So if you have per se, the buyer role is inside of the procurement manager role. The general accountant role is inside of the general accounting manager role. So, there's really not a way to manage them, per se, other than knowing, when I give somebody the procurement manager role. They've also got the buyer role. There's nothing documented that says, this is how it works, or this is what they have. I just know that because I've been working with these roles so much.

If you look at the reference documents, or security reference documents, they do show that, if you look at the general accounting manager job role, it will show it has the general accountant role inside of it. But these are the reasons why we say, you should customize your roles. Because you have so much in there, that the user, you don't necessarily want everybody to have everything that these roles have. You want. We work with least privilege, you want the user to have only what the user needs to have and no more and no less. Just what they need to be able to do.

So, we want to take away all those extra things that they don't need to have access to. There's no reason they should have access to do all of those things, all of the setups and the configurations and the things that are in there, that that user's not going to need to have access to.

So that's how we manage those things, is by removing the things that are not necessary and keeping the things that are necessary for the users. So that's kind of how the management is done.

So, I hope that answered, if it didn't add more to your question, and we'll try to get to it after.

Anyway, data security policies. This is where it gets kind of crazy. Let’s talk about them a little bit separately, financials versus human resources, Financials grants them access to be able to use a business unit or an access book. It's not the same as Data Access for users, because we're not stating what business unit they're going to see or what asset book or what sub ledger, I mean, or what we are giving them access to a specific sub ledger, but what data access set, or what inventory org. We're just telling them, they can access it, and I'll show you in a little bit what that means, what it looks like.

Projects module does allow more data security policies to check what they can do in the actual projects form. And you can, can they edit the task? Can they create? There's a little bit more to it with a data security policy than just the privileges. Human Resources. The aggregate privilege grants access to the form, but data security policies grant the actual what can you do in that form? Can you edit it? Can you view it? Can you report it? And the data security policies work together to allow that functionality.

So, they're very different in how they work. Go to the next.

So, for financials, this is what I mean by you can give them access to allow them to use a business unit. So, for Payments, Create a payables payment, this is a data security policy on a payments job role. You grant access to that business unit and the condition, that you can't see the whole thing here, that's Red. Access the business units for which the user is explicitly authorized. So we're saying they have access to the business units that they give them access to, and data access for users. So those are the business units they can access to, we're telling them, they can, they can have access to a business unit for only those that were saying they have access to, that we're giving them off authority, too.

So, go on to the next.

And so, these are some of the checkboxes when you open up the actions and you give them access to check what can they do for business unit. They can manage payments by business unit, manage expense reports, view the employee expense, create payables payment request, manage invoice, report payables. If I don't check report payables, then none of this data can go to OBI  for reporting.

So if you create reports out of OBI and the data's not coming over, the first thing I look at is did we check report payables? Because if you don't check that, the data is not going to go allow to go to OBI reporting. So, all of these things work together. Go to the next one.

So, when somebody says, for example, they're creating payments and they say, I can't see the business unit when I try to create a payment, I can't see the business unit. I ask them, send me a picture of what you see. And the reason I ask for that is because there's two different pictures that they could have. They can have the top one or the bottom one. The top one, they drop down the list of values under Business Unit. And they don't even have a box to select a business unit. They don't even have access to anything in a business unit. This tells me, there's no data security policy for business unit. They don't have access to a business unit at all. So that's what it looks like when you don't even have data security policy allowing access to a business unit.

The bottom one, gives access to a business unit. There's a blue box there. But there's no data in the box. So, that's telling me, there's a data security policy there that says, yes, you can use the business unit, but nobody gave them data access for users of the business unit because there's no data there. If they had been given a business unit in data access for users, there would be a business unit there for them to select.

So that's the difference between what happens when you don't have the data security policy for business unit, different from when you have no data access for users for business unit. That's why, that's the difference in what it looks like. So when they say, I can't see business unit, or, I can't see my asset book or, I can't see data access, or a data access set in the GL. I say, send me a picture, because I need to see the picture to know what's missing.

Go onto the next one.

In human Resources, you have aggregate privileges that do this. So, an aggregate privilege would be manage direct report. That's the aggregate privilege.

Next screen.

This is what an aggregate privilege looks like. It is the yellow box in the middle. The yellow octagon and it has three privileges associated to it. These three privileges are part of the aggregate privilege, the super privilege. I can't take any one of those away from it. I can't add to it. I can only use the manage direct report aggregate privilege, that's all I can use, but that's what it looks like. That's what a super privilege looks like as far as the picture goes.

Go to the next one.

And so, when I am, I get that privilege to a role. This person can manage direct reports.

Then, I have to add the data security policy. So, I come in here, and I say, OK, so, here's where you have the person profiles. So, the condition, my condition, says, access the security profile for the people in their security profile. So, if I, if their security profile on the data role that they're given, says they can only access people in a certain department, then those are the people that they can manage direct reports for, because that's what their security profile says on their data role.

And then the actions, what you can't see, is a little checkbox that says Manage Direct Reports. Now, if I give them the aggregate privilege that says manage direct reports, but I don't check this box. And I don't give them the data security policies for this. They won't even have the form that says manage direct reports. The form won't even show up, even though I've given them the privilege. Because in HR, this is security policy, works with it, and they work together. You can't have one without the other. You have to have both.

Go on to the next one.

These are the kind of data security policies that HR does. You have manage all these things, manage person, documentation, driver's license, e-mail. I have to have manage in order to update or see or do anything with those, or view. I have to be able to check the view person e-mail if I want someone to be able to see somebody's e-mail in the person form. Report. I need to check the report boxes if I want a person to be able to report these into OBI So all of these boxes have to be checked in HR, in order for these things to work.

Go on to the next one.

So that's the difference between financials and HR. They are so different in the way the roles are created. They have to be done differently. So, that's typically why you have one person who does financials design, and one person who does HR design, because they are so different. I just happen to be a weird kind of person who can do both kind of odd.

But, anyway. So, let me go through these lessons learned real quick, because I know Adil has some more he wants to talk about.

Data security policies are at the job role, top level. It doesn't matter where you what you have at the duty role levels and lower. The job role doesn't see them. They're on duty roles. They're on things all over the place. But we have tested and tested and tested.

And when something isn't working right, the data security policy has to be at the job role top level. So, it doesn't really matter where they are below. It's not going to fix it. It's not going to help the role. It doesn't really matter. It's the top role. Job role, whether data security policies need to be.

Documentation is key. Keep track of what you do when you remediate, when you design, because you can use things more than once, Review your data security policies after upgrades, they change them. That's one of the few things that I have noticed, that Oracle does not document anywhere. They add in data security policies all over the place, well, not all over the place, in a few specific areas. And then, all of a sudden, functionality doesn't work. They've been doing it a lot for expenses. And so, I'll notice that will have an I have one client specifically that their AP manager role handles all of their expenses and reimbursements and then, all of a sudden, after an upgrade, it doesn't work that role won't work anymore. And they have to go back in to the business unit, data security policy, and check more boxes for the expenses in order for it to work, because they keep adding a new data security policies for expenses that have to be checked.

Roles can be migrated from instance to instance, with the data security policy. So, if you spend a lot of time creating roles in a test environment, and you get it where it's working beautifully, and you want to migrate that to your production. You can migrate it with the data security policies exactly as it is. And if you don't know how to do that, let me know, and we will get documentation to you, because it's very simple, and it's very sweet, and you shouldn't spend all that time creating it, and not be able to take that.

It’s all yours Adil.

Adil: Donna, that was wonderful. Thank you, Not a lot of details in that session. I'm sure these slides will help. Everybody just expand their experience with cloud.  One thing that I did want to mention before we get into the role design is why people do that.

So, we see a lot of our customers from a governance and audit perspective where, as I mentioned before, they just want to segregate the duties, but, you brought up something that I wanted to just amplify.

We're also seeing this quarterly release management process create an obligation on the customers to go and review duty rules and inherited roles. So, even though you have custom roles that Donna can help you build. If Oracle releases a patch that changes the Data Security Policies, or even some of the inherited duty roles, you're going to have to revisit that. And that can take a lot of time. So, you know, certainly a great place to start are these tips but there's a lot more to drill into and there is a lot of frustration among the Cloud ERP customer base. You know, folks like ERP Risk Advisors can help you, streamline the whole process.

We're also seeing changes like an industries  especially in higher ed and banking.

You know, there have been some really high profile, shakeups so I guess to use that word generally speaking and so it's an opportunity that companies are going to restructure their business, look at their controls more closely.

So, if you are using, even if you're using the ERP as is and you are satisfied today, chances are that based on these industry and economic macro factors that you might have to reconsider them on top of the technology changes which are a given.

So, thank you. So what SafePaaS can help you with. Now where do we fit into all this. So, we have a process that streamlines what Donna described and we work closely with ERP Risk advisers, one of our partners. And so, what you're seeing is that approach and what we suggest you do is you start by defining the security model as Donna has laid out, very clearly. All these components of our security model. For us, we support, all the major business applications in the world. So, the goal is to be able to protect, govern all enterprise customers in the world. So, on that mission, basically, we define these security models which we have done for the past five years, all the nitty gritty details.

And then, once we have that, we take what's called a snapshot. Because we have APIs, and that gives us the ability to then, away from the target ERP system, be able to see the data in a form that organizes it from an audit and compliance perspective. So, whether you want to find segregation of duty issues within those roles, I spend a lot of my time, or just improve productivity of your organization. But that gives you an independent view. It’s a separate workbench where you can try things out. And then, what we can do in the second swim lane there, from our approach, you can try out these different ideas, because changing a privilege that cannot be changed. Being able to combine all that, you can test out your ideas. Because sometimes this impacts hundreds of employees that say, you have an order entry group or a payment group globally. So, you can try that out within the tools we have, run in SafePaaS and you can simulate that for even policy violations like sensitive access or data security policies or just good old segregation of duties. And then, it can also generate the final role. The Target role from a source roles, so that the source role is clean, and so that whole process gets streamlined.

So instead of being a one-off rule by role, now you streamline your roles management process, with obviously, audit and controls around it, that can be managed and reviewed by internal audit, compliance folks.

And those roles can then be assigned with the confidence that these are roles that are going to serve our needs. As opposed to the seeded roles.

On top of that, we have monitoring capabilities. So some our customers would actually turn off the role changes within their Security Console, and use SafePaaS to build their roles. That's just another alternative on how, if there's a significant problem and can take lots of time that you can work with experts like Donna and her company, they can help you streamline the process and then you can map that into SafePaaS as a platform where it’s sustainable beyond the initial cleanup.

So that's role design.

OK, I think I've touched on some of the benefits. Just to kind of close out the session and answer any more questions you have. We’re down to five minutes. So, we come from a governance and compliance perspective, so obviously, you can see that by using proper role design, you have lot of instruments and tools available to you to really ensure the end of the day that your teams are productive. Your workforce is productive. You're complying with your policies, You're mitigating fraud risk. You're adjusting agile approach to your organization changes. That may be a factor of external impact on your business.

The second point, I think, is really a top reason, we hear from our customers about, just the cost of managing cloud that was the promise. And it does come down insignificantly because you don't have the infrastructure. But because of these upgrades and changes, you still have to sustain some level of expense in terms of effort.

So, being able to streamline that, automate that, it reduces not only during the implementation or when you design, you bring in folks like Donna and her company to help you design good roles because we all know the systems integrators don't actually do that job. They don't do it very well, even if they start because they just don't come from that controls background and that's where your auditors will come in and find all these conflicts.

So, before all that happens during the implementation, we can help you as a team. Certainly, you should talk to Donna. And, on top of that, if you want to make that more sustainable, then you know, we can make help you streamline that.

And what that means is it lowers the cost for you of doing business, which is so important to us these days.

Donna: Biggest cost savings is licensing.

Adil: What's that?

Donna: Biggest cost savings is licensing. If you use seeded roles, they've got a ton of privileges inside there. That will hit you on licensing. But if you are not using those areas and you can customize the roles to remove those privileges, you're not going to be hit with unnecessary licensing fees.

Adil: Oh, that's a fantastic point. I totally overlooked that. Thank you, Donna, for bringing that up, so, yeah, I mean, look. There, there are advantages and, just saving,  total cost of ownership, very hard cost, not the soft costs. So, that's a fantastic point. Again, that's also can be construed as a compliance issue with your licenses. For example, Oracle can hit you pretty hard with their audits.

And again, you know, automating this whole process will help you easily extend your organization needs to what your current needs are for your customers, your suppliers, your employees, and so forth.

Uncovering privileges. That’s other important point, because when you scan using advanced analytics, like SafePaaS has, the platform working with, they got experts like Donna. You'll be able to identify these inconsistencies and, and like the licensing point just made, and be able to improve on that. So these are improving the security and productivity overall. So these are some points that, these are business drivers, if you're interested in and pursuing this further, and you want to improve your organization's productivity, and reduce the risk on your company, Please reach out to us and we can engage with you, and help you share more details specific to your pain points.

And then if it makes sense, you can try some of this out and see how we can help you improve the controls and improve your business.

Emma: I think that brings us to the end of the session.

Donna: do you have a contacts slide?

Emma: I do. indeed, Yes. This is just a little bit about SafePaaS about what we do.

We are a policy based access governance platform that has multiple capabilities. Everything from segregation of duties, to sensitive access risks and identity lifecycle management. Privileged access management. Access Certification. So really a complete platform for all your audit risk and compliance. Governance needs. Donna?

Donna: So, ERP Risk Advisory. Mostly a content company. We have ERP Armor rules. It's an SoD content, and sensitive access content that we use with SafePaaS, as well as other companies as well. We have ERP Armor roles, we have fully customized, upgrade, proof roles, that are already fully defined. So, you don't have to go through the hassle of creating your own roles. We can migrate these, import them straight into your system. We have reports, pre-built custom reports, ERP learning, it's an on demand training for auditors, administrators, and such like that. So, if you're interested, we have support at support.erpr.net. You're welcome to e-mail and get any information there that you're interested in. And yeah, so then I think the next one goes into just

Donna:  I have a question that was asked before. If you have, we had the question was we have when we, when we do a clone to a new instance, we have users and we have roles that we have to update all the time. There's a process, HCM data loader and that's usually used on the HR side, but you can use it for other things. There's a spreadsheet update, kind of like an FTBI kind of data loader that you upload roles for users, end users. So if you have specific roles that you want to grant to certain people in a test instance, all the time, each time you do a clone, you want to update these users for roles. You can create the spreadsheet and upload each time you do a clone. It's fairly simplistic if you e-mail me. I'll be more than happy to give you some more information about that. But yeah, it works really well. So you can just add you to remove roles from users, or add roles to users. So people have what they need. Every time you do a clone, you don’t have to update that all the time, manually gets to be a little bit of a, of a problem. There any other questions, Emma?

Emma: Yes, there's a question here. I think this one might be for Adil more than you, Donna. What is your recommendation on risk rating the roles?

Adil: Yeah. In fact, one of our clients just asked us this question a few weeks ago they, but one of the Big four auditors and they're burdened by the number of Roles, the global footprint. And so, one of the things they have negotiated is that there are different level of certification as a role. Access certification is a key part of this control overall for a company that runs Oracle.

And so being able to certify the roles that are accurate, complete, and they won't, as Donna said, provide only the access that they say they will. So, customers like to know that you can rate the roles, for example, of their privileges, privilege roles, that Donna was talking about, that impact your financial statements.

If you're coming from a SOX perspective or GDPR perspective, whatever your perspective is, those roles may be high risk. So you may want to certify them more often and look at them more closely, invest more time in it.

Also, there's some inquiry roles, which are less risky, and there's specific privileges we can extract out of our analytics. And those could be done, less frequent. And that's one way of looking at risk based approach to roles, which we highly recommend so that you're not boiling the ocean every three months.

Emma: We do have a bunch of other questions actually, but we are over time. So I will whoever sent in those questions. I will e-mail copying both Adil and Donna, and then they can answer your questions via via e-mail. And if anyone does want a copy of the deck, then please reach out and I'll make sure that you receive a copy of that, and you have our contact details there on the screen. So, any closing comments from either of our speakers today? It's been an excellent session.

Donna: Thank you all for attending, we appreciate it.

Adil: Thank you Donna, and thank everybody for attending. Have a nice day.

Emma: Absolutely. Thank you, everybody, and have a good day.