In part 1, I discussed the importance of understanding your company’s culture when embarking on a security project as this can be the key to success or failure. In this blog, I’ll take a closer look at the five key areas you should pay particular attention to.

1. User push back! You should be prepared for users to push back once administrative rights are removed and Application Control is put in place. In addition, do not be surprised if you lose the backing of management when faced with an unhappy workforce. I have seen so many security projects fail when security gets in the way of a user’s ability to do their job. Users may feel that such measures are draconian and that they are not trusted.

The larger the organisation, the more likely such projects will be supported and seen as normal and I would expect less push back.

2. User acceptance – security should be seen as an enabler. Crucially user acceptance comes down to presenting the changes in a positive light. Users are more likely to accept change if they understand it and feel they are gaining. Security should be an enabler. It is important to make sure you not only communicate how their computing experience will change and improve but also explain the benefits for the company.

Well-designed DiD strategy allows users to fulfill their responsibilities without being exposed to unnecessary risks and maintains performance and reliability. Information and systems security is in the interests of the company, ensuring it can remain competitive.

3. DiD is for everyone – that includes executives. I have discussed the importance of management buy-in already, but it is also important that managers set an example and are part of the project themselves. Too often, managers decide to exclude themselves on the basis that they are a part of management. If managers don't think a scheme is important, neither will the employees.

4. Language can be your downfall! The language used to promote the project should be positive and it is best to avoid using language such as ‘lockdown’ and ‘restricted privileges’. Such terms do not sit well with users and create the feeling that draconian controls are being put in place. If users can no longer perform a particular task on their endpoint, be ready to provide some justification.

5. End users are not idiots! Explain the WHY! Users will be more receptive to the project if they understand why you are implementing DiD. Explain the thought processes and how the decisions have been made. Mentioning the security aspects directly should be avoided. Failure to communicate creates an environment of suspicion and control. It is important that users understand why IT is trying to secure the environment and how this will help their job roles.

I have seen projects fail when they have not been communicated effectively and the policy design has been dictated to end users. In fact, I have seen the solution deployed to 10,000 machines WITHOUT any policy testing and this ultimately failed, as the DiD policies could not provide the correct level of elevation.

Likewise, I have worked with an engineering organisation which had all the right intentions but failed to communicate with the end users and gather requirements. Instead, they imposed policy on them. In addition, there was no feedback mechanism. This ultimately led to failure.

For more information on how to execute a successful security implementation and more detail on the above, please take a look at my book The Endpoint Security Paradox available on amazon <click here>.