Incident detection and the permanent working group (clause 30)

Requirement. The bank implements monitoring systems to obtain information about information-security incidents; a permanent operating working group is established to monitor these systems and resolve incidents as they arise.

The real challenge here is not collecting events but keeping the working group from drowning in a flood of disconnected alerts. Traditional threshold-based monitoring generates thousands of signals, and the critical one gets lost among them. 
Dynatrace relies on its built-in Davis AI engine, which does more than just collect telemetry: it automatically establishes cause-and-effect relationships, joins related signals into a single problem, and prioritizes problems by business impact. Instead of an alert storm, the working group receives a limited set of well-founded problem cards with the root cause and blast radius already identified — around the clock, in real time. This provides the operational foundation for the permanent working group the regulation requires. 

Incident evidence: integrity of logs and backups (clause 32)

Requirement. Incident information is documented by the Service; upon detecting an incident, the Service uses data from informational security monitoring systems and preserves the electronic logs of information systems and the backup copies (backup, snapshot, etc.) of the affected servers as of the moment of the incident, ensuring their integrity.

The Dynatrace Grail data store retains logs, traces, metrics, and events in a single space that can be investigated using the DQL query language. This makes it possible to reconstruct a complete chronology of events leading up to and during the incident, and to provide the regulator and CERT-CBU not merely proof of an outage but a detailed picture of what happened and why. The integrity of this evidence base is maintained through retention policies and access controls.

Boundary. Creating snapshots and backups of the servers themselves (virtual-machine images) is a task for backup systems. Dynatrace preserves the telemetry evidence trail — logs, traces, metrics, and events — which complements server backups and adds context during an investigation. 

Auditing user activity: logs, traces, and RUM (clause 43)

Requirement. The date (day/month/year) and time (hour/minute/second) of each operation are recorded, along with the user identifier in systems and applications, the device's identification data (IP address, MAC address, device name, and other identifiers), and all user operations and actions during the active session — in the corresponding electronic logs. Records may be changed or deleted only by Service employees authorized by order of the Chairman of the Board.

This requirement is addressed by three complementary layers of Dynatrace telemetry. Logs capture structured events with their attributes (timestamps, identifiers). Distributed traces (PurePath) follow every transaction across all components with full request and user context. Real User Monitoring (RUM) captures user actions at the session level, including device type, IP address, and geolocation, and — where needed — session replay. Together they produce the “electronic log” of actions that the regulation requires.

Boundary. Capturing the MAC address and the authorized-only record modification principle are implemented at the telemetry-source and access-model levels: records in Grail are governed by IAM role-based policies, retention periods and immutability are set by the data store's configuration. Individual attribute completeness (for example, the MAC address) depends on the telemetry sources providing them. 

Database activity monitoring (clause 53)

Requirement. The bank implements a Database Activity Monitoring (DAM) system to promptly detect and prevent suspicious activity in real time.

Dynatrace provides deep database observability: monitoring at the level of individual SQL statements through distributed tracing, health and performance monitoring of the DBMS through extensions for Oracle, Microsoft SQL Server, PostgreSQL, and MySQL (including the collection of audit logs and blocked-session data), and real-time anomaly detection by Davis — such as an abnormal increase in query volume or server load. Events from a dedicated DAM solution also can be forwarded to Dynatrace for correlation within a single analytical layer.

Boundary. DAM is a distinct class of security tools, and Dynatrace complements rather than replaces it. In particular, Dynatrace associates a SQL statement with the originating service or application user action, but it does not identify the specific database user at the level of an individual statement. The recommended model is a pairing of a dedicated DAM as the security control with Dynatrace as the observability and business-impact correlation layer. 

The health of network devices and security appliances (clause 67)

Requirement. Monitoring is maintained over the state of the software and hardware used to ensure network security; statistical data is collected and analyzed; emerging problems are detected early; and preventing emergency situations as a result.

Dynatrace extends unified observability to network infrastructure through SNMP extensions: Generic Network Device, Generic Cisco Device, Juniper (SNMP), F5 BIG-IP, Fortinet FortiGate, and others. The SNMP Traps extension provides event-based alerting (link down, overheating, component failure), while autodiscovery mechanisms (SNMP Autodiscovery, Discovery & Coverage) find devices on the network and apply the appropriate extension. Davis detects anomalies in interface metrics — errors, packet discards, utilization — at an early stage, before they escalate into an incident. All of this data is consolidated on a single platform alongside application and infrastructure telemetry.

Boundary. Dynatrace is not a full-fledged NPM/NDR system. The platform provides the status, performance, and statistical metrics of network devices and security appliances, as well as SNMP-trap alerting, complementing dedicated network tools without replacing deep traffic analysis. 

Application security at runtime (clauses 156, 164, 79)

Requirement. Regular scanning and remediation of vulnerabilities using CVE databases, scoring by CVSS, installation of updates (patches), and reporting to management (clause 156); checking for vulnerabilities before a system goes into production (clause 164); and protecting internet-facing services with IDS/IPS, WAF, and Anti-DDoS (clause 79).

Dynatrace Application Security addresses the application layer of these requirements through two modules. Runtime Vulnerability Analytics continuously detects vulnerabilities in third-party libraries, runtimes, and custom code, matching them against CVE databases (the NVD and Dynatrace's own feed) and CVSS v3/v4 scores. The Davis Security Score adds runtime context — public-internet exposure and the reachability of the vulnerable code — which separates genuinely critical vulnerabilities from theoretical ones, while Davis Security Advisor recommends priority patches and integrates with ticketing systems. This directly addresses clauses 156 and 164, including in the pre-production stage.

Runtime Application Protection provides safeguarding at runtime (the RASP approach): in real time it detects and blocks application-layer attacks, such as SQL injection, command injection, JNDI injection (the Log4Shell vector), and path traversal. Both modules run on the same OneAgent used for performance monitoring, with no separate agents or network appliances.

Boundary. Runtime Application Protection complements the network WAF and Anti-DDoS required by clause 79 but does not replace them: protection against volumetric DDoS attacks and traffic filtering at the network perimeter remain the job of dedicated tools. Source-code analysis at the build stage — the SAST/DAST of clause 163 — is also outside the platform's scope and requires a separate tool in the CI/CD pipeline. The separate requirements for guest Wi-Fi zones (clause 84) apply to physical and network controls and are not within the scope of the observability platform. 

Conclusion

Regulation No. 19/1 of the Central Bank of Uzbekistan is a systemic shift in how the regulator measures a bank's maturity in cybersecurity. Requirements for continuous monitoring, rapid response, process transparency, and a documented evidence base are creating a new operational reality for CIOs, CISOs, and CTOs.

As a unified observability and security platform, Dynatrace covers a significant portion of the regulation's technical requirements — incident detection (clause 30), the evidentiary integrity of telemetry (clause 32), user activity auditing (clause 43), the health of network devices (clause 67), and application security at runtime (clauses 156, 164, and 79) — and substantially strengthens database activity monitoring (clause 53). 
With an honest understanding of the boundaries: dedicated DAM solutions, network NPM/NDR, WAF and Anti-DDoS, and SAST/DAST remain standalone tools that Dynatrace unifies through a single analytical layer and business-impact correlation. The result for the bank: fewer incidents, faster response times, change control, and a real evidence base for the regulator and CERT-CBU.

BAKOTECH, as the official Dynatrace distributor in Uzbekistan, is ready to help banks navigate the path from assessing their current state to full platform deployment — a globally proven solution backed by local expertise.