Audit log review workflow

In short. The audit log records every meaningful action on your SGEN site — logins, role changes, content publishes, settings edits, billing changes, integration updates. Routine review catches anomalies before they become incidents and gives you a clean evidence trail when something genuine does go wrong. The daily habit: open SG-Admin → Activity → Audit log, filter to Authentication / Failed, scan the past 24 hours. Five minutes a day. That's the whole cadence compressed to one sentence — the rest of this page shows you what to look for and what to do when you find it.

On this page: What gets logged · Where to find it · Review cadence · Anomaly patterns · How to respond · Step-by-step

How to read the audit log, run a routine review cadence, and respond when an entry looks off.

The audit log lives at SG-Admin → Activity → Audit log. It is read-only — entries cannot be edited or deleted from the admin, by design.

What is this for?

The audit log answers the three questions that come up in any team running a website: "Did someone change this setting last night?", "Why did that account get a new role?", "Are there login attempts from places our team has never been?" Without it those questions are unanswerable; with it they take a minute to resolve — whether you are scanning for security anomalies, producing compliance evidence, or answering a colleague's quick question.

Good use cases

What NOT to use this for

• Real-time intrusion detection. The audit log is a record, not an alarm. For active alerts, feed scheduled CSV exports into your SIEM or security team's tooling.
• Performance debugging. The log covers access-control and content events — not page load times or server errors. Use your hosting platform's monitoring for those.
• Personal surveillance. The log records actions on the SGEN admin. Using it to track employee hours for performance reviews is a misuse and likely a policy violation in many jurisdictions.
• Replacing team communication. Most anomalies have benign explanations. Ask the actor before drawing conclusions.
• One-time reviews. The value is in the cadence, not a single read.

How this connects to other features

• Two-factor authentication and SSO — Every 2FA and SSO event appears in the audit log. Failed 2FA clusters are an early credential-compromise signal.
• Users and roles — Every user add, role change, and access grant is logged. The users list shows current state; the audit log shows how it got there.
• Backup and restore — Backup creation and restore initiation are logged. After a restore, review post-restore entries to confirm no unexpected changes.
• Security hardening — Routine audit log review is a baseline item in the security hardening checklist.
• Multi-site management — Audit entries are scoped per site by default. The org-wide view in SG-Dashboard aggregates across sites.
• Integration settings — Every integration change is logged. Unauthorised webhook URL changes are among the highest-risk events to catch quickly.

Full detail: Security hardening · Two-factor and SSO

Before you start

• Platform Admin access required. Standard editor and content roles do not see the Activity menu.
• Pick a cadence you will keep. A weekly 15-minute review beats a daily scan that gets skipped. Most small-to-mid teams settle on weekly review + monthly deep sweep.
• Know your baseline. Spend the first week observing — typical login hours, IP geographies, who routinely changes settings. Anomalies only stand out once you know normal.
• Have a response path ready. Before you need it: know who you will contact, how you will disable an account, and where you will log the incident.
• Confirm retention for compliance use cases. Business tier retains 1 year; Enterprise retains 7 years. If your compliance regime requires longer retention, arrange export to long-term storage before the window closes.

Before the cadence starts, confirm the response path is in place. The checklist below is what "ready to review" looks like — every item except the SIEM feed applies to a single-site team, and the SIEM feed is marked optional because it is only relevant if you need active alerting on top of the record.

Where to find it

• Audit log view: SG-Admin → Activity → Audit log
• Export: SG-Admin → Activity → Audit log → Export (top-right button) — CSV for the selected date range and filter set
• Per-user activity: SG-Admin → Users → [user name] → Activity tab
• Per-content activity: History link on each page, post, or product detail view
• Portfolio view: SG-Dashboard → Activity — aggregates across every site with a site-pick filter
• Search shortcut: Press / from the audit log page to jump to the search box
• Saved views: Save a filter combination for habitual reads — appears in a dropdown above the filter row

What gets logged

Every meaningful action is recorded as one audit entry. Each entry includes: timestamp, actor (user account or system), action, target, IP address, and outcome (success / blocked / failed).

What is NOT logged: page views by anonymous visitors, public-site search queries, individual keystrokes inside a draft (only the publish event is logged). The audit log is about access control and meaningful state changes, not analytics or editor telemetry.

Reading the six fields. Every entry, regardless of category, carries the same six fields. Knowing what each one tells you is what turns a wall of rows into a fast scan:

Read across the row, not down a single column. A new IP on its own means little; a new IP plus an off-hours time plus a role-change action is the pattern worth stopping on.

Routine review cadence

The cadence below suits a small-to-mid team on a single SGEN site. For multi-site portfolios or higher-risk profiles, increase frequency or add a security team pass on top.

The daily 5-minute scan is the highest-value habit. Most credential-compromise attempts surface as a cluster of failed logins within the first 24 hours.

What anomalous looks like

The signal is the pattern, not the single event. A failed login alone is meaningless; five failed logins followed by a success from a new IP is a credential-compromise signature.

Worth investigating:

• A login from a new geographic location for an admin user (especially Platform Admin)
• Multiple failed logins followed by a successful one — possible credential compromise
• Off-hours admin actions from a country where your team does not work
• Role escalation you did not approve, especially to Platform Admin
• Settings changes by someone who should not have that access
• Mass content deletes — more than 10 items in a short window
• Integration added or webhook URL changed without your authorisation
• A burst of activity from a single user that does not match their normal pattern
• SSO logins from users you do not recognise

Probably fine:

• A failed login here and there from team members — typos happen
• Settings changes by users with the right role doing their job
• New IPs when team members travel or work from home
• Bulk publishes during a scheduled content campaign
• Backup events on the regular schedule

When in doubt, ask the actor. Most anomalies resolve in a 30-second message. The cost of asking is low; the cost of missing a genuine incident is high.

When you are mid-scan and need to decide fast, the triage table below maps the entry you are looking at to the next move. It is the same signal-vs-noise judgement compressed into a lookup.

How to respond when something looks off

For most anomalies, step 1 and step 2 resolve the situation in under a minute.

1. Do not panic. Most anomalies have benign explanations — a colleague travelling, a contractor finishing late, a script you forgot you scheduled.
2. Ask the actor. "Hey, I see you did X at 11pm on Tuesday — was that you?" Wait for the response.
3. If they confirm: Note it in your weekly review log. No further action.
4. If they say no: Treat as a likely account compromise. Immediately disable the account from the Users list, force a password reset, and audit every action taken under that identity in the past 48 hours. If the actor had admin privileges, also rotate any API tokens or webhook secrets accessible from that account.
5. If the actor does not exist or does not respond within your incident window: Escalate to your security lead. Disable the account, preserve the audit entries, and document the escalation.
6. Document everything. Even routine "I asked, it was them" findings deserve a brief note. Patterns of false alarms sometimes reveal real signal in aggregate, and contemporaneous notes are your evidence if you ever have to defend an incident response decision.

The fast version of those steps: ask, then branch.

• Actor confirms → log it, done.
• Actor denies → disable, reset, audit 48 hours, rotate secrets if they had admin reach.
• Actor cannot be reached inside your incident window → treat as denial and escalate.

The single judgement call is your incident window — the time you will wait for a reply before acting as if the answer was "no." Set it once, in advance, and write it into the response path from Before you start. A common choice for a small team is one business hour during working hours and "act immediately" overnight, but the right window depends on your risk profile and team size. Whatever you pick, the value is that the decision is made before the pressure of a live incident, not during it.

How to run the audit log review workflow

The steps below are the routine review cadence in practice. Run the daily scan every working day; the weekly and monthly reviews on a fixed calendar slot.

Steps

1. Open the audit log

Navigate to SG-Admin → Activity → Audit log. The default view shows the past 24 hours, all categories, all actors, all sites (for multi-site portfolios). Use the filter row at the top to narrow.

2. Filter to the period and category you are reviewing

Daily scan: keep the default 24-hour window, filter to Authentication → Failed. This is the highest-value view.

Weekly review: change the date range to the past 7 days, filter to User management and Admin actions. Review every entry.

Monthly sweep: change to the past 30 days, review all categories. Use the search box to spot-check specific actors or targets.

3. Scan for the patterns described above

Look for the "worth investigating" patterns. For each entry that looks off, click it to open the detail view — this shows the full IP, user agent, session ID, and (for settings changes) the before/after values.

4. Investigate flagged entries

Contact the actor through your team chat. Verify the action was theirs. If yes, note the verification in your review log. If no — or if you cannot reach the actor within your incident window — escalate per the response steps above.

Investigate one entry at a time and resolve it before moving to the next. Batching "I'll ask about all of these later" is how a real signal gets lost in a list of benign ones. If a single review surfaces several flagged entries, work the highest-risk category first: role changes and integration changes before failed logins.

5. Document the review

Even a clean review deserves a note: "Weekly audit review recently — all entries verified, no action required." A history of clean reviews is evidence the cadence was followed consistently, which matters for compliance audits. For incidents that required action, document the timeline, response steps, and resolution.

6. Export for retention if compliance requires it

For quarterly compliance reviews: open the export panel, set the date range to the previous quarter, and download the CSV. Archive it in your compliance evidence store (a private bucket, a compliance platform, or a shared folder — wherever your auditor expects to find it).

Do not share audit-log exports outside your team. Exports contain access patterns, IP addresses, and user identities — sensitive in aggregate even if no individual entry is.

Time the export to the retention window, not only the calendar. Business tier keeps 1 year and Enterprise keeps 7; if your compliance regime asks for longer, the export is how the record survives past the in-admin window. Run it before the oldest entries you need would age out, and store the file somewhere with its own retention policy. The export below is one quarter's worth — one row per event, in the same six-field shape you read on screen.

What success looks like

Three signals tell you the workflow is running correctly:

1. The daily scan is a five-minute habit. It happens every working day. If it keeps getting skipped, shorten it to nothing but failed logins until the habit holds.
2. Anomalies are caught within hours, not weeks. When you next investigate a real incident, check the gap between the event in the log and your response. Under 24 hours is healthy.
3. Your weekly review notes are continuous. Open the team ops doc and scroll back 3 months. You should see a weekly entry even if every one says "no action required." Gaps in the notes are the warning sign.

Three worked scenarios show the cadence resolving the situations it is built for. They run from the most common outcome (nothing to do) to the rarest (a genuine incident), because that is the real ratio: most reviews end with a one-line "no action required" note, and the value of the habit is that you are practised and ready on the day one does not.

Example 1: The clean daily scan. You filter to Authentication and Failed for the past 24 hours and see two failed logins from a team member's familiar IP, both followed by a success a minute later. Verdict: typos, no action. You add one line to the review log — "recently daily scan, 2 failed logins (typos), no action" — and close the tab. Elapsed time: under three minutes.

Example 2: The investigated anomaly. The weekly review surfaces a settings change to SEO defaults at 11:28 by a content editor. You open the entry (the detail panel above), see it sits inside a session that also touched the SEO title template and og:image default, all from a familiar IP during working hours. The pattern reads as one person doing planned SEO work. A 30-second message confirms it. You note the verification and move on.

Example 3: The genuine incident. A daily scan shows five failed logins followed by a success from an unfamiliar region, then a role change on another account minutes later. You disable the affected account from the Users list, force a password reset, terminate active sessions, and audit the prior 48 hours. The result panel below is what the response produced. You document the timeline the same day.

A trend like this is why the daily scan beats a monthly one: the day-12 spike is obvious against a baseline of one-to-four, and catching it that day rather than weeks later is the whole point of the cadence. A monthly review would still find the spike — but a month after it mattered.

Anti-patterns

• Ignoring the log because "nothing has ever happened." Routine review is how you stay ready for the day something does.
• Sharing exports outside your team. Treat them as confidential — share with auditors through your compliance platform, not email.
• Disabling audit logging. There is no production scenario where this is correct. Talk to your account rep about export strategies if retention volume is a concern.
• Acting on a single anomaly without asking the actor. Ask first; act second.
• Treating the audit log as an alerting system. It is a record. Add a SIEM or scheduled-export feed if you need active alerts.
• Running the cadence inconsistently. A cadence you follow beats a more ambitious one you abandon.
• Reviewing without notes. An undocumented review is indistinguishable from no review for compliance purposes.
• Not training a second person. The cadence breaks during leave. Rotate the review monthly between two Platform Admins.
• Exporting without a retention plan. A CSV in a personal downloads folder is not an evidence pack. Decide where exports live, and for how long, before the first quarterly export.
• Setting the incident window during the incident. Decide in advance how long you will wait for an actor to reply before acting. Made under pressure, that call is almost always wrong in one direction or the other.

Troubleshooting

The audit log shows entries from a system actor I do not recognise. System actors are the SGEN platform itself — automated backups, scheduled tasks, integration callbacks. They appear as system, cron, or an integration identifier (webhook:zapier, for example). If a name is unfamiliar, check the integrations list. If you cannot identify the integration, treat it as a flagged entry and investigate.

An entry I expected to see is not there. Common reasons: the action did not succeed; the date filter is narrower than the action window; the actor is filtered out; or the action was a sub-event logged differently (individual draft saves are not logged — only the publish event is). If you have ruled these out and the entry is genuinely missing, contact support with the date, time, actor, and action you expected.

An IP address shows a country my team is not in, for a legitimate user. Common for users on VPNs, mobile hotspots, or corporate proxies routing through a different region. Ask the user — usually "yes, I'm on the VPN." Note it in your review log. If the user denies a VPN and the IP is genuinely unexpected, treat as a possible compromise per the response steps.

The audit log is loading slowly or timing out. Large date ranges with no filter applied can be slow on Enterprise sites with high traffic and long retention. Narrow the date range or apply a category filter before loading. For a full quarterly export, use the Export button rather than scrolling the in-admin view. If even narrow filters are slow, contact support.

The export CSV has fewer rows than I expected. The export honours your current filter. Clear all filters first, then export to get the unfiltered audit log for the date range. If the row count is still lower than expected after clearing filters, recheck the date range — the export honours the range shown in the date filter.

A user is asking me to delete an audit entry about them. Audit log entries cannot be deleted from the admin, by design — that tamper-resistance is the entire value for compliance and incident response. If a user believes an entry incorrectly attributes an action to them, investigate per the response steps and add a clarifying note to your team ops log. For data subject requests under GDPR or similar regimes, contact your account rep for the specific compliance path.

Webhook events appear in the audit log but my webhook receiver did not get them. The audit log records that the webhook was fired by SGEN, not that it was successfully received. Delivery failures are recorded under the integration's own log, not the platform audit log. Open the integration's detail view to see delivery status, retry history, and response codes.

The same event shows up twice. Some actions cross two recorded boundaries — a content publish from the inline editor can trigger both a publish event and a status-change event on the underlying object. Inspect the action column and timestamps. If they are genuinely identical with no plausible reason for the duplicate, contact support.

I manage several sites and cannot tell which one an entry belongs to. The per-site audit log shows only that site's events. To review across a portfolio, use the SG-Dashboard Activity view, which aggregates every site and adds a site column plus a site-pick filter. Filter to one site to match what its per-site log shows, or leave it open to scan the whole portfolio in one pass. If a familiar action is missing from a site's own log but present in the aggregate, confirm you are looking at the right site.

An actor shows as a role I did not expect for that action. The role recorded is the actor's role at the time of the action, not their current role. If someone's role changed between the action and your review, the audit entry preserves the historical role — which is correct for an evidence trail. Cross-reference the role-change entry to see when and by whom the change was made.

Related

• _workflows/role-onboarding/for-platform-admin.md — onboarding checklist for new Platform Admins; audit log review cadence is part of it
• _workflows/best-practices/security-hardening.md — broader security checklist; routine audit review is one item
• _workflows/best-practices/two-factor-and-sso.md — 2FA and SSO events appear in the audit log; use the cadence to confirm rollout health
• _workflows/lifecycle/backup-and-restore.md — post-restore audit review pattern
• platformyour admin area — users list shows current access state; audit log shows how it got there
• platformyour admin area — integration changes in the log; integration detail view shows delivery status
• glossary/index.md — actor, target, outcome, retention window, break-glass account, evidence pack