Application Security Requirements: How to Define Them Using OWASP ASVS, ISO 27001 and PCI DSS

“The application must be secure” is not a requirement. Developers can’t build to it, testers can’t verify it, and auditors can’t sign off on it. Many security requirements documents still read this way, as a list of goals rather than criteria anyone can check.

You don’t have to write requirements from scratch. OWASP ASVS, ISO 27001 and PCI DSS already set out what a secure application needs. Your job is to turn them into specific, testable application security requirements for your own applications. This guide shows how.

What Are Application Security Requirements?

Application security requirements are the security criteria an application must meet. They’re defined before development starts and verified before release. They fall into two types:

• Functional requirements cover what the application does. Examples are enforcing multi-factor authentication, checking authorization on every request, and validating user input.
• Non-functional requirements cover how the application behaves. Examples are encryption standards, logging, resilience, and how quickly vulnerabilities must be fixed.

Requirements come from three sources: business risk, the sensitivity of the data the application handles, and compliance obligations. They usually sit under a broader application security policy. The policy sets expectations across the organization, and the requirements apply those expectations to a single application.

Core Categories Your Requirements Should Cover

Most application security requirements fall into these categories:

• Authentication and session management: how users prove their identity, and how sessions are created, expired and ended.
• Access control: least privilege, role-based permissions, and server-side checks on every request.
• Data protection: classifying data, plus encrypting it in transit and at rest.
• Input validation and error handling: rejecting malformed input, and making sure errors don’t leak sensitive information.
• Logging and monitoring: which security events are logged, how long logs are kept, and who reviews them.
• Third-party dependencies: rules for adding open-source libraries and keeping them up to date.
• Vulnerability remediation: how quickly findings must be fixed, by severity. This category is often missing, but it decides whether the application security vulnerabilities you find actually get fixed.

Mapping Requirements to Frameworks

OWASP ASVS

The OWASP Application Security Verification Standard is the most practical starting point. It provides a detailed set of verifiable requirements, grouped into three levels:

• Level 1: a baseline for all applications.
• Level 2: for applications that handle sensitive data, which covers most business applications.
• Level 3: for critical applications, such as those in finance, healthcare or critical infrastructure.

Choose a level for each application based on its risk, and that level gives you a ready-made baseline.

ISO 27001 (Annex A Control 8.26)

Control 8.26 requires organizations to identify, specify and approve security requirements when they develop or acquire applications. It doesn’t prescribe specific technical controls. Instead, it expects requirements to reflect data classification, access needs, legal and regulatory obligations, and business needs such as transaction logging.

ASVS gives you the content of your requirements, and ISO 27001 gives you the governance around them.

PCI DSS

PCI DSS applies to any application that stores, processes or transmits cardholder data. Requirement 6 covers secure development: secure coding, protecting public-facing web applications, and managing vulnerabilities in custom and third-party software. Requirement 11 adds regular vulnerability scans and penetration testing.

Treat PCI DSS as an extra layer on top of your baseline for the applications it covers.

The practical approach: use ASVS as your baseline, add compliance-specific requirements where they apply, and map each requirement to the framework controls it satisfies. That way, one piece of evidence can support several audits.

How to Define and Enforce Application Security Requirements

1. Classify the application and its data. This tells you which ASVS level to use and which compliance frameworks apply.
2. Run a threat model. Frameworks cover common risks. Threat modeling finds the risks specific to your application, such as business logic abuse or a risky integration. Turn those findings into additional requirements.
3. Make every requirement testable. “Use strong authentication” can’t be tested. “All administrative accounts require multi-factor authentication, verified in pre-release testing” can.
4. Build requirements into the SDLC. Add them to design reviews, user story acceptance criteria, and CI/CD gates. Application security automation is what keeps those checks consistent without slowing releases down.
5. Keep evidence. Record test results, scan reports and remediation records as you go, rather than rebuilding them before an audit.
6. Review requirements regularly. Update them when the architecture changes, when the application starts handling new types of data, or when regulations change.

Where Seemplicity Fits

Most requirements are enforced when the application is built. Remediation requirements are different, because they depend on what happens after a finding is reported. Findings arrive from SAST, DAST, SCA and penetration tests, each in its own format and often without a clear owner. That makes fix timelines hard to meet and even harder to prove.

Seemplicity aggregates and deduplicates findings across your AppSec tools. It applies risk-based vulnerability prioritization, routes each fix to the team that owns it, and tracks progress against your SLAs. The result is that remediation requirements become measurable, with an audit-ready record of what was fixed and when.

Requirements Are Only as Good as Their Enforcement

Strong application security requirements are specific, grounded in a framework, and testable. Writing them is the easy part. Enforcing them over time, especially when it comes to remediation, is what decides whether your application security program actually reduces risk.