Inactive accounts should be removed or disabled after 90 days to reduce risk

Title: The Quiet Guardrail: Why 90 Days Really Matter for Inactive Accounts

Imagine you’re scanning a security dashboard and you spot a handful of user accounts that haven’t seen any action in months. They’re not actively used, but they’re still alive in your system. It’s a tempting target for clever attackers who love dormant doors. That’s why the PCI DSS guidance on inactive accounts matters more than it might sound at first glance.

Let me explain the logic in plain terms, then connect it to what teams actually do on the ground.

What the PCI DSS says about account management (in simple terms)

PCI DSS is all about protecting cardholder data. A big part of that protection is controlling who can access systems that store, process, or transmit payment information. If an account is unused, you’d think, “Why worry?” The reality is different. An idle account can become a backdoor—an overlooked entry point if someone gains access through a forgotten credential or a misconfigured integration.

To keep the surface area small, many security programs set clear lifetimes for accounts that aren’t being used. If an account sits idle for too long, it’s either disabled so it can’t be used, or removed entirely. This isn’t about city-planning fancy stuff; it’s about reducing risk in a practical, trackable way.

Now, onto the concrete piece many people ask about—the 90-day rule.

The 90-day rule: A quick roundup of the quiz-style question

Here’s the scenario you’ll sometimes see in quizzes or training modules:

Inactive accounts should be removed or disabled after how many days?

A. 30 days

B. 60 days

C. 90 days

D. 120 days

The correct answer is 90 days. Here’s why that window tends to line up with PCI DSS expectations and real-world security benefits:

• It’s long enough to differentiate between truly unused accounts and those that are merely dormant for a short project or seasonal work. A few weeks can be a red herring; 90 days hits a practical sweet spot.

• It’s short enough to limit exposure. The longer an account remains active without regular verification, the more time a malicious actor might spend probing for overlooked credentials or misconfigurations.

• It provides a repeatable, auditable process. Security teams like to measure, document, and prove their controls work. A 90-day rule makes it easier to demonstrate that you’re actively managing access rather than letting it drift.

The other options—30, 60, or 120 days—each have their own trade-offs. A 30-day window can be too aggressive for legitimate, slow-moving environments. A 60-day window might miss accounts that have a legitimate lull but still pose a risk. A 120-day window could let dormant accounts linger longer than is prudent, increasing risk and complicating audits. The takeaway: 90 days is a practical balance that aligns with risk reduction and governance needs.

From policy to practice: turning the rule into action

If you’re responsible for access controls, the 90-day guideline translates into a concrete workflow. Here’s how many teams implement it without turning the process into a headache.

1. Identify the inactive accounts

• Define inactivity clearly. Is it no logins for 90 days? No successful authentications for 90 days? No API activity? The answer depends on your environment.

• Separate types of accounts. People accounts are different from service accounts, system accounts, or third-party integrations. You’ll want different handling for each.

• Use your identity and access management (IAM) tools to generate a clean report. If you’re in a Microsoft-centric world, that means Active Directory or Azure AD; in a cloud-first setup, you’ll pull data from IAM brokers like Okta or Ping Identity.

2. Decide how to handle them

• Disable first, remove later. A common path is to disable after 90 days of inactivity, so you can reactivate if someone unexpectedly returns. This keeps operations flexible but secure.

• Remove if there’s no business need. Some accounts truly belong to projects that are over or contractors who have left. If there’s no ongoing requirement, removal minimizes risk.

• Handle exceptions carefully. Service accounts, emergency access accounts, or automated processes may need a different cadence. Document the rationale and keep a separate exception log.

3. Automate the cadence

• Set up automated reviews and scripts. A lot of teams use scheduled scripts to flag candidates for disablement or deletion, then route those lists to managers for confirmation.

• Tie it to change control. Don’t slam a lot of removals into production without a review trail. Attach the actions to change records and keep an audit trail.

• Maintain an alerting system. If an account is reactivated, your system should surface a notification so security teams can re-evaluate privileges.

4. Preserve auditability

• Keep records of why an account was disabled or removed, who approved it, and when. This matters during PCI DSS assessments and for long-term security governance.

• Log every disablement and deletion. You’ll want to demonstrate that the organization has a clean and consistent approach to account lifecycle management.

5. Communicate and train

• Make sure managers and system owners understand the policy. A one-size-fits-all rule won’t work if someone is constantly reactivating accounts without a legitimate business reason.

• Provide an easy path for exceptions. A simple form or ticketing route helps keep governance intact while supporting legitimate needs.

Why this matters beyond a quiz answer

You might be wondering, “Okay, 90 days is the number, but what’s the big deal in the real world?” It’s about risk reduction without turning security into a roadblock. When you prune idle accounts, you shrink the number of potential misconfigurations and reduce opportunities for credential stuffing, phishing, or insider misuse. It also helps with separation of duties: if an account sits idle too long, it’s easier to forget that it exists or to miss an alert tied to it.

A quick digression you might relate to

Security folks often talk about “identity hygiene.” It sounds a bit clinical, but it’s a helpful phrase. Just like cleaning a crowded closet makes it easier to find what you actually use, clearing out unused accounts makes access management clearer and safer. And as you probably know, a cleaner IAM environment translates to fewer surprises during audits and pen tests. It’s the kind of practical win that keeps everyone’s job sustainable, not just theoretical.

How to avoid common missteps

• Don’t treat inactivity as a one-and-done event. Stale accounts can reappear if there isn’t ongoing monitoring.

• Don’t confuse automated test accounts with real ones. Test or sandbox accounts can look idle, but they may be legitimate for certain environments. Flag them properly so they’re not disabled by mistake.

• Don’t rush removals without a plan. If a business unit relies on a dormant service account, a quick removal could break critical workflows. Document and coordinate.

• Don’t forget about privileged accounts. A privileged user’s inactivity might be more sensitive. Consider separate rules or more frequent reviews for those.

A practical checklist you can reuse

• Define inactivity precisely (logins, API calls, or both) and apply consistently.

• Classify accounts (user, service, integration, privileged) and tailor actions.

• Use a 90-day threshold as the baseline, with documented exceptions.

• Disable first, remove later if appropriate; keep the option to reactivate.

• Automate identification, notification, and remediation where possible.

• Maintain an audit trail for every action and decision.

• Review the policy with stakeholders regularly to keep it aligned with real-world needs.

A few real-world touches you’ll recognize

Many organizations lean on familiar tools to make this work smoothly. If you’re in a Windows-dominated shop, you’ll gravitate toward AD or Azure AD reports and deprovisioning workflows. Cloud-first teams often lean on identity providers like Okta or Ping Identity, synced groups, and automated deprovisioning pipelines. In both worlds, the heartbeat is the same: a reliable, repeatable process that reduces risk without slowing down legitimate work.

Closing thoughts: not just a rule, but a disciplined habit

So, the 90-day rule isn’t just a test question. It’s a practical discipline that helps keep sensitive data out of reach from misused credentials and forgotten access. It’s about balancing security with operational reality—clearing out what’s unused while preserving what’s essential for business continuity.

If you work in security, IT, or compliance, this rule is a good anchor for broader access control programs. It pairs well with other practices—strong MFA, regular privilege reviews, and robust logging—creating a more trustworthy security posture overall.

One last question to guide your thinking: when was the last time your organization conducted a clean sweep of truly inactive accounts? If the answer isn’t crisp, you’ve got a clear next-step. A 90-day review cycle isn’t only a checkbox; it’s a proactive stance that says, “We’re watching who has access—and we’re careful about who we let through the doors.”

So, the next time you glance at a dormant account list, remember: sometimes the quietest controls are the loudest guardians of safety. And yes, the 90-day window is a sensible rule that most teams can live with—protective, practical, and repeatable.