User Access Management Procedure

1. Purpose

This procedure defines how access to the Organisation's information, systems and networks is requested, approved, provisioned, authenticated, reviewed and withdrawn, so that every account belongs to an identified person or service, carries only the rights the work needs, and disappears when the need ends.

It implements the Access Control Policy. The policy states the rules; this procedure states who does what, in what order, within what time and with what evidence.

2. Scope

The procedure covers every identity that can reach the Organisation's information: employees, interns, contractors, consultants, supplier staff, customers' staff given access to the Organisation's platforms, service and application accounts, and administrators.

• In scope: directory and single sign-on accounts, email and collaboration tools, business applications, databases, servers, network devices, source repositories, cloud consoles, remote access gateways, and shared or generic accounts.
• In scope: physical badges and tokens only to the extent that they are tied to a logical identity; building access is governed by the Physical and Environmental Security Procedure.
• Out of scope: end-customer accounts of the Organisation's products, whose lifecycle is defined in each product's own security design.

3. Terms and Definitions

4. Roles and Responsibilities

4.1 Segregation of duties

No person approves a request that they will also execute or that grants themselves access. The access administrator cannot approve requests, and the person who reviews access to a system is not the holder of its administrator role. Where staffing makes this impossible, the Information Security team reviews the actions of that person [monthly].

5. Access Principles and Approval Authority

• Access is granted by default to nothing; a role or an explicit approval is required.
• Every account is named, individual and traceable to one identity, except the shared and service accounts allowed under account management.
• Rights follow job roles. A request that does not match a defined role is treated as an exception and needs the system owner and Information Security.
• Access to Restricted data, production systems, and administrator functions requires multi-factor authentication.
• Every grant has an end date or a review date; open-ended access is not given to third parties.

6. Role Templates and Lifecycle Timing

Role templates bundle the access that a job normally needs, so that requests are consistent and reviewers have a baseline to compare against. Each template is owned by the head of the function it serves and reviewed [every 12 months].

7. Creation of a New User Account

An account is created only when HR has confirmed that the person has completed the pre-employment checks required by the HR Security Procedure, or that the sponsor has confirmed equivalent checks for a third party.

7.1 Account request and creation

1. InitiateHR creates the joiner record with name, start date, role, department and line manager, at least [3 working days] before the start date. For a third party, the sponsor opens the request.
2. Request accessThe line manager raises an access request in [the ticketing tool] using the role template for the job and listing any additional access, with the business reason (Annexure A).
3. ApproveApprovers named in the approval authority table approve within [2 working days]. Approval is recorded in the ticket. A request without a business reason is returned.
4. Verify identityThe access administrator checks the request is from the manager of record and that the person exists in the HR record. Requests by email or phone without a ticket are refused.
5. CreateThe account is created with a unique identifier following the naming standard [firstname.lastname], with only the role template permissions, and disabled until the start date.
6. Set up authenticationA one-time credential is issued by a separate channel from the username, expiring after [24 hours]. Multi-factor authentication is enrolled on first sign-in.
7. ActivateOn the start date, the account is enabled and the user acknowledges the Acceptable Usage Policy, which is recorded.
8. Record and closeThe access register records the identity, systems, roles, approver and date. The ticket is closed only after the line manager confirms the access works.

7.2 Account types and rules

8. Secure Log-on Procedures

Systems must authenticate before showing any data or function, and must show nothing that helps an attacker, such as the names of valid users or the reason a log-on failed.

1. AuthenticateEach user signs in with a unique identity and at least one factor; multi-factor authentication is mandatory for remote access, administrator roles, email, cloud consoles and systems holding Restricted data.
2. Do not discloseLog-on screens show only a generic warning that use is for authorised purposes. Failed log-on messages say that the details are incorrect and do not say which part.
3. Limit attemptsAfter [5] consecutive failed attempts, the account is locked for [15 minutes] or until the service desk verifies the user, whichever the system supports. Alerts are raised for lockouts of privileged accounts.
4. Protect in transitCredentials are sent only over encrypted channels, according to the Cryptography Procedure. Clear-text protocols are disabled.
5. Time-outIdle sessions lock after [10 minutes] on endpoints and end after [30 minutes] on web applications handling Confidential data; administrator sessions end after [15 minutes].
6. Show last log-onWhere supported, the system displays the last successful and failed log-on so users notice misuse.
7. LogEvery successful and failed log-on, lockout and factor change is logged under the Logging and Monitoring Procedure.

9. Password Management

9.1 Issue and first use

Initial credentials are random, single use, delivered on a different channel from the username, and expire in [24 hours]. The user must change them on first sign-in. The access administrator never knows a user's permanent password.

9.2 Reset of a forgotten password

1. Verify the callerThe service desk verifies identity using self-service reset with multi-factor authentication where available. Otherwise it asks at least [two] pieces of information known to the user and HR, or calls back on the registered number or contacts the manager.
2. ResetA temporary credential is issued with the same expiry and forced change. For privileged accounts, a reset needs Information Security approval.
3. NotifyThe user receives a message on their registered contact route that a reset was done, so unauthorised resets can be reported.
4. RecordThe reset is logged with time, agent, verification method and ticket reference.

9.3 Compromised or exposed credentials

1. ReportAnyone who suspects exposure reports to the service desk within [1 hour].
2. ContainThe service desk forces a reset, ends active sessions and revokes tokens within [1 hour] of the report.
3. InvestigateInformation Security checks the logs for use of the credential and decides whether the event is an incident under the Incident Management Procedure.
4. RotateAny credential shared with systems the account could access, such as keys and service secrets, is rotated within [24 hours].
5. LearnThe root cause (phishing, reuse, breach list, insider) is recorded and used in awareness content.

10. Remote User Access

Remote access is a privilege granted to named users for business reasons. It is provided only through the approved gateway or zero-trust access service.

1. Request and approveThe line manager requests remote access stating the reason, systems and expected duration. Information Security approves; access from non-managed devices is limited to web applications and never to Restricted data.
2. Check the deviceManaged devices must be encrypted, patched within the deadlines in the Patch Management Procedure, running approved malware protection and enrolled in device management. The gateway checks device health on each connection where supported.
3. AuthenticateMulti-factor authentication is required on every connection. Credentials are never stored by the remote client.
4. RestrictUsers reach only the systems their role needs. Split tunnelling is disabled for administrator sessions. Remote administration uses a jump host and not direct access to servers.
5. MonitorRemote sessions are logged. Information Security reviews [weekly] for impossible travel, unusual hours or volumes, and connections from [countries not on the approved list].
6. Review and endRemote access is re-confirmed in the periodic review and removed when the reason ends.

Staff working from home or on the move follow the Mobile Device and Teleworking Policy, including the rules on public networks, screen privacy and the physical protection of devices. Remote access by suppliers follows the third-party rules in this procedure.

11. Account Management

The access administrator keeps accounts accurate between the formal events of creation, review and deletion.

11.1 Changes of role (movers)

1. NotifyHR informs IT of the transfer, with effective date, at least [3 working days] ahead.
2. RequestThe new line manager requests the new role template. The old manager confirms what access will be removed.
3. Add and removeThe access administrator adds new rights on the effective date and removes rights no longer needed within [5 working days]. Rights are not allowed to accumulate.
4. ConfirmThe register is updated and the new manager confirms the result.

11.2 Dormant, temporary and locked accounts

11.3 Service and shared accounts

• Each service account has a named owner, a stated purpose, the systems it can reach and a credential held in the vault.
• Interactive log-on is blocked for service accounts; they are used only by the application that needs them.
• Owners confirm [every 6 months] that each service account is still needed; unneeded ones are disabled.
• Shared accounts, where unavoidably allowed, are checked out from the vault with the user's identity logged and the credential rotated at check-in.

12. User Access Review

Access is reviewed so that rights match current duties. A review is complete only when every right is either confirmed or removed and the removals are done.

1. ExtractThe access administrator extracts the user, role and last sign-in list from each system and sends it to the reviewer [10 working days] before the due date.
2. ReviewThe reviewer marks each line Keep, Remove or Query, using the form in Annexure B. Silence is not approval; reviewers who do not respond within [10 working days] are escalated to the department head.
3. ActRemovals are completed within [5 working days] of the return of the form and confirmed by the administrator.
4. CheckInformation Security samples [10 percent] of each completed review for accuracy and reports misses.
5. ReportCompletion rate, rights removed and exceptions go to the Steering Committee.

13. User Account Deletion

Access ends when the need ends. Deletion is done in two stages: disabling at once, deleting after a retention window so that mail, files and keys can be handed over and investigation is possible.

1. TriggerHR raises the leaver request with the effective date as soon as the exit is known. For involuntary exits, HR coordinates the time with Information Security first.
2. DisableThe access administrator disables the directory account, single sign-on, remote access, VPN, badges and tokens, and revokes sessions and device certificates at the agreed time.
3. RecoverAssets are collected under the Asset Management Procedure. Delegated access to the person's mail and files is given to the manager for [30 days].
4. Remove from other systemsLocal and application-level accounts that single sign-on does not cover are removed from the register's list of systems within [2 working days]. Shared account credentials the person knew are rotated within [24 hours].
5. VerifyThe administrator checks the leaver against the master list and a next-day report of sign-in attempts. Any attempted use is escalated to Information Security.
6. DeleteAt the end of the window, the account is deleted and the data archived or erased in line with retention rules. The register entry is closed.

14. Privileged Access Management

1. RequestThe person or manager submits the privileged access request in Annexure C stating the task, systems and duration.
2. ApproveThe system owner and the Head of IT Security approve. Neither approves a request for themselves.
3. GrantThe administrator assigns the role, records start and end dates, and enrols the account for session logging.
4. UseThe holder uses the rights only for the approved task and records the ticket reference for each change.
5. Review and withdrawRights are removed at the end date. Information Security reviews logs of privileged activity [weekly] and the list of holders [quarterly].

Break-glass accounts are sealed in a safe or vault with dual control. Every use generates an alert to Information Security, requires a written reason within [1 working day], and is followed by credential rotation and a review recorded in Annexure C.

15. Cloud and Third-Party Access Controls

15.1 Cloud services

• Cloud accounts use single sign-on with multi-factor authentication. Direct local accounts are limited to the break-glass account.
• Roles are defined by task and by environment; production access is separate from development and test access.
• Programmatic keys and tokens are issued per application with minimum scope, stored in a secrets manager, rotated every [90 days] and never embedded in code or shared in chat.
• Permissions are reviewed [every 3 months] using the provider's access analysis, and unused permissions older than [90 days] are removed.
• Administrator actions on cloud consoles are logged to a store the administrators cannot alter, retained under the Logging and Monitoring Procedure.
• The cloud account owner is recorded in the Asset Management Procedure register.

15.2 Third parties and suppliers

1. Contract firstAccess is given only under a contract or agreement that contains confidentiality, security, audit and return-or-destroy clauses, as required by the Supplier Relationship Management Procedure.
2. Name a sponsorEach third-party account has a sponsor who requests, approves and removes it. Accounts are individual; supplier-wide shared accounts are not allowed.
3. LimitAccess is restricted to the systems, data and hours needed, with an end date not later than the contract end and not more than [12 months] without renewal.
4. SuperviseSupplier administrative sessions are enabled for a ticketed window, supervised or recorded, and logged.
5. Review and removeSponsors confirm [every 3 months] that each account is needed. The account is disabled at the end date and when the supplier's staff member leaves the engagement, on notice from the supplier within [1 working day].

16. Emergency Access

Emergency access lets work continue when approval cannot wait, for example for a production incident at night. It is exceptional and always reviewed afterwards.

1. RequestThe on-call engineer or incident manager asks the on-call manager for emergency access, giving the incident reference and the access needed.
2. ApproveThe on-call manager approves by recorded message or call. Information Security is informed at once.
3. GrantThe access administrator or an automated process grants the specific role, with an expiry of no more than [4 hours].
4. ReviewWithin [1 working day] the system owner and Information Security review what was done under the access, and the ticket is completed with the retrospective approval.
5. WithdrawAccess expires automatically. If it is still active after expiry, Information Security removes it and records the failure.

17. Monitoring of Access and Misuse

Information Security monitors authentication and access logs for signs of misuse. Detection use cases are tuned [every 6 months] and each alert type has an owner and a response time.

Confirmed misuse is handled as an incident and, for staff, under the HR Security Procedure. Findings feed the next access review.

18. Roles and Responsibilities Matrix

19. Measures

20. Reporting and Management Review

The Head of IT Security presents an access report to the Information Security Steering Committee [quarterly].

• Measures above with trend and cause for any missed target.
• Review results, number of rights removed, and overdue reviews with names of responsible managers.
• Privileged account count, break-glass use, and findings from the privileged activity review.
• Incidents caused by credentials, with root cause and action.
• Exceptions in force and proposed changes to roles, templates or this procedure.

Management decides on the resources needed, such as single sign-on coverage or password vault licences, and records its decisions in the management review minutes.

21. Records and Evidence

Annexure A: User access request form

Annexure B: User access review form

One form per system and review date.

Annexure C: Privileged access request and break-glass log

Annexure D: Leaver access removal checklist

22. Exception

Exceptions to this document are allowed only where compliance is not practicable and the risk has been assessed. A request must state what is to be excepted, why, the risk it creates, the compensating controls, and an end date no later than [6 months]. It is approved in writing by the document owner and the risk owner, recorded in the exceptions register, and reviewed at the end date. An exception does not change the document.

23. Enforcement

Compliance is monitored through internal audits, management review and routine checks by the document owner. Non-compliance is reported through the incident or non-conformity process and handled under the organisation's disciplinary procedure, and under the terms of any contract for people who are not employees. Serious or repeated non-compliance may lead to loss of access and, where the law is broken, to referral to the authorities.

24. Review

This document is reviewed at least every [12 months], and when there is a significant change to the organisation, its systems, its risks or the law, or after an incident that shows it was not effective. Each review is recorded in the revision history.

ISO/IEC 27001:2022 references

Related documents

• Access Control Policy
• HR Security Procedure
• Mobile Device and Teleworking Policy
• Acceptable Usage Policy
• Supplier Relationship Management Procedure
• Logging and Monitoring Procedure
• Cloud Computing Security Policy and Procedure
• Asset Management Procedure