Case Study

20,000 access requests a day, each one checked against its change ticket

How a leading banking group in the Middle East stopped privileged access being approved against expired change requests — without slowing anyone down.

Privileged accessITSM integrationBankingCustom API development
1,500
users in scope
2,500
safes
20,000
requests validated daily
30 days
from start to live

The problem

Every privileged access request at the bank was tied to a change ticket. On paper that is a solid control. In practice a person was reading the ticket and deciding whether it justified the access — and people approve twenty thousand of anything the same way they approve the first one.

What actually happened

Access was approved against an expired change request during a critical payment cycle. The change went ahead unauthorised, and priority incidents followed.

It was not a one-off. After recurring incidents exposed the same gap, the bank's security team asked for the check to stop depending on someone reading carefully at the end of a long shift.

What we built

A validation layer that sits between the access request and the approval. Before anything is granted, it reads the linked change ticket and answers three questions. Any one of them failing stops the request.

Accessrequest1Ticket valid?Open, in date, not expired2Right safe?Safe on ticket = safe requested3Right person?User ID on ticket = requesterAll three passAccess grantedAny one failsRequest rejectedP1 / P2 incidentIncident Manageradds safe + user IDad hoc, no standardchange ticket neededstill validated
Three checks, one outcome. The emergency path stays validated — it does not bypass the control, it supplies the missing detail.

How the ticket knows what to check against

Two mandatory custom fields were added to every change request: the safe name, and the requester's user ID. Nothing gets raised without them. When an access request arrives, the integration pulls both from the linked ticket and compares them to what is actually being asked for. A mismatch on either one stops the request.

The emergency question

Every reviewer asks the same thing: what happens at 3am when production is down and nobody has raised a change ticket? The answer is a defined path, not an exception. For P1 and P2 incidents the Incident Manager supplies the safe name and user ID directly, and the same validation runs against those. Emergency access is still checked — it just does not wait for a ticket that would not exist yet.

Before and after

Before

  • A person read the ticket and judged whether it justified the access
  • Expired change requests could be approved without anyone noticing
  • Nothing structurally connected the safe being requested to the safe on the ticket
  • 15–20 minutes per approval
  • Unauthorised changes and the priority incidents that followed

After

  • Three checks run automatically before approval is possible
  • An expired ticket cannot pass, regardless of who is approving
  • Safe and user ID are matched against the ticket every time
  • Under 5 minutes per approval
  • A defined, still-validated path for genuine emergencies

Results

Measure
Before
After
Approval turnaround
15–20 minutes
Under 5 minutes
Expired-ticket approvals
Possible
Blocked
Safe / requester match
Manual judgement
Enforced
Emergency access
Undefined
Defined and validated

The turnaround improvement is the number the business noticed. The one that mattered to the security team is the second row: access can no longer be approved against a change request that is invalid or expired, whoever is on shift.

Could we build this again?

Yes. The approach is not tied to one ITSM platform — it works anywhere the ticket detail can be retrieved through an API and mapped onto the access request. ServiceNow and Jira both qualify.

The work that does not transfer is the part that took the thinking: deciding which fields have to be mandatory, agreeing what a failed check does, and designing an emergency path that people will actually follow at 3am rather than route around.

RA

Rama Krishna Akula

Privileged access engineering

Led the integration, delivered in around 30 days with support from the ITSM development team for the ticket-side changes.

Approving privileged access against tickets nobody re-reads?

Spend 30 minutes with one of our certified engineers walking your current setup. You get the findings in writing afterwards.

Book a free 30-minute review →