How Long Should Audit Logs Be Kept? How the Number Is Actually Chosen

You should keep audit logs long enough to satisfy the duty you may have to prove, but not so long that a platform default is mistaken for a legal answer. Microsoft describes a policy duration as the amount of time to retain the audit logs that meet the policy criteria. That definition is plain, and it is also incomplete until the policy says which duty, system and record type set the clock.

How long should audit logs be kept in practice

The honest answer is not a single period. A single number is attractive because it fits a spreadsheet. It is also how weak policies are written.

Start with the record you may need to produce. If the disputed act is a payment release, the useful log is not merely a sign-in event. If the disputed act is a deleted customer record, the useful log needs to show the actor, the action and enough surrounding context to reconstruct why the deletion was allowed. The period should be chosen for that evidentiary use, not for the convenience of a storage tier.

Microsoft’s own product language shows why a retention answer can change inside one estate. It says the default retention period for audit records varies by license type and when the records were generated. It also says a default policy exists for all organisations.

"Duration: The amount of time to retain the audit logs that meet the criteria of the policy."

— Manage audit log retention policies | Microsoft Learn

That sentence is useful because it ties duration to criteria. It does not say that all logs should be treated alike. A login event for a low-risk collaboration account and an approval record for a changed credit limit may have different evidentiary value. The policy should say so.

There is a second trap. A platform maximum is not the same as a compliance requirement. Microsoft says organisations can retain audit logs for up to 10 years. That statement is not a quoted duty to keep every organisation’s every audit log for 10 years. It means the platform describes an upper capability, subject to the rest of its conditions.

Those conditions matter. Microsoft says retaining audit logs for 10 years requires the user who generates the audit log to have a 10-year audit log retention add-on license in addition to an E5 license. A retention policy that assumes a period the platform will not actually apply is not a policy; it is an aspiration with a deletion date hidden elsewhere.

This is why the retention answer should be written as a method. Identify the duty. Identify the system. Identify the log class. Identify the actual retention mechanism. Then test whether the record survives long enough to be produced when someone asks for it.

A previous discussion of Singapore tracing periods on Your Logs Keep Two Weeks. Singapore Law Says Five Years. makes the same point in a narrower context. The useful lesson is not that every log should keep that article’s number. The lesson is that a statutory production duty can be longer than a tool’s default memory.

Audit log retention policy as a written decision

A written retention decision should not begin with storage. It should begin with a claim the organisation may later need to prove. Storage is the implementation detail that follows.

The minimum useful policy names the log category, the event types, the covered systems, the period, the reason and the disposal rule. That is not a formal standard. It is the shape of an answer that a reviewer can test against a real event. If a policy cannot explain why the deleted-record trail is kept longer than a routine sign-in trail, the number may be arbitrary.

Microsoft’s examples show that policy criteria can be narrower than “all audit logs”. One Microsoft example creates a policy for the “User logged in” activity for six months for a named sample user. Another Microsoft statement says that, for Exchange mailbox activity, a custom policy with a retention period shorter than one year can retain audit records for that shorter duration.

That does not prove that shorter is better. It proves that the policy can operate at a more specific level than a single estate-wide number. A serious policy uses that specificity carefully.

The deletion side also needs to be explicit. Microsoft says retention policies define how long audit log data is retained before it is deleted. That wording is blunt enough for governance work. Retention is not just keeping. It is also deciding when the record disappears.

A policy that says “retain audit logs for one year” without naming the deletion event is incomplete. Does the period run from creation, closure of an investigation, account termination or export to an archive? The source material here does not supply a universal answer. The policy has to.

There is another limit. Vendor documentation can describe product behaviour. It does not settle a regulated entity’s full retention duty. A medical record duty, a contract duty and a litigation hold can all be outside the platform page that sets the default.

That is where vague governance language tends to fail. It says logs are “available for audit” and never states which audit. It says records are “kept as required” and never states the requirement. It says deletion is “automated” and never states what exception stops it.

For teams designing agent and application observability, the same discipline applies. The Observability collection is useful background because evidence is not the same as telemetry volume. More events do not automatically produce a better answer. The right events, kept for the right period, do.

Audit logs retention period by source and system

Retention periods usually come from several places. One place is product configuration. One place is a legal or regulatory reading. One place is the organisation’s own risk assessment. The error is to let the easiest one silence the others.

Microsoft gives concrete examples of product-driven variation. It says Audit (Standard) logs generated on or after October 17, 2023 follow the new default retention of 180 days. It also says organisations can have up to 50 audit log retention policies.

"Audit (Standard) logs generated on or after October 17, 2023 follow the new default retention of 180 days."

— Manage audit log retention policies | Microsoft Learn

Those are product facts. They are not a complete retention analysis. A reviewer asking about a disputed payment does not care that a default existed if the record needed for the payment disappeared too early.

Oracle’s audit documentation uses a different framing. It says the log retention period can be viewed in the tenancy details page. That is another reminder that retention may be a system-level setting rather than a single governance document sitting outside the tool.

Health-sector examples show a separate kind of problem, but they must be handled carefully. Accountable states that the regulation does not prescribe a specific audit log retention period, while logs often substantiate how controls operated and how events were handled. Schellman says a cited requirement does not specifically speak to retention timelines, what must be logged or how often audit logs must be reviewed.

"The regulation does not prescribe a specific audit log retention period, but logs often substantiate how controls operated and how events were handled."

— HIPAA Security Rule Audit Log Retention Period: How Long to Keep Logs, 28 February 2026

That does not let a healthcare organisation ignore audit trails. It also does not prove that every audit log must be kept for the longest period mentioned in any commentary. The supportable conclusion is narrower. The policy should connect audit logs to the records, investigations and defences they are expected to support.

Accountable says state-specific retention laws for medical records can be stricter and may effectively extend how long related audit artefacts are needed. It also recommends inventorying the states in which the organisation operates, mapping applicable record-keeping rules and adjusting audit log retention where a longer term is necessary.

That is a method, not a magic number. It is also the point at which legal, compliance and engineering teams have to work from the same table. If legal says a record may be requested years later and engineering says the audit trail expires earlier, the organisation has found a gap before an auditor does.

Be careful with secondary summaries that list familiar regimes and numbers. Logsign says the Sarbanes-Oxley Act concerns corporations active within the US and requires them to keep audit logs for 7 years. Logsign also says the VISA Cardholder Information Security Program concerns all e-commerce corporations and requires audit logs to be kept for at least 6 months. Those statements may be useful leads, but they are not a substitute for the primary obligation that applies to your organisation.

What this means if you have to produce evidence

Evidence production is where retention policy becomes real. The question is not whether a log once existed. The question is whether the organisation can still produce the right record, explain its completeness and show why it was kept or deleted.

Accountable says archived logs provide the evidentiary trail needed to reconstruct older events, meet breach-notification analysis timelines and satisfy compliance audit requirements. That is a broad statement from a secondary source. It is still operationally useful because it names the work the archive is supposed to do.

Take a changed credit limit. A reviewer may want the request, the approver, the policy condition and the result. A system log that only says an account was updated may not answer those points. Keeping the wrong event for a long period does not cure the evidentiary defect.

Take a deleted customer record. The organisation may need to show who deleted it, when it happened and whether the deletion was expected. If the log category that records deletion is kept for a shorter period than the records dispute window, the retention policy has silently chosen not to be able to answer.

Take a payment release. A finance policy may require approval above a threshold. The retention decision should not merely keep the final payment status. It should keep the approval trail for the period in which that payment can be challenged.

There is no virtue in keeping everything forever. Longer retention can preserve useful proof, but it can also preserve low-value records that no one can search, interpret or justify. A policy earns credibility when it says why some logs are disposed of earlier.

Logsign says it is important to know which logs should be kept and which logs should be disposed of to make sure the organisation is safe and complies with related regulations. That is a modest claim. It is also the part most retention documents skip.

Practical steps for setting the period

1. List the claims. Write the things the organisation may need to prove, such as a payment approval, a record deletion, a mailbox access event or a changed permission.
2. Map each claim to log classes. Do not write “audit logs” as one bucket if the useful evidence lives in different event types, products or accounts.
3. Record the source of the period. Mark whether the period comes from a legal reading, a contract, a platform setting, an investigation need or a business decision.
4. Check the platform reality. Microsoft says that if the user generating the audit log does not have the licences required for the selected retention duration, data is retained according to the highest priority retention policy.
5. Separate default from chosen period. A default may be acceptable for routine events, but the policy should say when a custom period is needed.
6. Write the deletion rule. State when the clock starts, what event ends retention and what kind of hold overrides disposal.
7. Test with a real scenario. Pick a payment release, a deleted record or a changed credit limit, then confirm that the required logs survive for the whole dispute window.
8. Keep the explanation with the setting. A console value without its reason is hard to defend, and a policy document without the actual setting is easy to misunderstand.

For AI agent actions, Crelis takes the narrow position that permission decisions and the resulting records should be treated as linked evidence, not as separate afterthoughts; see GREENLIGHT and the product demonstration.

Crelis is patent-pending. It holds no SOC 2, ISO 27001 or ISO 42001 certification, and claims none.

Related reading

• Your Logs Keep Two Weeks. Singapore Law Says Five Years. — a narrower example of retention driven by a production duty.
• Observability — every post on this site about records, monitoring and evidence.
• GREENLIGHT — the permission step for sensitive agent actions.
• Product demonstration — where to see the runtime evidence flow.