Bank of Russia security audit: scope the obligation before the test

A request to “audit Bank of Russia requirements” is not yet a purchasable scope. The buyer first needs to establish which regulated activity, legal role, information-protection level, and technological process are in view. Only then can the team decide whether it needs a formal conformity assessment, a penetration test, vulnerability analysis, or a coordinated package of several distinct work products.

This guide reflects the position verified on 9 October 2026 for organizations operating in the Russian financial sector. It is not a global banking standard and it is not an exhaustive catalogue of Russian regulatory duties. The compliance or legal owner should confirm the organization’s exact status, current text of the applicable acts, transitional rules, and any entity-specific directions before procurement.

The central buying principle is simple: start with the regulated activity and the required conclusion, then build the technical scope. Starting with “all external IP addresses” or “one mobile application” can produce a technically sound test that still leaves the audit question unanswered.

Build an applicability matrix before requesting proposals

Three Bank of Russia regulations illustrate why a universal checklist fails.

Regulation 851-P, dated 30 January 2025, concerns information protection by credit institutions and branches of foreign banks when performing banking activities connected with funds transfers. It replaced 683-P. Its framework separates recurring technical testing from formal assessment work; buying a penetration test alone does not make a conformity conclusion.

Regulation 821-P covers defined participants and operators in the national payment system, including roles such as funds-transfer operators and payment-infrastructure operators. It replaced 719-P, so 719-P should not be used as the current basis. Direction 7220-U amended 821-P with effect from 1 October 2026. A scope approved before that date needs a version check, especially where biometric transfers or a shared information-protection perimeter for several activities are relevant.

Regulation 757-P is the separate track for non-credit financial organizations conducting financial-market activities. Applicability and the required protection level depend on the entity type, activity, and criteria in the regulation. The schedule and method therefore cannot be copied from a credit institution or payment-system operator. Direction 7219-U contains later changes whose main provisions take effect on 1 January 2027; as of this article’s date, those future provisions must not be presented as current requirements.

Create one row for each legal role and regulated activity. Record the applicable act and edition, the triggering criterion, the assigned protection level if relevant, the responsible compliance owner, and the affected technological processes. Add a “not applicable” decision only with a short rationale and an approver. This turns legal interpretation into an inspectable scope decision without asking the testing supplier to determine the organization’s legal status.

A single company may have more than one row. A non-credit financial organization can also participate in a payment process under a separate role. A shared identity service, API gateway, or processing platform may support activities governed by different requirements. The applicability matrix should preserve those differences while showing their common technical dependencies.

Buy the work product the obligation calls for

The words “audit,” “assessment,” and “test” are often used as if they were interchangeable. They answer different questions and may require different performers.

GOST R 57580.1 describes a base set of organizational and technical information-protection measures. GOST R 57580.2 is a methodology for assessing conformity and documenting the result. Their roles are different. A penetration test can provide evidence about implemented technical behavior, but it cannot be relabelled as a 57580.2 conformity assessment after delivery.

Provider qualification must be attached to the work product. Where 851-P, 821-P, or 757-P specifically requires an external checking organization with stated licences or independence, procurement must verify that requirement for the formal assessment. For an external pentest, 2-MR recommends checking a technical-information-protection licence and independence. Its recommendation status does not cancel any separate binding qualification rule. The buyer must verify the requirements for both the regulated assessment and the planned technical service.

Pentest.red can supply scoped technical testing and traceable evidence for an audit package. That work does not automatically become the formal regulatory conclusion, and it should not be described as one unless the separately required role and qualification have been verified.

Translate each regulated process into a technical perimeter

A reliable scope starts with the financial operation, not the asset list. For each applicability row, describe the protected process from initiation to final state: customer or employee action, authentication, authorization, transaction creation, validation, transfer, clearing or settlement interfaces where relevant, status updates, notification, reconciliation, dispute handling, and privileged support.

Then map every process step to the systems that can change its confidentiality, integrity, availability, or authenticity. Include customer-facing applications, APIs, integration services, application servers, databases, administrative interfaces, identity providers, cryptographic services, message brokers, remote-access paths, monitoring, deployment controls, and recovery tooling when they can affect the protected operation.

The perimeter also needs environments, addresses, versions, accounts, roles, trust relationships, data classes, and owners. Name exclusions and the reason for each one. If production testing is restricted, state what representative environment and evidence will be used, and which claims will remain unverified. A clean exclusion is a risk decision; a silent omission is a traceability failure.

1. Activity and roleIdentify the regulated financial activity, legal role, protection level, applicable act, edition, and effective date
2. Protected processTrace the financial operation, data, authorization decisions, privileged actions, and failure paths
3. Technical perimeterMap applications, APIs, infrastructure, identities, providers, environments, exclusions, and owners
4. Method and performerAssign formal assessment, penetration testing, vulnerability analysis, or internal review with the required qualification
5. Acceptance and retestLink each obligation to evidence, findings, remediation owners, acceptance criteria, and retest status

This chain prevents two common procurement errors. The first is testing everything reachable while omitting an internal service that can change transaction state. The second is testing one regulated product thoroughly while leaving its shared identity, administration, or deployment path outside the boundary.

Treat a version change as a scope event

An audit file needs a regulation register with effective dates, not a folder of undated PDFs. For every source, record the document number, official title, amendment, publication source, effective date, applicability decision, and the date on which the decision was checked. Keep current requirements separate from approved future changes and from superseded acts.

Suppose a statement of work is signed in September, fieldwork begins in October, and the report is accepted in January. The version register should trigger two decisions. Before fieldwork, the compliance owner checks whether the newly effective amendment changes an applicability row, shared perimeter, method, or evidence requirement. Before acceptance, the owner checks whether a future-dated change now affects the conclusion or should instead become a readiness action for the next cycle. The report states the edition and evidence date it actually covers.

Put this gate in the contract. A named buyer decides whether a change requires a revised scope, fee, schedule, or acceptance criterion. The supplier should not silently adopt a new legal interpretation, and the buyer should not discover at acceptance that the report addresses an obsolete edition. A change that does not affect the engagement is also recorded with its rationale.

There is no single Bank of Russia testing interval or conformity score that applies to every financial organization. Frequency and assessment rules vary by legal role, protection level, activity, and work product. Put the exact obligation for each row in the matrix, along with the source and owner who confirmed it. Avoid copying a schedule from a vendor page into a company-wide policy.

Make third-party systems visible without transferring responsibility

Cloud platforms, processing partners, information-exchange operators, software vendors, and service providers can sit inside the operational chain even when the financial organization does not own the hardware. Asset ownership is therefore a poor test for inclusion. Ask whether the service stores, transmits, authorizes, modifies, logs, recovers, or administers the protected operation.

For each provider dependency, record the service and data flow, contracting entity, system owner, security owner, location, access model, shared-responsibility split, available logs, testing rights, notice periods, restrictions, and incident or recovery handoffs. Regulation 821-P contains contractual and control duties for particular relationships in the payment ecosystem. Those duties should be mapped to the exact covered role rather than generalized to every supplier.

Technical authorization matters as much as the contract. Obtain written permission from every affected system owner, define source addresses and accounts, agree stop conditions, and identify actions that are prohibited. If a provider refuses active testing, document the resulting gap and choose another evidence route, such as provider reports, configuration evidence, a segregated tenant, or a representative environment. Record what that evidence can and cannot prove.

Outsourcing an application or test does not outsource the buyer’s applicability decision, risk acceptance, or evidence custody. The accountable owner should be visible for every exclusion, exception, and dependency.

Design the evidence matrix before testing begins

A report is useful for a Bank of Russia audit only when a reviewer can trace the path from obligation to evidence. Build the matrix before fieldwork, with at least these columns:

• applicable act, edition, clause or internally approved requirement identifier;
• regulated role, financial process, protection level, and control objective;
• asset, component, environment, owner, and third-party dependency;
• required work product, method, performer qualification, and independence decision;
• test case or assessment procedure, expected result, and evidence format;
• finding identifier, affected version, proof location, severity rationale, and business impact;
• remediation owner, due decision, exception approver, acceptance criterion, and retest status.

The technical task should also define the authorized network ranges, accounts and roles, test window, production safeguards, stop and escalation conditions, recovery contacts, sensitive-data handling, excluded actions, reporting format, and the conditions for repeat testing.

Evidence should be specific enough for an independent reviewer to reconstruct the conclusion without receiving unnecessary secrets. Useful items include a timestamp, tested version or build, asset identifier, role used, request-and-response excerpt, relevant log reference, sanitized screenshot, and a short reproduction path. Raw credential material, full customer records, or uncontrolled exploit code do not belong in the audit package.

For example, use an isolated sandbox with synthetic accounts and no live funds to test whether a transfer can execute after its recipient or amount changes following authorization. Capture the synthetic transaction identifier, application build, policy or ruleset version, tester role, authorization snapshot, execution result, and reconciliation state. Set a safety stop if traffic reaches a live route, real account, or unapproved provider. If an external processor is excluded, show that boundary in the result and leave the end-to-end claim open rather than treating the sandbox as proof of the provider’s behavior.

For a broader treatment of control-to-evidence design, see the evidence-led audit readiness guide. For contractual acceptance mechanics, the penetration-testing scope and acceptance guide explains how to make exclusions, deliverables, and closure decisions reviewable.

Define acceptance and retest as part of the purchase

A penetration test is not complete merely because a PDF was delivered. Acceptance should check that the tested asset register matches the approved perimeter; all exclusions and deviations have an owner; every finding identifies the affected object and observed condition; evidence is reproducible and safely handled; and the report distinguishes tested facts, assumptions, and untested areas.

Remediation closure needs equally precise states. “Fixed” is a team assertion. “Retested on build X in environment Y, with the original path no longer reproducible under the agreed role” is evidence. If a change blocks the original path but creates a new exposure, the retest result should say so. If the relevant object was removed or the risk accepted, record the decision and approver rather than describing it as technically remediated.

Define what will be retested, what may be omitted, the change window, required access, evidence format, and treatment of partial fixes before the first test starts.

A practical acceptance gate asks four questions:

• Can compliance identify the applicable obligation and current edition?
• Can engineering identify the exact object, version, role, and observed behavior?
• Can risk management identify the owner and disposition of every gap?
• Can an independent reviewer follow the evidence from requirement through remediation and retest?

If any answer is no, the package is not ready for the intended audit decision even if the technical testing itself was competently performed.

A hypothetical buying scenario

Consider a hypothetical non-credit financial organization that offers a customer portal and also performs a defined role in a payment chain. The portal, payment API, identity provider, fraud engine, message broker, and managed database share one operational perimeter. The buyer should not declare “757-P audit” and send only the portal URL to a pentest vendor.

The applicability matrix first records the organization’s non-credit financial activity and determines the relevant 757-P classification. A separate row records its actual payment-system role and tests whether 821-P applies. Because the shared services support both rows, the technical map shows which requirements converge on identity, administration, logging, and recovery. Direction 7220-U is included in the 821-P version check because it is already effective; future 757-P changes are recorded as a planning item for work crossing 1 January 2027.

The buyer then separates deliverables. A qualified checking organization performs any formal conformity assessment required for the confirmed row. The penetration testing service tests the authorized attack paths and protected processes. Vulnerability analysis covers the agreed inventory with authenticated access where available. Internal compliance owners maintain the requirement-to-evidence matrix and issue the organization’s applicability and risk decisions.

The statement of work uses the scope planner to record environments, roles, provider permissions, exclusions, stop conditions, and expected evidence. The team reviews a sample penetration-test report before signature so that finding identity, proof handling, remediation fields, and retest statements are acceptance criteria rather than late formatting requests.

This approach does not promise that one engagement “certifies Bank of Russia compliance.” It produces the right technical evidence for the right rows, preserves the boundary between testing and regulated assessment, and makes every residual gap visible to the person authorized to accept it.

What a defensible scope looks like

A defensible Bank of Russia security-audit scope can be read in both directions. Starting from a regulation row, a reviewer can reach the regulated process, technical objects, method, qualified performer, evidence, finding, remediation decision, and retest. Starting from a finding, engineering can reach the affected process and understand why the evidence matters to the audit.

Before signing, require five named artifacts: the applicability and version matrix; the regulated-process and technical-perimeter map; the work-product and qualification decision; the requirement-to-evidence matrix; and the acceptance and retest plan. These artifacts make proposal comparison meaningful because suppliers price the same boundary and buyers know which conclusion each deliverable can support.

Where the confirmed scope and qualification requirements fit, Pentest.red’s role in that structure is concrete: help define the authorized technical perimeter, perform the agreed testing, document observable attack paths and vulnerabilities, and provide evidence that can be mapped into the buyer’s audit file. The organization’s legal applicability decision and any formal conformity conclusion remain with the roles authorized and qualified to make them.