Ozon’s Data Security team has published a detailed account of its internal audit methodology designed to move beyond formal compliance reports and deliver measurable improvements in data protection.
Alena, who leads the group of 11 analysts, explains that the company handles large volumes of personal data and private data distributed across numerous microservices. These include customer names, addresses, payment details, order contents, and internal business information that must be protected under Federal Law 152-FZ and company requirements. Primary fines for violations range from 150–300 thousand rubles, with repeat offenses reaching 300–500 thousand rubles and potential penalties up to 3 percent of annual turnover or 500 million rubles for data leaks.
How the datasec audit is conducted
The process begins with system familiarization: analysts map microservices, APIs, data flows, and access points, often creating visual diagrams that can take weeks to complete for complex CRM systems. They then review role-based access models to detect excessive permissions. In one audit, broad rights to modify product tags were narrowed because incorrect tagging could lead to storage and display errors causing significant financial damage.
Next, the team examines both employee and service account access. One review covered more than 84,000 user-role combinations, resulting in recommendations to revoke unnecessary privileges that could be exploited if an account were compromised. Logging is another focus area; teams are required to enable human-readable audit logs that support incident investigation, real-time alerts, and playbooks for detecting mass data exports or suspicious UI activity.
Protected access and storage are verified through mandatory use of HTTPS and database encryption so that even direct database access does not expose readable information. Analysts also assess additional architecture elements depending on the specific system under review.
Prioritization model and guiding principles
To decide which systems to audit first, the team applies a scoring framework that evaluates four core parameters: Data (volume and sensitivity), Importance (business criticality), Number (employee count interacting with the system), and Money (potential financial loss from downtime or leakage). Optional factors include incident history, user type, and regulatory obligations such as critical information infrastructure requirements.
The group stresses that audits must produce real changes rather than remain on paper. A notable success involved removing recipient names, phone numbers, and addresses from Ozon delivery boxes. Although the practice was legally permissible, the team argued it created an unnecessary risk of bulk data collection; after implementation, delivery operations continued without disruption.
Key recommendations include setting clear priorities, examining security implications at the business-requirements stage, being willing to redesign long-standing processes, maintaining open dialogue with development and business teams, and assembling analysts who are personally invested in practical outcomes. The ultimate measure of success, according to Alena, is when the first recommendation from an audit report becomes an implemented change in production.
