3.4 Questionnaire Results

The results of the questionnaire have been analysed to determine key features, need for the tool and any additional ideas provided by the responders. The raw data is attached in a spreadsheet at the bottom of this page. The survey was sent to 30 people out of whom 21 people responded (70%).

Question 1 - Please state your job role

The job roles provided by the questionnaire responders were categorised into three main areas of expertise. As Figure 9 shows, the majority of surveys were completed by responders with a technical or analytical background. To improve the usefulness of the questionnaires, more responses from Audit and IT Security professionals would be needed.

Figure 9 - Job Role of Responders

Question 2 - In your experience of IAM tools please set your priority of the following features (1 highest), based on providing effective access management?

Figure 10 shows the average score of each of the features. The top requested feature from the choice of four was the SoD interface. As a result the software development will have this feature as its main focus.

Figure 10 - Scoring of Features

Question 3 - Please rate the following features in order with business benefit in mind.

Figure 11 shows the rating of each of the given features. The overall highest rated feature was the audit histories reports with just over 75% of respondents viewing it as a 'must have' or very useful feature. The least rated feature was users provisioning their own access with 35% if respondents rating it as 'must have' or very useful feature. The Bingo List scored third highest which is surprising as the tool will need to provide some type of exception reporting, however ‘Bingo Lists’ may not be the best method to do this.

Figure 11 - Feature Ratings

Question 4 - Based on your previous experience of IAM tools, do you feel there are any key functionality areas within IAM tools that could be improved to satisfy the demands of the auditors?

Responders gave text answers to this question. A selection of answers from these questions have prompted the following features or ideas to include in the tool.

“A good function to have for Security and for Audit would be an automated "pressure map" that will show at a glance what accounts and privileges are removed from eligibility once a particular account or privilege is selected”

New feature: There needs to be a way to reduce or drop out features that do not need to be compared to make the tool easier to operate with a large number of applications and associated attributes.

“The ability to manage the breaches of guidelines as a BAU [business as usual] task is most important - at the moment it is a 'one-off' task undertaken irregularly due to being expensive. From this perspective, moving the task into one which is easy to perform, is vital, and one which we can look at the history of to prove improvements is important. Additionally, it offers little direct benefit to the business user so either 'side' benefits such as reducing licence fees for people who don't need a particular role/licence or removing it from their visibility entirely must be looked at.”

Idea: This is a great selling point for the tool, and should be included as part of marketing once the tool is ready.

“Clear, concise and available reporting of present and historic access. Risk appetite of the organisation should also be taken into account and be available to auditors, for example SoD is not always achievable for smaller organisations. So whilst it's important to understand where the high risk accounts are it's also beneficial to capture a justification.”

New feature: Comments/justification with exclusion flags in the reports should be considered for known risks not to keep showing up on the reports as this will limit the effectiveness and usability of the tool for users to identify new compliance breaches.

Question 5 - The tool could be licensed in two possible ways. It would be useful to know of which you would find most appealing and why?

Figure 12 shows the percentage responders who chose each particular option. 14% of respondents preferred not to answer the question.

Figure 12 - Preference for Licensing of User Guardian

The in-house option outweighs the PAYG. This would go against providing User Guardian as a Cloud based application. However the reasons for the choice have provided more insight into possible concerns over data security.

“It depends on the demand of the application. If everyone in the company require to use the application, an annual license would be the right choice. If the demand of this application is low, pay as you go licensing model would be good.”

“For compliance purposes we have an on premise model for confidential data. Before being able to use a cloud based service for company confidential information we would need to review the contract for the service, including information security clauses. Additionally we'd need assurances over where the data would be stored and who would have access to it from a support perspective. Assuming these are not available we'd look to host on premise. If they are available then we would consider the SaaS/PAYG model”.

“This depends on your market, we have clients which are military and Pharma based which are very protective of their data, so I feel you would need to have both models to gain the most benefits.”

These statements would suggest a Cloud based and in-house implementation would be the best options. The Cloud based option could be aimed towards small to medium sized businesses that have fewer applications, with an in-house version for larger businesses where an IAM solution exists or the data is very sensitive.

Question 6 - Does your current IAM system (if you have one) offer adequate functionality for audit reporting and setting SoD profiles for all your applications? Would a complementary reporting tool be something of interest?

Figure 13 shows the respondents choice of answer for Question 6. There seems to be a demand for an improved reporting tool that could be used alongside existing IAM solutions. In building a bolt-on reporting tool the API and application integrations could be minimised within User Guardian and instead IAM data could be obtained directly from the organisations current IAM tool.

Figure 13 - Need for User Guardian