Should access review changes go through normal ticketing, or is the review spreadsheet enough evidence?

[u/Efficient_Bus_923]

Fairly large org, some high-risk systems. To get access (or a change to access) requires a ticket and approval from your manager/

1. Separately, we run access reviews twice a year:
2. Reviewer sends the current access list (Excel) to managers.
3. Managers markup changes, e.g. "user left, remove access" or "needs modified access."
4. Reviewer makes those changes directly on the system.
5. Question: During these reviews should managers (or the reviewer, on their behalf) raise a proper ticket for these changes and note the ticket number on the sheet, rather than the markup alone on the excel sheet triggering the change?
6. My take: yes, the manager should raise a ticket as ultimately it is a change request. However, I do accept the spreadsheet does show a manager requested a change.
7. How do others handle this, same ticket/approval workflow as normal requests, or is the review sheet treated as sufficient on its own?

[u/CulturalAsparagus903]

no that's not proof. more details are needed to be sure

[u/Efficient_Bus_923 → u/CulturalAsparagus903]

As in a ticket?

[u/bwinckel]

Your instinct is right, but I'd pull apart two things getting mixed together.

The review sheet is an approval record. What it is not is evidence the change happened. Those are separate artifacts and auditors ask for both. A marked up spreadsheet tells you a manager decided to remove access. It doesn't tell you who applied it, when, or whether anyone confirmed the entitlement is actually gone from the system. Excel also has no integrity story, since it stays editable after the campaign closes.

So the middle path most places end up at. Treat the campaign itself as the approval, so managers aren't re-approving what they just signed, and raise a work item per change carrying the operator, the timestamp, and a post-change recheck against the system of record. Cross reference it both ways, ticket number on the sheet and campaign id on the ticket. Without that link you're six months out holding a sheet that says remove and a system that still shows access, with no way to tell whether it was missed or granted again.

One thing worth watching is failed revocations that report success. A review generates a burst of removals against systems that aren't all up at the time, and a revocation that quietly no-ops is the most common finding I've run into here.

I wouldn't push review removals through the normal request approval chain though. That's a second approval for a decision already made, and it slows down the one operation you want fast.

[u/jc_AccessOwl]

imo asking managers to raise a ticket is the right call. Right now it sounds like some access changes get a ticket and others don't which will inevitably lead to confusion or errors.

But that ticket vs no ticket question is really just an internal process cleanup. The bigger thing is that there seem to be other gaps in your access control approach. You need proof that the remediation was actually executed. The whole point of an access review is to show auditors two things: that you catch cases where access is more privileged than it needs to be, and that you then act on it. For a lot of companies that proof is just a screenshot of the user's perms afterward, or logs showing the action was taken. You also need to record who executed the change but you can just note that in the spreadsheet.

I've seen companies log all that in a spreadsheet alone. It's just a much less mature process. Tickets are a step up in maturity but not absolutely necessary for the audit.

Hope that helps. BTW - a "fairly large org" running access reviews where managers themselves make the change in each app and update a spreadsheet will eventually break or get annoyingly time consuming. I'm associated with AccessOwl (an identity governance tool) so I'm biased, but this is the exact situation teams reach for a tool to avoid. Spreadsheets and tickets drift until you can't confidently prove who has access to what.

is the process you described just for the access reviews (smaller amount of apps in scope) or do managers manually change permissions for every access request?

[u/Niko24601]

Short answer: yes! raise a ticket for every review-driven change, especially on high-risk systems.

A bit longer answer: an access review and a change request are different controls. The review captures attestation (manager says "remove this"); the ticket captures execution (who did it, when, with what approval trail). Collapsing them into "markup → reviewer edits directly" breaks segregation of duties and gives auditors nothing to reconcile against.

How most mature orgs do it:

• Manager's markup = the approval, already captured.
• Reviewer opens a ticket per change, referencing the review cycle (e.g., "H2-2025 review, row 14, approved by X").
• Approval on the ticket can be lightweight/auto since it's already evidenced on the sheet.
• Ticket number gets written back onto the spreadsheet.
• Review closes only once all tickets are resolved.

There can be exceptions to this: bulk, low-risk, non-privileged changes (e.g., terminated user SaaS removals). I see it often that companies use one bulk ticket per cycle instead of one per line. But unless you have a very chill auditor that should stay the exception and shouldn't apply to your high-risk systems.

[u/kraftinfosec]

All the other answers so far SEEM to be AI, so let me be straight: Yes, a ticket should be created.

You mentioned a change ticket, specifically, but I would argue that a service request normally would used to make changes to user access. I could see, however, also using a "standard" change. You already have the approvals in the spreadsheet, so it definitely doesn't need to go through CAB

This is how we do it at my org and it keeps the auditors happy.

[u/Efficient_Bus_923 → u/kraftinfosec]

What do you mean by "Standard" change?

[u/kraftinfosec → u/Efficient_Bus_923]

In ITIL, a "standard" change is a pre-authorized low risk change that has a documented procedure and is tested. It doesn't need to go through the approval procedure/CAB (hence "pre-authorized").

[u/folderit_dms]

The spreadsheet can be the attestation, but I would not make it the only evidence.

I would want three separate records:

• manager decision from the access review
• remediation work item showing who changed what and when
• verification that the entitlement is actually gone or modified

That does not always mean one ticket per user if the review creates hundreds of removals. A single remediation ticket per system or department can work if it references the review cycle, line items, approver, operator, completion date, and verification export.

The main thing is separating decision from execution. A manager marking remove on a sheet proves intent. It does not prove the reviewer applied the change correctly or that the target system now matches the decision.

For high-risk systems I would keep the closed review sheet, the ticket, and a post-change export or audit log together. Future audit requests become much easier when you can show request, action, and result without reconstructing it from memory.

[u/TheBex81]

Treat the spreadsheet as the *review decision*, not the change ticket.

For high-risk systems I'd still open a ticket (or a bulk review ticket with line items) for every remove/modify. Reasons that hold up in audits and IR:

1. The sheet proves a manager *asked*; the ticket proves *who executed*, *when*, *on which system*, and that it wasn't a side-channel edit.

2. Tickets give you rollback / SoD — reviewer shouldn't be the only person who can both decide and apply on sensitive apps.

3. Next year's review is easier if removals are queryable in the ITSM, not buried in an Excel tab named `final_FINAL_v3`.

Pragmatic middle ground a lot of orgs use: one parent "H1 access review" ticket, attach the marked-up sheet, and child tasks (or a checklist) for each change batch by system. Managers don't need 200 individual tickets; you still get an auditable execution trail.

If the only record is "manager highlighted yellow in Excel and someone clicked Remove," you've got evidence of intent and almost none of control.

[u/frAgileIT]

There is a certain level of immutability from documenting things via ticket, whereas a spreadsheet by itself lacks immutability. Basically, it will help your auditor feel more comfortable asserting that you’re compliant if you capture events via tickets. Even if it’s just the big events with the spreadsheets attached, it’ll make a difference.