Strapi audit logs: setup, retention and SIEM

Strapi audit logs show who changed what in the admin panel

Strapi audit logs are an Enterprise feature that records actions taken by administrators in the Strapi admin panel. On self-hosted plans, the free Community edition and the Growth plan do not include them, so a team that needs this record must be on Enterprise, which is priced on request. Editorial and security leads usually need the log for three situations: regulated publishing, where a reviewer must show who published or changed a page; periodic access reviews, where someone checks which accounts can still edit or publish; and incident investigation, where the team must establish who deleted content or changed settings, and when.

The log answers one question: who published, edited or deleted content, and who changed settings. Before relying on it, confirm with Strapi which admin actions are captured in your version, and whether changes made through the API are recorded the same way as changes made in the admin panel. The audit log does not replace application logs from your front end or API gateway, so plan to correlate the two during an investigation. Also confirm that every editor signs in with a named account. A shared login makes each entry show a shared name, which weakens the evidence even when the log itself is complete.

Decide who can read the log before you need it. Confirm in your version which roles can open the audit log, and keep that group small, because the people reviewing it are often not the people editing content. Map the audit log readers to the teams that will ask questions, such as editorial leads, security and compliance. For administrators who sign in through single sign-on, pair the Strapi log with your identity provider's sign-in records. Strapi SSO covers administrator login to the admin panel only, while end-user authentication is handled separately by the Users and Permissions plugin, so the two sources answer different questions.

Plan the review cadence and the evidence trail. Decide who reviews the log, how often, and what a finding triggers, such as a role change request or an incident ticket. Test the log once in a non-production environment: make a known edit, delete a draft, change a setting, and check that each action appears with the expected user and time. Keep a record of that test, because auditors and incident responders will ask how you know the log is complete. Retention and export are covered in the sections that follow, and both affect how long this evidence stays available to your team.

Retention, export and SIEM options compared

This table compares the four ways to handle Strapi audit log evidence: keeping the default 90-day retention, changing the retention period, exporting CSV for review and forwarding events to a SIEM. Read each row for when the option fits, who operates it and what to confirm in your Strapi version and environment. The main takeaway is that the 90-day default is a starting point, and keeping evidence longer depends on a retention setting you verify or on a SIEM you operate.

Option	When it fits	Who operates it	What to confirm
Default 90-day retention	Periodic reviews where events from the last 90 days are enough and no longer evidence window is required by policy	Strapi administrators with access to the audit log view, with no extra setup beyond the Enterprise plan	That audit logs are available on your plan, how your Strapi version applies the 90-day window and when older events are removed
Changing the retention period	Policy or contract requires a window that differs from the default, and the team can document the change	Platform or engineering team under change control, with an owner who signs off on the new period	Whether your version exposes the setting, whether a change applies to events already recorded, and any documented limits on the value
CSV export for review	Periodic access reviews, audit sampling or handover between administrators who need a file they can filter	Administrators or reviewers with export rights, under the same access controls as the admin panel	Which fields and filters the export includes, any date range limits, whether exports are themselves logged and how exported files are stored and deleted
Forwarding events to a SIEM	Evidence must outlive the Strapi retention window or be correlated with identity, network and other platform logs	Security or platform engineering team that operates the pipeline and the SIEM, with an owner for event schema changes	Whether your Strapi version and plan offer forwarding or whether a custom pipeline is needed, the event fields delivered, delivery guarantees, time synchronization and SIEM ingestion costs

What Strapi audit logs record and what they leave out

Admin actions are the events inside the Strapi admin panel that change who can access the instance and how it is configured. They are usually the first thing an investigation or access review asks about, so confirm carefully which of them your version logs and in what detail.

Sign-ins and failed attempts: confirm whether successful sign-ins, failed attempts, SSO sign-ins and sign-outs are each recorded as separate events.
Content type and configuration changes: confirm which schema edits, plugin settings and other configuration changes made in the admin panel produce an event.
Role and permission edits: confirm whether changes to admin roles, permission assignments and the users who hold them are logged, and whether the log shows the before and after state.
Actor identity: an investigation needs to know which administrator made the change and through which account. Confirm whether the event records the user identity, and whether it also records the role that user held at the time.

Check the exact event names and fields in the current Strapi audit log documentation for your version, and run a test sign-in and a test permission change to see what appears.

Which Strapi plan includes audit logs and what changes the decision

Audit logs are an Enterprise feature in Strapi's self-hosted plans. Growth includes content history and releases, but it does not include audit logs, so a team that needs an admin action trail has to be on Enterprise before it can rely on that feature. The Strapi self-hosted pricing page lists Growth at 45 US dollars per month including 3 users, plus 15 dollars for each extra user. Enterprise pricing is custom and comes from Strapi. Check the current listing before you decide, because plan contents and prices can change.

Your user count changes the arithmetic more than most teams expect. On Growth, cost grows with each added user. As an illustrative example, a team with 8 users would pay the listed 45 dollars plus 15 dollars for each of the 5 users above the included 3, which is 120 dollars per month at list price. That comparison only helps if Growth meets your needs, and it does not cover audit logs. For Enterprise, the number of users, environments and admin roles goes into the custom quote, so give the vendor a complete headcount and a list of who needs admin access before you ask for pricing.

Compliance evidence needs decide whether audit logs are a requirement or a convenience. Write down the questions an assessor is likely to ask, such as who changed a content type, who altered a role or permission, and who published content. Then confirm with Strapi which admin actions the audit log records in your version and which it does not. DeployOpen can prepare the systems, access controls and evidence for an assessment, but independent auditors issue any audit report or certification. An audit log that misses one of your required events does not satisfy the requirement, so verify coverage before you buy.

An existing SIEM budget can also change the answer. If your security team already collects logs from applications and cloud services, the question becomes whether Strapi's audit events can reach that SIEM at the retention you need. Enterprise also includes SSO, while on Growth SSO is an add-on, so a team that already plans administrator SSO through an identity provider may find the Enterprise comparison easier. Ask for a quote built from a written scope that lists user count, environments, SSO needs, log destinations and retention expectations. DeployOpen provides that quote after the scope is agreed in writing.

Setting up Strapi audit logs and checking that they record

This sequence confirms that Strapi audit logs are licensed, scoped, retained and recording the admin actions your policy requires. It ends with a documented test run that shows the same events in the admin log, the CSV export and the SIEM.

Confirm the Enterprise license and Strapi version
Audit logs are an Enterprise feature in Strapi's self-hosted plans, so start by confirming that your license entitlement covers them. Check the Strapi version running in each environment against the audit log documentation for that release, and confirm any gaps with Strapi directly. Your platform engineer completes this step and records the license scope, the version and the environments covered. It is done when the runbook names each environment and states that audit logs are available in it.
Decide which admin roles can view logs
Name the people who need to read audit events, usually security, compliance and platform administrators, and decide which admin roles carry that permission. Remove the permission from roles that only edit content. Your security lead signs off the role matrix, and the platform team applies it. It is done when a test administrator without the permission cannot open the audit logs and a test administrator with it can.
Set and record the retention period
Confirm the default retention period in the Strapi documentation for your version, then compare it with the retention your policy or regulator requires. Change the configured value if the two differ, and record the final setting. If your policy requires longer retention than Strapi keeps in the admin, plan SIEM forwarding to cover the gap. It is done when the configured value matches the signed policy record and a copy of the setting is stored with the runbook.
Run a test set of admin actions
Using named test accounts, perform four actions in order: a login, the creation of a content entry, the publication of that entry, and a role change on a test user. Write down the actor, the action, the target and the time in your own timezone for each one. Keep the notes with the test ticket. It is done when the list contains all four actions with exact times and the test accounts used.
Verify each event's actor, action and time
Open the audit log and find each of the four test actions. For each one, check that the actor is the correct test account, the action type matches what you performed, the target is correct and the timestamp matches your notes, allowing for any timezone display difference. Investigate any mismatch before continuing. It is done when all four events match the notes line by line and the result is recorded.
Check the CSV export against the test events
Export the audit log using the CSV export function available to your role. Open the file and confirm that the four test events appear with the same actor, action, target and time as in the admin view. Check that the columns are complete and that no rows are missing from the test window. Ask your team to confirm how the export handles very large date ranges. It is done when the exported file contains all four events with matching values.
Confirm the SIEM receives the same events
Confirm with your SIEM team how Strapi audit events are forwarded, since the method depends on your Strapi version and your SIEM setup, and check the current Strapi documentation for it. Then search the SIEM for the four test events and compare the actor, action, target and time fields with the admin log. Confirm that no test event is missing or duplicated. It is done when the SIEM shows every test event with fields that match the admin log.

Extending Strapi audit log retention beyond the 90-day default

The default retention for Strapi audit logs on the Enterprise plan is 90 days, so any control that asks for a longer evidence window needs a deliberate change. There are three routes: change the retention period in the Strapi configuration, export audit records on a schedule and keep the files in your own storage, or ship events to a SIEM that holds them under its own retention policy. Before choosing, ask the compliance owner which retention period the control evidence requires, how far back auditors will sample, and whether the evidence must be tamper-evident. Those answers decide which route is acceptable, and they should be written into your audit log procedure before the build starts.

Raising the retention period in Strapi keeps audit records inside the application database. It is the simplest route to set up, but it has the widest effect. Every extra month of admin activity adds rows, so database storage, backup size and restore time grow with it. Growth depends on how many editors and administrators work in the admin panel and how often they change content, so measure a representative month in staging before you set a period. The team that runs the database then owns the archive: they manage backups, restore tests, access to the audit table and the cost of keeping it online. Confirm the maximum period the setting accepts and whether a change applies to existing records or only new ones.

Periodic export moves evidence out of the application. Strapi's CSV export gives you a file you can store in object storage or a records system with its own access controls, and a scheduled job can produce it on a fixed cadence. The trade-off is custody. Once a file leaves Strapi, your team is responsible for where it sits, who can read or replace it, and whether a gap appears if a job fails. If the control requires that evidence cannot be altered, record a cryptographic hash such as SHA-256 for each file at export time, store the hashes apart from the files, and sign them with a key held in a key management service. Keep an export log as well, recording who ran the export, when, the date range and the row count, so an auditor can check completeness.

Shipping events to a SIEM suits teams that already correlate security events there and need one place to search across Strapi and other systems. First confirm how audit events leave Strapi: whether a supported streaming or forwarding option exists, what format it uses, and whether delivery is retried if the collector is unavailable. The SIEM then becomes the evidence store. Set the index retention in the SIEM to match the period the compliance owner gave you, decide whether older data moves to a lower-cost archive tier, and restrict who can query, change or delete the index. SIEM licensing and storage are priced by the SIEM vendor, so request ingest and retention figures in writing. DeployOpen can plan and build the export job or forwarding pipeline, but audit reports and attestations come from independent auditors.

Protecting the audit trail from tampering and overreach

An audit log is only useful as evidence if the people who administer Strapi cannot change or hide what it records. The controls below cover who can read the log, who can export it, how copies leave the admin panel, and who holds the keys to the destination. Each card names the owner who should approve that control.

Who can open the audit log

Access to the audit log in the admin panel depends on which roles hold the permission to view it. Start by listing every role that can open the audit log view, then confirm that content editors and developers cannot see it. Remember that a Super Admin role carries every permission, so review those accounts on a fixed schedule. Owner: security lead, who approves any change to role permissions.

Least-privilege roles for auditors and administrators

Give auditors a read and export path that cannot change users, roles, plugin settings or content. Keep operational administrators in roles that manage configuration but have no ability to alter log records. In a test instance, confirm exactly which permissions each role receives, then record that mapping in your access register. Owner: compliance lead, with the platform owner.

Protecting exported CSV files

A CSV export leaves the admin panel as an ordinary file with no access control of its own. Store exports in a restricted location with named access, and log who exported the file, when, and for what review. Compute a checksum at export time so that any later copy can be compared against the original. Delete working copies on a schedule that matches your retention policy. Owner: compliance lead.

Transport and storage for SIEM shipping

Forwarding evidence to a SIEM extends retention beyond the 90-day default, but the copy becomes a new target to protect. Use encrypted transport, authenticate the forwarding service with its own account, and restrict who can read or delete events in the SIEM index. Ask your SIEM vendor how write-once or immutable storage is configured, and whether your forwarding design adds signatures or hashes. Owner: security operations lead.

Separation of duties over the evidence

The people who administer Strapi should not be the only people able to alter the record of what they did. Assign log review to a reviewer outside the administrator group, keep Strapi administrator accounts and SIEM administrator accounts separate, and require a second approver for any change to retention or forwarding settings. Write these steps into your change process so they survive staff changes. Owner: CISO or head of security, with internal audit.

Operating Strapi audit logs during upgrades and incidents

Audit logs only protect you if someone checks them on purpose. For an Enterprise Strapi instance, the recurring work has four parts: reviewing admin-action events on a fixed schedule, confirming that CSV exports still contain the fields your reviewers rely on, verifying that events still reach the SIEM, and copying evidence out of Strapi before the retention window closes. Give each task a named owner in platform engineering or security, and record every run with the date, the reviewer and the result. A gap in that record is easy to spot during an audit or an incident review. Agree the review cadence with your compliance lead, so it matches how often your organization must show that privileged admin activity was checked.

Upgrades are the most common point where audit logging quietly changes. Strapi 5 minor releases have shipped roughly weekly, for example v5.56.0 on September 30, 2026 and v5.57.0 on October 7, 2026, followed by v5.58.0 on October 14, 2026. You do not need to upgrade every week, but you do need a standing version check and a planned window for applying minor releases. After each upgrade, run a test export from a staging copy, compare its column layout with the previous export, and send a test event through the SIEM pipeline. Keep the pre-upgrade export as a baseline. If a field name or event type has changed, update the SIEM parser before the change reaches production.

Retention is the constraint that drives most of these decisions. Enterprise audit logs keep events for a default period of 90 days, and that setting can be changed, so confirm the current value on your own instance before you rely on it. Anything older than the window must come from another source. The usual sources are the SIEM or log store that received forwarded events, exports saved on a schedule, and database backups taken during the period. If none of these exist, the events are gone, and the incident file should say so directly. Ask your SIEM provider and your backup team to confirm how long each holds data, since those periods are set outside Strapi and may be shorter than you expect.

When an investigation needs events older than the retention window, work through a fixed order. First, freeze the scope by recording the time range, the accounts and the content types involved, and pause any routine cleanup that could touch those records. Second, search the SIEM or log archive, which usually holds the longest history. Third, restore a database backup into an isolated environment only if the SIEM has no coverage, and extract the admin audit records from that restored copy. Document every source, its timestamp range and the integrity checks you ran. Involve legal and the compliance owner early, because restored backups can contain personal data and should follow your approval process. Keep the restored copy out of production so that the investigation does not alter live systems.

Limits to confirm in your environment before you rely on audit logs

Audit logs are only as useful as the evidence they hold, so each item below should be checked, not assumed. Confirm them against Strapi's current documentation and in a test instance that matches your production stack before you cite the logs in a control narrative.

Event coverage per content type and plugin

Confirm which actions are recorded for each content type, component and plugin your project uses, such as creates, edits, publishing changes and deletions. Coverage can differ between core content and plugin-owned data, so test one example of each type and check that the entry names the document and the acting user. Ask Strapi which events are in scope for your edition and version, and record the answer in your evidence file.

API calls versus admin panel actions

Admin panel edits and API requests can reach the log through different paths, so verify both. Test a token-authenticated REST or GraphQL write and confirm whether an entry appears, identifies the API token or user, and shows the changed values. If API-originated writes are missing, your evidence covers only human admin activity, so plan a second source such as gateway logging or database auditing for those paths.

Time zone and clock synchronization

Confirm whether log timestamps are stored in UTC or displayed in a local time zone, since the admin interface may show different values than the stored data. Verify that the Strapi hosts and the database servers synchronize to the same trusted time source, because mismatched clocks make sequence reconstruction unreliable during an incident. Ask your platform team to document the time configuration on each node and compare it with timestamps in an exported file.

Export format and size limits

Test the CSV export with a representative volume of entries from your own environment. Check the column set, how line breaks and special characters are escaped, how dates are formatted, and whether the export is complete or paginated. Confirm any row or file size limit and who can run the export. Ask Strapi for the documented limits for your plan and version, and keep a sample file with the expected headers as a reference for later comparisons.

Database and Node.js compatibility

Strapi 5 supports PostgreSQL 14 or later, MySQL 8.0 or later, MariaDB 10.3 or later and SQLite 3, and it runs only on Active or Maintenance LTS Node.js versions. Confirm that your database and Node.js release appear on that list. Supported status does not confirm identical audit behavior across databases, so test writes, exports and retention on the exact stack you plan to run.

Retention period and SIEM handoff

Confirm the default retention period for audit log entries in your edition, along with the steps to change it. Then verify that your SIEM export or forwarding path receives every event your policy requires before any pruning removes it. Name the owner of the retention decision and record the date your first export was validated. Confirm the retention settings and configuration steps in Strapi's Enterprise audit log documentation.

Questions buyers ask about Strapi audit logs

Do Strapi audit logs require the Enterprise plan?

Yes. Strapi lists audit logs as an Enterprise feature on its self-hosted pricing page, so you need an Enterprise license to use them. Community is free, and Growth starts at 45 US dollars per month including 3 users, with 15 dollars for each extra user, but Growth does not include audit logs. Enterprise pricing is custom, so the license cost comes from a conversation with Strapi. Confirm the current plan table with Strapi before you budget, because plan contents change. Also review the license terms for your deployment, since code under the Enterprise directories is covered by a separate Strapi license from the MIT-licensed Community Edition. The plan decision stays with your organization and Strapi.

What drives the cost of audit log setup work?

Four things drive the cost: the Strapi plan you hold, the number of systems the logs must reach, how long you keep records, and how much testing you need before sign-off. The Strapi license is paid to Strapi and recurs with the subscription. Implementation labor is a one-time cost tied to the written scope. SIEM integration adds effort that depends on the target platform, its ingestion format and who owns the pipeline. Retention design adds work if you must keep records beyond the 90-day default, because you need an export or shipping path and storage you control. Testing adds effort to show that events arrive complete. Ask every quote to split one-time work from recurring costs, and to name the systems in scope.

How long does audit log setup take in our environment?

Duration depends on your environment more than on the audit feature itself. The main dependencies are your Strapi version and hosting, your database (Strapi 5 supports PostgreSQL 14 or later, MySQL 8.0 or later, MariaDB 10.3 or later and SQLite 3), the SIEM you ship to, network paths, and how quickly your team approves retention and access rules. A single instance feeding a SIEM that already accepts your log format is a smaller job than several environments feeding a new SIEM. DeployOpen does not publish a duration. Most engagements are fixed-scope, so the timeline is set in writing after the environment is reviewed. Ask for the list of dependencies and approval steps in the proposal.

What does our team need to provide for the work?

Your team should provide admin access to the Strapi instance and its hosting, a named SIEM owner who can accept and index a new log source, and the written compliance requirements that set retention and review. You also need a change window for production and a test environment close enough to production to prove events arrive. Access should be scoped and recorded. Compliance requirements matter most: ask your compliance lead or auditor which records must be kept, for how long, and who reviews them. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications. Independent auditors decide whether your evidence is sufficient.

Can an internal team set up audit logs without outside help?

Often yes for the in-product part, but the full job usually needs more. Enabling audit logs and CSV export happens in the Strapi admin panel, and an engineer familiar with Strapi can configure and test them. Shipping events to a SIEM, designing retention and proving completeness need SIEM and security skills that many teams have only partly. Check three things: does someone own Strapi upgrades, can someone build and maintain a log pipeline, and does someone know what the auditor expects? If the answer to two of those is no, a partner is worth considering. Internal teams can also request a fixed-scope engagement that covers only the gaps they cannot fill.

Does 90-day retention meet our record-keeping obligations?

The 90-day default is the starting point in Strapi, and whether it is enough depends on your own record-keeping rules. Your compliance lead and auditor set those rules, not the platform. If you need longer retention, change the retention setting in Strapi or ship events to a SIEM you control for longer storage. Make sure the retention period in Strapi and in the SIEM match your policy, and document the decision with its reason. DeployOpen can design and document the retention approach and prepare evidence for an assessment. It cannot decide what your regulator requires or certify the result.

Is setup work priced as a fixed scope?

Most engagements are fixed-scope, which means the scope, deliverables and timeline are agreed in writing before work starts. A quote follows from that written scope, and DeployOpen does not publish a price list. To compare quotes from any provider, ask for the Strapi plan assumed, the SIEM and its ingestion method, the retention period, the test steps, the handover documents, and how changes to scope are priced. Ask whether ongoing support is included or offered separately, since upgrades and support can be arranged as a retainer. Quotes that leave these items out are hard to compare.

How DeployOpen works on Strapi audit logs

DeployOpen scopes Strapi audit logs as a written piece of work: which admin actions must be evidenced, how long records are kept in Strapi, and where longer retention lives in your own infrastructure. Engagements are fixed-scope, so the deliverables and the checks behind them are agreed before build starts.

How we scope

Confirm which Strapi plan and edition you run, since audit logs are an Enterprise feature on the self-hosted plans
Agree which admin actions, content types and environments must be evidenced for your reviewers
Record the retention period you need and how it maps to the 90-day default in Strapi
Define who may export CSV files and where exported evidence is stored and access-controlled

How we build

Enable and configure audit logging on the Strapi instances in the agreed scope
Set retention, export and access settings in line with the written requirements
Test that expected admin actions appear in the log and that exports match the source records
Where longer retention is required, wire log shipping to the SIEM you already operate

How we hand over

Deliver a runbook covering how to read, filter and export audit log entries
Document the retention settings, the SIEM forwarding path and the owner of each setting
Walk your operations and compliance staff through the evidence process before sign-off
Provide the test results and configuration record that your auditor may ask to see

How we support

Review audit log settings again when Strapi releases change admin or log behavior
Available as a retainer for ongoing checks, upgrades and SIEM pipeline fixes
Ask your auditor or certification body to confirm what evidence satisfies your controls, since DeployOpen prepares evidence but does not attest to it
Confirm the Strapi version and plan that your support terms cover before engagement starts

Strapi audit logs