Does the ticket exist?
The number resolves to a real change record.
20,000 access requests a day, each one checked against its change ticket
A banking group's privileged access requests were being approved against change tickets that had already closed, expired or never existed. The control looked fine on paper: every request referenced a ticket. Nobody was checking whether the ticket was still valid. This is how our engineers made the check automatic, and what changed at the point of approval.
20,000 requests validated a dayApproval time under 5 minutesZero approvals against expired ticketsCyberArk and ITSM, integrated
The problem
People approve twenty thousand of anything the same way
Every privileged access request carried a change ticket number, and every approver was supposed to open the ticket and confirm it was open, in scope and current. At a few dozen requests a day that is a real check. At twenty thousand it is a field people glance at. Approvers were confirming that a ticket number existed, not that the ticket did. Some referenced changes that had closed weeks earlier. Some referenced tickets that had been rejected. A few referenced numbers that did not resolve to anything.
An auditor sampling those approvals would have found a control that existed in policy and not in practice. That was the finding waiting to happen, and it was the reason the bank called.
The integration
Three checks, one outcome
The integration our engineers built sits between the privileged access platform and the change management system. Before a request reaches an approver, it is checked three ways.
Is it valid?
The change is approved, and its window is open right now — not last week, not tomorrow.
Does it match?
The system being accessed is inside the change's scope, and the requester is on it.
Fail any one and the request is blocked before a human sees it, with the reason attached. Pass all three and the approver receives a request that has already been verified — so the approval becomes a judgement about whether this person should do this now, rather than a clerical check on a ticket number.
What made it stick
Two mandatory fields, and an answer for 3am
Two things made this work in practice. The first was making the ticket reference and the target system mandatory fields on the request form, so there was nothing to validate against nothing. The second was emergency access. A control that blocks a legitimate 3am fix because no change ticket exists for an outage is a control that gets switched off by the end of the week.
The answer was a break-glass path: emergency access granted immediately against an incident record instead of a change record, fully logged, and reviewed the next business day without exception. The ordinary path became stricter and the emergency path became honest, which is the combination that holds.
At the point of approval
What changed at the point of approval
Before
An approver opened the request, opened the ITSM tool, searched for the ticket, checked its status and dates, went back to the request, and approved. Fifteen to twenty minutes on a good day. On a bad day, the ITSM search was skipped.
After
The request arrives pre-validated with the ticket details inline. The approver confirms the person and the purpose, and approves. Under five minutes, and the parts a human is bad at are done by the integration.
The numbers
Measured before and after
| Measure | Before | After |
|---|---|---|
| Requests validated against a live ticket | A sample, when audited | All 20,000 a day |
| Approval time | 15–20 minutes | Under 5 |
| Approvals against expired or invalid tickets | Unknown — nobody was counting | Zero, by construction |
| Evidence for the auditor | Reconstructed from approvals | Produced by the integration, on demand |
The hard part
What made it hard
Not the API. The change management data was inconsistent — windows recorded in different time zones by different teams, scope recorded as free text, some tickets closed without a status update. The first month of the engagement was spent making the change data clean enough to validate against, and that work is where most of the value came from. An integration against dirty data automates the wrong answer faster.
Repeatable?
Could we build this again?
Yes, anywhere privileged access and change management are two systems that do not talk — which is most organizations. The specific platforms were CyberArk and a mainstream ITSM tool; the pattern works across any privileged access platform with an API and any change system with structured records. It is IAM integration work, delivered as part of a PAM implementation, and it is one of the few controls that makes approvers faster and auditors happier at the same time. Most common in identity security for financial services, where SOX makes change control an examined process.
Approving privileged access against tickets nobody re-reads?
A free audit is 30 minutes with a certified engineer on how your privileged approvals actually work. Findings in writing.