All right. So developer segregation of duties is kind of a topic that we've been talking about in technology for many years, right? With Sarbanes Oxley, segregation of duties has been of importance and the lines of business, as well as in technology. So I very clearly have titled this presentation developer segregation of duties to not be confused between business segregation of duties, which obviously is a key issue, but is generally solved in the lines of business and not in the technology organization. So again, in the brief overview of my personal role, I sit in the CTO organization and I know in different organizations, my type of role can sit in multiple areas. But this function that I support is definitely heavily in alignment with our ICS or security information, security and cyber organization, as they support the IEM practices. However, we found that developer segregation of duties was something that was more operational in nature, include multiple aspects.
And we felt like we needed an ownership of that outside of the information security organization though, again, in close alignment. So the last couple years we have been working on developer segregation duties. We do have practices of course, in the organization, but in the organization, our size or in any many of your organizations of any size, you might have multiple tools, multiple practices that have grown up since your tech shop has been live and have different tools and, and activities, but it may not be a holistic view. So when we were looking at compliance and specifically questions from the regulators, we realized that we did not have one complete story about what is the developer segregation of duties. So that is when I was asked to take over as one owner or one view for oversight. So this does not mean that I own everything in aspect of segregation of duties, but it's my job to look through the organization and the current controls that we have to make sure that we have one story for developer segregation of duties.
So that became me again, my partner in crime is our head of identity and access management because a key piece of this covers into his organization. So what we started with is looking at developer segregation of duties from all the angles. So you have your traditional access roots where a developer right source code, and then it moves into a build release team or deploy agent or your SRE organization, whatever you call it, that will PR that will release those to the production environments. So that's what we call access activities or access controls. And of course through that, we are verifying that the person that wrote or authored the change is not the person that's put putting that into production. And we have controls for that, that are effective. Of course, doesn't say this here, but preventative controls anywhere that you can put them in is more efficient for your organization and helps eliminate some of the loopholes that you might have in a developer segregation and duties control environment.
But then you have to marry those with the IM access controls. So there's privilege access or break glass activities that resources can also get access to though. There's also security controls around those that potentially might be a back door. So when we evaluated those, we found that we had different set of logic for understanding who was the developer and who had access to do deploy activities versus separate from who we consider was the developer and who could have access to privilege access into the production environment. So what we found was that by marrying those two together, by looking at those practices, as well as looking at the access practices and seeing where we potentially had a gap in logic was really where we focused on the efficiencies for this. So that leads into the third bullet, which is the use of functional roles. So again, I want to stop in talk about automation for a second.
You should not be rolling your own for any of these activities. There are very, very solid tools in the SDLC space, in the IM space that support you in these practices. What we found was that tools that we already had had these capabilities, we just needed to use the capabilities for a common logic thread that we could use to make a story for developers, segregation of duties. So functional roles is what we introduced. We actually had an activity in Wells Fargo. We had normalized our job families in the last year, and we actually have aligned the functional roles to the job families. And we have made a finite statement that every individual in technology can only have one and only one developer segregation duties, functional role. So this basically means that we will not have any gaps. There is no gray space where you could actually be a developer one day and then a release engineer the next day, or in a different role.
Everyone can only perform one role that helps us with our preventative controls and to make sure that we have integrity in what we're doing. Yes, that did mean that some teams needed to review their staffing models, to make sure that they were able to accommodate that. But that enabled us to, to clarify our practices on, on segregation of duties. Additionally, we married this logic. So that functional role for an individual is used to assess both your access controls. And if you can do deployment or release or support activities, as well as your privileged access or break class capabilities. So this was a key, a key aspect in us solving this issue. And finally, developer separation scope is a bit vague. You could actually grow this into other areas, and certainly there are controls in your organization that this needs to run on top of, but as we found our scope for segregation duties, we looked through our change management controls, our release management controls, your perimeter, access controls and traditional access management controls.
All of those are foundational and that segregation dues needs to sit on top of, but developer segregation, dues is not necessarily solving those. So the reason I mention perimeter access controls is insider threat is another practice that your organization should have. And that is a way where if resources are going to try to skirt the issues, they may go farther than just trying to break into, I guess, your traditional control practices, but those are all vital aspects of a technology organization, but they're actually not developer segregation of duties. So it's also clear when you're doing a framework for what developer segregation of duties is that you effectively scope out what this practice will provide and what dependent controls it sits on. So again, all of the foundational aspects that an organizational has that should have existed for many years on segregation of duties is still vital to support. But we found that having someone come in and look at it from a holistic perspective and all the avenues that change could occur in a production environment, we were able to give it a holistic view that tightened our security posture and enabled the enterprise to have one, one risk perspective and, and risk metric across all these aspects. So I would lo that is the support of our best practices. And I'm happy to answer any questions about what we achieved here, or any thoughts from anyone that you might have on this topic.
