Audit Evidence, a Shared Admin Login, and 210 Undocumented Exceptions
An internal audit of a cardholder-scope estate of 5,000 assets is due in six weeks. Current state: 210 findings older than 90 days are marked accepted risk with no named owner and no expiry date; the scanning service account holds domain administrator rights; three analysts share one administrator login on the platform; retention is set to 45 days while the written policy requires 13 months; and the audit team wants proof of continuous monitoring across the full 13-month period. Storage on the platform is sized for roughly 60 days of results. The platform supports role-based access control and directory integration, and the identity team can supply group membership within two weeks.
1. Redesign access control. What roles do you create, how is the scanning account separated from human access, and what do you tell the auditor about the historical period?
Read the worked answer
Split the two identities that are currently conflated.
- Service account (machine identity). Used only by the scanner, scoped to read-only assessment rights, no interactive logon, credentials vaulted and rotated on a schedule. Remove domain administrator rights: domain admin on a scanning account converts every scanned host into a path to the domain, and it is the single worst finding in this setup. Replace with delegated local administrator rights and read-only SSH.
- Human accounts (named, not shared). Integrate with the directory, disable the shared administrator login, and issue named accounts mapped to groups:
- Viewer - dashboards and reports only.
- Analyst - analysis, tagging, exception requests; cannot change scan policy.
- Scan operator - policy, credentials, zones; cannot approve exceptions.
- Platform administrator - configuration and user management; small group, reviewed quarterly.
- Segregation of duties: the person who requests a risk exception must not be the person who approves it, and neither should be the only platform administrator.
On the historical period, be straight with the auditor: you cannot retroactively create 13 months of evidence from a 45-day retention setting. Disclose the gap, explain the remediation date, and offer what does exist - change records, ticket history, and any exported reports. Attempting to backfill or imply continuous coverage you cannot evidence is the finding that turns a control gap into an integrity issue.
2. Build the exception governance process for the 210 open findings. What must each entry contain and how is it reported?
Read the worked answer
An exception is a decision with an expiry, not a label.
Mandatory fields per entry:
- Named risk owner - a person accountable, not a team alias.
- Business justification tied to the asset's function, not a generic 'legacy system'.
- Compensating controls, described concretely and verifiable - 'isolated VLAN with deny-all inbound, verified by firewall rule ID' rather than 'network segmentation'.
- Residual risk rating after compensating controls.
- Expiry date, defaulting to one quarter, with re-review required to extend.
- Approver independent of the owner, at a level matching the residual risk.
- Remediation plan with a target date, even if the target is far out.
Reporting:
- Exception register reviewed monthly; ageing buckets published to the risk committee.
- Any exception past expiry auto-escalates and reverts to an open finding - silence must not equal acceptance.
- Track the count and severity of exceptions as a trend line; a rising trend with flat remediation is the signal that matters.
With 210 entries and six weeks, triage by severity first: anything in the cardholder environment or internet-facing gets a named owner and a real remediation date before the audit, not an exception renewal.
3. The auditor asks for proof of continuous monitoring over 13 months. What can you actually evidence within six weeks, and what must change to satisfy the requirement next cycle?
Read the worked answer
Be precise about what the control is and what evidence proves it.
Evidence available or obtainable in six weeks:
- Coverage evidence for the current period: asset inventory with deduplicated asset count, percentage assessed by agent or credentialed scan, credential success rate per region, and a scan schedule showing cadence across all zones.
- Freshness evidence: content update history and scan completion records for the retained window.
- Exception register and remediation tickets showing the loop from detection to closure.
- Dashboard and report snapshots exported with timestamps going forward, so each month adds a dated record.
- Interim compensating evidence for the older period: change tickets, scan schedule documents, and any archived exports held by other teams.
What must change for the next cycle:
- Retention raised to the policy's 13 months, which at current volume means roughly six to seven times present storage. Size it before enabling, or the disk fills and you lose the very evidence you extended retention to keep.
- Automated monthly evidence export to immutable storage, so evidence does not depend on the platform's database surviving.
- Written scan policy defining cadence, scope, and exclusions, approved by the control owner - an auditor tests against a stated standard, not against intent.
State plainly where the historical gap is and what closes it. An honest partial answer with a dated remediation plan is defensible; an implied 13 months that the platform cannot produce is not.