The Month-End Access Exception
A financial analyst needs to correct 200 misapplied customer credits before month-end close, which closes in three days. The corrections require write access to the production billing database. No scoped role exists for this; building one is estimated at two weeks. The analyst currently has read-only access. Last year an analyst with comparable write access deleted three days of invoice data during a similar correction, and recovery took 40 hours. Policy requires quarterly recertification of production access and logging of all production writes. A break-glass path exists but requires director approval plus a second approver, with a median turnaround of four hours per use, and the analyst expects roughly 15 correction batches.
1. Grant the standing access, deny it, or something else? Justify the decision against the specific numbers given.
Read the worked answer
Deny the standing grant. Grant scoped, time-boxed, supervised write capability instead.
Why the standing grant loses:
- A standing production write grant given for a three-day task persists far beyond the task. Quarterly recertification means the next formal review is up to ~90 days away, so the exposure window is not three days, it is up to a quarter.
- The precedent is directly adverse: last year's comparable grant produced 40 hours of recovery. That is not a hypothetical, it is a base rate for this exact scenario in this exact organisation.
- The volume does not require standing access. Fifteen batches over three days is roughly five actions a day; a standing grant is sized for continuous use.
Why a flat denial also loses: month-end close is a hard external deadline with financial-reporting consequences. Refusing without an alternative pushes the analyst to work around you - spreadsheets, exports, shadow copies - which is worse than a controlled grant.
The middle path that is actually implementable in three days:
- Time-boxed elevation - a grant with an automatic expiry at close plus 24 hours, not a standing grant.
- Pair the writes - the second approver from the break-glass process operates the change while the analyst specifies it, or reviews each batch before commit. This reuses an existing control instead of inventing one.
- Batch, don't drip - consolidate 15 batches into 3-4 reviewed change sets. This both cuts approval overhead and makes each change reviewable.
- Pre-stage a rollback - snapshot the 200 affected credit records before the first write. Last year's 40-hour recovery was expensive because it was improvised.
Cost check: break-glass at four hours per use times 15 batches is 60 hours, which does not fit in three days - so the naive 'just use break-glass' answer fails on arithmetic. Batching is what makes the approval path feasible.
2. How do you demonstrate to auditors that this was a controlled exception rather than a policy breach?
Read the worked answer
Auditors are not looking for the absence of exceptions. They are looking for evidence that exceptions were identified, authorised, bounded, and reviewed. Build the file around those four words.
Evidence to assemble at the time, not after:
- Identification - a written request stating the business need, the 200 records, and why the scoped role is not yet available. Dated before the access was granted.
- Authorisation - named approver(s) and the second reviewer, with the specific scope (which tables, read versus write, which records) and the expiry timestamp.
- Bounding - the auto-expiry record itself, plus the snapshot showing the pre-change state of the affected records.
- Logging - the production write log filtered to the exception window, reconciled against the 200 intended corrections. Any write outside that set is an incident and must be treated as one.
- Review - a post-close reconciliation confirming exactly 200 corrections applied and no others, signed by someone other than the analyst.
The honest framing for the audit conversation: this was a documented compensating control - time-boxing plus second-person review - substituted for the missing scoped role, with a remediation date for building that role. Do not describe it as temporary convenience.
The judgement: auditors penalise undocumented exceptions far more than documented ones. The risk in this situation was never the 200 corrections; it was leaving a trace that could be read as an unreviewed standing grant.
3. What do you change before the next close, and what would you refuse to change?
Read the worked answer
Change:
- Build the scoped role now and treat two weeks as unacceptable. It will be needed every close. Prioritise it against other access work explicitly rather than letting it drift; if it slips a second time, that is a resourcing decision for the access owner, not a recurring exception.
- Make batching the default. The four-hour approval turnaround was the real constraint, and 15 batches was a choice. Design the correction workflow around consolidated change sets.
- Measure break-glass turnaround. A four-hour median is what made policy look impractical. If the median drops, the exception pressure drops with it.
- Pre-snapshot production tables in scope at the start of every close. Cheap insurance, removes the 40-hour recovery tail.
Refuse to change:
- Do not lower the second-approver requirement because it 'slowed us down.' It is the control that makes a three-day grant defensible.
- Do not convert the exception into a standing grant with a vague review date. That is how last year's incident happened, and a repeated exception is a policy failure wearing a process costume.
The judgement: the failure here is upstream - a missing role that forces an annual crisis. Fix the upstream cause, keep the downstream control, and be explicit with the sponsor about which of the two is negotiable. Only one of them is.