Answer

Background:
In recent years, the number of attacks on information systems has increased, and data protection requirements have become stricter under the law. Companies demand comprehensive and continuous attention to security issues at all stages of the product life cycle.

Problem:
Non-functional security requirements are often formulated vaguely or copied from standards without adaptation to the project specifics. This leads to high risks, repetition, or unachievable tasks for the IT team.

Solution:
The analyst must:

1. Understand the regulatory environment (e.g., GDPR, Federal Law No. 152, ISO/IEC 27001) and adapt it to the project's needs.
2. During interviews with security experts, document specific threats and requirements (encryption, auditing, access control).
3. Decompose requirements into a format convenient for architects and developers (clear security criteria, password policies, logging and reporting requirements).
4. Coordinate technical measures with the team to implement them without blocking processes.

Key features:

• Mandatory interaction with security experts
• Translation of regulatory requirements into technically feasible tasks
• Keeping documentation up to date

Trick Questions.

Can checklists for security be fully trusted when forming requirements?

Checklists are useful as a starting point, but do not cover all business specifics. Security requirements should be individually discussed for each project.

Is security auditing mandatory for all parts of the system?

Some modules may not process sensitive data or be internal. However, risk analysis is mandatory for the entire solution. The principle of least privilege is implemented.

Is it worth trying to implement security requirements 100%?

Generally, the most critical measures corresponding to data classification and threat levels are executed. "Absolute security" is a myth; compromises are inevitable, and it is important to manage risks.

Common Mistakes and Anti-Patterns

• Formal copying of requirements without considering specifics
• Insufficient detail (e.g., "use encryption" without defining standards)
• Lack of regular security review when changes are made to the system

Real-Life Example

Negative Case: Security requirements were reduced to a point of "compliance with ISO standard" and forgotten about data transmission channel encryption settings. Result: incident, fine. Pros: Quickly created documentation. Cons: Actual vulnerability and problems during the audit.

Positive Case: The analyst engaged a security expert, conducted a threat analysis session, and documented requirements as acceptance criteria. All measures were agreed upon and feasible. Pros: Protection was implemented, audit successfully passed. Cons: More time and effort were required for coordination.