What an auditor, or Sekit's evidence engine, asks for.
Secure development policy
The rules the development team follows to build software securely: security requirements, code review and threat modeling.
Application security testing evidence
The proof that code and applications are automatically scanned for flaws (SAST/DAST), including dependencies and APIs.
From the Sekit evidence catalog
In practice
Application security requirements exist for the flagship product but rarely reach internal tools or vendor-supplied APIs. A consultant typically finds a documented API security standard covering authentication and authorization, but no equivalent requirements document for a new internal reporting app because it is treated as internal-only. Rate limiting is configured on the public API gateway, yet the admin API behind it has none. Requirements gathered during design get lost by launch because nobody re-checks the finished build against the original requirements list before go-live, so drift between what was specified and what shipped goes unnoticed.
Common gaps
Security requirements are documented for customer-facing applications but skipped for internal tools, leaving those systems without a defined baseline.
API authentication and rate limiting exist on the main gateway, but internal or partner-facing APIs bypass the same requirements.
Requirements captured at design time are never checked against what shipped, so the built application drifts from what was specified.
Questions your auditor will ask
Are security requirements defined before an application is built, or discovered afterward?
Threats and security requirements, including authentication and data-handling rules, are documented before development starts, then verified against what ships.
How are API-specific requirements different from general application requirements?
APIs have their own documented rules for authentication, authorization and data handling, tested before release and monitored once live.
What stops an API endpoint from being deployed without authentication?
Authentication, per-endpoint authorization and rate limiting are enforced technically at the API gateway, not left to individual developers to remember.
Who owns the decision on what security requirements an application must meet?
The documented policy assigns the requirement-setting step to a named role before the project's design phase closes.
Where regulation demands it
NIS2 Article 21 ties application security requirements to the secure development life cycle obligation (6.2) and authentication controls (11.6).
ENS mp.s.2 requires protecting web services and applications, the operational expression of A.8.26's requirements.
Related controls
Via the shared Sekit CSF topic, not the framework's own index.