“30 days retention” on a backup job or a log store is a factory default, not a decision. It defines the absolute limit of how far back you can recover — and for most organizations, that default window is quietly shorter than the mistakes, fraud attempts, and incidents that actually happen.
A Tuesday morning in Manteca
Picture a controller at a credit union in Manteca. It’s 7:40 a.m., coffee in hand, and she’s reviewing last month’s wire approval queue before the branches open. One transaction looks wrong — an invoice from a vendor that changed its bank details six weeks ago, right around when an employee left. She flags it, and the fraud team asks the obvious question: can we restore the ledger and the email thread from before the change?
She opens the backup console. The job has been running faithfully every night. And right there in the job settings: Retention: 30 days.
The change happened 41 days ago. The versions that matter no longer exist.
Nothing “broke.” No alert fired. The backup system did exactly what it was configured to do. That’s the uncomfortable truth about retention data — it’s one of the least-looked-at settings in the entire stack, and it silently decides the answers to questions you won’t be asked until the worst day of your IT year. Our disaster recovery team runs into this default again and again when we onboard new clients, and it’s the reason we treat retention as a boardroom conversation, not a checkbox in a backup wizard.
What does a “30 days retention” setting actually control?
Retention is one of three separate dials on any backup or logging system, and people constantly blur them together:
- Frequency — how often a copy is taken (hourly, nightly, continuous).
- Retention — how long each copy is kept before it’s overwritten.
- Isolation — where the copy lives, and whether ransomware or a rogue admin can reach it.
The retention dial answers a single question: how far back in time can you reach? NIST’s log management guidance draws a useful line here — keeping records for a short window (days or weeks) can be handled with online systems and regular backups, but longer windows (months or years) require deliberate archiving processes that most default configurations simply don’t include.1 In other words: the moment your real-world need exceeds 30 days, you’re not in “default settings” territory anymore. You’re in architecture territory.
Retention is also not purely an IT convenience. NIST’s storage security guidance is explicit that data retention is typically satisfied by keeping copies on backup media, and that the requirements driving it come from operational, legal, regulatory, or statutory sources — meaning the right number lives in your contracts, your regulators, and your incident response plans, not on the appliance’s configuration screen.2
Is 30 days of data retention enough for compliance?
Sometimes. But “sometimes” is exactly the problem — because the answer depends on which regulator owns the data in question, and the defaults on your gear don’t know.
If you touch criminal justice information — a dispatch center, a police records system, a county IT shop supporting law enforcement — the CJIS Security Policy includes an audit record retention control (AU-11) that requires keeping audit records for an organization-defined period, alongside contingency planning and system backup controls (CP-2, CP-9) that require backups of user-level, system-level, and documentation data, with testing to confirm the backups can actually be reliably retrieved.2 An appliance set to “30 days” doesn’t know what your CJIS agreement defines. If your audit trail evaporates faster than your defined retention period, that’s a finding.
If you’re a clinic or covered entity, the HIPAA Security Rule’s contingency plan standard requires procedures for backing up ePHI, restoring lost data, and continuing critical operations in emergency mode.3 When a practice’s EHR vendor only offers 30 days of point-in-time recovery, and a data-integrity problem surfaces at day 40, you’ve got a compliance gap wearing an operations costume. This is a big part of why our healthcare IT work starts with a retention map, not a hardware quote.
If you’re a bank or credit union, examiners will want to see that your recovery capabilities align with your documented objectives — and that the evidence of your testing goes back far enough to be meaningful. A retention window shorter than your exam cycle makes the evidence problem real.
The pattern across all of these: the frameworks don’t name a universal number of days. They name an obligation — and it’s on you to translate that obligation into a setting. CISA’s Cybersecurity Performance Goals frame the outcome side of this: systems necessary for operations are backed up on a regular cadence, stored separately from the source systems, and tested on a recurring basis.4 Notice what’s absent — any universal “30 days.” The government guidance deliberately leaves the number to a risk decision you’re supposed to make on purpose.
The 30-day trap inside Microsoft 365
The most common version of this problem doesn’t live on a backup appliance at all. It lives in the assumption that “it’s in the cloud, so it’s kept.”
Microsoft 365 keeps deleted items and version history for limited, default periods. Plenty of organizations we meet in Modesto and across the Central Valley are running on the platform’s native safety nets and assuming those nets are retention policy. They aren’t — they’re short-term recovery conveniences, and once a mailbox item clears those default windows, your only path back is a third-party backup you may not have. This is exactly why we treat Microsoft 365 backup as its own service rather than a line item: mail, OneDrive, SharePoint, and Teams all have their own deletion timelines, and none of them know your legal hold obligations.
The flip side matters too: indefinite retention isn’t a virtue. Keeping everything forever inflates eDiscovery scope, extends your breach blast radius, and creates data you’re obligated to protect but have no reason to hold. Retention is a two-sided decision — recover too little and you can’t respond to an incident; keep too much and the incident gets worse when it happens.
Sizing your retention window: a decision matrix
There’s no magic number, but there is a repeatable way to land on one. For each category of data, ask how far back a real event could need to reach:
| Data / system | Typical default you’ll find set | What 30 days actually covers | The question that sizes it correctly |
|---|---|---|---|
| Microsoft 365 mail & files | Native deletion windows + “it’s in the cloud” | Only the most recent mistakes | How far back do legal holds and fraud lookbacks reach? |
| File server / ERP database backups | 30 days on the backup job | A month of operational recovery | What’s the longest fraud or error discovery window we’ve seen in our industry? |
| Firewall, switch, and server logs | Often 7–30 days or local storage only | Barely enough to reconstruct one incident | Can we investigate an intrusion discovered at day 45? |
| EHR / clinical systems | Vendor-managed, varies widely | Depends entirely on the vendor contract | Does our BAA and downtime plan survive a day-40 data integrity event? |
| CJIS-regulated audit logs | Often whatever the system shipped with | Whatever “organization-defined” means — which is your job to define | Does our audit trail outlive our defined retention period? |
That last column is where a real vCISO earns their keep — translating regulatory language and actual threat patterns into concrete settings, then documenting why each number was chosen.
Five questions that expose a retention gap
If you want to know whether your organization has this problem, these five questions will find it faster than any product demo:
- For each critical system, what is the retention setting today — and who chose it? If the answer is “whatever the installer configured,” that’s your finding.
- How far back does our worst realistic scenario reach? Invoice fraud, a departing employee’s deletions, a slow-moving intrusion — most of these are discovered weeks after the event, not days.
- Are backups stored separately from source systems, and are they tested on a recurring schedule? That’s the CISA benchmark — separation plus recurring testing, not just a green checkmark on last night’s job.4
- Which regulators or contracts define a retention floor for us? CJIS agreements, HIPAA risk analyses, GLBA safeguards programs, and customer contracts can each impose different minimums on the same data.
- If we had to restore from day 35, could we prove it works? A restore test that only ever exercises last night’s backup tells you nothing about the deep window.
Notice that none of these questions is about backup software. The tool is rarely the problem. The unmade decision is.
How long should a 100+ employee organization keep data?
Here’s the honest answer: it depends on your industry, your contracts, and your threat model — which is precisely why the default shouldn’t survive contact with a real review. But we can offer a structure that holds up across the finance organizations, local governments, and mid-market companies we serve:
- Operational recovery tier: frequent restores, days to a few weeks of retention — this is where most daily mistakes live.
- Incident and fraud tier: 90 days to a year for the systems where wrongdoing or intrusion is discovered late — mail, logs, financial systems. NIST’s guidance is blunt that retention measured in months or years requires deliberate archival processes, not assumptions.1
- Regulatory and legal tier: whatever your frameworks and contracts define, held immutably where possible, with access controls and documented disposal at the end of the period.
The tier structure matters more than any single number, because it forces the conversation out of “is 30 days enough?” (unanswerable) and into “what does each category of data owe us?” (very answerable).
The decision Manteca should have made in advance
Back to our controller. The painful part of her Tuesday isn’t the loss — it’s that the decision that cost her was made by nobody, years earlier, by leaving a default in place. Retention data is like that. It’s invisible until the moment it’s the only thing that matters.
If you’re running a business of 100+ employees in the Central Valley, in Modesto, or across our California markets, and you can’t answer the five questions above with documented numbers and owners, that’s worth a conversation — not a sales pitch. We’d rather you start with our MSP evaluation checklist and compare us honestly against whoever you’re with today. And if the systems in question touch criminal justice data, our CJIS compliance checklist for city and county IT teams is a practical starting point written for exactly the people who get audited.
Thirty days is a fine default. It’s a terrible decision. Bring us the question before your worst Tuesday does.
Datapath provides managed IT, cybersecurity, and compliance support to regulated organizations that need clear ownership and audit-ready evidence.
