ISO 27001 A.8.26: Application Security Requirements

Quick Reference (60 Seconds)

Control: A.8.26, Application Security Requirements
Purpose: Define and specify security requirements for applications, ensuring security is built into applications from the start rather than bolted on later.
ISO 27002 attributes: Control type: Preventive · Properties: Confidentiality, Integrity, Availability · Concepts: Protect · Capabilities: Application security, System and network security · Domains: Protection, Defence
Who it applies to: All organizations that develop, acquire, or deploy applications (internal or customer-facing).
Minimum viable actions:

• Establish an application security requirements process (policy + template)
• Define security requirements for every new application or major change
• Review requirements with security stakeholders before development begins
• Maintain a requirements register linked to risk assessments

Key deliverables: Application Security Requirements Document, Security Requirements Traceability Matrix, Approved Requirements Register.

Audit questions you should be able to answer:

• Can you show me the security requirements for [application name]?
• How do you ensure security requirements are defined before development starts?
• Who approves application security requirements?
• How are requirements traced to design, implementation, and testing?

What the Control Asks For

Do you need this control?

A.8.26 is not mandatory in itself: under clause 6.1.3 you include it if your risk assessment calls for it, and record the decision in your Statement of Applicability. Include it if you develop, acquire or configure applications whose security requirements must be defined. Even buyers of SaaS need security requirements for what they procure.

Annex A 8.26 asks organizations to identify, specify and approve information security requirements when developing or acquiring applications.

What ISO 27002:2022 Adds

ISO/IEC 27002:2022 (8.26), paraphrased. Requirements are usually set through a risk assessment, with help from information security specialists. As applicable, they cover:

• (a) how much trust is needed in the identity of users and systems (authentication, 5.17, 8.2, 8.5);
• (b) the type and classification of information the application handles;
• (c) segregation of access and the level of access to data and functions;
• (d) resilience against attacks and accidental disruption (for example injection and buffer overflows);
• (e) legal and regulatory requirements in each jurisdiction where a transaction is generated, processed, completed or stored;
• (f) privacy needs of everyone involved;
• (g) protection of confidential information;
• (h) protection of data while processed, in transit and at rest;
• (i) encrypting communications between all parties;
• (j) input controls, including integrity checks and validation;
• (k) automated controls such as approval limits and dual approval;
• (l) output controls, including who may see outputs;
• (m) limits on free-text fields, which can lead to uncontrolled storage of personal or confidential data;
• (n) requirements from the business process, such as transaction logging, monitoring and non-repudiation;
• (o) requirements set by other controls, such as interfaces to logging, monitoring or data-leakage detection;
• (p) error-message handling.

Transactional services between the organisation and a partner add: the trust each party needs in the other's identity; integrity of exchanged information and how loss of integrity is detected (hashes, signatures); who may approve, issue or sign key documents; confidentiality, integrity, proof of dispatch and receipt, and non-repudiation of key documents; confidentiality and integrity of transactions; how long a transaction must stay confidential; and insurance and other contractual requirements.

Electronic ordering and payment applications add: confidentiality and integrity of order information; how far to verify the customer's payment information; avoiding loss or duplication of transactions; keeping transaction details out of publicly accessible environments; and, where a trusted authority issues certificates or signatures, building security into the whole certificate or signature process.

Cryptography (8.24) addresses many of these, subject to legal requirements (5.31 to 5.36).

In practice you will also want: a repeatable process; requirements written before build or purchase; review and approval; and traceability from requirement to test. These are good practice rather than words in the standard.

What the Standard Does NOT Require

• The standard does not mandate a specific requirements methodology (Waterfall, Agile, DevOps)
• It does not require all requirements to be documented in a single monolithic document
• It does not specify particular security controls, the requirements should reflect your risk assessment
• It does not require security requirements for trivial changes (bug fixes, cosmetic updates)

Why Application Security Requirements Matter

The Cost of Late Security

When security requirements are skipped:

• Architectural flaws are baked into the system and cannot be fixed without redesign
• Compliance gaps are discovered at audit time, requiring expensive rework
• Vulnerability remediation becomes a continuous firefight instead of planned prevention
• Customer trust erodes when security incidents reveal fundamental design weaknesses

The Indian Context

Indian organizations face unique challenges:

• Rapid digital payments growth: UPI passed 10 billion transactions a month in August 2023 (NPCI); payment apps must define requirements for fraud prevention, idempotency, encryption and API security
• DPDP Act 2023: Organizations must define requirements for data principal rights, consent management, and breach notification
• Startup ecosystem: Early-stage companies often skip requirements to ship faster, accumulating technical security debt
• Outsourced development: Offshore development teams need explicit security requirements to avoid assumptions

Scope and Applicability

In Scope

This control applies to:

• All new applications: whether developed in-house, outsourced, or purchased as COTS
• Major enhancements to existing applications that change security posture (new modules, integrations, data handling)
• Application integrations: APIs, middleware, third-party connectors
• Cloud-native applications: serverless, containerized, microservices architectures
• Mobile applications: iOS, Android, cross-platform
• AI/ML applications: models, inference pipelines, training systems

Out of Scope (with caveats)

• Minor bug fixes: patches that don't change security architecture
• Purely cosmetic changes: UI updates with no security impact
• Infrastructure-only changes: network, server, or storage updates (covered by A.8.1, A.8.2)
• End-user configuration changes: settings adjustments within defined parameters

Caveat: When in doubt, document the security impact assessment. A "minor" change that adds a new API endpoint or changes authentication flow IS in scope.

Applicability by Organization Type

Key Definitions and Terminology

Relationship to Other Controls

Directly Related Controls

Framework Mapping

Implementation Roadmap (Week-by-Week)

Figure · Tiers

Maturity levels for application security requirements

Phase 1: Foundation (Weeks 1–2)

Week 1: Policy and Governance

• Draft the Application Security Requirements Policy
• Define scope, roles, and approval workflow
• Identify applications in scope (inventory)
• Select requirements methodology (template-based, user stories, or hybrid)

Week 2: Templates and Standards

• Create the Security Requirements Template
• Define the Security Requirements Traceability Matrix format
• Establish the requirement classification scheme (must/should/could)
• Create the abuse case template

Deliverables: Policy draft, Requirements Template, SRTM template, Abuse Case template

Phase 2: Pilot (Weeks 3–4)

Week 3: Pilot Application

• Select one new application or enhancement for pilot
• Conduct threat modeling (e.g., STRIDE, PASTA, or ATT&CK)
• Elicit security requirements from stakeholders
• Document requirements in the template
• Map requirements to risks in the risk register

Week 4: Review and Refinement

• Conduct peer review of requirements
• Validate with development team (feasibility check)
• Validate with security team (risk coverage check)
• Refine templates based on feedback
• Obtain management approval for the requirements document

Deliverables: Pilot application security requirements, Review feedback log, Updated templates

Phase 3: Rollout (Weeks 5–8)

Week 5–6: Process Integration

• Integrate requirements process into SDLC/SDLC gates
• Integrate with project management methodology (Waterfall, Agile, DevOps)
• Train requirements analysts, product managers, and security team
• Create the Security Requirements Register (master list)

Week 7–8: Full Deployment

• Apply to all new applications and major enhancements
• Conduct quality assurance on requirements completeness
• Establish the requirement review board
• Deploy requirements traceability in ALM/SDLC tools

Deliverables: Integrated process, Training records, Requirements Register, Quality assurance report

Phase 4: Optimization (Weeks 9–12)

Week 9–10: Metrics and Monitoring

• Define and collect KPIs (see Section 13)
• Conduct first internal audit of requirements process
• Identify gaps and improvement opportunities
• Update requirements catalog based on new threats and vulnerabilities

Week 11–12: Continuous Improvement

• Update requirements templates with lessons learned
• Automate requirement traceability where possible
• Integrate with vulnerability management (new CVEs trigger new requirements)
• Update training materials

Deliverables: KPI dashboard, Internal audit report, Updated templates, Process improvement plan

Maturity Model

Detailed Implementation Guidance

The Security Requirements Process

The security requirements process follows this lifecycle:

Identify Application → Classify Risk → Threat Model → Elicit Requirements → 
Document Requirements → Review & Approve → Trace to Design → Validate in Testing → 
Verify in Operation → Update Requirements

Step 1: Identify the Application

For every new application or major enhancement, document:

• Application name and purpose
• Business owner and technical owner
• Data types processed (public, internal, confidential, restricted)
• User types and volumes
• Regulatory requirements (PCI DSS, HIPAA, DPDP Act, RBI, etc.)
• Technology stack (language, framework, database, infrastructure)
• Integration points (APIs, third-party services, legacy systems)
• Deployment model (on-premise, cloud, hybrid, SaaS)

Step 2: Classify the Risk

Use the organization's risk classification scheme to determine the security rigor:

Step 3: Threat Modeling

Threat modeling is the foundation of security requirements. Use one of these methodologies:

STRIDE (Microsoft): Identify threats by category:

• Spoofing, Can an attacker impersonate a user or system?
• Tampering, Can data be modified in transit or at rest?
• Repudiation, Can actions be denied without traceability?
• Information Disclosure, Can sensitive data be exposed?
• Denial of Service, Can the system be made unavailable?
• Elevation of Privilege, Can a user gain unauthorized access?

PASTA (Process for Attack Simulation and Threat Analysis; UcedaVélez and Morana, VerSprite): Seven-stage process:

1. Define objectives
2. Define technical scope
3. Application decomposition
4. Threat analysis
5. Vulnerability analysis
6. Attack enumeration
7. Risk and impact analysis

ATT&CK (MITRE): Map to known adversary tactics and techniques

Example Threat Model Output (STRIDE):

Step 4: Elicit Security Requirements

Requirements come from multiple sources:

Source 1: Threat Models

• Every threat maps to one or more requirements
• Prioritize by risk rating

Source 2: Compliance and Regulatory Obligations

• PCI DSS v4.0.1: "The system shall render stored PAN unreadable using strong cryptography" (REQ-PCI-01, PCI 3.5.1)
• DPDP Act 2023: "The system shall collect only the personal data named in the notice (s.5), process it only within the consent given (s.6), and erase it when the purpose is served or consent is withdrawn (s.8(7))" (REQ-DPDP-01)
• Record keeping: "The system shall retain transaction records for the period law requires, for example five years under PMLA s.12 for reporting entities" (REQ-REC-01)
• GDPR: "The system shall support data subject access requests within one month" (REQ-GDPR-01)

Source 3: Organizational Security Policies

• Password policy: "The system shall enforce minimum password length of 12 characters" (REQ-PWD-01)
• Encryption policy: "The system shall use TLS 1.3 for all external communications" (REQ-CRYPT-03)
• Logging policy: "The system shall log all administrative actions to a centralized SIEM" (REQ-LOG-02)

Source 4: Industry Standards and Best Practices

• OWASP ASVS: "The system shall validate all input on the server side" (REQ-VAL-02)
• OWASP Top 10: "The system shall use parameterized queries to prevent SQL injection" (REQ-INJ-01)
• CWE Top 25: "The system shall sanitize all output to prevent XSS" (REQ-OUT-01)

Source 5: Business Requirements

• Availability: "The system shall maintain 99.9% uptime during business hours" (REQ-AVAIL-01)
• Performance: "The system shall process 10,000 transactions per minute" (REQ-PERF-01)
• Scalability: "The system shall scale to 1 million users without architecture change" (REQ-SCALE-01)

Source 6: Abuse Cases

• Normal use case: "User submits feedback form"
• Abuse case: "Attacker submits feedback form with SQL injection payload to extract database schema"
• Requirement: "The system shall validate and sanitize all form inputs using a whitelist approach" (REQ-VAL-03)

Step 5: Document Requirements

Each requirement must be documented with:

Example Requirement Documentation:

Requirement ID: REQ-AUTH-01
Category: Functional Security
Priority: Must
Risk Reference: T-001 (Spoofing), Risk-045 (Unauthorized account access)
Description: The system shall require multi-factor authentication (MFA) for all 
administrative users accessing the administration console. MFA shall use TOTP 
or hardware token-based authentication.
Rationale: Administrative accounts are high-value targets for attackers, 
and stolen passwords are a leading way in (see the Verizon DBIR).
Source: STRIDE threat model, Organizational Authentication Policy v2.3
Verification Method: Functional testing (demonstrate MFA prompt), 
Configuration review (verify MFA enforced in policy)
Acceptance Criteria:
  - All admin login attempts require MFA
  - SMS-based MFA is not accepted (NIST SP 800-63B treats SMS as a restricted authenticator)
  - MFA bypass is not possible via API manipulation
  - Failed MFA attempts are logged and alerted
Owner: Development Team Lead
Target Date: 2026-03-15
Status: Approved

Step 6: Review and Approve Requirements

Establish a Security Requirements Review Board with:

• Security Architect (reviews threat coverage)
• Development Lead (reviews feasibility)
• Business Owner (reviews business alignment)
• Compliance Officer (reviews regulatory coverage)
• QA Lead (reviews testability)

Review criteria:

• Are all threats from the threat model addressed?
• Are requirements clear, testable, and unambiguous?
• Are priorities aligned with risk ratings?
• Are requirements feasible within project constraints?
• Are acceptance criteria specific and measurable?
• Are regulatory requirements complete?

Step 7: Trace Requirements to Design, Implementation, and Testing

Create a Security Requirements Traceability Matrix (SRTM):

Tools for traceability:

• Jira + Xray (test management)
• Azure DevOps (work item linking)
• GitHub + CodeQL (code-to-requirement mapping)
• DOORS (enterprise requirements management)
• Jama Connect (requirements + test management)
• Spreadsheet (small organizations)

Step 8: Validate Requirements in Testing

Security testing must validate that requirements are met:

Step 9: Verify in Operation

After deployment, verify requirements remain satisfied:

• Monitor security metrics (failed logins, input validation errors, encryption compliance)
• Conduct periodic security assessments
• Review requirements when new threats emerge

Step 10: Update Requirements

Security requirements are living documents:

• Update when new CVEs affect the technology stack
• Update when regulations change
• Update when business requirements change
• Update when new threats are identified
• Review annually at minimum

Requirements for Different Application Types

Web Applications

Key security requirement areas:

• Authentication: MFA, password policy, session management, OAuth/OIDC
• Authorization: RBAC, ABAC, least privilege
• Input Validation: Whitelist validation, parameterized queries, output encoding
• Output Encoding: Context-aware encoding (HTML, JavaScript, CSS, URL)
• Session Management: Secure cookies, session timeout, session fixation prevention
• Cryptography: TLS 1.3, certificate pinning, key management
• Error Handling: Generic error messages, no stack traces in production
• Logging: Security event logging, tamper-evident logs
• API Security: Rate limiting, authentication, input validation, CORS

Mobile Applications

Additional requirements:

• Local Storage: Encrypted storage, no sensitive data in device backups
• Code Obfuscation: Anti-tampering, root/jailbreak detection
• Network Security: Certificate pinning, no cleartext traffic
• Biometric Authentication: Fingerprint/face unlock integration
• App Distribution: Code signing, app store security review
• Clipboard Security: Prevent sensitive data in clipboard
• Screenshot Protection: Block screenshots of sensitive screens
• Keyboard Security: Disable custom keyboards on sensitive fields

Cloud-Native Applications

Additional requirements:

• Identity and Access Management: IAM roles, service accounts, least privilege
• Container Security: Image scanning, non-root execution, read-only filesystems
• Orchestration Security: RBAC in Kubernetes, Pod Security Standards (admission control), network policies
• Secrets Management: No hardcoded secrets, vault integration, rotation
• Serverless Security: Function-level permissions, cold start protection, event injection prevention
• Infrastructure as Code: Security scanning of Terraform/CloudFormation templates
• Observability: Distributed tracing, security metrics in cloud monitoring

AI/ML Applications

Additional requirements (see also the OWASP Top 10 for LLM Applications and the NIST AI Risk Management Framework):

• Model Security: Adversarial strength, model poisoning prevention, model extraction protection
• Data Security: Training data privacy, synthetic data generation, data leakage prevention
• Inference Security: Prompt injection prevention (LLMs), input sanitization, output filtering
• Explainability: Security-relevant decision explanations, bias detection
• MLOps Security: Secure pipelines, model versioning, access control to model artifacts
• LLM-Specific: RAG security, vector DB access control, hallucination mitigation

API-First Applications

Additional requirements:

• Authentication: OAuth 2.0, JWT, API keys, mTLS
• Authorization: Scope-based access, fine-grained permissions
• Rate Limiting: Tiered limits, burst handling, DDoS protection
• Input Validation: JSON Schema validation, content-type enforcement
• Versioning: Security considerations in API versioning strategy
• Documentation: Security parameters in OpenAPI specs, no exposed internal endpoints
• Error Handling: Standardized error responses without information leakage

Transactional and Payment Applications (27002 8.26)

For applications that exchange transactions with partners or take orders and payments, add these requirement packs:

India Fintech Requirement Set

• RBI Master Direction on Digital Payment Security Controls (2021) (it applies to banks, small finance banks, payments banks and credit-card-issuing NBFCs; fintechs working with them usually inherit it through contracts): set requirements for device binding, session timeouts, transaction limits set by the customer, real-time alerts, and secure application design for mobile and internet banking.
• Additional factor of authentication: follow the current RBI directions on authentication for digital payment transactions that apply to you.
• UPI and card payments: idempotency and reconciliation (REQ-TXN-01, 02); follow NPCI and card-network rules; card-on-file tokenisation instead of storing card numbers.
• CERT-In: log the events needed to meet the 6-hour incident reporting rule, and keep ICT logs for 180 days in India.

Free-Text Fields (27002 8.26(m))

Comment boxes and notes fields collect data nobody planned for: Aadhaar numbers, PAN, health details, card numbers. Requirements:

• REQ-FT-01: Validate free-text input and block or mask patterns such as Aadhaar (12 digits), PAN (AAAAA9999A) and card numbers (Luhn check).
• REQ-FT-02: Show a hint telling users not to enter personal or financial details.
• REQ-FT-03: Include free-text fields in DLP scanning (A.8.12) and in data-retention rules.
• REQ-FT-04: Limit length and character set where the business allows.

Acquired Applications (COTS and SaaS)

27002 8.26 applies when you acquire applications too. Before buying:

• send a security questionnaire built from your requirement catalogue;
• ask for an ISO 27001 certificate (check the scope) or a SOC 2 Type 2 report;
• confirm data location and residency, encryption, SSO and MFA support, logging and log export, and backup and exit terms;
• record which requirements the product meets, which you will meet by configuration, and which gaps you accept;
• put the key requirements into the contract (A.5.20).

Agile and DevOps Integration

In Agile environments, security requirements must be lightweight but effective:

Security User Stories:

As a [role], I want [security capability], so that [security benefit]

Example: As a customer, I want my payment card details to be encrypted 
using AES-256, so that my financial information is protected even if 
the database is compromised.

Security Definition of Done:

• All high-risk threats are addressed by implemented requirements
• Security requirements are traced to test cases
• Security tests pass in CI/CD pipeline
• SAST/DAST scan results have no critical/high findings
• Security review is complete in sprint review

Security Spikes:

• Dedicate sprints to security architecture when needed
• Use spikes for threat modeling, security architecture review, or tool evaluation

Security Champions:

• Embed security champions in each development team
• Champions review requirements and participate in threat modeling
• Champions bridge security team and development team

Tools, Technologies, and Solutions

Requirements Management Tools

Threat Modeling Tools

SAST/DAST Tools (for Requirements Validation)

Requirements Catalogs and Standards

Policy and Procedure Templates

Application Security Requirements Policy (Template)

Security Requirements Review Procedure (Template)

Risk Assessment and Treatment

Risk Assessment for Security Requirements

Risk Treatment Options

Audit and Compliance Checklist

Pre-Audit Self-Assessment

Auditor Interview Questions

Be prepared to answer:

1. "Show me the security requirements for [specific application]."
2. "How do you ensure security is considered before development begins?"
3. "Who is responsible for defining security requirements?"
4. "How do you trace security requirements through the development lifecycle?"
5. "What threat modeling methodology do you use?"
6. "How do you handle security requirements in Agile development?"
7. "How do you ensure requirements remain current with new threats?"
8. "Show me evidence that requirements were reviewed and approved."
9. "How do you handle third-party application security requirements?"
10. "What happens when security requirements conflict with business deadlines?"

Common Audit Findings and How to Avoid Them

Metrics and KPIs

Process Metrics

Outcome Metrics

Dashboard Sample

┌─────────────────────────────────────────────────────────────────────┐
│           APPLICATION SECURITY REQUIREMENTS DASHBOARD               │
│                    [Organization] — [Month Year]                      │
├─────────────────────────────────────────────────────────────────────┤
│  REQUIREMENTS COVERAGE: 98%  ████████████████████░░  Target: 100%  │
│  REVIEW RATE: 100%         ████████████████████████  Target: 100%  │
│  TRACEABILITY: 92%         ██████████████████░░░░░░  Target: 95%   │
│  THREAT MODEL COVERAGE: 100% ██████████████████████  Target: 100%  │
│  VULNERABILITY DENSITY: 0.3  █░░░░░░░░░░░░░░░░░░░  Target: <0.5  │
│  SECURITY TEST PASS: 97%   ███████████████████░░░  Target: 95%  │
│  PROD DEFECTS: 1           ░░░░░░░░░░░░░░░░░░░░░░  Target: <2    │
│  REVIEW CYCLE TIME: 4.2 days ████████████████████░  Target: <5    │
│  EXCEPTION RATE: 2%        █░░░░░░░░░░░░░░░░░░░░░  Target: <5%   │
└─────────────────────────────────────────────────────────────────────┘

Common Pitfalls and How to Avoid Them

Pitfall 1: "Security Requirements Are Too expensive"

Symptom: Management pushes back on requirements process as a cost center.

Reality: A flaw designed out at the requirements stage costs far less than one found in production, when it may need a redesign.

Solution:

• Show cost comparison: requirements phase vs. production vulnerability remediation
• Show that traceability makes audits and customer security reviews faster
• Start with critical applications only, expand gradually

Pitfall 2: "Agile Teams Can't Do Requirements"

Symptom: Agile teams reject formal requirements as "waterfall."

Reality: Agile requires lightweight requirements, not no requirements. Security user stories and acceptance criteria are Agile-native.

Solution:

• Use security user stories, not formal documents
• Embed security in Definition of Done
• Use security spikes for architecture
• Show that security requirements reduce sprint firefighting

Pitfall 3: "Copy-Paste Requirements from Templates"

Symptom: All applications have identical requirements, regardless of risk or technology.

Reality: Templates are starting points, not final answers. Requirements must be tailored to each application's threat model and context.

Solution:

• Template provides framework; analysts fill in specifics
• Threat modeling drives requirement selection
• Review board checks for appropriateness
• Update templates with organization-specific patterns

Pitfall 4: "Requirements Are Written and Forgotten"

Symptom: Requirements document is created but never referenced again.

Reality: Requirements must be living documents, traced through the entire lifecycle and updated when context changes.

Solution:

• Automate traceability in ALM tools
• Include requirements in sprint reviews
• Review requirements at major milestones
• Trigger updates from CVE feeds and threat intelligence

Pitfall 5: "No One Reviews Requirements"

Symptom: Requirements are written but never reviewed, leading to gaps.

Reality: Review is where quality happens. Multiple perspectives catch what one person misses.

Solution:

• Establish a review board with mandatory attendance
• Use a structured review checklist
• Record review feedback and resolution
• Track review cycle time as a KPI

Pitfall 6: "Third-Party Apps Are Excluded"

Symptom: COTS and SaaS applications have no security requirements.

Reality: Third-party applications are often the weakest link. You must define requirements for vendor selection and configuration.

Solution:

• Include vendor security requirements in RFPs
• Require vendor security documentation (SOC 2, ISO 27001)
• Define configuration security requirements
• Include security requirements in contract SLAs

Pitfall 7: "Business Overrules Security"

Symptom: Security requirements are bypassed to meet deadlines.

Reality: This creates risk that may materialize as breach, compliance failure, or reputational damage.

Solution:

• Risk acceptance process with executive sign-off
• Security gates in SDLC that cannot be bypassed without CISO approval
• Board-level reporting on security requirements adherence
• Metrics that make bypasses visible

Pitfall 8: "AI/ML Security Is Different"

Symptom: AI/ML applications have no security requirements because "AI is new."

Reality: AI/ML applications have additional security requirements (adversarial strength, model security, data privacy) but they still need requirements.

Solution:

• Use the AI/ML requirements in the application-types section above
• Include adversarial testing requirements
• Define model governance and explainability requirements
• Train teams on AI/ML security (OWASP Top 10 for LLM Applications, NIST AI RMF, ISO/IEC 42001)

Illustrative Scenarios

Hypothetical scenarios: composite examples for guidance, not real organisations or verified outcomes.

Scenario 1: Payment Gateway Without Transaction Requirements

Situation. A small Indian payment gateway's API retries timed-out requests from merchants. There is no idempotency requirement, so during a network slowdown some customers are debited twice. Refunds can be issued by any support agent with no approval limit.

What the requirements process adds.

1. A STRIDE threat model of the payment flow identifies duplication, tampering with callbacks, and refund abuse.
2. Requirements REQ-TXN-01 to REQ-TXN-05 are added: idempotency keys, daily reconciliation, signed callbacks, maker-checker for refunds above a limit, and an audit trail.
3. Each requirement gets a test case in the SRTM; the pipeline runs the duplicate-request test on every build.
4. The free-text "notes" field on refunds gets the PII guard (REQ-FT-01).

Lesson. 27002's ordering and payment points (loss or duplication, dual approval, non-repudiation) are exactly where payment products fail.

Scenario 2: Bank Enhancement With No Documented Requirements

Situation. A bank is moving parts of a legacy core system to microservices. The original system has no recorded security requirements, and new features are being added without them.

What the requirements process adds.

1. A requirements policy and template, with a review board (security architect, development lead, compliance, business owner).
2. Threat modelling of the new services and their APIs; requirements for authentication, authorisation between services, encryption, logging, transaction integrity and maker-checker.
3. Requirements written only for new and changed components, not retroactively for all legacy code.
4. Traceability from each requirement to design, code and test, and automated security tests in CI.

Lesson. Start with what is changing. Requirements for every enhancement, traced to tests, give auditors and regulators a clear trail.

Multi-Framework Mapping

OWASP ASVS Mapping

ASVS chapters (authentication, session management, access control, validation, cryptography, error handling and logging, data protection, communications, business logic, files, APIs, configuration) give ready-written, testable requirements. ASVS 5.0 (May 2025) reorganised the chapters; reference the version you use in your requirement IDs.

PCI DSS v4.0.1 Mapping

DPDP Act 2023: Requirements to Build In

NIST SP 800-53 Rev 5 Mapping

COBIT 2019 Mapping

CIS Controls v8 Mapping

Regulatory and Industry Context

India

International

Roles and Responsibilities (RACI)

RACI Matrix for Application Security Requirements

Legend: R = Responsible, A = Accountable, C = Consulted, I = Informed

Role Descriptions

Documentation and Evidence Requirements

Recommended Documentation

ISO 27001 does not mandate specific documents for this control. If you select it, keep the documented information you need to show it is planned and working (clause 7.5), and set retention in your own retention schedule. Typical records:

Evidence for Audit

Continuous Improvement

Improvement Cycle

Plan → Implement → Measure → Review → Improve

Plan: Set targets for requirements coverage, review cycle time, vulnerability density.

Implement: Execute requirements process, collect metrics, gather feedback.

Measure: Track KPIs, conduct surveys, analyze audit results.

Review: Monthly metrics review, quarterly process review, annual complete review.

Improve: Update templates, enhance training, adopt new tools, refine threat models.

Improvement Triggers

Maturity Advancement Path

FAQ

Q1: Do we need security requirements for minor bug fixes?

A: No, but you must assess the security impact. If the bug fix changes authentication, authorization, input validation, or any security control, security requirements must be reviewed and updated.

Q2: How do we handle security requirements in Agile/Scrum?

A: Use security user stories, security acceptance criteria, and security Definition of Done. Schedule security spikes for threat modeling and architecture review. Our guide includes Agile-specific templates.

Q3: What if a requirement is not feasible within project constraints?

A: Document the constraint, propose compensating controls, and escalate to the review board. If the risk is acceptable, the CISO can approve an exception with documented risk acceptance.

Q4: How often should security requirements be updated?

A: At minimum, annually. Additionally, update when: new CVEs affect your stack, regulations change, new threats are identified, technology changes, or after a security incident.

Q5: Do COTS/SaaS applications need security requirements?

A: Yes, but the requirements focus on vendor security posture, configuration security, and integration security rather than code-level requirements. See the vendor management guide in the toolkit.

Q6: How do we measure the effectiveness of our security requirements?

A: Track vulnerability density, security test pass rate, production security defects, and audit findings. See Metrics and KPIs above.

Q7: What threat modeling methodology should we use?

A: STRIDE is best for general applications. PASTA is better for risk-driven organizations. ATT&CK is best for threat-intelligence-driven organizations. Start with STRIDE if you're new to threat modeling.

Q8: How do we handle legacy applications that never had security requirements?

A: For legacy applications, conduct a security architecture review and retroactively document requirements for any enhancements or integrations. Do not attempt to retroactively document all legacy code, focus on current risk and future changes.

Q9: Are there security requirements specific to AI/ML applications?

A: Yes, AI/ML applications require additional requirements for adversarial strength, model security, data privacy, explainability, and MLOps security. See the AI/ML section above, the OWASP Top 10 for LLM Applications and the NIST AI Risk Management Framework.

Q10: How do we ensure developers actually read and implement the requirements?

A: Integrate requirements into their tools (Jira, Azure DevOps), make requirements part of sprint planning, conduct security training, use security champions, and verify through code review and security testing.

Q11: What is the difference between a security requirement and a security control?

A: A security requirement is WHAT must be achieved ("The system shall encrypt data at rest"). A security control is HOW it is achieved ("Use AES-256 encryption via the cloud KMS"). Requirements come first; controls implement them.

Q12: How do we prioritize security requirements?

A: Use risk-based prioritization. Critical-risk threats map to "Must" requirements. High-risk threats map to "Must" or "Should." Medium-risk map to "Should" or "Could." Use MoSCoW or similar prioritization.

Q13: Can we use the same requirements for all applications?

A: No. Templates provide a starting point, but each application needs tailored requirements based on its threat model, data classification, technology stack, and regulatory context. Copy-paste requirements lead to gaps and false confidence.

Q14: How do we handle security requirements for outsourced development?

A: Include security requirements in the Statement of Work (SOW), require vendor security documentation, conduct vendor security assessments, and verify requirements through acceptance testing and security testing.

Q15: What is the Security Requirements Traceability Matrix (SRTM)?

A: The SRTM is a document that maps each security requirement to: the threat it addresses, the design element that implements it, the code module that contains it, and the test case that validates it. It provides end-to-end traceability for audit and assurance.

References and Further Reading

Standards and Guidelines

1. ISO/IEC 27001:2022: Information Security, Cybersecurity and Privacy Protection, Information Security Management Systems, Requirements. ISO, 2022.
2. ISO/IEC 27002:2022: Information Security, Cybersecurity and Privacy Protection, Information Security Controls. ISO, 2022.
3. NIST SP 800-53 Rev 5: Security and Privacy Controls for Information Systems and Organizations. NIST, 2020.
4. NIST SP 800-218: Secure Software Development Framework (SSDF) v1.1. NIST, 2022. (SP 800-64 Rev 2 was withdrawn in 2019.)
5. OWASP Application Security Verification Standard (ASVS) 5.0 (2025); v4.0.3 (2021) is still widely used.
6. OWASP Top 10:2025 (final January 2026; the 2021 edition is still widely referenced). OWASP.
7. OWASP Software Assurance Maturity Model (SAMM) v2.0. OWASP, 2020.
8. BSIMM: Building Security In Maturity Model (use the latest edition).
9. PCI DSS v4.0.1: Payment Card Industry Data Security Standard. PCI SSC, 2024.
10. CIS Controls v8: CIS Controls and CIS Benchmarks. Center for Internet Security, 2021.

Threat Modeling Resources

11. Microsoft Threat Modeling Tool: https://www.microsoft.com/en-us/securityengineering/threatmodeling
12. OWASP Threat Dragon: https://owasp.org/www-project-threat-dragon/
13. STRIDE: Loren Kohnfelder and Praerit Garg, Microsoft, 1999.
14. PASTA: Tony UcedaVélez and Marco M. Morana, Risk Centric Threat Modeling, Wiley, 2015.
15. MITRE ATT&CK: https://attack.mitre.org/

Indian Regulatory Resources

16. Digital Personal Data Protection Act 2023: Government of India, 2023.
17. RBI Master Direction on Information Technology Governance, Risk, Controls and Assurance Practices: Reserve Bank of India, 7 November 2023 (in force from 1 April 2024); and RBI Cyber Security Framework in Banks: circular of 2 June 2016.
18. SEBI Cybersecurity and Cyber Resilience Framework (CSCRF) for SEBI Regulated Entities, circular of 20 August 2024.
19. IRDAI Information and Cyber Security Guidelines: Insurance Regulatory and Development Authority of India, 2023. Also: RBI Master Direction on Digital Payment Security Controls, Reserve Bank of India, 18 February 2021.
20. IT Act 2000 (as amended): Ministry of Electronics and Information Technology, India.

Industry Research

21. IBM Cost of a Data Breach Report 2024: IBM Security and Ponemon Institute, 2024.
22. Verizon Data Breach Investigations Report 2024: Verizon, 2024.

Books and Training

26. "Threat Modeling: Designing for Security": Adam Shostack, Wiley, 2014.
27. "The Art of Software Security Assessment": Mark Dowd et al., Addison-Wesley, 2006.
28. "Secure Coding in C and C++": Robert Seacord, Addison-Wesley, 2013.
29. "Application Security Program Handbook": Derek Fisher, Manning, 2023.