Log retention

Retention in Qorionix means one specific thing, and it is narrower than the word usually implies: it is how far back log search will look for you, according to the plan you are on. It is a visibility window.

It used to be true that nothing in the platform deleted an expired log event. That has changed: a background job now moves events older than your plan's window to compressed off-box storage and then removes them from the live database — see "Hot and archive" below for exactly what that does and does not mean for you.

How long, per plan

There is also a separate, lower-level idea of retention per event classification — different windows for privileged audit records than for bulk telemetry. The endpoint that reads it exists and it returns an empty list for every organisation, because nothing populates it and there is no way to configure one. So today there is a single window per plan and no per-classification control. Do not plan around one.

How the window is enforced

Enforcement happens at read time. When you ask the events endpoint for a range that starts earlier than your plan allows, the start of your range is pulled forward to the boundary and the query runs. It does not fail.

The reasoning is defensible and the consequence is worth knowing about. Asking for the last 90 days on a 30-day plan is an ordinary thing to do, and returning an error every time would be noisier than quietly returning the 30 days that exist. But the narrowing is silent — there is no warning in the response saying your window was shortened. So if you asked for six months and got three, nothing told you why.

One more case, for completeness: an organisation with no licence record at all is treated as having no limit rather than no data. That matters during onboarding and in trials, where you may see more history than your eventual plan will show you.

What actually happens at expiry

A background job periodically finds events older than your plan's window, writes them to compressed off-box storage in day-sized batches, records exactly what it wrote (tenant, object, time range, event count), and only then removes the live rows — never the other way round, so a failed off-box write never costs you the only copy. The events endpoint and an ordinary live search both stop returning an event the moment it is removed from the live table, which is now the same moment it stops being held there at all.

Three consequences, in descending order of how pleased you will be to hear them:

• Upgrading still restores visibility, through archive search rather than an ordinary query. Move from Protect to Complete and the events between 90 and 365 days old are not simply sitting in the live table waiting for a wider query — they were archived and removed once your window was 90 days. They are still there, and the widened window makes them reachable again immediately via archive search (see the next section), which clamps to your CURRENT plan's window, not the narrower one that was in force when they were archived.
• A downgrade narrows what you can reach the same way. Reducing your plan does not delete anything extra on its own, but archive search will refuse to read further back than your new, narrower window allows.
• Retention is now closer to a real data-minimisation control than it used to be, with one honest caveat. Once your deployment has an off-box archive location configured, an expired event is genuinely removed from the live database, not merely hidden — the property a data-minimisation claim actually needs. Without one configured, the job measures what it would remove and does not delete, precisely so that a customer's data is never destroyed with no off-box copy by default. If you rely on this for a specific compliance statement, ask us to confirm your deployment's configuration rather than assuming it — see How to get help. Deletion of tenant data on request remains a separate, deliberate mechanism — see GDPR: subject requests, export and erasure.

Hot and archive: what actually happens at your plan's boundary

Every stored event carries a storage tier of hot or archive. hot means the event is in the live database and answers ordinary search instantly. Behind the scenes, a background job periodically archives events older than your plan's retention window into compressed off-box storage and then removes them from the live database — this is what actually discharges the storage-limitation obligation retention exists for (see the callout above): the row genuinely stops being held in the primary system, not merely hidden from a query.

This is a real change from how the platform used to behave, and it matters if you read an older version of this article: archiving is built, scheduled and running, not a stored label with nothing behind it. Every archived slice is recorded in a manifest (which tenant, which object, which time range, how many events) before the live rows are removed, so a deletion is always traceable to the copy that justified it.

Archived data is not gone for good, and — new — it is no longer unreachable from search either. See the next section.

Searching your archive (cold-tier search)

Once an event has been archived and removed from the live database, an ordinary search box query will not find it — a live search only ever looks at the live table. To reach further back than that, use archive search: a distinct, explicit action in the SIEM search console's Query tab ("Search archived data too"), not something a normal search does automatically.

Archive search runs as a background job, the same shape as an async pipe-query job: you give it a query (the same pipe query language, restricted today to where, sort by and take — no join, union or summarize against archived data yet) and an explicit time range, and it decompresses and scans the archived objects covering that range, applying your filter to each decoded row. It reports real progress (how many archived files it has scanned so far) and a final count, and every result row is labelled plainly as coming from the archive, right next to the live rows it is shown alongside — never mixed in silently.

There are size guards too: one archive search job may cover at most 400 archived files and 2 GB of compressed data, and at most roughly 400 days regardless of plan. A window that is too wide is refused up front, before anything is read, with a message telling you to narrow it — never a job that quietly runs for an hour and returns nothing useful.

Getting your data out

This is the least flattering section and the most useful one. There is no log export. No comma-separated download, no bulk JSON, no scheduled extract, no export this search button. If you need your log events outside the platform, you page a query.

1. 1

   Decide what you actually need to keep

   Almost nobody needs every event. What an auditor or an insurer asks for is usually a category — administrative changes, privileged sign-ins, defence-tampering events — over a stated period. Narrowing first turns an impossible extract into a feasible one.

2. 2

   Use the search endpoint and page it by time

   POST /api/v1/organizations/{orgID}/siem-search/run returns up to 1,000 rows per call, newest first, and includes the original log line. There is no offset or cursor, so you page by narrowing the window: run the query, note the oldest timestamp you received, and run it again with timestamp < that value. Repeat until it comes back short.

3. 3

   Or use the events endpoint if you want a fixed window

   GET /api/v1/organizations/{orgID}/siem/events requires an explicit start_time and end_time and supports an offset, which some people find easier to script. Note that this is the endpoint the retention clamp applies to, so it cannot reach past your plan's boundary at all. Both endpoints need the siem:queries.read permission.

4. 4

   Store the result somewhere with its own retention

   A folder on a laptop is not a retention strategy. If the reason you are extracting is an obligation, put the extract wherever your other records of that obligation live, and write down the query you used and the date you ran it — an extract nobody can reproduce is weak evidence.

5. 5

   Do it before you need it, not after

   The events endpoint will not show you anything past your window, so an extract you decide to take a year late is an extract you cannot take. If you are on a 90-day plan and you have an obligation measured in years, set a recurring reminder now.

When your obligation outlasts your window

This is common and it is not a fault in the product. Audit and record-keeping obligations under NIS2, DORA, ISO 27001 or a sector regulator are frequently measured in years; a 90-day plan is measured in weeks. Four honest options, and you will probably use more than one:

Move up a plan

365 or 730 days covers most ordinary obligations, and the change takes effect on your existing history, not only on new events: events already archived under your old, narrower window become reachable again via archive search the moment your new window covers them. This is the cleanest answer where the budget exists.

Keep the log at the source as well

Your Microsoft 365 tenant, your cloud provider and your domain controllers all have their own audit retention, entirely independent of ours. For an obligation that genuinely needs years, the source system's own configuration is usually the cheaper and more defensible place to satisfy it. Qorionix collecting a copy does not remove your ability to retain the original.

Take stamped evidence bundles on a schedule

The evidence bundle is a point-in-time artefact you download and keep yourself. Be precise about what it contains: control evaluations and framework mappings, plus a summary line for each high and critical alert in the period — identifier, title, severity, status, time. It does not contain the log events underneath those alerts. So a bundle proves what you were told and when; it will not later let you reconstruct why a rule fired. It also does not break at retention expiry, because it never referred to the log rows in the first place.

Export the specific evidence for a live incident immediately

When something real happens, extract the relevant events the same week, using the steps above, and attach them to whatever record you keep of the incident. This is the single habit that most reliably prevents a retention problem, and it costs twenty minutes at a moment when you are already paying attention.

If two screens show you different numbers

The public pricing page agrees with the licence system too, so it is a reasonable second opinion. None of the three is a contract; see the callout near the top.

What to read next

1. Searching your logs — how to build the queries the export steps above depend on.
2. The evidence bundle — what it does and does not preserve.
3. GDPR: subject requests, export and erasure — the mechanism for actually removing data.