Slack access requests: a policy template

Someone needs Figma for a design review, so they ask in Slack. A person in IT reads the message, works out whether they should have it, finds the right manager, waits for a reply, assigns the app in the identity provider and answers the thread. Three months later the review is long over and the access is still there.

Most of that work is looking up rules that were never written down. This guide gives you an access policy you can copy: who may ask for what, who approves, how long access lasts, what happens when it ends and what IT records. Then it shows how to run that policy from Slack without losing the audit trail.

The short version: put every rule in the policy, not in someone's head. Give every grant an end date. Record each step as it happens.

Why access requests clog the IT queue

An access request looks small. In practice it is a chain of hand-offs, and each one waits for a person:

1. Someone reads the request and works out which app and which level of access is meant.
2. They check whether this person should have it. If the rule isn't written down, they ask around.
3. They find the approver, send a message and wait.
4. They chase the approver.
5. They assign the app or group in the identity provider and reply.
6. Someone is supposed to remember to remove it later.

Step 6 is where the risk sits. Granting access has a trigger: someone asked. Removing it usually has none, so temporary access quietly becomes permanent. The UK's Cyber Essentials scheme asks organisations to "remove or disable special access privileges when no longer required (when a member of staff changes role, for example)" in its requirements for IT infrastructure. NIST's security control catalogue, SP 800-53, goes further for temporary accounts: control AC-2(2) asks systems to remove or disable them automatically after a set period.

Slack adds its own problem. Requests arrive in direct messages, busy channels and threads, and the approval is often a thumbs-up emoji. When an auditor asks who approved someone's access to the finance system, nobody can find it.

None of this needs more IT staff. It needs the rules written once, so most requests can follow them without anyone's judgement.

What an access policy must say

A good policy answers the same questions for every app. NIST's account management control, AC-2, is a useful checklist even if you are not a US government system. It asks organisations to specify "authorized users of the system", to "require approvals by [named personnel or roles] for requests to create accounts", to authorise access based on "a valid access authorization" and "intended system usage", and to review accounts at a frequency you define. Its least privilege control, AC-6, sums up the aim: allow "only authorized accesses for users (or processes acting on behalf of users) that are necessary to accomplish assigned organizational tasks."

Cyber Essentials puts the first step even more simply: you "must have in place a process to create and approve user accounts."

In plain questions, your policy needs to say:

Two rules apply everywhere. Nobody approves their own request. And the requester never chooses the approver; the policy does. NIST covers this under separation of duties (AC-5), which asks organisations to "define system access authorizations to support separation of duties."

Just-in-time access

Just-in-time access means people get access when they need it, for a limited time, instead of keeping it for good. Microsoft's Privileged Identity Management documentation defines it as "a model in which users receive temporary permissions to perform privileged tasks, which prevents malicious or unauthorized users from gaining access after the permissions expire. Access is granted only when users need it."

The idea started with admin roles, but it works for everyday apps too, and identity providers already support the pieces. Microsoft Entra PIM can "assign time-bound access to resources using start and end dates", "require approval to activate privileged roles" and "use justification to understand why users activate." Okta's Access Requests lets admins set conditions that define "who can request access, the level of access that they can request, the duration of access, and the approval sequence for each app."

So time limits are not a technical problem. The hard part is choosing the durations, and that belongs in the policy.

An access policy template

Copy this, replace the values in brackets and keep it where IT and approvers can read it. The tiers and lengths below are starting points, not a standard. Pick what fits your risk.

Tiers, approvers and lengths

Policy text

APP ACCESS POLICY
Version [1.0]. Owner: [IT lead]. Last reviewed: [date].

1. Scope
   Covers every app and group managed in [identity provider].
   Each app has a named owner and a tier: Standard, Sensitive,
   Privileged or Not requestable.

2. Asking for access
   Ask in [#it-help] or message [the IT bot] in Slack.
   Say which app, which access level and why.
   A request for someone else names the person who needs it.

3. Approval
   The tier sets the approver. The requester never chooses.
   Nobody approves their own request.
   Approve with the approve button, not with a reply.
   No answer after [1] working day: the approver is reminded.
   No answer after [2] working days: the request goes to
   the app owner. Silence is never an approval.

4. Granting
   Access is granted in [identity provider] by app or group
   assignment. Accounts are never shared.
   Every grant has an end date within the tier's longest length.

5. Ending
   Access is removed automatically on the end date.
   The person is told [3] working days before.
   Keeping access needs a new request and a new approval.
   On a leaver's last day, all access is removed.
   After a role change, access from the old role is reviewed
   within [10] working days.

6. Exceptions
   Emergency: the on-call IT lead may grant Privileged access
   for up to [4] hours without prior approval. It is reviewed
   on the next working day.
   Contractors: the end date is the contract end date or the
   tier's longest length, whichever comes first.
   App with no tier: IT decides, then adds the app to this
   policy so the next request follows it.
   Approver away: their named delegate decides.

7. Records
   For every request keep: requester, app, access level,
   reason, policy rule, approver, decision and time, how it
   was granted, end date, and when and how it was removed.
   Keep records for [your retention period].

8. Reviews
   Sensitive and Privileged access: every [quarter].
   Standard access: every [six months].
   App owners and managers keep or remove each grant.

Three exceptions cause most of the trouble, so decide them up front. Emergencies need a fast path that is still recorded and reviewed afterwards. Approvers on holiday need a named delegate; Okta, for example, lets admins delegate tasks "when approvers or task assignees are unavailable and escalate stalled tasks." Apps nobody has classified should go to IT once, and then into the policy, so the same question never needs a person twice.

Running it from Slack

Slack is where people already ask, so keep it there. Just make the request structured and the approval recorded.

A good flow has six steps:

1. The employee asks in plain words. "I need Figma for the design review."
2. The requester is identified from the identity provider. Their Slack account must be linked to a person in your identity provider. A name typed into the message proves nothing.
3. The policy decides. Look up the app's tier, whether this person may ask, who approves and the longest access allowed. If they can't ask, say so and say why.
4. The approver gets a card. It shows who is asking, which app and level, why, the rule that chose this approver and the end date, with Approve and Deny buttons.
5. Access is granted and timed. Assign the app or group, reply in the thread with the end date and schedule the removal.
6. Every step is written to the record as it happens.

You can build this with your identity provider's own tools. Okta Access Requests can take requests from Slack: users tag the @Okta bot or use the /access slash command, and "any messages and actions within Slack are also reflected in the Access Requests web app." Approvers can act in Slack or Microsoft Teams. Two details from Okta's documentation are worth copying into any process: an approver who isn't an active user leaves the task unassigned, which "may stall the request resolution", and a request "expires if there's no activity in it for 60 days."

A few rules keep the Slack side clean:

• Buttons, not replies. "ok" in a thread is not an approval record.
• Requests go to a bot or a channel, not to one person's DMs, so nothing is lost when that person is away.
• Show the rule on the card. Approvers decide faster when they can see why they were asked.
• Keep sensitive requests private. Okta, for example, lets you mark a request, or all of a team's requests, as private.
• Remind and escalate on a timer. Never approve because nobody answered.

Expiry and access reviews

Expiry and reviews do different jobs. You need both.

Expiry handles access you knew was temporary. Set the end date when access is granted, not later. Remove it automatically on that date, and warn the person a few days before so they can ask again if they still need it. NIST's AC-2(3) asks systems to disable accounts that "have expired" or have been inactive for a set period. Microsoft PIM handles the edge case well: a user can ask for an extension before an assignment expires, or a renewal after, and both need approval. Copy that rule. Keeping access is a new decision, never a default.

Access reviews catch the rest: access granted before the policy existed, access left over after a role change and apps that never had an end date. In a user access review, managers or app owners confirm each grant or remove it. NIST's AC-6(7) asks organisations to review the privileges assigned to roles "to validate the need for such privileges" and to "reassign or remove privileges, if necessary." Cyber Essentials asks you to remove or disable user accounts "when they're no longer required (for example, when a user leaves the organisation or after a defined period of account inactivity)."

Expiry also makes reviews smaller. If most access ends on its own, a review only has to cover what is left.

The audit record IT needs

When an auditor, a security lead or a customer's security questionnaire asks why someone had access, answer from one record, not from Slack search. NIST's AC-2(4) asks systems to "automatically audit account creation, modification, enabling, disabling, and removal actions." Microsoft PIM lets admins "download audit history for internal or external audit."

Keep these fields for every request:

Write each field when it happens. A record pieced together later from chat history is slow to produce and easy to dispute.

How the BeforeQuery AI ITSM Agent helps

The AI ITSM Agent runs app access requests in Slack the way this policy describes. An employee asks in plain words. It recognises who is asking from your identity provider, so they don't fill in a form. It looks up the access policy for that app: who may ask, who approves and the longest access allowed. If the person may not ask, it says why.

The approver the policy names gets a card in Slack with who is asking, why, and the rule that asked them, and approves or denies with one tap. The agent assigns the app or group in Okta, replies in the thread and schedules removal for the end date. Approvers come from your policy, never from the AI's judgement. Nothing is approved automatically when an approver doesn't answer; it reminds them and escalates. Every request is recorded: who asked, who approved, what changed and when it ends.

If an app has no policy yet, the request goes to your IT team with the person, the app and the reason already filled in. Writing a policy for that app lets the next request run on its own. The same agent runs access reviews, where managers keep or remove each grant and removals happen in Okta.

The AI ITSM Agent works with Slack and Okta, with hand-offs to Jira. To see it with your own policy, book a demo.

Frequently asked questions

What is just-in-time access?

Just-in-time access gives people the access they need only when they need it, for a set time, instead of permanently. Microsoft describes it as temporary permissions that stop unauthorised users from gaining access after the permissions expire. In practice every grant has an end date, and keeping access means asking again.

Who should approve app access requests?

The person who knows whether the access is needed and answers for the risk. For everyday apps that is usually the requester's manager. For apps holding sensitive data, add the app owner. For admin roles, use IT or security. Name roles in the policy rather than people, and never let anyone approve their own request.

How long should temporary access last?

As short as the work allows. A simple approach is a default and a maximum for each tier, for example 90 days for everyday tools, 30 days for sensitive systems and a few hours for admin roles. These are examples, not a standard. Whatever you choose, set the end date when access is granted and remove it automatically.

Can Okta handle access requests in Slack?

Yes. Okta Access Requests, part of Okta Identity Governance, can be integrated with Slack and Microsoft Teams. Users request access by tagging the Okta bot or using the /access command, approvers can act in Slack, and requests stay in sync with the Access Requests web app. Admins define who can request each app, the approval sequence and the duration of access.

What happens if the approver doesn't respond?

Remind them, then escalate to a named backup such as the app owner. Don't approve automatically after a timeout, because silence isn't a decision. Okta, for example, lets admins delegate tasks when approvers are unavailable and escalate stalled ones.

Do we still need access reviews if access expires automatically?

Yes, but they get smaller. Expiry handles access you knew was temporary. Reviews catch standing access granted before the policy, access left over after a role change and apps with no end date. NIST SP 800-53, for example, includes regular reviews of accounts and of the privileges assigned to roles.

Sources

• NCSC: Cyber Essentials requirements for IT infrastructure v3.3 (April 2026)
• NIST SP 800-53 Rev. 5: Security and privacy controls (AC-2, AC-5, AC-6)
• Microsoft Learn: What is Microsoft Entra Privileged Identity Management?
• Okta: Access Requests
• Okta: Submit requests from Slack