Skip to content

Access Requests and Approvals

All standard access requests must follow this procedure and the Access Control Policy.

1. Request Submission

Access requests must be submitted through Linear using the designated access-request issue type or template.

Each request must identify:

  • The individual requiring access.
  • The target system and environment.
  • The requested role or permission level.
  • The business justification.
  • The requested duration, where access is temporary.
  • Any relevant operational or project requirements.

Requests for privileged or production access must explicitly identify the elevated permissions being requested and explain why they are necessary. See Privileged Access.

2. Approval

An authorized Engineering Lead or designated system owner must review the request before access is granted.

The approver must confirm:

  • The business need is legitimate.
  • The requested permissions are appropriate.
  • The request complies with the RBAC Matrix or has a documented exception.
  • Additional restrictions or approval requirements have been satisfied.

Privileged access requires explicit approval from an authorized approver.

Approval must be recorded in Linear with an identifiable approver and timestamp. A request must not be treated as approved solely because it has been acknowledged or discussed informally.

The DevOps Engineer must not independently approve their own access requests. Those requests require an authorized approver independent of the request.

3. If an Approver or DevOps Is Unavailable

For a routine request, contact another authorized Engineering Lead or designated system owner if the usual approver is unavailable. If no authorized approver is available, hold the request; lack of response is not approval.

If the DevOps Engineer is unavailable after approval, provisioning may be performed by another administrator who is already authorized for the target system. The relevant system owner or Engineering Lead should identify the alternate, and the ticket must record who performed the work. Do not share accounts or credentials, or grant someone new administrative access solely to work around the unavailability.

If delay would create significant operational or security impact, follow the Emergency Access procedure. Emergency access is limited to the minimum necessary access and duration, and requires documentation and retrospective review; it is not a substitute for approval of routine requests.

4. Provisioning

After approval, the DevOps Engineer or another administrator already authorized for the target system provisions the approved access. If DevOps is unavailable, follow the alternate-administrator process above.

The person performing provisioning must:

  1. Verify the recorded approval.
  2. Grant only the approved permissions.
  3. Apply applicable authentication and security requirements.
  4. Verify the resulting access where reasonably practicable.
  5. Record the actual permissions and provisioning date.
  6. Update the Access Management Register.
  7. Document completion in Linear.

Where the granted permissions differ from those requested, the difference must be documented and appropriately authorized.

5. Request Completion

The Linear issue must contain sufficient information to demonstrate that the request was approved and implemented. The issue should link to the relevant Access Management Register entry where appropriate.

Requests that are rejected must record the decision and, where appropriate, the reason for rejection.

6. Changes to Existing Access

Changes to permissions must be approved before new or elevated access is granted. When responsibilities change, the individual's existing access must be reassessed; permissions approved for a previous role are not automatically still authorized.

Follow Onboarding and Offboarding for role changes and removals. Update the Access Management Register and record completed changes in Linear.