Access Request & Approval Form
Captures requested access, business justification, data owner approval and expiry for non-standard entitlements.
Available soon
- Format
- Word
- Size
- 59 KB
- Length
- 19 pages
- Version
- 2.0
- Updated
What's inside
What changed
- 2.0
Rewritten to the depth of the other CISO Times packs: the form now comes with when to use it, who approves, the route a request takes, guidance for each field and the decision in order; each part's fields carry hints; and two worked requests, one granted and one capped by a contractor's end date, and a request the conflict check stops, are added.
- 1.0
Published.
Preview
The document from section 1, as you will receive it. Highlighted [[text]] is for you to replace; shaded guidance boxes are for you to delete before approval. The cover and document control pages are in the file.
How to use this form
Use this form to request, approve and record access a person's role profile does not give them. It records who asked, why, what the person will hold afterwards, who approved it, who made the change and when it ends. It is the record behind every non-standard grant in the Access Provisioning Log, and the reason the access can be removed when it is no longer needed.
A form records approval; it does not make an unapproved grant legitimate. Access granted first and approved afterwards is a breach of the Access Control Policy, whatever the form later says.
When to use the form
One request per person and per system. Use the form for these requests, and only these:
Request | This form? | What applies |
|---|---|---|
A joiner or mover receives the base profile and their role profile | No | The HR record is the request and the approved profile is the approval (JML-03). The line manager confirms the profile on the ticket. |
Access outside the person's base and role profiles | Yes | One form per person and system, with a business reason, two approvals and an expiry no more than [[6]] months ahead (JML-04). |
A mover's old access still needed after the mover window | Yes | Requested as non-standard before the window closes; otherwise it is removed (JML-08). |
Renewal of non-standard access before it expires | Yes, a new form | The same approvers as the original request, before the expiry date; otherwise the access is removed at expiry (JML-04). |
Extension of a non-employee's end date | The sponsor register, and a new form for any non-standard access that continues | Only the sponsor extends the end date (JML-10). Non-standard access never outlasts the new end date (JML-04). |
Access that would create a segregation-of-duties conflict | Yes | Part B stops the request until the conflict is separated or accepted as an exception under P02 SD-04 (JML-06). |
Privileged, emergency or service account access | No | The privileged access pack's request and elevation procedure applies (JML-16). |
A password or second-factor reset | No | The service desk's identity checks apply (JML-13). |
Approval authority
Who approves each kind of request. Nobody approves their own access, or the access of anyone who approves theirs.
Request | Who approves | Rule |
|---|---|---|
Base and role profile, for a joiner or a mover | None beyond the HR record: the profile is approved in advance by its owner and the owner of each system in it. The line manager confirms which profile applies. | JML-03 |
Non-standard access | The line manager (or the sponsor), and the owner of the system or data. With an expiry no more than [[6]] months ahead. | JML-04 |
Renewal of non-standard access, or extension of a non-employee's end date | The same approvers as the original request, before the expiry or end date. | JML-04 |
Access that would create a segregation-of-duties conflict | Not granted unless accepted as an exception under P02 SD-04, approved at the level P02 sets for the exception's band. At Critical that is the board, or a board risk committee it has delegated this to; in a two-tier structure, the management board; where there is no board, such as in an owner-managed company, executive management. | JML-06 |
An exception to the Access Control Policy | Through the P02 exception process, approved at the level P02 sets for the band. At Critical, the board, or a board risk committee it has delegated this to; in a two-tier structure, the management board; where there is no board, such as in an owner-managed company, executive management. | P02 EX-05 |
Privileged, emergency or service account access | As the Privileged Access Standard sets. | JML-16 |
A conflict accepted as an exception is approved at the level of its P02 band. A High exception, for example, is approved by the Head of Information Security and the accountable executive (risk owner), and lasts no more than 90 days.
Rules the form applies
JML-04 Access outside the person's profiles is non-standard. It needs a business reason, approval by the line manager (or the sponsor) and by the owner of the system or data, and an expiry date no more than [[6]] months ahead, or the non-employee's end date if that is sooner. At expiry it is removed unless the same approvers renewed it beforehand, with a new expiry date.
JML-05 Nobody approves their own access, or the access of anyone who approves theirs. The person who makes the change in a system does not approve it (P02 SOD-IT-01).
JML-06 Before any access right is granted or changed, the person granting it checks the person's resulting access, everything they will hold after the change including what they still hold from an earlier role, against the Segregation of Duties Conflict Matrix (P02 SD-03). A grant that would create a conflict is not made unless it has been accepted under P02 SD-04.
JML-14 Every grant, change, suspension and removal is recorded in the access provisioning log with its request reference, the approvers, who made the change and when it was completed. A removal is recorded as complete only when it is confirmed in the system.
Steps
Step | What to do | Who | When |
|---|---|---|---|
S1 | Complete Part A: the person, the system, the right in the system's own words, the business reason, the start and the expiry. | Line manager; Sponsor | Before the access is needed |
S2 | Complete Part B: list the person's resulting access, including what they still hold from an earlier role, and check it against the conflict matrix. Return the form if Part A is incomplete. | IT service desk | On receiving the form, before it goes to the approvers |
S3 | Decide Part C. Each approver confirms they are neither the person nor someone whose access the person approves, and that nobody approving will make the change. | Line manager; System owner | Before the requested start |
S4 | Complete Part D: make the change, set the expiry in the system where it can be set, confirm the right in the system, and log it. | IT service desk; System administrator | From the approved start |
S5 | Remind the requester before the expiry. Without a renewal approved by the same approvers, remove the access at expiry and record it in Part D. | IT service desk | [[10]] working days before the expiry; removal on the expiry date |
Guidance — delete before approval
Give the form a reference from the ticket, and keep the completed form with the ticket. The Access Provisioning Log records the grant with the same reference, so an auditor can go from either to the other.
Set the expiry in the system wherever it can be set. Where it cannot, the reminder [[10]] working days before is the control, and the monthly reconciliation counts anything past its expiry (JMM-04).
Who completes each part
Part | Completed by | Before | Never |
|---|---|---|---|
A Identity and request | Line manager, or the sponsor for a non-employee | The access is needed | Asks for access "the same as" someone else, or for no end date |
B Resulting access and conflicts | IT service desk | The form goes to the approvers | Checks only the right being added |
C Independent approvals | Line manager or sponsor, and the system owner | The requested start | Approves their own access, or access they will grant themselves |
D Fulfilment and expiry | IT service desk, a system administrator or the supplier that runs the system | The task is closed | Grants before Part C is complete, or closes the task before the right is confirmed in the system |
Renewals, extensions and removal at expiry
Non-standard access ends on its expiry date unless the same approvers renew it beforehand (JML-04). The IT service desk reminds the requester [[10]] working days before. A renewal is a new form, with a new reason and a new expiry no more than [[6]] months ahead; it is never a reply to the reminder saying "still needed".
If an approver has left or moved, the person now in that role approves the renewal. If nobody renews in time, the access is removed on the expiry date and recorded in Part D. Asking again later is always possible; keeping access while a renewal is "in progress" is not.
A non-employee's end date is extended only by the sponsor, in the sponsor register (JML-10). Extending the end date does not extend non-standard access: each right the person still needs is renewed on its own form, with an expiry no later than the new end date.
A right that most people in a role have renewed for a year is a candidate for the role profile. Raise it at the profile's next review instead of renewing it person by person.
Quick checks before you sign
Before you approve (Part C) | Before you grant (Part D) |
|---|---|
Is the right named exactly as the system names it? | Are both approvals in Part C, from two different people? |
Does the reason name a task the job cannot do without it? | Are you neither of the approvers, nor the person receiving the access? |
Is the expiry no more than [[6]] months ahead, and before any end date? | Does Part B show no conflict, or a separated one, or an approved exception? |
Does Part B list everything the person will hold, not only the new right? | Is the approved start today or earlier? |
Are you independent of the person and of whoever will make the change? | Can you set the expiry in the system? If not, is the reminder diarised? |
Would you be content to explain this approval to an auditor next year? | Have you confirmed the right in the system before closing the task? |
Common mistakes
Mistake | What it leads to | Rule |
|---|---|---|
Granting first and completing the form afterwards | Access with no approval behind it; the form only records a decision nobody made. | JML-04 |
Copying another person's access | Rights nobody chose, including rights that conflict with the person's own. | JML-04, JML-06 |
An expiry of "permanent" or "review in a year" | Non-standard access that becomes standing access by default. | JML-04 |
Checking the new right on its own | A conflict made of a new right and an old one, as in the stopped request below. | JML-06 |
One approver signing for both roles | A single person deciding both the need and the permission. | JML-04, JML-05 |
Closing the task when the ticket is closed | A right recorded as granted or removed that the system does not show. | JML-14 |
Field guidance
Field | A good answer | Common reason the form is sent back |
|---|---|---|
Right requested | The role, group or permission exactly as the system names it. | "Same as Sam", or "finance access". |
Business reason | The task the person's job cannot do without the right, and for how long. | "Needed for work", or the person's job title alone. |
Expiry | A date no more than [[6]] months after the start, and no later than a non-employee's end date. | Left blank, "permanent" or "until further notice". |
All access held after this change | Everything the person will hold, from the provisioning log and the system, including an earlier role's leftovers. | Only the right being added. |
Conflicts found | Conflict IDs from the matrix, or "none" with the matrix version. | Blank, or "checked" with no version. |
Independence | Two named approvers, neither of them the person or the implementer. | The requester approving as line manager of themselves, or the administrator approving their own change. |
Confirmed in the system | A screenshot, extract or system log showing the right, with the date. | "Ticket closed". |
The form
Guidance — delete before approval
Replace the placeholders with blank space when you adopt the form, or keep them as prompts. Keep the expiry limit and the conflict check the same as the Access Control Policy.
Part A: identity and request
Completed by the line manager, or by the sponsor for a non-employee.
A Identity and request | |||
Request reference from the ticket | [[from the ticket]] | ||
Date requested | [[Date requested]] | ||
Person name and account | [[name and account]] | ||
Employee or non-employee | [[Employee or non-employee]] | ||
HR record or sponsor register entry its reference | [[its reference]] | ||
Engagement end date non-employees only | [[non-employees only]] | ||
Line manager or sponsor | [[Line manager or sponsor]] | ||
System | [[System]] | ||
System or data owner | [[System or data owner]] | ||
Current profiles base and role profile | [[base and role profile]] | ||
Right requested in the system's own words | [[in the system's own words]] | ||
Business reason the task the job cannot do without it | [[the task the job cannot do without it]] | ||
Start | [[Start]] | ||
Expiry no more than the policy allows | [[no more than the policy allows]] | ||
Part B: resulting access and conflicts
Completed by the IT service desk before the form goes to the approvers. Resulting access is everything the person will hold after the change, including what remains from an earlier role (JML-06).
B Resulting access and conflicts | |||
All access held after this change including what remains from an earlier role | [[including what remains from an earlier role]] | ||
Conflict matrix version and date checked | [[Conflict matrix version and date checked]] | ||
Conflicts found conflict IDs, or none | [[conflict IDs, or none]] | ||
How the conflict is separated the right removed, if any | [[the right removed, if any]] | ||
P02 exception reference and expiry only if the conflict cannot be separated | [[only if the conflict cannot be separated]] | ||
Checked by and date | [[Checked by and date]] | ||
Part C: independent approvals
Both approvals are needed. A refusal by either ends the request.
C Independent approvals | |||
Line manager or sponsor decision, name and date | [[decision, name and date]] | ||
System or data owner decision, name and date | [[decision, name and date]] | ||
Independence each approver is neither the person, nor someone whose access the person approves, nor the implementer | [[each approver is neither the person, nor someone whose access the person approves, nor the implementer]] | ||
Approved start and expiry | [[Approved start and expiry]] | ||
Conditions of approval | [[Conditions of approval]] | ||
Refusal or return reason | [[Refusal or return reason]] | ||
Part D: fulfilment and expiry
Completed by whoever makes the change, who is never one of the approvers (JML-05).
D Fulfilment and expiry | |||
Implementer not an approver | [[not an approver]] | ||
Granted rights and completion date | [[Granted rights and completion date]] | ||
Confirmed in the system how, and evidence reference | [[how, and evidence reference]] | ||
Provisioning log reference | [[Provisioning log reference]] | ||
Expiry set in the system or the reminder that replaces it | [[or the reminder that replaces it]] | ||
Reminder recipient and date | [[recipient and date]] | ||
At expiry removed, or renewed on form reference | [[removed, or renewed on form reference]] | ||
Decision and handoff
The approvers and the implementer ask these questions in order, and stop at the first that settles it.
Question | Yes | No |
|---|---|---|
Is Part A complete, with the right in the system's own words, a reason and an expiry? | Next question. | Return the form to the requester with what is missing. |
Is the right already in the person's base or role profile? | Close the form: profile access needs no request. | Next question. |
Is the expiry no more than [[6]] months ahead, and no later than a non-employee's end date? | Next question. | Return the form with the latest allowed expiry. |
Does Part B show a conflict in the resulting access? | Stop. Separate it by removing one of the two rights, or route it to the P02 exception process. Grant nothing until one is done. | Next question. |
Have both approvers approved, each independent of the person and the implementer? | Grant from the approved start. | Refuse, with the reason in Part C. |
Expiry must be no more than [[6]] months ahead and no later than a non-employee's end date. Return incomplete requests. Refuse a conflict that has not been separated or accepted. A renewal needs the same approvals before the expiry; without one, the access is removed at expiry.
Send the decision to the requester and the implementer. Keep the approved form with the ticket and the provisioning log entry. Confirm the right in the system, set or diarise the expiry, and only then close the fulfilment task (JML-14).
Worked example: NS-2026-031, a non-standard right for a new starter
EXAMPLE, not part of the form. The organisation is the one used throughout the pack: a wholesale distributor with about 900 staff, three warehouses and an online ordering service that takes 60% of its orders. J-05 joined as a sales account manager on 14 Sep 2026 with the RP-06 profile. The job also needed one report the profile does not hold. Replace the example with your own, or delete it from the adopted form.
A Identity and request — EXAMPLE | |||
Request reference from the ticket | NS-2026-031 | ||
Date requested | Before the start date, 14 Sep 2026 | ||
Person name and account | J-05, sales account manager | ||
Employee or non-employee | Employee | ||
HR record or sponsor register entry its reference | HR record, joiner recorded on 3 Sep 2026 | ||
Engagement end date non-employees only | Not applicable: an employee | ||
Line manager or sponsor | Sales Director (line manager) | ||
System | SYS-01 ERP (hosted; P06 SUP-004) | ||
System or data owner | Chief Financial Officer | ||
Current profiles base and role profile | BP-00 base profile; RP-06 Sales account manager | ||
Right requested in the system's own words | Pricing approval report (read) | ||
Business reason the task the job cannot do without it | Checks discounts against approved price lists for key accounts | ||
Start | 14 Sep 2026 | ||
Expiry no more than the policy allows | 12 Mar 2027; the latest allowed is 14 Mar 2027 | ||
B Resulting access and conflicts — EXAMPLE | |||
All access held after this change including what remains from an earlier role | SYS-07: Staff account and single sign-on SYS-06: Mailbox and office apps SYS-01: Customer accounts and price lists (read) SYS-01: Sales orders SYS-01: Pricing approval report (read) | ||
Conflict matrix version and date checked | [[Matrix version]], checked before the grant on 14 Sep 2026 | ||
Conflicts found conflict IDs, or none | None | ||
How the conflict is separated the right removed, if any | Not needed | ||
P02 exception reference and expiry only if the conflict cannot be separated | Not needed | ||
Checked by and date | IT service desk, before the grant | ||
C Independent approvals — EXAMPLE | |||
Line manager or sponsor decision, name and date | Sales Director (line manager): approved | ||
System or data owner decision, name and date | Chief Financial Officer (system owner): approved | ||
Independence each approver is neither the person, nor someone whose access the person approves, nor the implementer | Confirmed. Neither approver is J-05; neither makes the change; J-05 approves nobody's access. | ||
Approved start and expiry | 14 Sep 2026 to 12 Mar 2027 | ||
Conditions of approval | Read only. Renewal needs the same two approvals before the expiry. | ||
Refusal or return reason | None | ||
D Fulfilment and expiry — EXAMPLE | |||
Implementer not an approver | ERP provider (P06 SUP-004) | ||
Granted rights and completion date | Pricing approval report (read), 14 Sep 2026 | ||
Confirmed in the system how, and evidence reference | [[Evidence reference: ERP role report]] | ||
Provisioning log reference | [[Log entry]] | ||
Expiry set in the system or the reminder that replaces it | The ERP role has no end date of its own, so the reminder replaces it | ||
Reminder recipient and date | Sales Director, on 26 Feb 2027 | ||
At expiry removed, or renewed on form reference | Removed on 12 Mar 2027 unless renewed beforehand | ||
The checks behind it
Check | Result | Rule |
|---|---|---|
Is the right outside the profiles? | Yes: RP-06 holds SYS-01: Customer accounts and price lists (read) and SYS-01: Sales orders, and the base profile holds SYS-07: Staff account and single sign-on and SYS-06: Mailbox and office apps. | JML-04 |
Is the expiry within the limit? | 12 Mar 2027, before the latest allowed date of 14 Mar 2027, [[6]] months after the start. | JML-04 |
Two approvers, each independent? | Sales Director (line manager) and Chief Financial Officer (system owner). Neither is the person or the implementer. | JML-04, JML-05 |
Conflict in the resulting access? | None of the matrix's conflicts appears in the 5 rights listed in Part B. | JML-06 |
Made by someone other than the approvers? | ERP provider (P06 SUP-004), by service desk ticket. | JML-05 |
Reminder before expiry | 26 Feb 2027, [[10]] working days before 12 Mar 2027. | JML-04 |
The second request: NS-2026-033, capped by an end date
Field | EXAMPLE |
|---|---|
Person | J-09, contractor, sponsored by the Head of Logistics, 21 Sep 2026 to 29 Jan 2027 |
Profiles | Base profile only. A business analyst for the warehouse system upgrade: the base profile and one non-standard right. |
Right requested | SYS-01: Stock and purchasing reports (read) |
Business reason | Analyses stock movements for the warehouse system upgrade |
Approvers | Head of Logistics (sponsor) and Chief Financial Officer (system owner) |
Implementer | ERP provider (P06 SUP-004) |
Expiry | 29 Jan 2027. [[6]] months from the start would be 21 Mar 2027, but the engagement ends sooner, and non-standard access never outlasts it. |
Reminder | 15 Jan 2027, to the sponsor |
Worked example: a request the conflict check stops
EXAMPLE. M-01 moved from accounts payable clerk to payments officer on 7 Sep 2026. Suppose the new line manager had asked, on this form, for the mover to keep the old right SYS-01: Supplier master data, including bank details for a handover of supplier queries. Part B lists the resulting access:
Access right | From | Conflict |
|---|---|---|
SYS-07: Staff account and single sign-on | Base profile | |
SYS-06: Mailbox and office apps | Base profile | |
SYS-01: Payment run approval | New profile RP-05 | SOD-FI-01 |
SYS-05: Treasury folder | New profile RP-05 | |
SYS-01: Supplier master data, including bank details | Requested on this form | SOD-FI-01 |
The two marked rights are the two duties of SOD-FI-01, rated High in the Segregation of Duties Conflict Matrix: "create or change suppliers and their bank details in the finance system" and "approve payments". The decision stops at the fourth question. Nothing is granted until the conflict is separated or accepted as a P02 exception. Here it can be separated, because the handover work does not need the bank details right: the request is refused, with that reason in Part C. (EXAMPLE)
In the EXAMPLE, no such request was made: the old right was simply never removed, and the month-end reconciliation found it. Separated: the old role's access removed. No P02 exception. Mover requests now replace the old profile by default (JML-08), and the conflict check covers the person's resulting access (JML-06).
Records and retention
Keep each completed form, with the ticket, for [[the period your records policy sets, and at least until the next audit]].
Record | Rule |
|---|---|
The approved request for non-standard access, with its expiry | JML-04 |
The segregation-of-duties check for each grant, kept as P02 SD-07 sets | JML-06 |
The access provisioning log entry for every grant, change, suspension and removal | JML-14 |
Measure. JMM-04, non-standard access past expiry: non-standard access rights past their expiry date at the period end, neither removed nor renewed. Target: zero. In the EXAMPLE, 3 at the end of July, 1 at the end of August, 0 at the end of September, out of 17 live non-standard rights. Every non-standard right given an expiry at adoption has now been removed or renewed.
Related documents
Document | Relationship |
|---|---|
Access Control Policy | The rules this form applies (JML-04, JML-05, JML-06, JML-14) |
Joiner-Mover-Leaver Operating Procedure | When non-standard access is requested in each lifecycle event |
Role-Based Access Profile Matrix | The profiles a request is checked against: anything outside them is non-standard |
Access Provisioning Log | Where the grant, the expiry and the removal are logged |
Leaver Timeliness & Orphaned Account Report | Counts non-standard access past its expiry each month |
Segregation of Duties Conflict Matrix; Security Exception Request & Approval Form | The conflicts checked in Part B, and the exception request when one cannot be separated (Security Exception, Waiver & Segregation of Duties pack) |
Access Review Campaign Workbook | Non-standard access is reviewed with everything else at each campaign (User Access Review pack) |
Privileged Access Request, Elevation & Revocation Procedure | Privileged access, which this form does not cover (Privileged Access Management pack) |
Adapting this template
Guidance — delete before approval
Small organisation: the form can be a ticket with these fields. Keep Part B: the conflict check on resulting access is what an auditor tests. Where the line manager is also the system owner, a second person, such as a director, gives the second approval.
Regulated entity (NIS2, DORA): for the digital providers its Article 1 names, Implementing Regulation (EU) 2024/2690 asks for access rights authorised by the relevant persons, third-party access limited in scope and duration, and a register of rights granted (Annex point 11.2): Parts C and D and the expiry are that record. A DORA financial entity assigns access on need-to-know, need-to-use and least privilege (Delegated Regulation (EU) 2024/1774, Article 21(a)) and enforces segregation of duties (21(b)).
IT run by a service provider: where a supplier makes the change, it completes Part D and confirms the right in the system. It never approves: Part C stays with your managers and system owners.
Delete this section before approval.
Framework references
These references show where this document supports an external framework. They indicate relevance only and do not reproduce the text of any standard. Editions referenced: ISO/IEC 27001:2022 incl. Amd 1:2024; NIST CSF 2.0; Directive (EU) 2022/2555 (NIS2) and Implementing Regulation (EU) 2024/2690; Regulation (EU) 2022/2554 (DORA); Delegated Regulation (EU) 2024/1774.
Framework | Reference | Supported by |
|---|---|---|
ISO/IEC 27001:2022 | Annex A 5.18 — Access rights | Whole form: access requested, approved, granted, recorded and removed at expiry |
ISO/IEC 27001:2022 | Annex A 5.15 — Access control | When to use the form: access outside the profiles approved each time |
ISO/IEC 27001:2022 | Annex A 5.3 — Segregation of duties | Part B: resulting access checked against the conflict matrix; Part C: independence |
NIST CSF 2.0 | PR.AA-05 — “Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties” | Parts B and C: permissions approved with least privilege and separation of duties |
NIS2 — Implementing Regulation (EU) 2024/2690 | Annex, point 11.2 — access rights are provided, modified, removed and documented under the access control policy: assigned and revoked on need-to-know, least privilege and separation of duties; “modified accordingly upon termination or change of employment”; authorised by the relevant persons; third-party access limited in scope and in duration; a register of access rights granted; logging of the management of access rights; and review at planned intervals | Parts C and D: access authorised, limited in duration and recorded |
DORA — Regulation (EU) 2022/2554 | Article 9(4)(c) — policies that limit access to information and ICT assets to what is required for legitimate and approved functions, with controls that ensure sound administration of access rights | Part A: the business reason; access limited to what the job needs |
DORA — Delegated Regulation (EU) 2024/1774 | Article 21(a) — access rights assigned on need-to-know, need-to-use and least privilege principles, including for remote and emergency access | Part A: need to know, need to use and least privilege |
DORA — Delegated Regulation (EU) 2024/1774 | Article 21(b) — an access control policy with segregation of duties that prevents combinations of access rights able to circumvent controls | Part B and the worked example the conflict check stops |
DORA — Delegated Regulation (EU) 2024/1774 | Article 21(e) — account management: roles for granting, reviewing and revoking access; privileged access on a need-to-use basis; removal without undue delay; review at least every six months for systems supporting critical or important functions and at least yearly for others | Steps and Part D: granting, expiry and removal |
Definitions
Term | Meaning in this form |
|---|---|
Access right | What an account may do in a system: a role, group or permission, in the system's own words. |
Base profile | The access everyone gets on day one: an account, single sign-on, a mailbox and the office apps. |
Implementer | Whoever makes the change in the system: the service desk, an administrator or a supplier. Never an approver of the same request. |
Non-employee | Anyone who is given an account but is not on the payroll: a contractor, an agency worker, a consultant or a supplier's staff. |
Non-standard access | Any access right that is not in the person's base or role profile. Needs its own approval and an expiry date. |
Renewal | A new approval of non-standard access, by the same approvers, before its expiry, with a new expiry date. |
Resulting access | Everything a person will hold after the change: the base profile, their role profile, any non-standard access and whatever remains from an earlier role. |
Role profile | The standard access for one job role, on top of the base profile, approved in advance by the profile owner and the owner of each system in it. Granted without further approval. |
Segregation-of-duties conflict | Two duties that would let one person make and hide an unauthorised change, payment or access grant, as listed in the Segregation of Duties Conflict Matrix. |
Sponsor | The employee accountable for a non-employee's access: normally the line manager of the team they work for. Confirms the end date, and ends or extends the access. |
Working day | Monday to Friday, excluding [[public holidays where you are]]. |