Audit Logs

Scope

How to review Portal’s audit log: work anomaly alerts, filter and export records, check log integrity and understand retention.

What the audit log is for

Portal records every administrative action in your tenant: who did it, what changed, when, from where, and whether it succeeded. Use the audit log to answer questions such as “who gave this person that role?”, “who exported our user list?”, “which support engineer looked at our directory?”, and “has anyone tampered with the record?”.

The log is append-only. Nobody, including Cadres, can edit or delete a record inside your retention window. Each record is chained to the one before it, so Portal can prove the sequence has not been altered.

Who can see it

Audit review needs the View audit logs permission. The built-in Super user and Admin roles have it. Changing anomaly thresholds also needs Manage anomaly thresholds, which Admin and Super user hold.

Everything you see is scoped to your current tenant. A banner at the top of the page names that scope. Cadres support staff see your audit log only inside an approved support-access session, and every one of their reads is itself recorded in your log.

Open the audit log

Open Monitoring, then Audit Logs. The page has five tabs:

Tab	Use it for
Review	Search, read and export records. Open anomaly alerts appear at the top.
Point-in-Time Access	Reconstruct what one person could do on a past date.
Sign-ins	Successful, failed and blocked sign-in attempts for your people.
Anomaly rules	See and tune the thresholds that raise alerts.
Streams	Push records to your SIEM or log collector. Shown when you can manage webhooks.

Start with open anomaly alerts

Portal watches the audit stream for bursts that usually mean something is wrong. When a rule trips, an alert opens at the top of the Review tab and everyone with audit access gets a notification in the bell: red for a critical rule, amber otherwise. One alert raises one notification, so a burst that keeps extending an open alert does not flood the bell.

Each alert shows the rule, its severity, the observed count against the threshold, the rolling window, and whether the alert was also sent to your webhooks.

• Review matching rows filters the table to the person, action or IP address that produced the alert.

• Acknowledge closes the alert. Do this after you have recorded what you found and what you did. The acknowledgement is itself an audit record naming who closed it.

• The delivery status next to the alert says whether it also went to your Webhooks subscriptions. Enqueued means it will be delivered. Failed means the alert is open in Portal but could not be queued; check the Webhooks page. Not attempted or skipped means no delivery was tried, for example because the alert opened during a recovery path.

The rules Portal ships, with their default thresholds:

Rule	What it counts	Window	Default	Severity
Rapid failure burst	Failed or denied actions by one person (or one IP address)	1 hour	25	Warning
Privilege escalation burst	Role assignments by one person	24 hours	100	Critical
Mass destructive operations	Deactivations, deletions and removals by one person	1 hour	20	Critical
Audit surface probe	Audit reads and exports by one person	1 hour	20	Warning
Operator read burst	Reads of your directory by one Cadres support credential	1 hour	200	Warning
Support access request flood	Support-access requests	1 hour	15	Critical
Secret disclosure burst	Vault secret reveals and check-outs by one person	1 hour	15	Critical
Support access approval burst	Support-access approvals by one person	1 hour	15	Warning

Alerts are raised per tenant. Platform-wide records that belong to no tenant never raise alerts in your tenant.

Tune the thresholds

Open the Anomaly rules tab. Each row shows the rule, its severity, its window, the shipped default and the value in force for your tenant.

1. Enter a whole number from 1 to 100,000 and select Save.
2. Select Reset to default to remove your override.

A new threshold applies to the next matching event. Alerts that are already open are not re-evaluated.

Search the log

Use the filters above the table, then select Apply filters. Select More filters for the full set.

Filter	What it does
Affected person	Records about this person: changes to their account, memberships and access.
Performed by	Records where this person did the action, including approved support-access activity.
Keyword	Free text across the action name, resource, IP address, request ID, actor name and email, and the recorded details.
Action	One exact action code, for example user.updated.
Resource type and Resource ID	The history of one object, for example one group.
Start date and End date	Narrow the window. Use one for any investigation; do not page through the whole log.

Two presets sit above the table:

• Operator reads shows every read of your tenant’s data by Cadres support in the last 7 days. See See who read your directory.

• Risky sign-ins shows sign-ins that Portal scored as moderate, high or critical risk in the last 7 days.

Results are paged from the server. Use Previous and Next; the first page is never the whole result.

Every audit-log read and export is itself recorded, so you can later prove who looked at the evidence and when.

Read a record

Select Review on a row to see the full record: who did it (a person, a SCIM connector, a service client, an external system, or Portal itself), what changed, the outcome, the resource, the network address, the request ID and the integrity state of that row.

Email addresses inside the recorded details are shown as a short fingerprint plus the domain. Portal keeps the domain so you can correlate, and hides the local part because search terms and details can carry personal data.

The request ID appears in Portal’s application logs as well. Quote it when you open a support case about an event.

Check the log has not been tampered with

A banner above the table reports the integrity of your tenant’s chain. Read it before you rely on any row as evidence, and check that the row’s own Integrity badge agrees.

Banner or badge	Meaning	What to do
Audit chain verified clean (green)	The most recent check passed. Rows up to the stated boundary are certified.	Use the rows as evidence.
Last clean check is stale (yellow)	The last clean check is older than two hours.	Select Verify now.
Pending next check (yellow)	The row is chained but newer than the last check.	Check again after the next scheduled scan, or select Verify now.
Not yet checked (yellow)	No check has run for this chain yet.	Select Verify now.
Pre-immutability row (grey)	The row predates chaining.	Treat it as advisory. It cannot be proven unaltered.
Integrity check found violations (red)	The chain does not verify.	Do not use the log as evidence. Treat it as a security incident and contact Cadres support.
Latest integrity check failed to complete (red)	The check itself errored.	Select Verify now once. If it fails again, contact Cadres support.

Portal checks every tenant’s chain once an hour by default. Verify now runs the same check immediately for your tenant and records that you asked for it.

Export records

• Export CSV downloads the rows that match your current filters. Use it for bulk review outside Portal.

• Download signed export downloads the same rows plus a manifest that carries the query, the signing key, and a hash of the file. Use this when the export leaves Portal or goes into a compliance package.

• Verify signed export takes a manifest, and optionally the CSV, and confirms that the file is byte for byte what Portal issued for your tenant. The result names the tenant and the signing key. Verification of someone else’s tenant fails and is recorded.

If a signed export or verification reports that the signing key is unavailable, Portal’s signing key has not been set up on your deployment. Contact Cadres support; the plain CSV export still works.

Exports are rate limited: 20 CSV exports and 10 signed exports a minute. If you hit the limit, wait a minute and retry.

Scheduled signed evidence

Instead of remembering to export every month, pin your current filters into a schedule and Portal produces a signed export for each closed period.

1. Set the filters you want repeated. The date range and paging are ignored; the schedule works out each period itself.

2. Under Scheduled signed evidence, enter a name, choose Daily, Weekly (Mon-Sun) or Monthly, and set the time of day in UTC.

3. Select Create schedule. It appears under Active schedules with its next run time.

Generated evidence lists each run, newest first, with the period, row count and status. A completed run has a Download action that saves the CSV and its manifest. They verify with Verify signed export exactly like a manual signed export.

A failed run shows the reason. Common causes are a filter that produces more rows than one export allows, and a signing key that is not set up. Other schedules keep running when one fails.

• Disabled pauses a schedule until you enable it again.
• Delete removes it from the active list. Evidence already generated stays downloadable.

Support staff acting under support access can view schedules and download evidence but cannot create, pause or delete them. Schedules always belong to a member of your tenant so the recurring decision is attributed to you.

See who read your directory

Cadres support can read your tenant’s data through the operator console only under an approved support relationship, and every read is recorded.

1. Open Audit Logs and select Operator reads. Widen the date range for an older incident.

2. Each row answers four questions: who (the support engineer’s email and the credential used), what (the kind of object and the screen or endpoint), how much (the number of items returned), and when.

3. Portal does not record what the engineer searched for, or anything it returned. Only the names of the query parameters are kept, because search terms can carry personal data.

One row is one request. A read that returned 100 users is one row with a result count of 100, so look at the count to spot a sweep. The Operator read burst rule opens an alert when one support credential crosses 200 reads in an hour; tune it under Anomaly rules.

Sign-in attempts

The Sign-ins tab lists every sign-in attempt for people in your tenant: password, passkey, password reset, invitation acceptance, guest and trial sign-up, and break-glass access. Filter by person, method, result and date.

• Blocked: too many attempts means Portal’s rate limit stopped the attempt.

• Breached password blocked means the password appears in a known breach list and was refused.

• Failed rows clustered on one person, or one IP address across many people, usually mean a credential-stuffing or brute-force attempt. Suspend the account if needed and contact Cadres support.

Select See this person’s sign-in attempts from any audit record to jump here with that person selected.

Point-in-time access

The Point-in-Time Access tab answers “what could this person do on that date?”. Choose a person and a past instant. Portal lists the permissions they held, the roles and groups that granted them, and whether they were a super user at that time.

Read the limitations shown with the answer. Access through a group that was later deleted cannot be reconstructed, and when Portal cannot determine super-user status for that instant it says unknown. An empty permission list marked unknown is never proof of no access.

Every reconstruction is recorded in the audit log.

Stream records to your SIEM

The Streams tab pushes each new record to a receiver you run. It needs the Manage webhooks permission as well as audit access.

Add a generic web stream

1. Select Add stream target and choose the generic receiver type. It is the first option in the target type list.

2. Enter a name and the receiver address. It must be a secure (TLS) address on a public host.

3. Leave the signature mode at its default unless your receiver only accepts the newer signature format.

4. Submit. Portal shows the signing secret once. Copy it into your receiver so it can verify the signature header on each delivery. It cannot be shown again.

5. Select Send test delivery. The result appears on the row and is recorded in the audit log.

Add a Splunk HEC stream

1. In Splunk, create an Event Collector token with the index and sourcetype you want.

2. Select Add stream target and choose Splunk HEC. Enter a name, the collector URL, the token, and any optional sourcetype, source, index or host values.

3. Submit. The token is stored encrypted and never displayed again.

4. Select Send test delivery. Splunk should show the test event within a few seconds.

Check, rotate and pause

• Do any audited action and confirm it reaches the receiver within about 30 seconds. Each event carries the time the record was written.

• Rotate secret issues a new signing secret for a generic web stream and shows it once. Rotate token takes a replacement Splunk token.

• Deactivate stops deliveries but keeps the stream and its delivery history so you can still prove what was sent. Reactivate it when the receiver is back.

When deliveries fail

Portal retries failed deliveries. If the receiver stays down, the events land in the dead-letter queue on the Webhooks page. Once the receiver is healthy, open the queue, inspect the payload, and select Replay. Payloads never contain your secret or token.

Platform-level records outside your tenant are never streamed. A lost secret or token cannot be recovered; rotate it.

Retention

• Records stay visible in Portal and in exports for your tenant’s retention window. The window can be set between 30 days and 10 years for your tenant. Ask Cadres support to change it.

• After the visibility window, records are hidden but not yet destroyed. They are physically deleted after the deployment’s hard-delete window, 2 years by default. A tenant window never shortens that.

• Records of support-staff reads are kept for 90 days by default, then deleted. They count as access evidence and sit outside the tamper-proof chain.

• Portal cannot erase individual records or fields inside the retained log. Doing so would break the chain. For a privacy request, deactivate the person and remove their access; their historical audit records remain until the retention window ends.

• Each retention run leaves its own audit record, so you can show an auditor when evaluation and deletion happened.

• A legal hold placed by Cadres at your request suspends deletion for the records it covers without changing anything else.

Support access and your log

Cadres support cannot browse your audit log from their own console. They must request support access, have it approved, and then work inside your tenant. Everything they do there, including audit reads and exports, appears in your log with the support-access request attached, so you can review it afterwards by filtering Performed by to the engineer or the action to the support-access events.

When something looks wrong

Symptom	Likely cause	What to do
No results	Wrong tenant or date window	Check the scope banner and widen the dates.
A row has no actor name	The person has since been removed from the directory	The record is still valid; the ID remains.
An event is missing from search and export	It is older than your retention window	Records past the window are hidden. Ask Cadres support if you need to confirm one exists.
Integrity banner is yellow	The scheduled check has not run recently	Select Verify now.
Integrity banner is red	The chain failed or the check errored	Retry once for an error. For a violation, stop using the log as evidence and contact Cadres support.
Signed export fails with a key error	The deployment’s signing key is not set up	Contact Cadres support. Use plain CSV meanwhile.
A scheduled run failed	Filter too broad, or signing key not set up	Narrow the filters or contact support; the next run retries.
Stream test fails	Receiver unreachable, wrong URL, or a private address	Fix the receiver and test again. Portal rejects private and local addresses.