FSTEC Compliance Audit: Method and Evidence

A small software company wins a contract to maintain an appointment-booking portal for a hypothetical state institution. The contract contains one line: before a new release goes live, the vendor must provide the results of an "FSTEC compliance audit". The company finds a contractor and, three weeks later, receives a forty-page report in which almost every item is marked "compliant". The report was assembled from policies, procedures and screenshots that the developers themselves had sent over.

A month later the customer runs its own check. The portal's admin panel is reachable from the internet and protected only by a password, with no second factor, and the login log is kept for three days and reviewed by no one. Yet the security policy described all of this correctly.

The example is hypothetical and does not refer to any real organization, but the gap between paper and reality in it is easy to recognize. The phrase "FSTEC audit" usually hides three different questions. Which requirements actually apply to the system? Do the security controls really work? And is a formal attestation required — something no audit and no penetration test can replace? Below we look at how to establish applicability, how to build an evidence-based assessment, where a pentest fits, how to prioritize nonconformities and how to choose a provider whose report will survive a retest.

What People Actually Buy When They Order an "FSTEC Audit"

An FSTEC compliance audit is a structured assessment of how far an information system, its security controls and its supporting processes meet those requirements of FSTEC of Russia (the Federal Service for Technical and Export Control) that apply to that system. The key word is "apply". There is no single list "for everyone": different legal acts govern different system types and information categories, and different kinds of assessment have different goals and legal consequences.

A good audit produces three results: a picture of the gaps against specific requirements, citing the document and its version; technical evidence that the controls work; and a remediation plan that can be defended before management, the government customer or the regulator. A poor audit produces a table of statuses backed by nothing but correspondence with the system owner.

Applicability Starts With the System, Not the Name of the Service

Before discussing method, three questions need answers. Who owns the system: a government body, a state institution, or a commercial company operating it for a government customer? What information does it process: restricted-access information, personal data, public information? And what is the purpose of the assessment: an internal gap analysis, preparation for attestation, a contractual condition, or a check after a major change?

The answers determine which documents form the basis. Protection of information in state information systems is one regime, personal data is another, significant objects of critical information infrastructure are a third. For the last two we have separate guides: personal data security assessment under 152-FZ and critical information infrastructure audit. A report built against "FSTEC in general" either checks things it does not need to or misses things that are mandatory.

Applicability of specific requirements, protection classes and protection levels is established from the official texts and, in disputed cases, with lawyers who specialize in information protection. The entire audit matrix depends on this decision.

Audit, Pentest and Attestation Are Different Kinds of Work

A gap analysis shows where the system diverges from requirements. A penetration test shows what an attacker can do in practice within agreed boundaries. Attestation of an information object (an "object of informatization" in Russian regulatory terms) is a formal procedure with an established order and legal consequences. Pentests and scans provide important evidence for any of these, but they do not become attestation merely because they check controls related to FSTEC requirements. A pentest is not certification, not attestation and not an assurance opinion on compliance.

If what you need is the technical part — verifying whether controls work on external interfaces, in a web application or on the internal network — it pays to agree its boundaries in advance: which systems are in scope, which requirements the test should support with evidence, and which methods are acceptable in production. Pentest.red performs this kind of testing and can format results so they map conveniently onto your requirements matrix; a good starting point is the pentest scoping page. It does not replace attestation or a legal opinion on which requirements apply: those need a separate qualified assessment.

The 2026 Regulatory Baseline: What to Check Before Work Starts

Documents cited in old reports and templates go out of date, and in 2026 this is especially visible.

For state information systems, the key change is FSTEC of Russia Order No. 117 of 11 April 2025 on requirements for protection of information in state information systems and other information systems of state bodies, state unitary enterprises and state institutions. The order was registered by the Ministry of Justice on 16 June 2025 as No. 82619 and, from 1 March 2026, replaced the former Order No. 17 framework.

Two conclusions follow. A report prepared today should not cite Order No. 17 as the current general requirements for state information systems; mentioning it is appropriate as historical context, for example when comparing with an earlier audit. And the scope of Order No. 117, as its title indicates, covers information systems of state bodies, state unitary enterprises and state institutions; it does not create a universal regime for every private company. A contract may flow down compliance-support or evidence duties to a commercial contractor. Direct applicability of Order No. 117 to the specific system and operator must be established separately.

A separate procedure is attestation of information objects against requirements for protection of restricted-access information that does not constitute a state secret. Its procedure is set by FSTEC of Russia Order No. 77 of 29 April 2021 (registered on 10 August 2021, No. 64589). It was amended by Order No. 60 of 27 February 2026, registered on 24 June 2026 as No. 87202 and published on 25 June 2026. A description of attestation that relies only on the 2021 text is now incomplete.

The practical rule: the team works from the current consolidated version of the applicable acts, not from a registration record or someone else's template. And assessment frequency — "once a year", "every two years" — cannot be carried over from one regime to another by analogy. The cadence of repeat assessment or reassessment comes from the specific applicable act or contract; the timing of a technical fix retest is set separately in the remediation plan or contract.

Why a Checklist Does Not Prove Compliance

Information protection requirements are usually phrased as outcomes or measures: something must be restricted, logged, protected. A documentary review confirms that a control is described, not that it works: that the log is really written and retained for the required period, that the admin interface is really closed, that updates are really installed.

NIST SP 800-115, the guide to technical security testing and assessment, explicitly names both roles of technical checks: finding vulnerabilities and verifying compliance with a policy or other requirements. A mature audit rests on that dual role. The same work identifies weaknesses and produces compliance evidence, so an "audit" and a "pentest" do not have to be two unrelated projects if the test results are tied to requirements in advance.

A caveat: SP 800-115 was published in September 2008, replacing SP 800-42, and contains no modern tooling. The document itself describes its content as an overview of key elements rather than a comprehensive program. It is a framework for planning and documenting checks, not a list of what to check.

If the organization also reports to foreign partners, NIST CSF 2.0 is useful: current and target profiles let you describe the same state of affairs in management terms without repeating fieldwork. Do not assume a ready-made authoritative mapping of FSTEC requirements to CSF: the team must document and validate any mapping used against the wording of requirements, not section titles.

Method: From Requirement to Evidence

Planning, Execution and Post-Execution

SP 800-115 describes an assessment in three phases: planning, execution and post-execution. Planning fixes the scope (systems, interfaces, sites, data flows), the list of applicable requirements with versions, the rules of engagement and the system owner's written authorization with objectives, time windows, permitted methods and emergency stop contacts. Technical tests do not start without that authorization.

Execution collects evidence: review of documents and configurations, interviews, technical tests. Post-execution is analysis and the write-up of findings and recommendations. Remediation and retesting form the next, practical cycle, owned by the organization. It is worth planning in advance but should not be blended into the assessment phases, otherwise it becomes unclear which state of the system the conclusions describe.

The Requirement-to-Evidence Matrix

The heart of the audit is a matrix in which every requirement is rewritten as a testable statement. Not "security event logging is ensured", but "logins to the admin interface are logged with account, time and source; the log is retained for at least the required period and protected from modification". Each statement records the method, artifact type, assessor, date and result: compliant, partially compliant, noncompliant or not applicable — with a justification.

SP 800-115 separates examination techniques (documents, configurations, logs) from testing techniques (scanning, penetration testing) and stresses the limitations of each. The matrix makes the choice of method explicit: you can see where a conclusion rests on a screenshot from an email thread and where on a reproducible test.

Version discipline helps. OWASP ASVS recommends including the version directly in the requirement identifier, for example v5.0.0-1.2.5, because numbering changes between versions. The same goes for FSTEC requirements: act, version, clause. After the transition from Order No. 17 to No. 117, a reference like "clause such-and-such" without the document and date is meaningless.

1. ApplicabilityDetermine the system type, information category, applicable act and its current version, including amendments.
2. Testable statementRewrite the requirement as a concrete statement about the system that can be confirmed or refuted.
3. Method and authorizationChoose the least disruptive sufficient method and obtain written authorization for technical checks.
4. ArtifactCollect dated evidence from a specific host: an export, a log excerpt, a test record.
5. RetestAfter the fix, repeat the same method and update the matrix status with a new date.

Which Evidence to Accept and Which to Reject

Strong evidence differs from weak evidence not in volume but in whether it can be rechecked. A screenshot without a date or host name says only that a setting existed somewhere at some point. A dated export from a specific host, a test result and a repeatable command describe the state of a specific system at a specific moment. The table illustrates the approach rather than restating clauses of an order: exact wording comes from the applicable act.

The last column matters more than it seems: if it is unclear how to retest a finding, after the "fix" you are left with the system owner's word. How to organize a retest that actually proves something is covered in our article on penetration test remediation validation.

Technical Checks: Depth Versus Operational Risk

Technical verification usually combines configuration review, vulnerability scanning and, where permitted and justified, penetration testing. SP 800-115 relates its subject matter to the control families of audit and accountability, risk assessment, system and communications protection, and system and information integrity — which is what an auditor usually has to confirm.

The Least Disruptive Sufficient Method

Non-intrusive examination barely affects operations but can miss exploitable weaknesses. Active testing gives stronger evidence but requires agreed windows and constraints. For production systems handling regulated data, it is sensible to choose the least disruptive method that yields sufficient evidence, and move to active testing where the wording of the requirement or the level of risk calls for it and the system owner has consented.

Take a hypothetical system that issues certificates to citizens. The password policy can be confirmed by exporting the directory settings and attempting to set a weak password on a test account. But whether a user can obtain someone else's certificate through an authorization flaw can only be confirmed by testing the application — no document will answer that. Different requirements within the same system call for different depth, and the matrix must reflect that.

Staging Versus Production

Active tests are often moved to a staging environment. That is reasonable, but staging results do not carry over to production automatically: versions, configuration, network rules, integrations and data may differ. If a conclusion concerns the production system, the matrix should show what confirms that staging matches production, or add safe checks in production, such as reconciling versions and access rules.

Reproducibility

Record tool versions, scan profiles, time windows, raw output and commands. Then a second reviewer or the regulator can see how a conclusion was reached, and a retest compares like with like. "No vulnerabilities found" without saying with what, when and within which boundaries proves nothing.

Web Interfaces and APIs: Application-Layer Checks

Many systems under FSTEC requirements are portals, personal accounts and APIs for data exchange with other agencies. OWASP's discipline is useful for them, provided the standard versions are recorded in the report. Testing itself is covered in more detail in our guide to web application vulnerability testing.

OWASP WSTG defines test cases, while OWASP ASVS defines verifiable requirements for application security controls. A specific matrix may pin WSTG 4.2 and ASVS 5.0.0 as its chosen versions; the provider must state exactly which releases it used. ASVS requirements are available as CSV and JSON, which makes them easy to import into the matrix. The 2025 edition of the OWASP Top 10 is an awareness document about critical web application risks. It works well for conversations with management but is not a verification standard: "Top 10 coverage" without ASVS requirements and WSTG test cases is weak evidence.

Application-layer evidence is easy to record and recheck. HTTP itself does not link requests to one another; the application maintains the user session through cookies or tokens, and session data can perfectly well be stored on the server. So the auditor checks how sessions are built: cookie attributes (Secure, HttpOnly, SameSite), rotation of the session identifier after login, termination on logout and after timeout. The Content-Security-Policy header restricts which resources a page may load and helps mitigate cross-site scripting and data injection. A CORS policy determines which third-party origins the browser will allow to read responses. An overly broad policy is material when it lets unintended origins read sensitive browser responses; severity depends on credentials, data and impact. API authorization is checked with test cases for access to other users' objects and functions. All of this is recorded as a dated request–response pair and is easy to repeat after a fix.

Prioritizing Nonconformities: Regulation, Exploitability, Business

A missing procedure and an internet-facing panel with an authorization bypass are formally both "noncompliant", but fixing them with equal urgency would be odd.

For technical findings, mapping to CWE weakness classes is useful. MITRE's 2025 CWE Top 25 highlights the most dangerous weaknesses behind published vulnerabilities; MITRE notes that they are often easy to find and exploit and can lead to system takeover, data theft or denial of service. A CWE mapping reveals the root cause and helps fix a class of defects rather than a symptom: if one API method lacks an authorization check, look for the same in neighboring ones. MITRE also publishes the 2025 CWE Top 10 KEV Weaknesses list, a ranking based on vulnerabilities in CISA's Known Exploited Vulnerabilities catalog. A class appearing in a KEV-derived ranking is one prioritization signal. Known exploitation of the specific finding requires vulnerability-specific or observed evidence.

A practical severity model considers three dimensions: regulatory (is a mandatory requirement of the applicable act violated), technical (weakness class, external exposure, known exploitation) and business (which data and processes are affected). A report with only "yes" and "no" statuses hides from management exactly what it needs to decide. More on this in our article on risk-based vulnerability prioritization.

Trade-Offs and Limitations

A documentary audit is cheaper and faster, but its evidence is weaker. Technical verification requires authorizations, coordination and budget, but shows how controls actually perform. A combination usually makes sense: technical tests for internet-facing and high-impact systems, configuration and document review where the wording of the requirement allows it.

A one-off audit captures the state on a single date, while configurations drift and releases introduce new weaknesses. In its Secure by Design materials CISA calls for reducing exploitable defects as early as the design stage, and its guidance on secure software deployment stresses the role of robust testing and measurement. For an audit this means checking processes too — how changes reach production, who approves them, whether security checks run — not just the configuration on the day of the visit.

International guidance does not replace national requirements. NIST, OWASP and CWE improve the quality of evidence, but compliance is assessed against the applicable FSTEC documents. Treating an international control as equivalent to a national one without comparing the wording easily creates a false sense of compliance: an ASVS logging requirement may differ from a specific act's requirement in the set of events or the retention period.

Finally, an internal team knows the environment, while an external provider brings independence. If applicable requirements prescribe a particular type of assessor or licenses, that takes priority and is verified against official texts and registers.

Before, During and After the Audit

Before work starts you need an up-to-date system inventory, data flow diagrams, assigned owners, current policies, enabled logging, an agreed list of applicable documents with versions, written authorization and rules of engagement. Without them the provider spends billable time reconstructing basic information.

During the audit you need a rapid communication channel, conditions for stopping tests immediately and a procedure for handling evidence. Audit materials contain information about configuration and vulnerabilities, so they are protected as strictly as the systems themselves: restricted access, controlled storage, destruction periods agreed in advance. Decide beforehand whether a critical finding is reported immediately or waits for the final report.

After the audit, nonconformities become a remediation plan with owners and deadlines, followed by a retest using the same method that confirmed the finding. This practical "fix — retest — update the matrix" cycle is worth running between scheduled assessments too, and the matrix should be maintained rather than archived. CSF 2.0 profiles provide a convenient format for tracking movement from the current state to the target one.

How to Choose an FSTEC Audit Provider

Compare providers only after the applicable requirements, scope and depth are defined. The logic of CISA's Secure by Demand guide, written for software customers negotiating with suppliers, transfers well to buying an audit: ask verifiable questions and demand evidence, not marketing claims.

Ask which documents and versions will be used and how the provider determines their applicability. Clarify the method: work phases, WSTG version, ASVS version and level. Request an anonymized sample report with a requirement-to-evidence matrix. Find out how findings are mapped to CWE and prioritized, how authorization, rules of engagement, stop conditions and data handling are documented, and whether a retest is included in the contract.

If third-party products are in scope, bear in mind CISA's position: products should be secure out of the box, and multi-factor authentication, logging and single sign-on should be provided at no extra charge. Auditors usually map these features to access-control and event-logging requirements, so check in advance whether they are available in your product edition and enabled.

Red flags include a guarantee of "passing" a check or attestation, no technical component, references to standards and orders without versions and dates (including citing Order No. 17 as current requirements for state information systems), a report with statuses only, refusal to show an anonymized sample, and a promise of "attestation" based on a pentest. If applicable requirements call for licenses or other authorizations, verify them in official registers rather than taking the provider's word.

If you order the technical component of the audit separately, it is easy to discuss it concretely with Pentest.red: the list of systems and interfaces, the requirements the test should support, constraints on windows and production, and expectations for artifact format and retesting. You can start from the scoping page or the page on our penetration testing service. Scope of work, timing and cost are determined after the scope is reviewed, while attestation and the legal applicability of requirements remain with specialized organizations.

Decision Order: Where to Start

First, applicability is determined: system type, information category, the specific act and its current version. Then the scope is fixed, a method and evidence type are chosen for each requirement, the depth of technical testing is set according to risk and authorization is obtained. Only then is a provider selected — on verifiable criteria. After that, nonconformities are prioritized, remediated and retested, and the matrix is maintained. Choosing a provider before applicability is settled means buying someone else's interpretation of the requirements along with the service.

A rule of thumb, always checked against the wording of the requirement: if a web application or API is internet-facing and processes regulated data, require technical testing against chosen, recorded versions of WSTG and ASVS where relevant. For other technologies, choose system-appropriate methods; for an internal, low-impact system, document and configuration review may suffice if the requirement wording allows it.

Conclusion: Compliance Is Proven by Evidence

A good FSTEC compliance audit answers not "does a document exist" but "does the control work, and what proves it". Applicability is determined from current official texts: since 1 March 2026 the general requirements for protecting information in state information systems are set by Order No. 117, and the attestation procedure under Order No. 77 has been amended by Order No. 60. The method's framework comes from the SP 800-115 phases, verifiable requirements and test cases for applications from ASVS and WSTG with recorded versions, and root-cause prioritization from CWE classes.

In the hypothetical example, one matrix row citing the current version of the requirements, the documented and justified system-specific statement "the admin interface is unreachable from the internet and requires a second factor", and one reproducible test would have exposed the gap described. They would not by themselves establish compliance with the full set of applicable requirements. In this scheme a pentest is a source of strong evidence, but not attestation and not an opinion on compliance. The best result comes when correct identification of requirements, a versioned method, reproducible checks and a remediation plan with retesting are brought together in one piece of work.