Answer.

Background of the question:

Information security requirements are a critical component of large IT projects, dating back to the times when the first security audit standards emerged (for example, ISO 27001 or the requirements of Federal Law 152 in Russia). Without clear analysis and formalization of requirements, the system's security risks becoming declarative and impractical.

Problem:

Security requirements are often formulated abstractly ("everything must be protected"), do not take into account real business processes and architecture, and are not broken down by levels: organizational, technological, and user. Moreover, clients and developers may interpret the same requirements differently — leading to a mismatch between feasibility and compliance.

Solution:

The systems analyst begins by studying corporate, state, and industry standards (e.g., GOST, GDPR, PCI DSS, ISO 27001). Then, together with the architect and security professionals, he identifies business-critical processes, data storage and transmission points, potential threats, and determines the list of relevant risks. Based on this, the analyst prepares a detailed requirements matrix regarding access, storage, logging, encryption, and incident scenarios. After approval, he formalizes them in documents — ensuring that each requirement can be verified through testing or audit.

Key Features:

Security requirements are formalized taking into account architecture, business processes, and RegTech standards.
It is necessary to distinguish between organizational, technological, and user security policies.
Close collaboration with security professionals, architects, legal advisors, and QA engineers is mandatory.

Tricky Questions.

Why should you not rely solely on technical means of information security (antivirus, firewalls, SIEM)?

Because information security is a process, not just a set of systems. Organizational procedures, human factors, regular checks, and user training play a crucial role.

Can the requirements be considered fulfilled if the system has only undergone internal testing?

No — compliance with regulations often requires external audits, certifications, and sometimes stress tests under the regulator’s supervision.

Is it enough to simply state in the technical specifications that "the system must be protected according to Federal Law 152"?

No — it is necessary to specify concrete measures (access control, log storage, data encryption), implementation locations, and verification criteria.

Common Mistakes and Anti-Patterns

Formulation of vague or declarative requirements ("it should be secure")
Separation of the security process from architectural and business analysis (operating "in parallel", not interacting)
Overestimating the role of technical means without considering human and process factors
Lack of regular checks on the relevance of information security requirements

Real-Life Example

Negative Case: In an online banking project, the analyst submitted only a general phrase "requirements of Federal Law 152 must be met" in the technical specifications. Contractors implemented standard authorization and an SSL certificate, but at the external audit stage, it became clear that there was no control over data storage and an unprotected authentication log.

Pros:

Rapid development

Cons:

Non-compliance with the regulator
Risk of launch blockage

Positive Case:

At the start of the project, the systems analyst coordinated a list of threats with security professionals and the client, developed detailed requirements for encryption and auditing for each scenario, and identified responsible parties. Eventually, the system passed the audit without remarks.