Access Request Approval Checklist

An access request process for small teams: check the business need, apply least privilege, get the owner's approval, grant with an expiry and keep evidence.

Typical schedule per access request
The checklist 4 sections, 13 items
Variables {{requester}} {{system}} {{access_level}} {{approver}}
Start from CI

Use this template Free, no credit card. Imports the checklist into your Runbook organization.

Use this checklist whenever someone asks for access beyond their standard role: admin rights in a tool, a production database, a customer's data, a finance system. It turns "can you add me to X?" in a chat message into a decision that is checked, approved and recorded.

Who owns it

The admin of the requested system owns the run and does the actual provisioning. The system or data owner approves the request. The requester's manager confirms the business need. The approver must not be the requester, and for admin access it should not be the person who grants it either.

Common pitfalls

Approving the tool, not the level. "Access to the CRM" can mean read-only or full export. Write down the exact role or permission set.
Permanent access for a temporary need. Most elevated access is needed for a project or an incident. Set an end date and a reminder to remove it.
Granting to the person, not a group. Individual grants are hard to review later. Use a group or role where the system supports it.
Approval in a private message. If the approval only exists in someone's direct messages, you cannot show it in an access review or audit. Record it in the run.
Never checking that it works. Confirm with the requester that they have what they asked for, and nothing obviously more.

Starting a run from your request form or chat workflow keeps every request in one place. The audit trail then shows the need, the approver and the date for each grant, which is what access reviews under frameworks such as SOC 2 or ISO 27001 usually look for.

The checklist: Access request: {{requester}} to {{system}}

Request

Requested system {{system}} and exact access level {{access_level}} recorded
Business reason and expected duration recorded
{{requester}}'s manager confirmed the business need

Review

Least privilege checked: {{access_level}} is the lowest level that meets the need
Offer read-only or a narrower role where it does the job.
Existing groups or roles checked before creating a custom permission
Conflicts checked, such as one person both creating and approving payments optional
Data owner or system owner {{approver}} approved the request
The approver is not the requester. For admin access, prefer an approver other than the person granting it.

Provision

Access granted through a group or role, not as an individual permission where possible
Expiry date set in the system, or a removal reminder created
MFA confirmed on the account receiving elevated access
{{requester}} confirmed the access works as requested

Record

Grant recorded in the access register or app inventory
Request linked to the next access review for {{system}} optional

Checklist as Markdown

# Access request: {{requester}} to {{system}}

## Request
- [ ] Requested system {{system}} and exact access level {{access_level}} recorded
- [ ] Business reason and expected duration recorded
- [ ] {{requester}}'s manager confirmed the business need

## Review
- [ ] Least privilege checked: {{access_level}} is the lowest level that meets the need
  Offer read-only or a narrower role where it does the job.
- [ ] Existing groups or roles checked before creating a custom permission
- [ ] Conflicts checked, such as one person both creating and approving payments (optional)
- [ ] Data owner or system owner {{approver}} approved the request
  The approver is not the requester. For admin access, prefer an approver other than the person granting it.

## Provision
- [ ] Access granted through a group or role, not as an individual permission where possible
- [ ] Expiry date set in the system, or a removal reminder created
- [ ] MFA confirmed on the account receiving elevated access
- [ ] {{requester}} confirmed the access works as requested

## Record
- [ ] Grant recorded in the access register or app inventory
- [ ] Request linked to the next access review for {{system}} (optional)

Start this checklist from your pipeline

When an access request form is submitted, POST /api/v1/runs with template "Access request: {{requester}} to {{system}}" and access_level and approver.

curl -X POST https://runbook.metastic.ch/api/v1/runs \
  -H "Authorization: Bearer $RUNBOOK_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"template": "Access request: {{requester}} to {{system}}", "variables": {"requester": "…", "system": "…", "access_level": "…", "approver": "…"}}'

See the API and the GitHub Action

Frequently asked questions

What is a good access request process for a small company?

Keep it simple: one place to submit requests, a recorded business reason, approval by the system or data owner, provisioning through groups, and an expiry date for elevated access. Record each step so you can answer "who approved this?" later. A checklist run per request does all of this without a dedicated identity governance tool.

What does least privilege mean in an access request?

It means granting the lowest level of access that still lets the person do the task, for the shortest time needed. In practice: read-only instead of edit, one project instead of the whole account, and an end date instead of permanent access. Ask "what is the task?" before "which role?".

Who should approve access requests?

The owner of the system or data, usually a team lead or department head, approves. The requester's manager confirms the need. The requester should never approve their own access, and admin access is best approved by someone other than the person who grants it.

Updated 2026-11-04