An overdue access review is a campaign that still has open items after the due date you told the auditor, the manager, or yourself. The entitlements on those items are still granted. The evidence file for the period, if you export it early, shows pending where a decision should be. The next campaign then starts on top of the unfinished one. That stack is the cost. It is measured in days past due, in privileged seats that nobody decided, and in the hours spent reconstructing context after the quarter has already moved on.
Rutagon builds the campaign clock and the close rule for mid-market SOC 2 teams. The GRC platform you already run can store a review once it is finished. The overdue condition is a property of the items: pending, and now is after due_at. We compute that every morning, we escalate it, and we refuse to mark the campaign closed while any item is still pending. NIST SP 800-53 AC-2 is the control family this evidence is usually mapped to: accounts are reviewed, and access that is no longer required is removed. A campaign that is still open is not that evidence yet.
What an overdue access review still allows
Until someone decides, the seat stays. The application does not know the campaign is late. AWS IAM Identity Center still has the permission set assignment. Entra still has the role. The internal admin tool still has the flag. Overdue is a status in the review system. Standing access is the fact in the directory.
Take a campaign of 400 items with a Friday due date, as an example of the report we generate, not as a promise about your counts. The following Wednesday, 90 items are still pending. Those 90 entitlements have had extra days of access with no recorded decision. If 14 of the 90 are admin or production-deploy seats, those 14 are the ones that matter in an audit sample. The other 76 still have a cost: they are the pile a reviewer returns to without remembering why the seat existed. Days late on the admin rows is the number we put at the top of the report.
There is a second cost inside the evidence, described in what failed access reviews look like in a SOC 2 audit. An auditor samples a privileged user and asks for the decision in the period. The item is pending. You can explain that the campaign was "basically done." The sample wants a decider, a time, and a result. Pending has none of those. Teams then spend a week chasing reviewers for seats they could have decided in the original window, and the narrative in the workpaper is that the control did not operate for those users.
The third cost is the next cycle. Quarterly access review automation assumes the previous quarter closed. If it did not, the new extract contains the same unresolved seats plus whatever changed this quarter. Reviewers see a larger queue and treat it as noise. Managers see two campaigns and are not sure which one the auditor will read. We keep a single open campaign per scope and per period. A new period does not open until the previous one is closed, or until an named exception says why it cannot close, with an owner and a date.
How the clock is implemented
Each campaign has due_at, a scope, and a list of items. Each item is one subject and one entitlement: a person and a group, a person and a role, a CI role and a trust policy. Item state moves in one direction.
states: pending -> decided_maintain | decided_revoke
decided_revoke -> revoked (request_id required)
overdue: pending AND now > due_at
close: rejected while any item is pending or decided_revoke without request_idPending is the initial state. A maintain decision stores the decider, the time, and a reason code from a short list the control owner agreed: still in role, contractor extended to a date, break-glass. A maintain decision on a seat that was supposed to be temporary also stores the new end date. A revoke decision stores the decider and the time, and it stays in decided_revoke until the remove call returns a request id and a later ingest shows the entitlement gone. Then the state is revoked.
Overdue is not a state someone clicks. It is computed. The morning job writes overdue_days onto every pending item whose campaign is past due_at. The export includes that number. A dashboard that hides it behind a filter will be wrong the week the auditor visits. We put overdue items in the default view for the campaign owner.
Reminders are dated off due_at, not off "whenever someone remembers." A typical schedule we configure is a reviewer reminder three days before the due date, a second reminder the morning after, and a manager notice at seven days past due. The manager is the manager attribute from the IdP, which is the same attribute we use for routing in the first place. If the manager attribute is empty, the notice goes to the campaign owner and the item is flagged no_manager. Escalating to a mailing list named security@ is how notices get archived unread. We send to a person.
Silence is not a maintain. Some products offer "no response means approve" because it makes the completion percentage go up. That setting produces a closed campaign whose decisions were the absence of a decision. We do not enable it. An item with no decider remains pending, and the campaign remains open. Completion percentage is decided / total, and overdue percentage is pending past due / total. Both are on the evidence export. A completion number that treats silence as approval will not match the export we hand to the GRC platform.
What close means for the evidence file
Close is an operation with a precondition. If any item is pending, close returns the list of those items and does not write a closed timestamp. If any item is decided_revoke without a request id, close returns those too. The campaign owner can see exactly which rows block the file. Exporting access review evidence is the shape of the file once close succeeds: every item has a decider, a time, and either a maintain reason or a remove request id.
The recertification evidence for SOC 2 CC6.2 is that closed file, for the population in scope, inside the period. An export taken while items are overdue is a draft. We watermark drafts with closed_at: null so a draft cannot be dropped into the evidence folder under the same name as the final file. The final object is written once, to the evidence bucket, with the campaign id and the period in the key. Replacing it requires a new campaign id. Silent overwrite is how a later edit changes what the auditor already sampled.
There is a labor cost we track because it shows up on the same report. Each overdue item records the reviewer's last login to the campaign and the number of reminders sent. A reviewer with 80 items and four reminders is a routing problem: the queue is too large, the reviewer is the wrong owner, or the entitlements are not described in language the reviewer can judge. We split those queues by system and by privilege before the due date when the first-week decision rate is low. Splitting after the date saves less, because the context is cold.
Privileged items past due are listed separately from the long tail of ordinary group memberships. The campaign owner gets that list every morning after due_at. The ask is small: decide these 14, or name the person who will. The other 76 can follow the normal reminder schedule. Treating every overdue row as equal is how admin seats wait behind a license-group argument.
Rutagon's work on this control is the state machine, the computed overdue flag, the manager notice, and the close precondition. The GRC platform remains the system the auditor's request list points at. We feed it a file that is actually closed. Security automation covers the remove calls that turn decided_revoke into revoked. Without those calls, a campaign can be "closed" in spirit and still leave the admin role attached.
Frequently Asked Questions
When is an access review overdue?
The campaign has a due date, and at least one item is still pending after that date. Overdue is computed each morning. It is not a label someone applies when the quarter feels late. Days late are stored on the item and included in the export.
Does the access stay in place while the item is open?
Yes. The directory and the applications enforce the current grant, not the review status. An overdue admin item is an admin grant with no decision in the period. The point of the morning report is to make those grants visible while they are still undecided.
Can a campaign close if a few items are unfinished?
Close is rejected while any item is pending, and while any revoke decision has no API request id. The response lists the blocking rows. A draft export is marked with an empty closed timestamp so it is not stored as the final evidence object.
What if a reviewer never answers?
The item stays pending. Silence is not recorded as maintain. Reminders go to the reviewer, then to the manager on the IdP record, then the row remains on the campaign owner's overdue list. The completion percentage does not move until a person decides.
What should the auditor receive?
The closed export for that period: a decider and a time on every item, a reason on every maintain, and a remove request id on every revoke, plus the overdue history if items were late before they were decided. A file with pending rows is a draft, and we do not present it as the quarter's recertification evidence.
Ask for an access-review diagnostic that shows which campaigns are past due and which privileged items are still undecided. Contact Rutagon at rutagon.com/contact, 907-841-8407, or contact@rutagon.com.