Retention, and how far back you can look
What your retention window controls, what it does not, what happens at the edge of it, and why an obligation longer than your plan means exporting first.
Your plan carries a retention figure — 90, 365 or 730 days. This article says precisely what that number controls, which is narrower than the phrase 'data retention' normally implies, and what to do when the length of time you are obliged to keep records is longer than the length of time your plan lets you search.
The window each plan buys
| Plan | Retention window | What that covers in practice |
|---|---|---|
| Core | 90 days | A quarter. Enough to investigate something noticed weeks after it started, not to answer a question about a year ago. |
| Protect | 90 days | The same quarter, now across every log source (infrastructure sources included), plus threat hunting. |
| Complete | 365 days | A year. The point at which an annual audit can be answered from the platform rather than from memory. |
| Enterprise | 730 days | Two years. Chosen for the regimes that expect a two-year evidential period. |
The figure lives on your licence record and is copied from the plan catalogue when the licence is issued, so it cannot drift away from the plan you bought. If your console ever shows a retention figure that does not match your plan, your organisation's plan view names the disagreement explicitly in a drift list rather than picking a side. Send us that list.
Because the number is a plan attribute, changing it means changing plan. There is no separate retention setting you can turn up on its own, and there is no per-source override. Changing your plan covers what else moves when you do that.
How the window is applied
When you run a log search, the query window you asked for is compared with your retention days and narrowed if it reaches further back. You do not get an error; you get a shorter window. That is the whole mechanism, and knowing it changes how you read an empty result.
The place this matters most is a search that legitimately returns nothing. On a 30-day window, a search for a sign-in six weeks ago returns no rows — and 'nothing happened' and 'you cannot see that far back' look identical on the screen. Before concluding that an event did not occur, check that the period you asked about is inside your window. This is the same principle the posture assessment applies to skipped checks: an absent answer is not a clean answer. When a check cannot run makes the general argument better than we can repeat it here.
One special case: an organisation with no licence record at all is treated as having no clamp, and searches are unbounded. That exists for bootstrap and test flows and is not a state a paying tenant is in. A zero means 'no clamp', not 'no data'.
What the window does not cover
The retention clamp is applied on the log search path. Several other things in the platform have their own lifetimes and are not governed by this number, and it is worth knowing which is which before you rely on one of them as your record.
- Your audit trail is a separate, hash-chained record of privileged actions with an actor on every row. It is the thing an auditor asks for, and it is not what a log search reaches into.
- Evidence bundles are generated artefacts. Once produced and stamped, a bundle is a fixed document that does not shrink when your search window does. This is the mechanism to use when you need something durable — see The evidence bundle.
- Posture findings and change records belong to the assessment run that produced them, and carry the check pack version they were evaluated against so that two runs are comparable.
- Sentinel-Q conversation history is retained against the same retention figure as your logs, which is worth knowing if you are relying on a past investigation's reasoning.
When your obligation is longer than your plan
This is the situation the article exists for. Retention windows are commercial; retention obligations are legal, and they do not consult your invoice. A few common mismatches:
| Obligation | Typical horizon | What that means here |
|---|---|---|
| NIS2 incident record keeping | Beyond the incident, into the following audit | An incident from eleven months ago on a 90-day plan cannot be reconstructed from a search. Produce a bundle at the time. |
| Answering a supervisory authority or a client's security questionnaire | Usually the last 12 months | On Core or Protect you will be answering from bundles you generated, not from live data. |
| An insurer or a contract requiring evidence of monitoring | The policy or contract period | Generate the evidence on a schedule rather than on request. Requesting it late is the failure mode. |
| Employment or dispute matters involving one person's activity | Unpredictable, often long | Export what you have as soon as the matter is known. Do not assume the window will still cover it. |
The rule to take away is simple and it is the reason this article is written for whoever runs IT rather than for the owner: if your obligation is longer than your plan's window, export before the window closes on it. Nothing will warn you. The events do not vanish in a way you can see; they stop being findable, which is the same thing from where you are standing.
Work out your real obligation first
Not the longest number anybody in the office has heard of — the one that actually applies to your sector and your contracts. For most small firms it is a year, driven by client questionnaires rather than by regulation.
Compare it with your plan's window
If the obligation is longer, you have two options: move to a plan whose window covers it, or generate evidence on a schedule. For most firms the second is cheaper and sufficient.
Generate an evidence bundle on a fixed cadence
Monthly or quarterly, in your calendar, with a named person. The bundle is hash-stamped, so a filed copy can later be shown not to have been altered. The default reporting window inside a bundle is 30 days, so a quarterly cadence leaves gaps — set the window deliberately.
File the bundle outside the platform
Your own document store, with your other statutory records. A bundle that only exists inside the system it is evidence about is not doing the job you generated it for.
Export before you downgrade or cancel
A plan change narrows the window immediately. Cancellation is worse — see Leaving, and taking your data with you, which sets out exactly what the export contains and, more importantly, what it does not.
Retention and the right to erasure
Retention and erasure pull in opposite directions and they are answered in different places. Retention is about how long you may look back. Erasure is about removing a specific person's data on request, and it is a compliance operation rather than a retention setting.
The important honesty point is that the organisation-wide erasure operation and the per-individual subject request are not the same thing, and the per-module fan-out behind subject requests currently reports success without deleting anything. If somebody has asked you to erase their data, read GDPR: subject requests, export and erasure before you answer them, and do not assume the retention window will quietly take care of it. It will not: nothing is deleting on a schedule.
What to do next
- Check which window you are on in your subscription summary, and whether it matches the plan you think you bought.
- Put a recurring reminder in a calendar to produce an evidence bundle. Ten minutes a quarter buys you the year of history your plan may not.
- If your obligation genuinely needs a longer window rather than filed evidence, talk to us about the plan rather than working around it — and note that plan figures are provisional and a firm quote is available on request.