Strapi 5.61 Audit Logs: CMS Governance Guide
A practical guide for Australian teams using Strapi 5.61 audit logs to govern CMS changes, MCP actions, exports, retention, monitoring and incident evidence.
Strapi released version 5.61.0 on 4 November 2026. Its headline governance change is broader audit coverage: Media Library events, content-history restores, discarded drafts, and updates to project or Media Library settings can now leave an administrative trail.
This matters because a modern CMS is no longer changed only by an editor typing in the back office. Administrators alter roles, developers rotate tokens, webhooks connect business systems, schedulers publish releases and AI tools can write content through Strapi's MCP server. When something goes wrong, the business needs to know who or what changed which control, when, and with what result.
Strapi's new logs improve that evidence, but logging is not automatic governance. Australian small-business guidance from the Australian Signals Directorate recommends policy, useful event details, retention, centralisation, protection and regular review. The practical job is to turn product records into an owned operating process.
A Broader Audit Trail for Human and Automated CMS Changes
The release lands as CMS operations spread across editors, administrators, APIs, schedulers and AI agents.
4 November 2026
Strapi 5.61 shipped with new audit events for media, restored history, discarded drafts and settings.
More than editors
Audit payloads can distinguish changes originating in the admin panel, MCP server or scheduler.
90-day default
Strapi's default retention is useful for recent troubleshooting, but it may not match every investigation or compliance need.
Controlled export
CSV export needs separate Read and Export permissions, and exporting becomes an event in the audit log.
Enterprise boundary
The built-in Audit Logs feature is available with the Strapi CMS Enterprise plan.
SME guidance
ASD's October 2026 handbook tells small businesses to protect, retain, centralise and review high-value logs.
What Strapi 5.61 adds to the audit trail
The latest release closes practical gaps around content and asset operations. Media files and folders now share create, update, delete and move events. A media update can identify changed fields such as name, alternative text, caption, focus area, folder or replaced file. A folder deletion records the folder and affected files, giving support teams a better starting point when assets disappear.
Content History restores create an entry.history.restore event as well as the usual update. Discarding draft changes creates an entry.draft-discard event, although the discarded draft content is not retained in that log. Project logo changes and Media Library options such as optimisation, responsive dimensions, orientation and AI metadata can also be recorded.
These events join audit coverage introduced across recent Strapi releases for releases, locales, tokens, administrator accounts, passwords, webhooks, SSO settings, review workflows and CSV exports. The result is more useful evidence across content, identity, configuration and integration changes.
Know what the log proves — and what it does not
An audit log is activity evidence, not a guarantee that a change was correct, authorised or harmless. A recorded publish can still contain the wrong content. A recorded token change does not prove every downstream integration is secure. A successful login is not proof that the user should still have access.
| Question | What Strapi can help show | What the team must add |
|---|---|---|
| Who changed content? | User, action, time and relevant payload detail | Approval rules and business ownership |
| Was a change automated? | Admin-panel, MCP or scheduler origin on supported actions | Tool identity, scope and workflow documentation |
| Why did an asset disappear? | Media delete or move evidence in 5.61+ | Backup, recovery and incident procedure |
| Was a secret exposed? | Token or webhook configuration activity without recording access keys or header values | Secret-manager, rotation and downstream review evidence |
| Did anyone read sensitive content? | Not through MCP read-only audit events | Separate access controls, gateway logs and data governance |
Strapi deliberately avoids recording some sensitive values: access keys, password material and webhook header values are excluded, and webhook URLs are reduced to scheme and host. That reduces one risk while also limiting forensic detail. Document the boundary before relying on the log during an incident.
Use a six-stage path from CMS activity to business evidence
A supportable model moves beyond simply enabling the feature. Inventory the changes that matter, configure coverage and retention, protect viewing and export, preserve evidence outside the CMS where required, review high-risk events, and connect findings to incident response.
Each stage needs a named owner and a testable outcome. Without that, audit records become a screen teams open only after the evidence they need has expired.
1. Inventory high-value CMS events
List the Strapi actions that could affect revenue, customer trust, privacy, publishing or connected systems. Start with administrator changes, role and permission changes, tokens, webhooks, SSO settings, publish and unpublish activity, Content History restores, release actions, Media Library deletions, and changes made through MCP.
Map each event to a business journey. For example, a webhook change can interrupt CRM lead delivery; deleting product media can damage ecommerce pages; changing a role can expose draft or customer-related content. This keeps the logging programme tied to business impact rather than volume.
2. Set retention from investigation needs
Strapi documents a 90-day default, and records beyond the configured period are deleted and unavailable from its interface. Treat that as a software setting, not a universal recommendation. Decide how far back the business needs to investigate a disputed publish, unauthorised administrator change or integration failure.
Document the chosen period, storage impact, applicable contractual or regulatory needs and any external archive. For Strapi Cloud, license settings can define retention; project configuration can lower it but cannot override the licensed period with a longer value.
3. Separate viewing, exporting and administration
Give Audit Logs Read access only to roles that investigate or oversee CMS activity. Grant Export separately and narrowly: a CSV can contain user, network, content and configuration evidence that should not become an unmanaged attachment.
Strapi requires both Read and Export permissions for CSV export, and records the export as its own audit event. Use that trail, but also define where exports may be stored, who can share them, how long they remain useful and how they are deleted. Avoid placing raw exports in general chat channels or broad shared drives.
4. Preserve critical evidence outside the CMS
ASD guidance recommends centralisation and protection against modification or deletion. For higher-value sites, do not leave every investigation dependent on the same application being investigated. Decide which Strapi events, application logs, reverse-proxy logs, identity-provider events and deployment records should reach a protected central logging or monitoring service.
Keep time synchronised across systems and preserve stable identifiers that let investigators connect a CMS event to an identity login, deployment, API request or downstream integration. A CSV exported after an incident can support analysis, but it is not equivalent to continuous forwarding and protected retention.
5. Review high-risk patterns, not every row
Small teams do not need to stare at a feed all day. Define a short review rhythm and a few meaningful patterns:
- failed or unusual administrator logins;
- new administrators, role changes or SSO setting changes;
- token creation, regeneration or permission changes;
- webhook destinations or enabled events changing unexpectedly;
- bulk media deletions or moves;
- history restores, discarded drafts or out-of-window publishes;
- MCP-origin writes outside the approved content types or operating window;
- audit-log exports by unexpected roles.
Not every audit event creates a built-in alert. Use central monitoring, scheduled review or a support workflow to turn relevant evidence into action. Record who reviews it, how often, what creates a ticket and what severity applies.
6. Connect evidence to incident response
Write a short runbook for content damage, credential misuse, integration changes and suspected agent activity. It should preserve evidence before making broad changes, identify affected systems, contain access, recover content or configuration, verify connected services and document the decision to close.
Test the runbook with a harmless scenario, such as a controlled webhook change or draft restore in non-production. The goal is to prove the team can find the record, link it to surrounding evidence, route it to the right owner and recover safely.
Give MCP and scheduled changes explicit ownership
Strapi's payload origin distinguishes admin-panel, mcp and scheduler activity. That is valuable because a person may approve work while software performs the final action. Scheduled activity has no active user on the execution event, although the earlier scheduling record identifies who created it.
There is an important boundary: Strapi says entry actions performed through MCP are logged like their admin-panel equivalents, but actions that only read content are not logged. An AI client could therefore access content without creating an audit event in this feature.
For each MCP client, record the owning team, token, allowed tools, permitted content types, environment, expiry or review date and incident contact. Restrict access at the token and application layers, retain gateway or infrastructure logs where appropriate, and test that prohibited writes fail. Do not interpret an absence of MCP audit events as proof that no content was read.
Treat audit records as protected operational data
Audit trails can help protect personal information, and they can also contain it. Strapi log details may include user identity, IP address, content identifiers and request or response details. OAIC guidance lists internal access controls and audit trails among the practices and systems organisations should consider for managing personal-information risks.
Apply data minimisation to the logging programme itself. Keep the events and detail needed for investigation, restrict access, use approved storage, set retention deliberately and redact evidence before sharing it outside the response team. A support ticket usually needs a concise finding and record identifier, not a raw log export containing unrelated activity.
This guide is technical implementation guidance, not legal advice. Organisations with regulated data, contractual evidence requirements or suspected privacy incidents should involve their legal, privacy and security advisers.
Questions to Answer Before You Rely on the Audit Trail
Use these prompts with business, content, security and implementation owners.
Plan
Does the current Strapi subscription include Audit Logs in every required environment?
Coverage
Which high-impact content, identity, token, webhook, media and settings events are recorded?
Gaps
Which reads, infrastructure events or downstream changes require another evidence source?
Retention
Will evidence still exist when a customer, auditor or responder is likely to need it?
Access
Who can read, export, configure or disable logging, and how often are those rights reviewed?
Integrity
Which critical records are centralised and protected away from the application?
Review
Who checks high-risk events, on what schedule, and which pattern creates an alert or ticket?
Response
Can the team preserve evidence, contain access, recover content and verify integrations?
Testing
Have human, scheduler and MCP scenarios been exercised in a safe environment?
A practical 30-day rollout for an Australian SME
Days 1–5: inventory and verify
Confirm the Strapi version, plan, environments and current retention. List high-impact events and the people, schedulers, integrations and MCP clients that can change the CMS.
Days 6–10: configure and restrict
Review auditLogs.enabled, retention and export limits in configuration. Limit Read and Export access, record configuration ownership and protect any existing CSV exports.
Days 11–17: connect the evidence
Map Strapi events to identity, hosting, deployment and integration logs. Select the records that need central retention and make sure clocks, environments and identifiers can be correlated.
Days 18–23: define review and response
Create a small set of high-risk patterns, assign review frequency and ticket routing, and write runbooks for content damage, administrator misuse, webhook changes and MCP-origin activity.
Days 24–30: test and improve
Run safe scenarios in non-production: restore a version, discard a draft, move media, rotate a test token, change a test webhook and perform an approved MCP write. Verify the evidence, access controls, retention path, escalation and recovery outcome.
Strapi Audit Log FAQs
Practical answers for business owners, content teams, developers and support partners.
Sources checked
- Strapi: Release v5.61.0
- Strapi Documentation: Audit Logs
- Strapi Documentation: Admin Panel Configuration
- Strapi: Audit Log Expansion and Export
- Australian Signals Directorate: Small Business Event Logging
- Australian Signals Directorate: Event Logging and Threat Detection
- OAIC: APP 1 Guidelines
Sources were accessed on 9 November 2026. Product behaviour, limits and plan availability can change; verify current Strapi documentation and your organisation's configuration before implementation.
Need Help Governing a Strapi Website?
VaniTech can review your Strapi upgrade, access model, integrations, MCP controls, logging coverage and support runbooks so the evidence is available when your business needs it.