152-FZ Audit: Where Legal Duties End and Technical Evidence Begins

Consider a hypothetical example that does not describe any real company. An online retailer is preparing to launch a loyalty programme: sign-up on the website, a mobile app, a CRM holding purchase history, a call centre run by a contractor and an email marketing service. A month before launch, management sets the task: "pass a 152-FZ audit and get a certificate". The budget covers one piece of work, and the choice is leaning towards a pentest of the customer account area. The decision looks simple, but it mixes three different questions. Does the law apply, and what duties does it place on the company as an operator? Are the organisational duties met: purposes, legal grounds, documents, roles, contracts with processors? And do the technical measures in specific systems work as declared?

A pentest answers only part of the third question. It can be a strong source of technical evidence, but on its own it does not establish compliance with legal, organisational and documentation requirements, and it does not confirm that processing is lawful. A private audit or pentest is not a "152-FZ certificate", not an attestation and not an assurance opinion. Below we look at how to separate these layers, how to build the technical part on reproducible evidence and how a buyer should accept the result.

Legal applicability first, technical scope second

Federal Law No. 152-FZ "On Personal Data" is Russia's principal personal data law. Its stated purpose is to protect the rights and freedoms of individuals and citizens when their personal data is processed, including the right to privacy and to personal and family secrecy. The law has changed substantially, including through Federal Law No. 266-FZ in 2022, so the original 2006 text or undated summaries are not a reliable description of current requirements. Specific conclusions about what a particular operator must do require qualified legal review and a check against the current consolidated text as of the date of the work.

For a technical provider this leads to a practical rule: do not draw conclusions about scope until the inputs are defined. Otherwise the pentest will test what is convenient to test, not what matters.

Operator, purposes and categories of data

The first step is to record who acts as the operator and who acts on the operator's instructions. In our example the retailer determines the purposes of processing, while the call centre and the email service process data on its behalf. Next come the processing purposes: fulfilling orders, running the loyalty programme and marketing communications. For each purpose the categories of data and of data subjects are recorded: customers, programme members, employees and counterparty representatives. These answers determine which systems belong in the audit at all and which legal grounds counsel will review.

Information systems, threat model and protection level

The next step is a list of personal data information systems, a threat model and the applicable protection level. The composition and content of organisational and technical measures for personal data security in such systems are set by FSTEC of Russia Order No. 21 of 18 February 2013, registered by the Ministry of Justice on 14 May 2013 under No. 28375. Alongside it sit Government Resolution No. 1119, the FSB of Russia's requirements for cryptographic protection where such protection is used, and later amendments. These documents must be read in their current versions, and interpreting them for a specific operator is a job for counsel working together with an information security specialist. The technical team's task is to receive the finished threat model and protection level as inputs, not to invent them on its own during testing.

Three kinds of work and the boundaries between them

It helps to split the audit into three kinds of work with different performers and different evidence. Legal work answers which duties apply and whether processing is lawful. Organisational work checks how those duties are documented and carried out: policies, internal orders, registers, contracts, consents, handling of data subject requests and incidents, and staff awareness. Technical work checks whether systems do what the documents declare: access control, authentication, logging, protection of data in transit, secure configuration and vulnerability management.

The most useful findings sit where the columns meet, where the declared state differs from the actual one. A strong audit links every material documentary claim to a technical check and explicitly marks claims that cannot be tested as unverified.

What a pentest can and cannot prove

NIST SP 800-115 names two purposes of technical testing: finding vulnerabilities and verifying compliance with a policy or other requirements. It is the second purpose that makes a pentest valuable for a personal data audit: it shows whether a declared measure actually works. But the same document states plainly that it is not a comprehensive testing programme. A pentest will not tell you whether processing purposes are lawful, whether consents are sufficient, whether the protection level was determined correctly or whether notification duties were met. For more on fitting testing into inspection preparation, see our piece on penetration testing for audit readiness.

Inventory: systems, flows and explicit exclusions

An audit can only be as good as its scope. The system list includes databases, CRM and HR systems, public websites and their forms, mobile apps, APIs, file stores, backups and contractor systems. Anything missing from the list is effectively unaudited, whatever the final report says. In our example it is easy to forget the exports sent to the email service and the call centre's accounts in the CRM, even though that is exactly where data leaves the core perimeter.

Next, map the data flows: collection, transmission, storage, processing, transfer to third parties and deletion. The flow map is not paperwork for its own sake: it shows which points must go into the test plan and where responsibility passes to a contractor.

Web forms, cookies and sessions

Much data collection happens over the web. HTTP itself does not keep state; cookies add it: the server sends a Set-Cookie header and the browser returns the value with each later request. Session identifiers in the customer account area and on sign-up forms therefore belong both on the flow map and in the test plan.

Exclusions as a decision, not a default

If a contractor-hosted system or a legacy application is out of scope, the report should say so and explain why. Management and any future inspector should never have to guess what was examined. Current and target profiles in the spirit of NIST CSF 2.0 help record the starting point and the goal, so that the remediation plan has structure instead of turning into a flat list of findings.

Technical methods: from plan to report

The technical part goes through three phases. Planning fixes the scope, rules of engagement, test windows, contacts and escalation paths. Execution combines documentation and configuration review, vulnerability scanning and, only where explicitly authorised, penetration testing. Analysis turns observations into prioritised findings with recommendations and a note of which technique produced each one.

Authorisation and rules of engagement

Any active testing needs explicit written authorisation from the system owner, with scope, targets and time windows defined. Systems at a hosting provider or contractor need their consent as well. In the retailer example, that means a separate agreement with the call centre if its CRM access is in scope. Nothing in this article grants or implies authorisation to test any system.

Working with real personal data

Systems holding real records need additional rules: minimal access to data, proof of a weakness without bulk extraction of records, and immediate notification of the client if sensitive information is encountered unexpectedly. The contract should define how work artefacts that may contain personal data are stored, protected and destroyed: screenshots, logs and exports. The audit itself must not become a new leakage channel.

Web applications and APIs: checks that can be repeated

Web applications and APIs are the usual entry point for personal data, so they need a structured test catalogue rather than a general statement. The OWASP Web Security Testing Guide provides such a catalogue: the work plan can cite specific WSTG areas, which makes coverage visible and comparable between providers. How to build a standards-based web application check is covered in our article on web application vulnerability testing.

Versioned requirements instead of general references

OWASP ASVS sets requirements for technical security controls and recommends citing them with a version, for example in the form v5.0.0-1.2.5, because numbering can change between releases. For an audit this means the buyer and provider agree in advance which ASVS chapters and level apply, findings cite versioned identifiers, and a retest assesses exactly the same requirement. The OWASP Top 10 is useful as a shared vocabulary, but a report that says "checked against the Top 10" is weaker evidence than one mapped to WSTG tests and ASVS requirements. A method that links standards to management decisions is described in our piece on application security audits.

HTTP level and baseline hygiene

Several controls are visible directly on the pages that collect data: cookie attributes, the Content-Security-Policy header, which helps detect and mitigate cross-site scripting and data injection, CORS settings for cross-site requests, and Permissions Policy to restrict browser features. These checks are cheap, repeatable and good evidence of baseline hygiene, though they do not replace testing of access logic.

Prioritising findings by risk to the data

In a personal data audit the main risk is theft or disclosure of that data, so it makes sense to rank findings by their impact on the data, not by their number. CWE Top 25 root-cause categories help link a specific error to a weakness class, and the list of weaknesses linked to CISA's Known Exploited Vulnerabilities (KEV) catalogue indicates which findings to raise above theoretical ones.

Independent sources converge on the same defect classes: cross-site scripting, OS command injection and directory traversal. That means injection and cross-site scripting checks should be in scope for any web system that handles personal data. It is also worth checking the baseline measures that CISA treats as secure by default: whether multi-factor authentication is enabled for administrative and privileged access, whether logging is switched on and logs are retained, and whether access is centralised where the product supports it.

Remediation and retest: what evidence to accept

A report of findings is the middle of the work, not its end. Value for the operator appears when remediation is confirmed by the same check that found the problem. How to track fixes and prove them is covered in detail in our article on vulnerability remediation control.

1. RecordThe finding is described with the system, reproduction conditions, evidence and a versioned reference to the requirement
2. FixThe system owner applies the fix and describes what changed and where
3. RetestThe provider repeats the original test with the same technique against the same requirement version
4. AcceptanceThe finding is closed only on a reproducible negative result; otherwise it goes back to the owner

Acceptance criteria

If a fix cannot be verified by technical means, for example a change to a contract with a processor, it is recorded as organisational evidence. It is assessed by counsel or by the person responsible for organising processing, not by the technical provider.

Trade-offs between depth and the cost of assurance

The depth of the technical part depends on how exposed the systems are and how sensitive the data is. Full testing is justified when systems are reachable from the internet, hold large volumes or sensitive categories of data, or have changed noticeably since the last assessment. For small internal systems, a documentary review and configuration analysis may be enough, but that decision should be recorded in the report as a conscious scoping choice.

Documents or testing

A document review is faster and less disruptive, but it only asserts that measures exist. Testing needs authorisation and coordination, but it shows whether those measures work.

Automation or manual work

Scanning gives broad and repeatable coverage but misses business-logic and access-control flaws. Manual testing finds them but covers less ground in the same time. A convincing report combines both approaches and states the source of each finding.

Production or staging

Testing in production is realistic but puts availability and real data at risk. A common compromise is active tests in a representative staging environment, with passive configuration review and pre-agreed low-impact checks in production. Any audit still remains a snapshot of one moment: after major changes the assessment should be repeated, and its frequency should be set by risk and by the requirements counsel confirms.

How to choose a provider and what not to ask of one

Choose a provider once scope and purpose are defined, otherwise proposals cannot be compared. Assess three things: how transparent the method is, whether the provider can cover the layers you need or will state honestly which of them remain with counsel, and how personal data will be handled during the work. If you need a check of organisational and technical measures against regulator requirements, it is useful to compare the approach with our piece on FSTEC compliance audits. A practical next step is to describe the scope of the technical part: systems, access, constraints and expected evidence can be prepared in advance on the Pentest.red pentest scope page.

Ask which licences or accreditations your counsel considers necessary for the planned scope, and verify them in official registers. Do not accept claims of certification or past results without documents you can check.

Questions for the provider

Which methods and versions will be used, and which identifiers will findings cite? How will documentary claims be mapped to technical checks, and how will claims that could not be verified be reported? What written authorisation and rules of engagement are needed before active testing begins? How will artefacts containing personal data be stored and destroyed? Is a retest included, and on what terms? What will the result contain: scope and exclusions, method, evidence, risk ratings and a remediation plan?

Red flags

Be wary of a template document package delivered without any inspection of real systems, no request for written authorisation, an unnamed methodology, findings without reproducible evidence, a promise to "pass the inspection guaranteed" and a result labelled as a 152-FZ compliance certificate. No methodology supports guaranteeing an outcome, and a technical report is not certification, attestation or a compliance opinion.

What to decide before you commission the work

Back to the hypothetical retailer. Instead of a "certificate", management needs three clear results. The first is a picture of applicable duties, confirmed by counsel against the current version of the law and subordinate acts. The second is verified organisational measures: documents, roles, contracts with processors and the procedure for handling data subject requests. The third is technical evidence on the loyalty programme systems, with versioned references to requirements, written authorisation, evidence for every finding and a retest.

In this setup a pentest is an important source of evidence, but only one of them. It shows where personal data is actually exposed and gives a verifiable plan of fixes. The launch decision, however, is made on the basis of all three layers together, not on a single report.