Proving 90-Day Rotation to an Auditor
A subscription software company has onboarded 1,900 secrets over two years. PCI DSS scope covers 260 credentials that must be rotated at least every 90 days. The rotation dashboard reports 96% compliance, but an auditor's sample of 25 in-scope credentials found 7 that had not changed in over 200 days. The investigation identifies three causes: three accounts are associated with the wrong platform in the rotation engine and fail silently; two are excluded from rotation by a setting on their safe; and two rotated successfully but the application kept using the old password because the previous value remained valid during a grace period, so the effective credential never changed in practice. Separately, a data-loss-prevention scan found 340 credentials pasted into Confluence pages across 60 spaces. The next audit is in ten weeks.
1. Why did the dashboard overstate compliance, and how do you redefine the compliance measure?
Read the worked answer
The dashboard counts rotation engine events, not credential change. Four distinct gaps sit outside that count:
- Failed silently: wrong platform association means the job never succeeds, but an account whose job errors may simply drop out of the success denominator rather than appear as non-compliant.
- Excluded by configuration: safe-level exclusions remove the account from the population entirely. A control that lets the measured object leave the measurement is not a control.
- Rotated but not applied: the target system now holds a new value, the grace period keeps the old value valid, and the application never picked up the change. Two credentials are technically rotated and operationally unchanged.
- Population drift: the denominator may be built from what the tool manages rather than from the 260 credentials the PCI scope defines, so in-scope credentials that were never onboarded cannot be found missing.
Redefine compliance for one credential as: target system confirms the credential changed within the last 90 days, the authorised consumer authenticated successfully with the new value, and the previous value is no longer accepted.
Build the measurement from three reconciled sources: the PCI-scope inventory (the authoritative list of 260), the rotation engine's per-account job history, and the target system's authoritative last-change attribute. Where they disagree, the target system wins. Report the population as exactly 260, with every exclusion listed as an exception rather than removed.
2. Give the remediation order for the seven findings and the exception process for anything you cannot fix in ten weeks.
Read the worked answer
Order by known exposure, then by systemic cause.
- The seven sampled findings first, because they are already written down in an audit report. Two of them (the grace-period pair) are the highest real risk: a credential that appears rotated while the old value still works is a false sense of security.
- Fix the mechanism, not just the instances. Correct the platform association for the three mismatched accounts, test rotation against a non-production copy of the target, then rotate. For the grace-period pair, shorten the grace window and add post-rotation verification that the application authenticated with the new value before the old one is invalidated. For the two exclusions, determine whether the setting was a legitimate break-glass arrangement or an error; a legitimate one keeps its exclusion only with a named owner, an expiry date, and a compensating control.
- Then sweep the rest of the 260 for the same three failure patterns, because a sample of 25 that finds 7 implies a population problem, not seven problems.
- Re-sample and report the same way the auditor did, to show the fix worked.
Exception process: every exception carries an owner, a justification, an expiry date, a compensating control (network restriction, enhanced monitoring, shorter verification interval), and a ticket. Exceptions appear in the compliance report as a named count, never dropped from the denominator. An exception without an expiry is a permanent hole with a signature on it.
Realistic scope for ten weeks: the seven findings and the population sweep are achievable; retiring every exclusion across 1,900 secrets is not. Say so explicitly in the report rather than committing to a date you will miss.
3. What evidence package do you hand the auditor, and how do you handle the 340 credentials in Confluence?
Read the worked answer
Evidence package, per in-scope credential: credential identifier mapped to the PCI scope entry; the rotation event with timestamp and operator or automation identity; target-system confirmation of the change; confirmation that the application authenticated with the new value; the approval or ticket reference where a manual rotation occurred; and the exception record if one applies. Include the population statement - 260 in scope, N compliant, M exceptions, with reasons - and the sampling method you used to verify it. Export it in a form the auditor can re-perform, not a screenshot of a dashboard.
The 340 Confluence credentials: deletion is not remediation. Confluence page history retains prior versions, so a page purged today still exposes the value in its version history, trash, and any space export or backup. Therefore:
- Rotate all 340 first, treating each as confirmed compromised. Order by privilege and reachability: production database and cloud credentials before read-only API keys.
- Then remove the content, including version history and trash, and check attachments, comments, and exports.
- Check the blast radius: who had access to those 60 spaces, and were any of them externally shared or public links.
- Prevent recurrence: pre-receive scanning on repositories, DLP alerting on Confluence rather than periodic scans, and a paste-safe path so engineers have somewhere to store a secret that is easier than a wiki page.
- Measure time-to-rotation for leaked secrets; that is the number the auditor will track next cycle.