Too often, in the world of IT, it is easy to get caught up in the cool features and deploying new security technology and forget about the people who may be affected by those decisions. Whilst much of the technology that we implement in the InfoSec world is transparent to the “average” end-user, there are some spaces that are very heavily focused on the user who is, more often than not, NOT a technologist. With the focus on self-service capabilities, especially within the Identity and Access Management space, we as security practitioners need to be extremely aware of the impact we can have on people and their productivity.

Take, for example, the case of user access requests. In a perfect world, all users will be given exactly all the access they need on the day they begin work based solely on their job description and without human intervention; as we know, this is not often the way it really works. The reality is that we (technologists) put in a process (or set of processes) that ask the manager, admin assistant or user to provide information to get them the rights to do their job.

We rarely think about this in the context of what that user/manager/admin assistant may know (or not know) about the technology they need and make sure we are asking them questions in terms that they understand. We also don’t think about this population as one that is less comfortable with change to processes with which they have become familiar. When making a change to a technical security process, take the time to understand what downstream impacts there may be and give ample enough time and communication so that they can be adjusted, if at all possible. Neither technology nor security is their day job, so make sure not to take them away from doing that primary job in order to spend time understanding how to submit a request or translate a file share path into the group name that protects it.

Lastly, it is easy for security technologists to consider the level of support that they need when rolling out a new product, which is likely lower than that of the general population of the company or customer base. Layer on the fact that security is a topic that induces additional fear and anxiety for the average user, and spending time to ensure that service desks have the training they need to answer the calls and that users have enough guides and references to walk them through the steps will pay dividends when considering the acceptance and long-term cost of user-facing security projects.

Don’t forget: not everyone is a technologist and the more that security is delegated to the mass population of users (as it appropriately should), then we need to act similarly to traditional application development deployments and consider both the user and those that are the first-line of defence when helping those users.