Audit History on Your Terms

An audit trail has two jobs that pull against each other. It has to last long enough to answer an auditor, a regulator, or an incident review years after the fact. And it names people, so keeping it forever means keeping those people forever.

AI Rule Engine now lets you see exactly how long your history is kept, sets a sensible default for organizations that need years of it, and lets the ones that need more choose it deliberately. Alongside that, streaming to your own security tooling no longer loses events when your collector has a bad afternoon.

How long your plan keeps audit events

Audit events are recorded on every plan, including the ones that cannot browse the log, and each one expires when it reaches the retention of the plan it was recorded under:

Plan	Audit events kept for
Free	7 days
Pro	30 days
Team	90 days
Enterprise	7 years, or longer if you choose

You no longer have to look it up. On every plan, the header of the Audit Log page, under Administration on your organization, states how long your organization keeps its events, so whoever is answering the auditor knows how far back the record goes before they start digging. Browsing the events themselves is on Team and Enterprise.

Enterprise: seven years by default

Enterprise organizations keep audit events for seven years by default. That is years of history to answer a review with, without keeping the name of every person who ever touched a rule for the rest of time.

Some organizations do need more, so longer retention is an explicit choice rather than a silent default. On the Audit Log page, an organization admin opens the Retention card, chooses Change, and picks 10, 15 or 25 years, or Indefinitely. The card then says plainly which setting is in force and how it compares with the plan default.

A few things are worth knowing before you choose:

• The choice is recorded. Changing retention is itself an audit event, so the record shows who decided how long the record lasts.
• It applies going forward. Each event’s expiry is fixed when it is written, so a change neither extends nor shortens events already stored.
• It survives a plan change. If the organization moves to a lower plan, that plan’s retention applies to new events. Return to Enterprise and your choice comes back into force.
• Older Enterprise events keep what they had. Events recorded before the seven-year default existed were written with no expiry, and they keep it.

If you need the trail to outlive both the live log and us, the Compliance Archive add-on writes a daily, write-once copy to immutable storage you own.

Streaming that holds what your collector refuses

On Enterprise, the Streaming card forwards every audit event in near real time to a security information and event management system of your own, such as a Splunk HTTP Event Collector. The weak point of any push-based stream is the collector being down: events sent into an outage are easy to lose.

Events your destination does not accept are now held, not dropped:

• A failed delivery is retried a few times over about two and a half minutes, which rides out a collector restarting or briefly pushing back. A refusal that waiting cannot fix, such as a rejected credential, is not retried in that burst.
• If the destination still has not accepted the events, they are held, and the card tells you how many are waiting and since when.
• Newer events queue behind the held ones rather than jumping ahead, so your collector never receives today’s events before yesterday’s.
• Every five minutes the held events are offered to the destination again, oldest first. Once it accepts them, the card shows the catch-up until nothing is left, and new events go straight through again.

Turning streaming off keeps whatever is held, and it is sent when you switch streaming back on. Point streaming at a new destination while events are held and they go to the new one, so fixing a moved endpoint fixes the backlog too.

Two things to plan for. Delivery is at least once, so after a retry your collector can receive an event it already has; drop duplicates by each event’s id. And held events are read back from your audit log when they are sent, so an event that reaches the end of your retention during a very long outage can no longer be streamed. To recover an outage that long in full, export the period from the log or use the Compliance Archive.

Open the Audit Log page in your organization to see your retention and the state of your stream.

Visit RuleEngine.ai to try it.

The AI Rule Engine Team