ITILSO0102 Access Management Process

Access Management Process

ITIL® 2011 Service Operation Process and Policy Pack v2 ©CertiKit ITIL is a registered trade mark of AXELOS Limited

Access Management Process

Implementation guidance The header page and this section, up to and including Disclaimer, must be removed from the final version of the document. For more details on replacing the logo, yellow highlighted text and certain generic terms, see the Completion Instructions document.

Purpose of this document This document sets out the access management process including flowchart, activities, reporting and roles and responsibilities.

Areas of the ITIL® Framework addressed The following areas of the ITIL Framework are addressed by this document: •

Service Operation: Access Management

General guidance The control of access to systems and services is a vital element of effective security and one which is often the source of publicized breaches. It is important to have a clear, defined process for user creation and access rights amendment which is audited on a regular basis.

Many organizations also fail to review who has access to which systems (and their level of access) resulting in a form of “access creep” where employees collect access rights as they move from role to role.

It is well worth spending a significant amount of time up front to put an accurate, role-based security framework in place and then ensuring that this is placed under strict change management. For some application systems the definition of roles and authorities is a specialized skill which may require external resource to get right.

Review frequency We would recommend that this document is reviewed annually.

Version 1

Page 2 of 36

[Insert date]

Access Management Process

Document fields This document may contain fields which need to be updated with your own information, including a field for Organization Name that is linked to the custom document property “Organization Name”.

To update this field (and any others that may exist in this document): 1. Update the custom document property “Organization Name” by clicking File > Info > Properties > Advanced Properties > Custom > Organization Name.

2. Press Ctrl A on the keyboard to select all text in the document (or use Select, Select All via the Editing header on the Home tab).

3. Press F9 on the keyboard to update all fields.

4. When prompted, choose the option to just update TOC page numbers.

If you wish to permanently convert the fields in this document to text, for instance, so that they are no longer updateable, you will need to click into each occurrence of the field and press Ctrl Shift F9.

If you would like to make all fields in the document visible, go to File > Options > Advanced > Show document content > Field shading and set this to “Always”. This can be useful to check you have updated all fields correctly.

Further detail on the above procedure can be found in the toolkit Completion Instructions.

This document also contains guidance on working with the toolkit documents with an Apple Mac, and in Google Docs/Sheets.

Copyright notice Except for any specifically identified third-party works included, this document has been authored by CertiKit, and is ©CertiKit except as stated below. CertiKit is a company registered in England and Wales with company number 6432088.

Licence terms This document is licensed on and subject to the standard licence terms of CertiKit, available on request, or by download from our website. All other rights are reserved. Unless you have purchased this product you only have an evaluation licence.

If this product was purchased, a full licence is granted to the person identified as the licensee in the relevant purchase order. The standard licence terms include special terms relating to any third-party copyright included in this document.

Version 1

Page 3 of 36

[Insert date]

Access Management Process

Disclaimer Please Note: Your use of and reliance on this document template is at your sole risk.

Document templates are intended to be used as a starting point only from which you will create your own document and to which you will apply all reasonable quality checks before use.

Therefore, please note that it is your responsibility to ensure that the content of any document you create that is based on our templates is correct and appropriate for your needs and complies with relevant laws in your country.

You should take all reasonable and proper legal and other professional advice before using this document.

CertiKit makes no claims, promises, or guarantees about the accuracy, completeness or adequacy of our document templates; assumes no duty of care to any person with respect its document templates or their contents; and expressly excludes and disclaims liability for any cost, expense, loss or damage suffered or incurred in reliance on our document templates, or in expectation of our document templates meeting your needs, including (without limitation) as a result of misstatements, errors and omissions in their contents.

Version 1

Page 4 of 36

[Insert date]

Access Management Process

Access Management Process

Version 1

DOCUMENT REF

ITILSO0102

VERSION

1

DATED

[Insert date]

DOCUMENT AUTHOR

[Insert name]

DOCUMENT OWNER

[Insert name/role]

Page 5 of 36

[Insert date]

Access Management Process

Revision history VERSION

DATE

REVISION AUTHOR

SUMMARY OF CHANGES

Distribution NAME

TITLE

Approval NAME

Version 1

POSITION

SIGNATURE

Page 6 of 36

DATE

[Insert date]

Access Management Process

Contents 1

2

Introduction ............................................................................................................... 9 1.1

Vision statement.......................................................................................................... 9

1.2

Purpose ....................................................................................................................... 9

1.3

Objectives.................................................................................................................... 9

1.4

Scope ........................................................................................................................ 10

Access management process .................................................................................... 11 2.1

Overview and process diagram ................................................................................... 11

2.2

Process triggers.......................................................................................................... 13

2.3

Process inputs............................................................................................................ 13

2.4

Process activities........................................................................................................ 13

2.4.1 2.4.2 2.4.3 2.4.4 2.4.5 2.4.6

2.5

Process outputs ......................................................................................................... 18

2.6

Access management tools .......................................................................................... 19

2.6.1 2.6.2 2.6.3

2.7 2.7.1 2.7.2 2.7.3 2.7.4 2.7.5

3

Receive request ......................................................................................................................... 14 Verification ................................................................................................................................ 14 Access Requests ........................................................................................................................ 15 Removal requests ...................................................................................................................... 16 Check and monitor identity status ............................................................................................. 17 Log and track access .................................................................................................................. 17

Service desk system................................................................................................................... 19 Application administration tools ................................................................................................ 19 Security audit tools .................................................................................................................... 20

Communication and training ...................................................................................... 20 Communication with users ........................................................................................................ 20 Communication with IT teams ................................................................................................... 20 Communication with system owners ......................................................................................... 20 Process performance ................................................................................................................. 21 Training for access management ............................................................................................... 21

Roles and responsibilities ......................................................................................... 22 3.1

Operational roles ....................................................................................................... 22

3.2

RACI matrix................................................................................................................ 22

3.3

Access management process owner ........................................................................... 23

3.4

Access management process manager ........................................................................ 23

3.5

Requester .................................................................................................................. 24

3.6

Service desk ............................................................................................................... 24

3.7

Approver ................................................................................................................... 24

3.8

User........................................................................................................................... 25

4

Associated documentation ....................................................................................... 26

5

Interfaces and dependencies .................................................................................... 27

Version 1

Page 7 of 36

[Insert date]

Access Management Process

6

7

8

5.1

Other service management processes ........................................................................ 27

5.2

Business processes ..................................................................................................... 28

Process measurements and metrics ......................................................................... 29 6.1

Critical success factors................................................................................................ 29

6.2

Key performance indicators........................................................................................ 29

6.3

Process reviews and audits......................................................................................... 30

Process reporting ..................................................................................................... 31 7.1

Process reports .......................................................................................................... 32

7.2

Operational reports ................................................................................................... 33

Glossary, abbreviations and references .................................................................... 34 8.1

Glossary..................................................................................................................... 34

8.2

Abbreviations ............................................................................................................ 36

8.3

References................................................................................................................. 36

Figures Figure 1: Access management process ........................................................................................ 12

Tables Table 1: RACI matrix ................................................................................................................... 22 Table 2: Associated documentation ............................................................................................ 26 Table 3: Interfaces with other service management processes .................................................... 27 Table 4: Interfaces with business processes ................................................................................ 28 Table 5: Critical success factors................................................................................................... 29 Table 6: Key performance indicators ........................................................................................... 29 Table 7: Process reports ............................................................................................................. 32 Table 8: Operational reports ...................................................................................................... 33 Table 9: Glossary of Relevant Terms ........................................................................................... 35

Version 1

Page 8 of 36

[Insert date]

Access Management Process

1 Introduction 1.1 Vision statement The vision of [Service Provider] in the area of service management is as follows: [Insert the vision statement defined as part of service strategy] This process forms a key part of the realisation of that vision.

1.2 Purpose Access management plays a critical part in the secure delivery of services and the protection of [Organization Name] assets such as personal information, financial data, intellectual property and commercially sensitive documents. In an increasingly connected world where cyber-crime is becoming more prevalent, the secure allocation and control of access forms a key cornerstone of our information security approach.

But access management is not just about preventing access to unauthorised people; it is also about ensuring that the level of service provided to legitimate users of our systems is responsive as well as secure and that unnecessary delays to the delivery of products and services to customers is avoided.

This document defines how the process of access management is implemented within [Organization Name].

The purpose of the access management process according to ITIL® is:

“… to provide the right for users to be able to use a service or group of services.”

Source: “ITIL Service Operation Book 2011. Copyright © AXELOS Limited 2011. Reproduced under license from AXELOS

1.3 Objectives The objectives of the access management process are to: • •

Provide authorised users with access to services in line with service level requirements Prevent users from accessing resources to which they are not authorised

Version 1

Page 9 of 36

[Insert date]

Access Management Process •

Ensure that access to services is controlled according to business requirements at all times

1.4 Scope The scope of this process is defined according to the following parameters: • • • •

Organizational o [List organizations and parts of those organizations covered] Geographical o [List locations from which access requests will be submitted and managed] Services o [Define the services covered by the process] Technical o [If necessary, cover the technology that will be managed via this process]

This process covers the management of all access by [Service Provider] in support of the customers and users of services defined in the service catalogue.

The following areas are specifically excluded from this process: [Describe any areas that need to be clearly stated as outside the scope]

Version 1

Page 10 of 36

[Insert date]

Access Management Process

2 Access management process 2.1 Overview and process diagram The process of access management is shown in Figure 1 and summarised below.

Changes to access for individuals may arise for a number of reasons, including new starters, leavers, secondments and promotions and they will therefore be submitted from a number of sources such as Human Resources, line management and the individual themselves.

It is important that the rules for granting, removing and amending access are clear and are in line with [Organization Name] information security policies. These rules include who may approve such access and this will vary according to the system or area involved. Access management has a strong link with the request fulfilment process as this will usually be used as the vehicle for processing access requests; a request model will therefore exist for each type of access request and will include the appropriate routing for approval.

Checks will be made at each stage of the process to ensure that the people involved are who they say they are and that the correct approvals are given at each stage. The security management information system will be used to enable this.

Once checked and approved, the access request will be carried out according to its type (e.g. new, change or removal). Separation of duties between the IT analysts involved will also be in place so that no one person is able to carry out a task on their own e.g. create a new user and provide that account with access to resources. This policy will be implemented with appropriate access restrictions on the members of the team carrying it out.

In addition to fulfilling requests related to access management, the process also involves monitoring levels of access and identifying occasions where the access control policy has been violated e.g. when one user uses another’s account to access a system. Such instances will be raised as security incidents via the incident management process. Regular access reports will also be produced to allow system owners to verify that the users and their access levels are correct.

Version 1

Page 11 of 36

[Insert date]

Access Management Process

Figure 1: Access management process

Version 1

Page 12 of 36

[Insert date]

Access Management Process

2.2 Process triggers The access management process is initiated as a result of one or more of the following triggers: • • • • •

A request to create a new user account and provide access to specified services A request to remove access to one or more services on a temporary or permanent basis A request to amend the access of an existing user A change request to create, amend or remove access to one or more users, perhaps as part of a project or as a result of a security review As a result of a security breach (i.e. an incident) which requires prompt action to limit the impact to the organization

2.3 Process inputs The process of access management requires a number of inputs in order to be able to function effectively. These may not always be available but will ideally be: •

• • • • • •

Information security policies with regard to areas such as: o Access control methods (e.g. single sign-on) o User account naming conventions o Password policies (length, strength etc.) o Internet access Up to date information regarding system and service owners and request approvers and their contact details Information about the user population, including business organization structure and upcoming changes to it The service catalogue with details of services available and service levels for access management tasks Procedures describing the method of access management for individual systems and services e.g. how to create a user, profile parameters to be specified Incidents (possibly arising from event management) identifying potential security breaches related to access management Change requests where multiple user accounts are involved, or the action required is not standard

2.4 Process activities The individual process activities at each step are detailed as follows.

Version 1

Page 13 of 36

[Insert date]

Access Management Process

2.4.1 Receive request Access to IT systems should be requested via the IT Service Desk. Where online or electronic forms are available for specific systems these should be used. In addition to system-specific details, the following should always be given: • • • • • •

Name Role Department Contact Details Name of line manager Start date (and end date if applicable)

For each system to which access is requested, further information may be required such as: • • •

Name of an existing user whose access should be duplicated (if new user is performing the same or similar role) Modules required Payroll or employee number

Where possible, requests for access should be pre-approved by the system owner or line manager before being submitted to the IT Service Desk from the approver’s email address.

2.4.2 Verification In general the fact that a request has been submitted from an existing user account will be taken as evidence that the submitting user is who they say they are. If a request is submitted via telephone or personal visit, then further identification will be required. If this is not available then the request must be submitted via one of the authorised channels such as the service request system as evidence of identity.

All requests for access to a specific system must be approved by the system owner. This will normally be a manager within the organization with specific responsibility for the security and use of that system. In some circumstances the system owner may delegate authority to approve requests to the employee’s line manager, but this fact must be recorded and verified on a regular basis.

No user accounts should be created without the required approval having been given. In the event that approval is refused, the IT service desk will inform the submitter of the request, together with any reason given. It is up to the requester to discuss the rejection directly with the system owner if required.

Version 1

Page 14 of 36

[Insert date]

Access Management Process

2.4.3 Access Requests Once an approved request with sufficient details has been received, the IT Service Desk will manage the creation of the user account. This may be done by the IT Service Desk themselves, or passed to a second or third line team to perform. User accounts should be created in line with the standards established and documented for that specific system.

These will detail parameters such as account name format, initial program calls, assigned printers etc. Account creations will be logged via the IT Service Desk System as service requests and tracked through to closure. The name of the IT service desk analyst creating the user account must also be recorded.

The IT Service Desk will set an initial password. This will be a strong password according to published guidelines. A random password generation tool may be used if available. The password will be set to expire upon first logon at which point the user will define a new password which is known only to them and which meets the parameters defined for that system.

If additional authentication tools are to be used (such as an RSA Token) the appropriate procedure for the setup of these items should be followed.

Once the user account has been created, the request should be assigned to a different member of the IT service desk team to assign the access rights to the account. Under no circumstances should the account be created and access rights assigned by the same person. For most systems, this will be achieved by placing the user account in a specific group or role that is specified on the approved request.

Upon successful completion of account setup the IT Service Desk will inform the user of the account name via email along with instructions regarding how to set a strong password when changing the initial one set by the IT Service Desk. The initial password should be communicated by telephone directly to the user after verifying the user’s identity. If the user is not available, a message should be left for them to contact the IT service desk. The password should not be left as a message.

If an authentication token is also required, this will be sent to the user by internal or external post. For external mail, a recorded delivery service should be used. Correct receipt of the token should be confirmed with the user by the IT service desk before communicating the initial password.

The service request will then be closed on the IT Service Management System.

Privileged access rights are those that involve a higher level of system access than a typical user. This includes “root” or “domain administrator” access and various types of supervisory access within application systems and databases.

The process for managing privileged access rights is basically the same as for other types of user but the approval and review aspects should be treated much more rigorously. The number of people with such rights should be carefully controlled and rights should be

Version 1

Page 15 of 36

[Insert date]

Access Management Process

removed as soon as they are no longer required. The following factors should be considered by the system owner as part of the approval criteria for such requests: • • • • •

Why does the user need privileged access rights?

Is there an alternative way to achieve the desired end result without granting privileged access rights?

Does the user have the necessary training and expertise to avoid mistakes when using the privileged access rights?

How long are the rights needed for?

Is a documented agreement such as a Non-Disclosure Agreement required (e.g. for third parties)?

A user who requires privileged access rights such as domain admin should request that a separate user account be created with these rights (e.g. john smith admin). Under no circumstances should the password for the default admin user account be issued. If the need for access is temporary, then an expiry date should be set on the user account when it is created.

When creating such accounts it should be emphasised to the user that they are only for use when a higher level of permissions is needed and their normal, lower access level account should be used most of the time.

The need for accounts to hold privileged access rights will be reviewed according to the standard review process but may be performed on a more frequent basis depending on the sensitivity of the system(s) involved.

2.4.4 Removal requests It is the responsibility of users and their managers to inform the IT Service Desk in a timely manner when employees leave the organization and so no longer need access to IT systems.

As much advance notice as possible should be given. In those circumstances where an employee has been involuntarily terminated at short notice the IT Service Desk must be informed by telephone immediately.

The IT service desk will assess the urgency of the deregistration request based on the information provided and will decide whether to disable the user account straight away or to wait until the user leaves the organization. In general for unfriendly terminations deregistration will be completed immediately whereas for voluntary resignations it will be done on the day the person leaves.

For most systems, the IT Service Desk will take the initial step of disabling the user account rather than deleting it. This will prevent access by the user but will retain all of the information associated with the account and its data.

At a later date and with the system owner’s permission, the account may be deleted once any outstanding issues have been resolved.

Version 1

Page 16 of 36

[Insert date]

Access Management Process

All user accounts associated with the user in question should be disabled even if Single Sign On (SSO) is in place e.g. if the user is in Finance, access to Active Directory and the Finance system (and any other systems the user has an account on) should be disabled. This is necessary to prevent the account being used by someone who still has access to the network in future. Accounts should be disabled in order of importance e.g. the Finance system before email.

If the deregistered user has an authentication token this should be retrieved as part of the termination process and returned to the IT service desk.

2.4.5 Check and monitor identity status From time to time there is a need to amend user access rights, often as a result of role changes or promotions. This adjustment must be carried out in a secure manner to ensure that the principles set out in the information security policy are maintained.

Once the request has been approved, the request should be allocated to a member of the IT service desk team to assign the amended access rights to the account. For most systems, this will be achieved by placing the user account in a different group or role as specified on the approved request.

Upon successful completion of the adjustment request the IT Service Desk will inform the user via email. If an authentication token is also required as a result of the adjusted access rights, this will be sent to the user by internal or external post. For external mail, a recorded delivery service should be used. Correct receipt of the token should be confirmed with the user by the IT service desk before closing the request record on the IT service management system.

2.4.6 Log and track access In order to ensure that access to IT systems is only available to authorised personnel, [Service Provider] will carry out a user access review every six months. The scope of the review should be defined in terms of the systems and networks that will be covered.

The owners of the systems and networks to be reviewed should be informed of the intention to carry out a review so that adequate time can be allocated to complete it within the target timescale.

[Service Provider] will create a listing all of the authorised users of each system together with their current level of access. This should as a minimum state the following information: • • •

Name of system Username User role title

Version 1

Page 17 of 36

[Insert date]

Access Management Process • • • • • •

User department User account name Date of user account creation User role(s) assigned Additional access rights assigned Are privileged access rights assigned to this account

Where appropriate, supporting information such as the specific permissions associated with each role defined in the system should also be provided. The report should be produced in electronic form (either spreadsheet or document) and securely emailed to the system owner. In some circumstances it may be appropriate to encrypt the file containing the report e.g. if it is to be sent to a remote office via the Internet.

The list will be reviewed by the system owner and any accounts that should not be maintained will be identified. In the event that an account is found to have been accessed after an employee has left the organization, a security incident will be raised and investigated in accordance with documented procedures.

System owners will look to identify: • • • • •

People who should not have access (e.g. leavers) User accounts with more access than required by the role User accounts with incorrect role allocations User accounts that do not provide adequate identification, e.g. generic or shared accounts Any other issues that do not comply with the organization’s access control policy

A list of issues identified should be compiled by the system owner and sent to the Information Security Manager. Any issues that appear to be urgent should be flagged as such without delay so that prompt action may be taken. Incidents should be raised where a breach of information security policy has been identified.

Actions resulting from the review should be prioritised and carried out according to their urgency. Non urgent issues may be added to the continual improvement plan as part of a wider programme of improvement. A record should be kept of all actions taken.

2.5 Process outputs The outputs of the access management process will be the following: • • • • •

New user accounts with appropriate access rights Existing user accounts with amended access rights Removed user accounts with disabled access New incidents where access control policy has been violated Access review assessments and inputs to continual service improvement

Version 1

Page 18 of 36

[Insert date]

Access Management Process

2.6 Access management tools There are a number of key software tools that underpin an effective access management process. These are subject to change as requirements and technology are updated and so specific systems are not described here. However the main types of tools that play a significant part in the process within [Organization Name] are as follows.

2.6.1 Service desk system The service desk system provides the workflow engine and database to track the core activities within access management. These include: • • • • • • • • • • • • •

Request logging Routing and assignment of requests to teams and individuals Recording of actions against requests Updating of request status from open through to closed Definition and selection of request models Assessment of impact and urgency and auto-calculation of priority Email communication with users from within request records Request categorisation to multiple levels Reporting Definition of SLA targets for service request fulfilment Automated request escalation according to SLA Provision of self-service interface for users to submit service requests and view status of open requests Facility to create request records from an email mailbox

The service desk system is integrated with the systems that support various other processes, including incident, change and configuration management.

2.6.2 Application administration tools In most cases the actual creation of user accounts and the assignment of access rights will be achieved using an administrative interface to each individual system. This may vary for those systems where single sign-on is active but an element of local configuration may still be required.

For those systems with Role-Based Access Control (RBAC) user setup should be a straightforward two step procedure of user account creation and assignment to a role (note separation of duties required).

Version 1

Page 19 of 36

[Insert date]

Access Management Process

2.6.3 Security audit tools Reporting tools may be used to query system logs for access-related messages (e.g. unsuccessful logon attempts) which may give rise to incidents in some circumstances. Audit reports may be generated from within the administrative interface of individual systems.

2.7 Communication and training There are various forms of communication that must take place for the access management process to be effective.

These are described below.

2.7.1 Communication with users As part of the processing of access management requests there may be communication with the user involved in order to clarify details (such as contact information) and to check that the request has been fulfilled correctly e.g. in the case of a user creation. The name of a new user account and the initial password will also need to be passed on.

2.7.2 Communication with IT teams Depending on the user account involved, it may be necessary to pass access requests on to other teams within IT to fulfil all or part of the request. This will be defined in the request model used.

2.7.3 Communication with system owners In general, system owners will be required to authorise access requests to the systems they take ownership of and to perform regular checks that the access permissions in place remain appropriate.

Version 1

Page 20 of 36

[Insert date]

Access Management Process

2.7.4 Process performance It is important that the performance of the access management process is monitored and reported upon on a regular basis in order to assess whether the process is operating as expected. The content of performance reports is set out in section 6 of this document, but it is vital that the reports are not only produced but are also communicated to the appropriate audience.

This will include the management of IT concerning resource utilisation and allocation.

2.7.5 Training for access management In addition to a well-defined process and appropriate software tools it is essential that the people aspects of access management are adequately addressed. The process requires that training be provided to all participants in order that it runs as smoothly as possible.

The main areas in which training will be required for IT staff participating in access management are as follows.

• • • • •

Information security policies, their content and implications for access management The access management process itself, including the activities, roles and responsibilities involved Access management software tools such as the service desk system and application administrative interfaces The basics of the technology and how it is implemented within [Organization Name] The business, its structure, locations, priorities and people

In addition, training should be provided to the user population regarding how to interface with access management, including: • • •

How to submit an access request via the various means available Use of the self-service portal, including submitting, updating and tracking an access request Use of the self-help service available via the intranet

This training may be provided via short workshops and supplemented by on demand resources such as videos and user guides.

Version 1

Page 21 of 36

[Insert date]

Access Management Process

3 Roles and responsibilities This section describes the main operational roles involved in the access management process, their interaction with the process and their detailed responsibilities.

3.1 Operational roles The following main roles participate in the access management process: • • • • •

Requester Service Desk Approver User Process Manager

There may also be interaction with IT and business management at various points in the process.

3.2 RACI matrix The table below clarifies the responsibilities of these roles at each step of the access management process using the RACI system, i.e.: • • • •

R: Responsible A: Accountable C: Consulted I: Informed

STEP

REQUESTER

SERVICE DESK

APPROVER

USER

PROCESS MANAGER

Receive request

R

I

Verification

I

R

Access requests

I

R

I

A

Removal requests

I

R

I

A

Check and monitor identity status

I

R

I

A

Log and track access

R

A R

C

A

A

Table 1: RACI matrix

Version 1

Page 22 of 36

[Insert date]

Access Management Process

3.3 Access management process owner The responsibilities of the access management process owner are: • • • • • • • • • • • • • • •

Sponsoring, designing and change managing the process and its metrics Defining the process strategy Assisting with process design Ensuring that appropriate process documentation is available and current Defining appropriate policies and standards to be employed throughout the process Periodically auditing the process to ensure compliance to policy and standards Periodically reviewing the process strategy to ensure that it is still appropriate and change as required Communicating process information or changes as appropriate to ensure awareness Providing process resources to support activities required throughout the service lifecycle Ensuring process technicians have the required knowledge and the required technical and business understanding to deliver the process and understand their role in the process Reviewing opportunities for process enhancements and for improving the efficiency and effectiveness of the process Addressing issues with the running of the process Identifying improvement opportunities for inclusion in the CSI register Making improvements to the process Working with other process owners to ensure there is an integrated approach to the design and implementation of request fulfilment, problem management, event management, access management and incident management

Source: “ITIL Service Operation Book 2011. Copyright © AXELOS Limited 2011. Reproduced under license from AXELOS

3.4 Access management process manager The responsibilities of the access management process manager are: • • • • • • • •

Working with the process owner to plan and co-ordinate all process activities Ensuring all activities are carried out as required throughout the service lifecycle Appointing people to the required roles Managing resources assigned to the process Working with service owners and other process managers to ensure the smooth running of services Monitoring and reporting on process performance Identifying improvement opportunities for inclusion in the CSI register Working with the CSI manager and process owner to review and prioritise improvements in the CSI register

Version 1

Page 23 of 36

[Insert date]

Access Management Process • • • • • • • • •

Making improvements to the process implementation Planning and managing support for access management tools and processes Coordinating interfaces between access management and other service management processes Driving the efficiency and effectiveness of the access management process Producing management information Managing the work of access management staff Monitoring the effectiveness of access management and making recommendations for improvement Developing and maintaining the access management systems Developing and maintaining the access management process and procedures

Source: “ITIL Service Operation Book 2011. Copyright © AXELOS Limited 2011. Reproduced under license from AXELOS

3.5 Requester The person submitting the access management request will: • • • •

Ensure that all required information is provided in support of the request Answer any additional questions posed by the service desk regarding the request Submit requests in sufficient time to allow the request to be processed within the SLA Provide feedback regarding satisfaction levels with the access management process

3.6 Service desk The service desk’s responsibilities with respect to access management are as follows: • • • • •

The receipt, verification and management of access requests in line with procedures and the SLA The creation of new user accounts and the assignment of rights to them The amendment of user accounts and access rights The removal of access rights in accordance with approved requests The running of standard reports to monitor the ongoing assignment of access rights

3.7 Approver Within the context of the access management process and in their role as system owner, the approver will:

Version 1

Page 24 of 36

[Insert date]

Access Management Process • • • •

Maintain a clear understanding of the types of users of the systems under their ownership and the access rights required Review access requests for systems under their ownership in a timely manner to allow the SLA to be met Signify their approval or rejection of access requests according to established procedures Nominate one or more deputies to perform their role when they are unavailable

3.8 User With respect to access management requests the user will: • • •

Co-operate with the service desk in the fulfilment of the access request, including the provision of additional information when required Test and confirm the successful completion of the access request when asked to do so by the service desk Comply with information security policies at all times

Version 1

Page 25 of 36

[Insert date]

Access Management Process

4 Associated documentation The following documentation is relevant to the access management process and should be read in conjunction with it:

DOCUMENT

REFERENCE

VERSION

LOCATION

ITIL Service Operation Book

ISBN number 9780113313075

2011

[Network drive location]

Request Fulfilment module user guide

[Network drive location]

Service management system user guide

[Network drive location]

Service management system administration guide

[Network drive location]

Application system administration guides Incident Management Process

ITILSO0301

Change Management Process Request Fulfilment Process

ITILSO0501

V1.0 Final

[Network drive location]

V1.0 Final

[Network drive location]

V1.0 Final

[Network drive location]

Table 2: Associated documentation

In the event that any of these items is not available, please contact the Service Desk Supervisor.

Version 1

Page 26 of 36

[Insert date]

Access Management Process

5 Interfaces and dependencies The access management process has a number of interfaces and dependencies with other processes within service management and the business. These are outlined here and are described in further detail in the relevant procedural documentation.

5.1 Other service management processes ITIL LIFECYCLE STAGE

PROCESS

INPUTS TO ACCESS MANAGEMENT FROM THE NAMED PROCESS

OUTPUTS FROM ACCESS MANAGEMENT TO THE NAMED PROCESS

Service Design

Service Level Management

Targets for the turnaround of access requests

Reports on achievement against targets

Service Catalogue Management

Service catalogue listing available services

Feedback on user population and distribution

Details of service and system owners

Service Transition

Service Operation

Continual Service Improvement

IT Service Continuity Management

Requirements for access when service continuity plans have been invoked

Access created for service continuity situations

Information Security Management

Information security policies for access control, separation of duties etc.

Reports on access management activities for analysis

Change Management

Change requests raised to create/amend/remove multiple users

Feedback on changes processed

Knowledge Management

Information about technology and business

Feedback on user population and distribution

Incident Management

Incidents requiring action to be taken by access management

Incidents raised as result of detected security breaches

Request Fulfilment

Provides the mechanism through which access requests are processed

Completed requests

Event Management

Alerts regarding unauthorised access attempts and breaches

Feedback on usefulness of information provided and improvements to it

Seven-Step Improvement Process

Improvement approach

Identified process improvements

Table 3: Interfaces with other service management processes

Version 1

Page 27 of 36

[Insert date]

Access Management Process

5.2 Business processes [Business processes will obviously be numerous and highly industry- and organizationspecific. We therefore recommend that you only address those that are closely linked to the process in question here.]

BUSINESS AREA

BUSINESS PROCESS

INPUTS TO ACCESS MANAGEMENT FROM THE NAMED PROCESS

OUTPUTS FROM ACCESS MANAGEMENT TO THE NAMED PROCESS

Human Resources

Recruitment

Requests for new users to be created

Notification of completed requests

Employee promotion and secondment

Requests for changed access permissions

Notification of completed requests

Employee termination

Requests for accounts to be disabled

Notification of completed requests

Finance Sales and Marketing Production/ Operations Legal and Compliance Research and Development Distribution and Logistics Customer Services Purchasing Public Relations Administration [Insert further business processes here] Table 4: Interfaces with business processes

Version 1

Page 28 of 36

[Insert date]

Access Management Process

6 Process measurements and metrics In order to determine whether the access management process is working effectively and achieving what we want it to achieve, we must first define our critical success factors and identify how we will determine if they are being fulfilled.

6.1 Critical success factors The following factors are defined as critical to the success of the access management process:

REF

CRITICAL SUCCESS FACTOR

CSF1

Access is provided to those that are legitimately authorised

CSF2

Access is denied to those that are not authorised

CSF3

The process provides value for money

Table 5: Critical success factors

6.2 Key performance indicators The following KPIs will be used on a regular basis to evidence the successful operation of the access management process:

CSF REF

KPI REF

KEY PERFORMANCE INDICATOR

CSF1

KPI1.1

Percentage of access requests processed within SLA targets

KPI1.2

Percentage of access requests where incorrect access was granted

KPI2.1

Number and percentage of unauthorised users or access found as a result of regular reviews

CSF2

Number of incidents where inappropriate access was a factor CSF3

KPI3.1

Cost per access request overall

KPI3.2

Cost per new user request

Table 6: Key performance indicators

Version 1

Page 29 of 36

[Insert date]

Access Management Process

6.3 Process reviews and audits Reviews will be carried out by the process owner in conjunction with the process manager on a three-monthly basis to assess whether the access management process is operating effectively and delivering the desired results.

These reviews will have the following as input: • • • • • • •

Follow-up action list from previous reviews Relevant changes and developments within the business and IT KPI reports from the previous period Details of all complaints logged during the period Internal and external audit reports Feedback from users and customers Identified opportunities for improvement

Each review will be documented by the process owner and actions arising agreed and published.

Audits will be carried out on an annual basis by the internal auditing department. The scope and timing of the audit will be agreed in advance. Recommendations from the audit will be published and actions discussed and agreed with the process owner.

All actions will be followed up by the internal auditor within the agreed timescales for each action.

Version 1

Page 30 of 36

[Insert date]

Access Management Process

7 Process reporting It is important that regular reports are produced for two main reasons: 1. To help to assess whether the access management process is meeting its critical success factors (see section 6.1 above) 2. To assist operational supervisors in the day-to-day management of the access management process and its resourcing These two purposes may require different views of the information available and will need to be produced at varying frequencies for differing audiences.

The format of the reports produced will also be subject to regular review and amendment as requirements become clearer and the available reporting technology within the business matures. What must be avoided is the continued production of reports that are not read and serve no purpose. It is up to the process owner, in consultation with the process manager, to ensure that all reporting remains focussed and relevant.

The following tables show the reports that will be produced together with their purpose, method of production, data source, audience and frequency. Some of the reports listed will be used for multiple purposes.

Version 1

Page 31 of 36

[Insert date]

Access Management Process

7.1 Process reports The following reports are produced by the process manager and are intended to help the process owner assess whether the CSFs for access management are being met.

REF

REPORT TITLE

DESCRIPTION

METHOD OF PRODUCTION

DATA SOURCE

FREQUENCY

AUDIENCE

CSFR1

SLA met

Percentage of access requests processed within SLA targets

Service desk system reporting tool

Service desk database

Monthly

Process owner

CSFR2

Incorrect access

Percentage of access requests where incorrect access was granted

Service desk system reporting tool

Service desk database

Monthly

Process owner

CSFR3

Unauthorised users

Number and percentage of unauthorised users or access found as a result of regular reviews

Spreadsheet produced from figures obtained during access reviews

Access review results

Quarterly

Process owner

CSFR4

Access incidents

Number of incidents where inappropriate access was a factor

Service desk system reporting tool

Service desk database

Monthly

Process owner

CSFR5

Request cost

Cost per access request overall

Service desk system reporting tool Costing information from HR and IT Finance

Service desk database Finance model

Quarterly

Process owner

CSFR6

New user cost

Cost per new user request

Service desk system reporting tool Costing information from HR and IT Finance

Service desk database Finance model

Quarterly

Process owner

CSFR13

[Insert further reports]

Table 7: Process reports

Version 1

Page 32 of 36

[Insert date]

Access Management Process

7.2 Operational reports The following reports are to provide further ongoing operational information to the process manager. They are in addition to the relevant process reports described above.

REF

REPORT TITLE

DESCRIPTION

METHOD OF PRODUCTION

DATA SOURCE

FREQUENCY

AUDIENCE

OPR1

Request trend

Number of requests processed by type

Service desk system reporting tool

Service desk database

Weekly

Process manager

OPR2

Request time

Average time to process an access request, by type

Service desk system reporting tool

Service desk database

Monthly

Process manager

OPR3

Request sources

Number of requests by source e.g. department

Service desk system reporting tool

Service desk database

Monthly

Process manager

OPR4

Requests by system

Number of requests by application system

Service desk system reporting tool

Service desk database

Monthly

Process manager

OPR5

Requests by Analyst

Number of requests processed

by IT analyst

Service desk system reporting tool

Service desk database

Weekly

Process manager

[Insert further reports] Table 8: Operational reports

Version 1

Page 33 of 36

[Insert date]

Access Management Process

8 Glossary, abbreviations and references 8.1 Glossary For a full list of terms used and their definitions within ITIL, please refer to the back of any of the books in the ITIL Lifecycle Suite 2011.

The following subset of terms is specifically relevant to this document:

TERM

MEANING

Alert

A notification that a threshold has been reached, something has changed, or a failure has occurred

Application

Software that provides functions that are required by an IT service

Audit

Formal inspection and verification to check whether a standard or set of guidelines is being followed, that records are accurate, or that efficiency and effectiveness targets are being met

Category

A named group of things that have something in common

Change

The addition, modification or removal of anything that could have an effect on IT services

Closed

The final status in the lifecycle of an incident, problem, change etc. When the status is closed, no further action is taken

Continual service improvement

A stage in the lifecycle of a service. Continual service improvement ensures that services are aligned with changing business needs by identifying and implementing improvements to IT services that support business processes

Directory service

An application that manages information about IT infrastructure available on a network, and corresponding user access rights

Escalation

An activity that obtains additional resources when these are needed to meet service level targets or customer expectations.

Event

A change of state that has significance for the management of an IT service or other configuration item

Identity

A unique name that is used to identify a user, person or role

Impact

A measure of the effect of an incident, problem or change on business processes

Incident

An unplanned interruption to an IT service or reduction in the quality of an IT service

Incident management

The process responsible for managing the lifecycle of all incidents

Information security policy

The policy that governs the organization’s approach to information security management

IT service

A service provided by an IT service provider. An IT service is made up of a combination of information technology, people and processes

Key performance indicator

A metric that is used to help manage an IT service, process, plan, project or other activity

Monitoring

Repeated observation of a configuration item, IT service or process to detect events and to ensure that the current status is known

Version 1

Page 34 of 36

[Insert date]

Access Management Process

TERM

MEANING

Priority

A category used to identify the relative importance of an incident, problem or change

Rights

Entitlements or permissions granted to a user or role

Role

A set of responsibilities, activities and authorities assigned to a person or team

Security management information system

A set of tools, data and information that is used to support information security management

Service catalogue

A database or structured document with information about all live IT services, including those available for deployment

Service desk

The single point of contact between the service provider and the users

Service level agreement

An agreement between an IT service provider and a customer

Service level target

A commitment that is documented in a service level agreement

Service owner

A role responsible for managing one or more services throughout their entire lifecycle

Urgency

A measure of how long it will be until an incident, problem or change has a significant impact on the business

User

A person who uses the IT service on a day-to-day basis. Users are distinct from customers, as some customers do not use the IT service directly

Vision

A description of what the organization intends to become in the future

Table 9: Glossary of Relevant Terms

Based on “ITIL Service Operation Book 2011”. Copyright © AXELOS Limited 2011.

Reproduced under license from AXELOS

Version 1

Page 35 of 36

[Insert date]

Access Management Process

8.2 Abbreviations The following abbreviations are used in this document: • • • • • • • •

CSF: Critical Success Factor CSI: Continual Service Improvement IT: Information Technology ITIL: Information Technology Infrastructure Library RBAC: Role-Based Access Control SKMS: Service Knowledge Management System SLA: Service Level Agreement SSO: Single Sign On

8.3 References The following sources have been used in the creation of this process document and should be consulted for more information on particular aspects of it: • • • • •

ITIL Service Operation Book 2011. Copyright © AXELOS Limited 2011 [Organization Name] IT organization structure, published dd/mm/yy [Organization Name] Business Strategy yyyy-yyyy [Organization Name] IT Strategy yyyy-yyyy [Organization Name] IT Service Management Strategy yyyy-yyyy

Version 1

Page 36 of 36

[Insert date]