SailPoint, Inc. Common Stock Status update

Hello, and welcome to my session. My name is Will Harrington. I am an identity strategist for SailPoint, and today is going to be the first of a four-part series of webinars directed at government organizations. Through this webinar series, we will be talking about how we can apply identity practice to some typical government settings. One of those settings is the machinery of government changes and how identity governance, or I am going to say IGA systems, can be impactful and very useful as a part of machinery of government. In future webinar recordings, there will be discussion around how identity governance can be integrated with cybersecurity, as well as another session on AI in identity governance and what the impact of that is, as well as the final recording in the series will be about building a business case.

As a part of securing machinery of government changes, I am going to start saying MOG. Machinery of government is quite a tongue twister, and it is getting a little bit tiring. So I am going to go to MOG and IGA. When I say MOG, you know I am talking about machinery of government changes. As a part of today's presentation, we will be covering what is a machinery of government change. This is a government webinar, so I hope all of the people who are attending today know exactly what a machinery of government change is. Those of you who are coming in from the private sector, that a machinery of government change is just like a reorg.

If you are dealing with a lot of reorgs in your organization, then maybe the same logic can apply to you, and certainly this information presented today is interchangeable between government and private. Today we will be talking about reorgs in the context of machinery of government in a government setting, and the public sector is going to be getting a lot of attention as a part of this. Second on the list is the challenges of managing a MOG. What are they? What is a MOG? The challenges of managing a MOG. There is a lot of data that changes hands as a part of a MOG, and we will get into the details of that, what the current practice is.

I have had the privilege of presenting at several Public Sector Network events in Melbourne, Adelaide and Sydney at the moment, and I will be presenting in Brisbane. I have had the opportunity to talk to a lot of public service employees, and I have queried them about how they go about machinery of government changes, and they have been able to share some details. So this is just a bit of a collation of that sharing and just what I thought was the most common. Then we are going to get into the good part, which is talking about how identity governance or IGA systems can be used as a part of facilitating MOG changes. What can we automate? Let us finish up with how to build a business case. How do we build a business case through the lens of a MOG? A MOG is a big part of government.

It happens all the time. Then there must be some way we can use that information and use that volume of change and the inefficiency of the process to be able to say, "Okay, well, if I don't have an identity governance system, how can I frame the data to then serve the purpose of building a business case for maybe the implementation of an identity governance system?" I think a MOG provides a really good place to begin that conversation. One announcement redraws the whole org chart. Just like I said earlier, a MOG is a reorg. This is where election results or we have a new ministry where there are policy shifts and portfolio changes.

This is something we just saw in Victorian Government in the last week, where we have a new premier, and as a part of having that new premier, there's a new set of ministers with new portfolios, and those portfolios are merged together or divested or moved to other ministers. That is really at the heart of machinery of government because it is those ministers who will then organize the reorganization of those departments and staff to make them more efficient and make them more effective in serving the ministerial outcomes so that it makes it easier for them to be able to communicate with their departments and affect change, really, as a part of serving in government.

The result of that is lots of change, lots of staff members maybe changing their job titles, changing their domain or email domain suffixes, changing their HR attributes, who their reporting line managers could be. There are many ways that people can move throughout an organization, and we see this quite a lot, not just in the public service, but we see it in private sector as well. Quite often, I'm quite close to working with financial services institutions, so FSIs, and every year there would be a bit of a reorg here and there, and managers would change, and people would need to reapply for their jobs. In the public service, it's just pretty much the same thing, but very much in a high volume, right? It happens quite often. As governments change, everything likes to get reorganized.

This isn't exclusive to just employees, but contractors that might be serving in departments as well systems and access need to move to the correct department. You've really got to ask the question for some of those non-human entities as well. We're talking a lot about agents these days and machine accounts. We've talked about third parties, but what happens to the ownership of those agents? There's a lot of questions. What happens to all of the access of the staff and the contractors who have that access? That's really forming the basis of this conversation today in that, pardon me, sometimes that access is retained. Sometimes people keep accounts that they shouldn't. Sometimes accounts remain enabled. Sometimes people hold that access, and maybe sometimes that access is used as a part of a threat vector.

These are the sorts of the problems that we're trying to solve as a part of a MOG change. Once again, entitlements, they provide access to records that could be classified as private. The people who do move from one department to another or who change from one government to another, should they retain access to those same records? How do you manage that effectively? How do you do that in such a way where everybody There's a large volume of change that occurs at a particular time, and that change needs to occur within a particular timeframe as well. What's the final result of a lot of this? It's being able to still deliver services to citizens effectively.

Making sure that the public service can still operate at the rate of efficiency that they do, but also be able to perform these MOGs and still deliver on the SLAs to the public. If we have a look at the order of things, just in case you don't know, a MOG order is announced, spreadsheets are compiled. This is a common thread of conversation that I had with a lot of the attendees to these PSN events, is that they said that they dealt with MOGs just through a lot of spreadsheets. What do they do with these spreadsheets?

They collate names, roles, and access that has been captured, and a lot of those spreadsheets either just get directly submitted to the service desk for someone on the service desk to then manually implement those changes and say, "I've got a list of 30 names with access add and revoke instructions or operations." Somebody on the service desk has got to work through a lot of different applications and systems. Active Directory could be representative for hundreds of applications, and then we might have more direct access in SaaS applications like Salesforce, or we might be working directly with a database as a database administrator. The service desk needs to be able to iteratively work through these lists and add and remove the access as required. Operationally, that's incredibly inefficient. That manual labor, that manual effort, it is certainly open to mistakes.

I might miss a line, I might miss a piece of access that needs to be removed. I might miss a piece of access that should be added. There could be mistakes in that spreadsheet as well. There might be just an erroneous key entry in one of those spreadsheets that breaks access for a particular user, or a user can't necessarily be set up because of the quality of the data that's being submitted. Also, I've spoken to some people at these PSN events that they said they do spreadsheets, but we do all the spreadsheets through PowerShell scripts or scripts, and that's also common as well. But where's the auditability of that? How do we know that the code that is executing on those spreadsheets is good? How do we know that there's not something in that code that is not missing something?

Or maybe that code is really good at adding access or not removing access. What are the guidelines for this code? Who owns it? What if the person who wrote that code leaves the public service, and we cannot refer back? How do we audit that? How do we know that this code is good, and what is the reusability of this code? So some really big problems when we are just dealing in the world of spreadsheets. It is okay, though. We have got a good answer. Accounts keyed in. That is the carry on from spreadsheets, and then we have got access copied like for like. This is just something else that I heard quite a lot at these government events as well, is that, well, how do I set up a user in their target environment, like in their target department?

Well, the way that we do it is we look at somebody else who is similar, maybe a similar manager, similar department, similar cost center, similar job code, something like that, and then we just copy and paste that user. So that is what we would call Model ID in the old mainframe world, where we would just take somebody and replicate that person to then set up that new user. But that is quite erroneous. The world has moved on from Model ID, and it does present an opportunity for permissions creep or over-entitling a person as a part of setting up their access. Number 5 and number 6. So we have also got old access disabled later and cleanup deferred. They are the same, but this is where we are dealing with large volume of change.