Development of a user action audit module for 1C-Bitrix

User Action Audit: Where Logging Breaks in Bitrix

The standard Bitrix event log records the fact: module, operation type, time, user ID. But when prices in the catalog go haywire in production or a group loses its permissions, this set is not enough. The log shows that someone changed an infoblock element — and that's it.

What exactly was in the field before the edit, what other entities the same session touched, whether the request came from the interface or via the API — the log stays silent.

Incident investigation turns into archaeology: we cross-reference web server logs, version history, and witness accounts.

A separate pain point is settings.

Changes to discount rules, cart parameters, the access permission scheme, or payment system binding do not always leave a clear trace of changes: some operations are logged impersonally, others only at the moment of application, without intermediate states.

Answering the question "who changed the settings and when" after the fact is often impossible, which means it is also impossible to prove that the regression came from outside rather than from a release.

The cost of such a gap is measurable. An incident with prices on a marketplace or with permissions to a restricted section takes days to investigate, and all that time the business process is stalled or running incorrectly.

When personal data is involved, the absence of a traceable record of changes is also a direct regulatory risk: an auditor will ask who opened a customer's profile and why, and there will be nothing to show.

We break down how this is closed: how to extend user action auditing so that the log answers "who, when, what was before and what came after" — without rewriting the core and without losing performance on high-load projects.

What a managed audit delivers: effect in measurable terms

Incident investigation speed

When the log records who changed what and when, investigation stops being archaeology. Instead of interviewing employees and reconciling backups, an engineer opens the log, filters by object, and sees the chain: panel login, property edit, publication.

The time to investigate a typical incident drops from hours to minutes — the question "who broke the page" is closed by fact, not by guesswork.

Share of recoverable changes

The audit stores not only the fact of an edit but also the previous value of the field: who replaced it and with what. This enables a pinpoint rollback — restore a specific element without deploying the entire database backup.

The share of changes that are recovered without a full rollback grows to the majority of typical cases: content, prices, module settings.

Eliminated class of failures

A separate class of failures is a "silent" edit that bypasses the process: someone changed a template or a discount rule, and the site no longer works as intended.

With action traceability, this scenario stops being invisible: a deviation from the expected state is recorded and makes it into the report. This doesn't catch every error, but it removes an entire layer of failures that previously surfaced only at the client's end.

Access control as a consequence

When every action is tied to an account, permission separation becomes verifiable: you can see who has broader access than their role requires and who used it.

This reduces the risk of accidental and intentional edits by contractors and interns — access is granted on an as-needed basis, not "just in case."

Traceability for the external perimeter

If integrations with 1C or external services are connected to the project, the audit shows exactly what came in from outside and what went out.

When data diverges between systems, you can see at which step the exchange failed — and this, too, cuts investigation time down to a single query to the log.

Methods of logging actions: built-in journal, module, external collection

The standard event log covers the basic scenario: it records entry into the administrative panel, edits to infoblock elements, and changes to module settings.

This is enough to answer the question "who broke the page," but not "who exported the customer database." The retention depth is limited by the module settings, and some operations — working with orders, exports, calls to internal methods — do not make it into the log at all.

A custom audit module intercepts events at the core level and writes them to a separate table with its own indexes.

This gives control over the set of fields, the retention period, and access separation for the logs themselves, but it adds a database write for every action — under high administrator activity, the load on the system grows noticeably, and this needs to be factored into the architecture in advance.

External collection moves logging out of the production environment: events go to a separate storage where they can be kept for years and analyzed without risk to the main site.

The cost is an additional service that needs to be maintained, and a delay between an action and its appearance in the storage.

In practice, the approaches are combined: the standard journal is kept as a quick answer to current questions, the module covers sensitive operations, and external storage handles long-term history and incident investigation.

The choice is dictated by the retention depth, the acceptable load on the system, and which actions actually need to be visible.

How we implement the audit module: stages of work

We start with an audit of how action logging is currently set up: which events are already recorded by standard tools, what ends up only in web server logs, and which operations are not recorded at all.

At this stage, it is important to understand who performs which actions in the system and where the boundary lies between administrative and user scenarios — this determines the depth of the future module.

1. Audit of current logging. We compile a list of operations that need to be recorded: login and logout, editing content and settings, working with orders, changing access rights. We compare it with what is already being logged and note the blind spots.
2. Event schema. We design which event goes into which journal, which fields it carries (who, what, when, from where, previous and new value), and how long it is stored. We separately describe what to do with bulk operations so that the journal does not grow excessively.
3. Module configuration. We connect handlers to the required events, configure filters, permissions for viewing the journal and exporting. We delimit access so that an ordinary employee does not see others' actions, while an administrator sees everything.
4. Scenario testing. We run through real work situations: editing a page, changing an order status, changing roles, a failed login. We make sure that each action leaves a record with correct data.
5. Load testing. We observe how the journal behaves under peak activity and, if necessary, enable archiving of old records.
6. Handover of the regulation. We provide the team with instructions: how to read the journal, which events to consider suspicious, how to export data for investigation.
7. Support. After launch, we monitor the module's operation and adjust the logging rules if new scenarios appear.

This order yields a predictable result: the journal is filled with the necessary events, does not slow down the system, and remains readable for those who will work with it.

What remains with you after implementation: configurations and regulations

After implementing the user action audit module, you are left not only with a working tool, but also with a complete set of artifacts that allow the system to be developed, handed over to new administrators, and pass inspections without haste. Below is what exactly is documented in the documentation and settings.

• Module configuration — a working set of rules: which events are logged, the log retention depth, the list of objects under monitoring, and notification trigger thresholds.
• Event schema — a map: which user action generates which record, where it is stored, and how it relates to a system object. With it, a new engineer gets up to speed in an hour, not a week.
• Access policies — which employees can view the log, who can export data, and who configures the rules. Role separation is documented in writing.
• Audit documentation — a description of the module's logic, instructions for administrators, the procedure for handling incidents, and report templates for management.
• Review regulation — a step-by-step scenario: who responds to a suspicious event and within what timeframe, how the verification result is recorded, and where the incident is escalated.
• Set of reports — ready-made exports on user actions, permission changes, and bulk data operations that can be reviewed regularly or on request.
• Maintenance guide — how to update the rules as headcount grows or processes change, so that the audit does not become outdated within six months.

All artifacts are delivered within your environment and are not tied to us as a contractor: configurations reside in the system, while schemas and regulations are in the documentation.

Describe your task — we will come back with an estimate and a plan for what will be included in the package specifically for your processes.

Case study: how user action auditing reduced incident investigation time

The client is a manufacturing holding company with a portal on 1C-Bitrix: a catalog, manager personal accounts, and integration with an accounting system.

Before the audit module was implemented, the action log was kept only at the core level — logins and critical errors were recorded, but it was impossible to determine which employee had changed a price, unpublished an item, or rewrote a product property.

Investigating a single incident took an average of two business days: a backup was restored, tables were compared manually, and employees were interviewed.

What was changed

We designed an audit module that writes every significant action to a separate storage: creation, modification, and deletion of infoblock elements, edits to users and access rights, order operations, and system login and logout.

For each record, the author, timestamp, object identifier, and a before/after snapshot of the changed fields are saved — this enables restoring changes without rolling back the entire database.

We also configured filters by sections and roles so the log would not grow excessively: technical exchange operations with the accounting system are written in summary form rather than line by line.

The retention policy is one year with automatic archiving; older periods are exported and do not slow down the interface.

Metrics before and after

• Incident investigation: previously ~2 business days of manual reconciliation — now 15-20 minutes using a query in the log.
• Share of recoverable changes: previously about 40% (only what was captured in the backup) — now 100% for actions covered by auditing.
• Disputed edits: before implementation, an average of 5-6 episodes per month where the author of a change could not be confirmed — after implementation, such situations are resolved with a reference to the log entry.

After six months of operation, the portal load did not increase: records are written asynchronously by a separate process and do not block the catalog's operation.

If you have a similar task, describe which actions need to be covered by auditing, and we will come back with an estimate and a plan.

How is an action audit different from backup?

These are different tasks, and confusing them means being left without answers at the moment of investigation.

Backup stores the state of the system at the moment the copy was taken: if an incident occurred between two copies, you will restore the data, but you will not know who changed it, when, or through which section of the administrative panel.

Audit and backup complement each other: the former answers the question "who did what," the latter — "how to return the system to a working state."

An audit records every significant action: logging into the control panel, editing an infoblock element, changing module settings, deleting a user, exporting data.

The record contains the author, time, object, and nature of the operation — from it, a complete picture of what happened is reconstructed, down to the sequence of steps taken by a specific employee.

A backup does not provide such detail: it is a snapshot without history, and from it you cannot tell whether a change was intentional or accidental.

The difference in approaches becomes apparent at the moment of incident investigation. If a content manager accidentally unpublishes a section, the backup will restore the page but will not explain the cause — and a week later the mistake will repeat.

The audit log will show who changed the status, at what time, and from which address — that is enough to adjust access rights or procedures. Reverting changes without understanding their source treats the symptom, not the cause.

A complete picture is achieved only through the combination: the log is responsible for transparency and investigation, backups — for recovery after a failure or an unsuccessful update.

We design both circuits together so that the client has both a history of actions and a rollback point. Describe your task — we will get back to you with an estimate and a plan.

Technical concerns about user action audit

User action audit raises a predictable set of objections from engineers: will the system slow down, will storage grow, will the module break when the core is updated, who will get access to the log. Below is an analysis of each from an engineering perspective.

Load and storage volume

Recording an event is a single insert into the log table, not a full page rebuild. With a reasonable index scheme and asynchronous writes, the overhead per user session stays within the statistical margin of error.

Volume grows linearly with the number of actions: if only significant events are written (login, entity change, permission change, export) rather than every cursor movement, the log remains compact over a year.

Old records are moved to archive on a schedule — the history depth is configured according to regulations, not "forever".

Compatibility and permissions

The module is installed as a separate extension and does not modify the core — platform and product updates proceed as usual, and integration points survive major branches.

Access to the log is granted through the standard permission model: the administrator sees everything, the department head — only their sections, the security service — access events and role changes. Every read of the log is also recorded, so that the audit does not turn into a blind spot.

What happens when the core or product is updated?

The extension is isolated from the core, so updates are installed as usual. Before a major update, we run a compatibility check on a copy — if an integration point has changed, we adapt the extension before rolling out to production.

Can the storage depth be limited?

Yes. The retention policy is set in the settings: a hot period in the main table, then archive or export. This way the log does not grow indefinitely, while the required history depth remains at hand.

Let's discuss the audit task: we'll come back with an estimate and a plan

To make the estimate accurate rather than an "average market" figure, we need to understand your configuration: which 1C-Bitrix edition the portal runs on, which modules have already been customized, where data on user actions is currently stored, and which events are critical to log first.

This determines the architecture of the user action audit module — whether we write our own core event handler or extend the standard journal, and how we organize storage and export.

On the call, we'll clarify the requirements and the scope of the task:

• which entities and admin panel sections should be covered by the audit — content, orders, access rights, module settings;
• which roles get access to the journal and whether differentiated visibility by department is needed;
• the retention depth for records and export requirements — compliance, internal audit, incident investigation;
• how the module fits into the current environment: a separate module, a core update, integration with an external system;
• the load on the portal and the acceptable impact on admin panel performance;
• implementation timelines and the handover procedure for the result — test environment, production, administrator training.

Based on the conversation, you'll receive an estimate and a plan: the module composition, the storage and role scheme, the work stages with checkpoints, and a list of what we hand over upon completion — source code, configuration, administrator instructions, and the journal handling policy.

Describe the task in any convenient format — we'll come back with an estimate, a plan, and a proposal for implementation timelines.