On this page
Research context
This protocol asks what share of temporary staging access grants remain active after the ticket that justified them is closed. The unit is one access grant, identified by the person, the system, and the grant start time. The study measures the grant duration, the ticket close time, and whether the access was removed or reviewed at the expected date. It does not evaluate whether the person used the access appropriately.
Set the scope to one staging environment, one identity provider, and one access request process. Record the role definitions, the approval rules, and the ticket system at the start. If the process changes during the window, keep the earlier definition for the full sample or analyze the change as a separate period. A new expiry default can look like better behavior when it is only a new setting.
Define the population as every temporary staging grant created during the window, including grants that were denied or withdrawn. The unit is the grant, not the person, because one person can hold several grants for different tasks. A grant that is extended remains one unit with a revision history. A new grant for a different system is a new unit.
Record the role, the system, the requesting team, and whether the grant was time-bound at creation. These strata matter because a read-only grant and an administrative grant carry different risk. Include grants that were never used, because an unused grant is still standing access. Test the unit definition on two ordinary grants before collection begins.
Define a temporary grant as one created for a specific ticket with an expected end date. Define the ticket close time as the time the work was marked complete or cancelled, not the last comment. Define an overdue grant as one that remains active more than a stated grace period after the ticket closes. Define a reviewed grant as one with a recorded decision to keep, reduce, or remove the access.
Do not count a grant as removed when the account is disabled but the role remains assigned. Do not count a review as complete when the reviewer only opened the access page. A grant that is extended needs a new approval and a new end date. Each definition should include one positive example and one boundary example.
For each grant, capture the person, the role, the system, the ticket, the request time, the approval time, the expected end date, and the actual removal time. Add whether the grant was reviewed and whether the ticket closed before or after the expected end date. Record the source system for each field and whether the value was observed or inferred. Keep the packet with the access review evidence.
Practical application
Also capture whether the grant was used during the period and whether it was broader than the task required. These fields help explain an overdue grant that was harmless in practice but still a control failure. If the removal was recorded in a ticket rather than the identity system, record both times. A second reviewer should be able to reconstruct the grant lifetime from the record. Keep the packet with the access review evidence.
Draw the sample from the identity provider and the access request system rather than from a list of known exceptions. Record the export date, the filters, the row count, and the selection rule. Include grants from every role and every requesting team so the result is not dominated by one group. If the population is ordered by request time, a fixed interval spreads the sample across the window.
Collect the grant as it existed at the ticket close, not as it looks after a later cleanup. If the access was removed during an audit, record the audit date and analyze the original overdue period separately. Do not reconstruct a missing removal from the absence of activity. Note the collection date separately from the grant date.
A useful additional measure is the share of grants that were never used. An unused grant is an unnecessary exposure even when it is removed on time. Show the usage flag, the role, and the duration beside the request and describe the pattern. The owner can then decide whether the request form is too permissive or the role definition is too broad.
Report the number of grants, the share removed by the expected date, the share overdue at ticket close, and the share still active at collection. Show the counts by role and requesting team. Present the median days overdue and the share of grants with a recorded review. Use the same denominator for every rate.
Inspect the overdue grants and describe the pattern without naming the person. A cluster in one role may point to a default that is too broad, while a cluster in one team may point to a missing close step. Compare the result with the ticket type, because a long-running project may legitimately need a longer grant. Report the unused grants separately.
A useful additional view is the gap between the expected end date and the actual removal. A grant that is removed a few days late is a different problem from one that remains for months. Show the distribution and describe the tail. That view helps the owner decide whether to change the default expiry or the close checklist.
Operating controls
The review should also compare the grant with the role the ticket actually required. A read-only task served by an administrative grant is a least-privilege gap even when the grant was removed on time. Record the requested role and the granted role. That comparison shows whether the approval process is too broad.
The record cannot show whether the person used the access outside the ticket or whether the access was necessary for the work. It can show only the grant and the removal timestamps. An overdue grant is not proof of misuse, and a timely removal is not proof of least privilege. The protocol also cannot capture access granted through a shared account or a direct database connection.
Identity systems can omit role assignments inherited from a group, and tickets can be reopened after closure. A grant that looks overdue may belong to a reopened ticket. Record those cases and their treatment instead of dropping them silently. If the approver and the requester are the same person, note the independence limitation and analyze that subgroup separately.
A useful check is whether the removal was confirmed in the identity system or only in the ticket. A ticket that says removed while the role remains assigned is a false close. Record both states and the person who verified the removal. That evidence prevents a clean-looking audit from hiding a standing grant.
Give the result to the security owner and the access administrator and ask them to choose one observable change. The change might be a default expiry, a close-ticket reminder, or a weekly overdue report. Record the owner, the effective date, and the measure that will show whether the change worked. Avoid changing the default and the reminder at the same time.
Repeat the protocol with the same definitions after the change and compare the same fields. If overdue grants fell but access requests rose, the default may be too short for legitimate work. If reviews improved but removals did not, the review may not include the removal action. Close the review when the owner accepts the finding and the next sample is scheduled.
The final view is the access review cadence and who participates. A review that only the requester attends is not independent. Show the reviewer and the review date beside the grant. That context helps the owner decide whether the review is a real control or a formality. Record the next review date with the sample.
Sources
Frequently asked questions
What should happen first?
Begin with a bounded ticket, approved access, explicit acceptance evidence, and a named reviewer.
Who approves production changes?
The client's technical owner keeps final merge and release authority.
Related research
How often do outsourced pull requests arrive without a reproducible test?
Where does review time accumulate in a distributed engineering team?