Trace a change from its request to its recorded outcome.

1. Prepare investigation access and the change reference

Start with the request created in Request and approve a change. Record the approximate time, requester, connector instance, policy context, rule, and change-request reference. Use a separate authorized investigator: the Linux requester and Security reviewer in that pilot have no app role, and participation does not grant deployment-wide audit access.

• audit:view allows reading audit events for this Naradox deployment.
• audit:export separately allows creating and downloading audit exports.
• audit:verify separately allows a full audit-integrity verification.

The standard Audit operator role supplies all three. Assign it only to an investigator who needs that deployment-wide responsibility. Team rule access does not narrow the audit inventory to that team. Audit rights also do not grant general Jobs access, firewall editing, or traffic-log access. See Access and permissionsfor the surrounding access model.

2. Find the relevant events in Platform > Events

1. Open Platform > Events and use Recent events.
2. Choose a time preset such as Last hour, or set From and To around the pilot. The date/time controls display local time; retain the time zone when sharing an investigation window.
3. Choose Changes and, when useful, select Check Point under Area. These filters help locate rule and object requests and approval decisions.
4. Inspect the matching rows, open View on a candidate event, and compare its rule, instance, and recorded change reference with the pilot.

Use action or actor text of at least two characters to narrow the list. The actor filter searches the recorded actor identifier; a displayed name or email is not a general directory search. Typed action text matches part of an action name. Comma-separated actions and quick-filter selections use exact action names. The action's tooltip exposes that technical name.

Filter by target type and Filter by target match the recorded type and identifier exactly. Copy those values from an event's details when needed; a friendly rule name is not a substitute for its identifier. These fields also require at least two characters in the browser.

Filters combine, so remove a narrow actor or target filter before following other participants. Use the pagination controls to read further. Refresh advances a relative preset to the current time; a custom window stays fixed. Ordinary audit-view events are hidden by default. Use Include view events when they matter to the investigation.

3. Read what the event actually confirms

Read Action, Signal, and Summary together. In the detail drawer, retain the Event ID and inspect Important details. Expand Raw details for the available change, job, target, and request identifiers. An event ID identifies one audit record; it is distinct from an HTTP request ID or a change-request reference.

• Queued confirms admission to background work. It does not confirm that Check Point accepted or published a change.
• A successful approval event confirms that a vote or decision was recorded. Read whether more votes are needed or application was queued. A successfully recorded rejection can also have a success outcome.
• No change means that the recorded operation left its target unchanged. It is not proof of a new modification.
• Failed, a denied action, and Reconciliation required describe different outcomes. Read the recorded reason; an ambiguous vendor result must not be treated as success or automatically repeated.

The actor describes the identity recorded for that event. Background work can have a system actor, while its details identify the original request. Historical names come from recorded identity snapshots where available; later account renaming does not relabel those events. Older records without that information may show only an identifier.

4. Follow the request through application and installation

Match the recorded change reference to the change request, then follow its application job reference where available. Clear Changes, the actor filter, and any restrictive Area or target filter when investigating job lifecycle events: the job has its own target and can be recorded by a different actor.

Build a short sequence: request submitted, required decisions recorded, application admitted, and terminal application outcome. Read the current request and recorded result using the change workflow. If additional job inspection requires authority you do not have, give the exact reference to an authorized operator. Audit access alone does not open every job.

For the comment-only pilot, successful application establishes the management change. Policy installation has a separate result when required. Neither a recorded approval nor an installation request proves successful deployment to a gateway. Record any unresolved stage instead of turning a missing completion event into an assumed success.

Keep each evidence source in context. Rulebase history helps compare saved configuration and inspect vendor-reported publications. Logs and Watchlist describe available traffic evidence. A Naradox audit event is not a traffic record or a complete inventory of changes made outside Naradox. The same investigation method applies to managed object changes.

Preserve a signed export when evidence must be retained

1. Set an explicit investigation window and review all current filters. Include related job events if the evidence needs to cover execution.
2. Choose Export, check Current selection, and choose Start export.
3. Wait for the export to succeed, then choose Download signed export. The ZIP contains the NDJSON event data and its signed JSON manifest.
4. Save the original ZIP in your organization's controlled evidence storage. Download it promptly: generated export artifacts have a 24-hour lifetime.

Enqueued period and Enqueued filters identify the selection actually submitted. Changing the page filters later does not change that running export. Start another export for a different selection. The manifest records the applied filters and row count; an export is not limited to the current table page.

Export completion means that an artifact was produced. Damaged source records can still be exported for investigation. Its signed source_integrity result covers only the exported rows and must be checked separately; a filtered archive cannot establish completeness of the deployment's entire history.

Have the installation operator verify the archive with the bundled scripts/verify_audit_export.py helper and the matching signing-key environment. From the release directory, the command is python3 scripts/verify_audit_export.py --bundle /path/to/audits.signed.zip. Keep the report alongside the original archive. Overall verification requires both a valid artifact and a verified source attestation; possession of a downloadable ZIP is insufficient.

Check audit integrity for an investigation

With audit:verify, use Verify now under Audit integrity on Events. Platform managers find that action under Platform > Settings > Logging > Audit integrity & retention. Wait for the background check and refreshed status. If status polling fails, use its retry action to continue following the same verification.

Verified reports a completed check without detected integrity findings; read Last checked as well. Waiting for automatic verificationis not a completed verdict. Needs attention requires investigation: run a fresh check if authorized and involve the operator if it persists. A loading error leaves the status unknown.

Manual verification and the daily automatic verification examine the retained deployment-wide chain. Quick logging diagnostics examine a bounded recent window and current head. After retention removes older events, verification covers the retained segment and its signed boundary; it does not recreate deleted evidence.

Naradox's signed chain is tamper-evident, not immutable storage. A complete rollback to an older consistent database, or compromise of both data and signing keys, needs comparison with separately retained evidence. Preserve verified exports or downstream history outside the installation when your investigation requires that assurance.

Keep retention and external delivery separate from an event search

Platform managers review the saved retention period under Settings > Logging > Audit integrity & retention. Keep indefinitely is the default. A finite period enables cleanup, so export and verify required evidence before shortening it. An investigation does not require changing retention.

If an event exists in Naradox but is missing from your SIEM, investigate delivery separately. The operator can inspect Audit delivery under Advanced & troubleshooting. A destination test or successful HTTP acceptance does not prove downstream parsing and indexing. Confirm the event in the destination using its identifier; forwarded audit events can be delivered more than once. Follow Platform operations for destination setup, testing, and delivery recovery.

Resolve missing evidence without assuming an outcome

• No Events access or empty preview: confirm current audit permissions. Export or verification authority alone does not grant the event preview.
• No matching events: check time bounds, combined filters, exact target identifiers, pagination, and retention. Retry an explicit loading error before interpreting the list as empty.
• Request found, completion missing: remove actor and quick filters, follow the recorded job reference, and ask the operator to investigate the current result before repeating a write.
• Export or verification failed: retain its reference and displayed error. For support, include the event ID, available Request ID, time window, and safe change/job references using the support checklist.