I am an InfoSec professional working as an IT auditor. For several months now, I have working closely with our information security team to strengthen the security controls governing our PCI and SOX compliance efforts. Last week, new security policies went live in the production environment. In response to a comment by @Lilienthal, we are implementing these safeguards to better safeguard the production environment containing card holder data, customer PII data, and non public financially sensitive data from unauthorized access / use by employees without a need to access this information. The new controls came about both due to compliance requirements (i.e: PCI) and also to strengthen our security due to customer security being necessary and the right thing to do.

@Brandin, the new policies were communicated through joint emailing between our team and the IT Security team.

@JAB, developers either have no access or R- only access to the production servers. However, other teams such as the IT Security and DBA do have frequent needs to access the production environment, which somewhat prompted such a process change.

As examples, the following requirement is now in effect: (among others)

  1. Access to production servers must be through a jump box proxy.

Before these new changes became effective, as long as an employee had logical access to a production server, he / sh could directly access the server from his / her end point machine. Now access to sensitive company and customer data is centrally controlled through a proxy rather than individual end point user computers.

This week, our team has been getting complaints from IT and non-IT users that the new security measure are getting in the way of them performing their jobs. It seems that the end users don't really see the purpose of the new policies, although it was explained to them through a joint effort of both our teams.

As monitoring security and internal controls compliance is part of my job, I don't to go to my manager unless absolutely necessary as it seems I am unable to do my job. I also do not to alienate coworkers as I will most likely need their cooperation in the future.

When faced with resistance from other employees in implementing what is ultimately necessary and beneficial to the company, how can one best explain the situation diplomatically and effectively?

  • 10
    How much involvement did the users have in reviewing and testing the policies before they went live? – Patricia Shanahan Nov 7 '17 at 4:39
  • 1
    What's the actual problem? Non-compliance? Grumbling? The latter is to be expected when policies change. How you can sell something like this depends on details you haven't provided, specifically the actual reasons you're implementing changes. – Lilienthal Nov 7 '17 at 7:53
  • @Lilienthal - yes end users are complaining that the new policies are cumbersome and slowing down users work. I only used one new policy as an example. I also added more description on the reasoning for implementing such policies as you had requested. – Anthony Nov 8 '17 at 1:05
  • 2
    "the new security measure are getting in the way of them performing their jobs" - What about finding a technical solution to specific problems? "Getting in the way" is not specific. Example: "I didn't need to supply my password every time on this page before; now it is slowing down my work." Solutions: password-less logins using private/public key pairs, use a password manager, etc. – Brandin Nov 8 '17 at 12:00
  • 1
    How did you notify the affected persons of the changes? A company-wide e-mail might have been ignored, only skimmed, or forgetten. Something like a reminder banner near the top of affected pages might help. – Brandin Nov 8 '17 at 12:08

When faced with resistance from other employees in implementing what is ultimately necessary and beneficial to the company, how can one best explain the situation diplomatically and effectively?

Most changes take time. Also, most people are reluctant to change at first for several reasons, mostly due to the fact that they are already used to the current procedures and the new ones result unfamiliar to them.

A way to make those people stick to the change process is to make them aware of the benefits it will have after they have learned the new way.

People may get frustrated at first because things are different than they were used to (sometimes meaning they have a temporal drop in efficiency while they are learning), so telling them "hey, bear with me, after you handle the new policies this will be even easier than before" may help them take the process with a better attitude.

In short, they will eventually come to like it with time (that is, if the changes were not a failure), so a bit of patience from your side is also recommended.

As a side note, it is important to keep in mind that "what is necessary and beneficial to the company" may not be the case for the final users or employees. This could be one reason why those people are not comfortable with the changes, as usually changes in policies are made with the company's benefit as a whole (income, metrics, standards, regulations, etc.) rather than being beneficial to the employee/user directly (like a UX redesign for example).


As with any security additions that limit end users, you get backlash. Usually this passes quickly as they get used to it, the more mature (mentally) and professional the group, the less time it takes.

You don't have to do anything except politely defend the new security measures whenever needful. But, even if you personally disagree with some of the measures, do NOT let people know that. Just be professional.

  • It also might be helpful when defending the new security measures to emphasize that there is no chance of the changes being reversed as they are driven by external requirements. This might stop the grumbling quicker when people realize their complaints are fruitless. – David K Nov 30 '17 at 13:27

Security isn't an "on" or "off" thing. Each individual measure you take in the hope of improving security also has a cost, and the value of the improvement in security needs to be weighed against that cost.

As an extreme example, turning off your servers and locking them in a vault will make them considerably more secure. Yet, if your customers can't access your servers to buy things from you and you can't access them to sell things, your company won't have any revenue and the overall benefit will be (very) negative.

So as a security engineer you need to to consider not just how to make things more secure but do risk analysis and risk management: understand what risks you're taking, why, what bad things could happen and their probabilities, and the cost of those bad things should they happen. You should regularly find yourself saying, "yes, this bad thing could happen with some probability, but it's more cost effective to run that risk than to try to mitigate it further."

For your jump host, if you're surprised by the reaction of the people who need to access that server you missed something in your analysis. (You can't do a risk-benefit analysis if you don't know how much implementing a particular measure will make the users' jobs easier or more difficult.) You need to try to find out before you implement a security measure how much harder it will make users' lives. And once you've worked that out, and why it makes things harder, you're also in a better position to implement mitigating measures.

Using the example of a jump host, not allowing direct login might mean not only that users have to type an ssh command twice but also that copying files back or forth (say, to pull a backup out of the system) becomes more difficult. You might be able to mitigate this by preparing an entry for their SSH config files that uses ProxyCommand to set things up so they can still use a single SSH command just as they used to do.

Showing that you're considering how your changes affect other people's jobs will probably go a long way toward making your changes more acceptable to them.

  • Just please don't turn into one of those people who think "Yes, this bad thing could happen, but it would be to other people, so whatever." because we have too many of those already. – Erik Nov 30 '17 at 8:21
  • @Erik, that would be precisely the opposite of what I'm saying here. Something bad happening to other people is something that has a non-zero chance of coming back to you in a bad way. This could be via making others resent you and reducing their cooperativeness towards you or problems with their systems causing you trouble in some way. To some degree, everybody dealing with IT security is in it together with everybody else. – cjs Mar 18 '18 at 3:12

"When faced with resistance from other employees in implementing what is ultimately necessary and beneficial to the company, how can one best explain the situation diplomatically and effectively?"

I think this is the wrong approach. Of course you can try and explain again. But that will not help the users.

So, what I would like to suggest is:

  1. Find out what they are trying to do when security measures get in the way.

  2. Find a way for them to be as productive as before. Maybe with the help of other departments.

Understanding the necessity for the measure is only one tiny part. That part is what matters to you. But to them it matters how to do their job efficiently without having to bother with those measures. So, I feel this is where you can get them on board.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.