Ninety Days to Attribute Every Administrative Action
An external auditor has flagged six items at a 60-person company. You have 90 days, 40 engineering hours, and no budget for new tooling. Findings: (1) 14 staff, including 3 contractors, log in to a shared "opsadmin" account holding domain administrator rights; (2) MFA is enforced on the VPN but not on internal applications, which use password-only SSO; (3) a support vendor holds one persistent remote-access credential for a shared jump host; (4) the quarterly privileged-access review was last completed 11 months ago; (5) three privileged accounts have no recorded owner; (6) 9 of 60 leavers in the past year still had active directory accounts 30 days after their last day. The regulator requires least privilege with attributable audit trails.
1. Rank the findings by risk and defend the top one using likelihood, impact, and detectability rather than a policy citation.
Read the worked answer
1. Shared domain-admin account (highest). Impact is total - domain administrator, no scope limit. Likelihood is high because 14 people, including three contractors outside direct management, are one phishing email from unrestricted control. Detectability is effectively zero: every log line reads "opsadmin", so you can neither attribute an action nor scope a breach. A control that is absent across all three dimensions outranks one that is merely overdue.
2. Stale leaver accounts (9 in 12 months). Likelihood is not speculative - it already happened nine times, roughly 15% of last year's departures. Impact depends on what each account could reach, but the counts make it the most proven control failure on the list, and it is the cheapest to close.
3. Vendor persistent access on a shared jump host. Narrow path, but it is a third party with standing access and again one shared credential. One accountable vendor engineer is better than 14 anonymous admins, so it ranks below #1, but it is unmonitored and unbounded in time.
4. Missing MFA on internal applications. Raises the likelihood that findings 1–3 are exploited; it is not itself the exposure.
5. Privileged-access review overdue. It is the detective control that would have surfaced 1 and 6. Its absence is why 1 and 6 persisted, but on its own it exposes nothing.
6. Three unowned privileged accounts. Likely a subset of #1 and #2 once you look; treat as a scoping task, not a separate project.
2. Build a 90-day remediation sequence that fits inside 40 engineering hours.
Read the worked answer
Weeks 1–2 (~5 h) - stop the bleeding. Disable the 9 leaver accounts and assign named owners to the 3 orphaned accounts. This closes findings 5 and 6 with hours of work and gives the auditor early evidence of movement, which buys room for the rest.
Weeks 3–7 (~18 h) - the main event. Create 14 named accounts, map them to two or three roles (not 14 copies of domain admin), run parallel for five working days, then disable opsadmin. Keep exactly one break-glass credential in a sealed vault with an alert on use. Build in ~1 h per person for creation, verification, and hand-holding; contractors need sponsor sign-off.
Weeks 6–10 (~10 h) - reuse what is already licensed. Extend the existing SSO MFA to internal applications via conditional access. Do not buy anything; the licence is already paid for and the work is configuration.
Weeks 8–12 (~6 h) - close the loop. Run the overdue access review across privileged accounts and set a recurring calendar reminder with a named owner. Retroactively document the missed quarters honestly rather than backdating.
Vendor (~1 h of negotiation, plus contingency). Ask for per-engineer named accounts. If the vendor cannot deliver inside 90 days, apply compensating controls: per-session approval, time-boxed credentials, and session recording on the jump host. Record a time-bound risk acceptance with a named owner and a review date.
Budget check: ~40 h, with no slack. Protect the weeks 1–2 block first - it is the lowest cost per finding closed.
3. The vendor's product cannot issue per-engineer credentials. What do you document, and what makes the compensating control actually count?
Read the worked answer
Document
- A formal, time-bound risk acceptance naming the residual risk (standing third-party access, shared credential, no individual attribution).
- The compensating controls in place: per-session approval before the credential is released, credentials valid for the session only, session recording retained for the audit retention period, and an alert on any use outside an approved session.
- A named business owner who accepts the risk - not the security team, which usually has no authority to accept it.
- An expiry date and a trigger that reopens the decision, e.g. contract renewal or the vendor shipping named accounts.
What makes it count
A compensating control is only a control if it produces evidence. If session recordings exist in principle but are never reviewed, never retained, and never retrievable, the auditor will treat attribution as absent and the acceptance as an excuse. Write down the review cadence and who reviews - and check that the evidence actually exists before the audit, not after.
Also scope the acceptance precisely. "Vendor access is monitored" is not a control statement. "Vendor engineer X accessed jump host Y on date Z for approved session W, recorded and reviewed" is. The regulator's requirement is attributable audit trails; the acceptance documents a gap against that requirement, it does not satisfy it.