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.
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 Standard Actually Requires

Figure · Process

What A.8.26 asks you to do

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

This control is about shifting security left, embedding security into the earliest phase of the application lifecycle, before a single line of code is written. The standard expects organizations to:

1. Establish a formal process for defining security requirements for all applications (new and existing)
2. Include security in the requirements phase, not as an afterthought during testing or deployment
3. Cover functional and non-functional security requirements, what the application must do (e.g., authentication) and what constraints it must operate under (e.g., performance under load)
4. Link requirements to business and security risks, every requirement must be justified by a risk
5. Review and approve requirements before development or acquisition proceeds
6. Maintain traceability, requirements must be traceable through design, implementation, testing, and operation

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 impact 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 premium-tier 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 transformation: UPI transactions crossed 10 billion per month in 2024; payment apps must define security requirements for fraud prevention, 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)

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 (OWASP), 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: "The system shall encrypt cardholder data at rest using AES-256" (REQ-PCI-01)
• DPDP Act 2023: "The system shall implement data minimization and purpose limitation" (REQ-DPDP-01)
• RBI guidelines: "The system shall maintain transaction logs for 7 years" (REQ-RBI-01)
• GDPR: "The system shall support data subject access requests within 30 days" (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. 
Password-only authentication has been the root cause of 80% of breaches in 
administrative interfaces (Verizon DBIR 2024).
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 guidance)
  - 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 policies, 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 AI/ML Security Master Course):

• 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

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

Indian Tool Vendors and Service Providers

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 premium-tier"

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

Reality: Requirements prevent 40-60% of vulnerabilities. The impact of NOT defining requirements is 10-100x higher in production.

Solution:

• Show overhead comparison: requirements phase vs. production vulnerability remediation
• Demonstrate audit efficiency: traceability reduces audit overhead by 30%
• 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 AI/ML security requirements catalog (see Section 8.2)
• Include adversarial testing requirements
• Define model governance and explainability requirements
• Train teams on AI/ML security (Singahi's AI/ML Security Master Course)

Illustrative Scenarios

Illustrative scenario, a composite example for guidance, not a specific Singahi engagement or a verified outcome.

Illustrative Scenario 1: Indian Fintech Startup, Payment Gateway Security Requirements

Organization: A fintech startup in Bengaluru building a payment gateway for Indian merchants. Context: 50 employees, 3 developers, processing 100,000 transactions/day. PCI DSS compliance required for card processing. DPDP Act 2023 compliance required for customer data. Challenge: No security requirements process. Developers were writing code without any security specifications. First penetration test revealed 47 critical vulnerabilities. Approach:

1. Week 1: Singahi consultants conducted a workshop on security requirements. Defined a lightweight template suitable for small Agile teams.
2. Week 2: Threat modeling workshop using STRIDE for the payment gateway. Identified 12 threats, including card data exposure, API abuse, and fraud.
3. Week 3: Documented 35 security requirements covering authentication, encryption, input validation, logging, and fraud detection.
4. Week 4: Review board (founder, tech lead, Singahi consultant) approved requirements. Traced requirements to user stories in Jira. Results:

• Next penetration test: 3 critical vulnerabilities (93% reduction)
• PCI DSS compliance achieved in first audit attempt
• Security user stories became 20% of sprint backlog
• Development velocity initially dropped 15% but recovered as security became routine
• impact of security requirements process: (one-time) + /month (ongoing)
• impact of first penetration test remediation without requirements: Key Lesson: Even small teams benefit from lightweight security requirements. The impact of requirements is 15% of the impact of fixing vulnerabilities after the fact.

Illustrative Scenario 2: Large Indian Bank, Core Banking System Enhancement

Organization: A national bank with 2,000+ branches, modernizing core banking system. Context: 500+ IT staff, 200+ applications, legacy COBOL systems being migrated to microservices. RBI compliance mandatory. Project budget: . Challenge: Core banking system had no documented security requirements from original development (1980s). Enhancement team was adding features without security context. RBI inspection flagged "inadequate security design." Approach:

1. Phase 1 (Month 1): Singahi conducted enterprise security requirements assessment. Defined enterprise-wide security requirements policy and standardized templates.
2. Phase 2 (Months 2-3): PASTA threat modeling for the core banking microservices. Identified 45 threats including data integrity, authorization bypass, and API abuse.
3. Phase 3 (Months 4-6): Documented 150+ security requirements across authentication, authorization, encryption, audit logging, fraud detection, and data integrity.
4. Phase 4 (Months 7-9): Review board (CISO, CTO, compliance head, external auditor) approved requirements. Established traceability in IBM DOORS.
5. Phase 5 (Ongoing): Integrated requirements into CI/CD pipeline. Automated security testing validates requirements in each build. Results:

• Security requirements process became mandatory for all 200+ applications
• RBI inspection: zero findings on security design
• Vulnerability density in new code: 0.2 per 1000 LOC (industry average: 1.5)
• Security testing in CI/CD catches 85% of issues before deployment
• impact of requirements program: /year
• Estimated impact of RBI penalties and breach remediation avoided: +
• Time to security audit readiness: reduced from 6 months to 2 weeks Key Lesson: Enterprise-scale security requirements require investment in tools, training, and governance, but the return is exponential in risk reduction and compliance confidence.

Multi-Framework Mapping

OWASP ASVS Mapping

PCI DSS 4.0 Mapping

DPDP Act 2023 Mapping

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

Mandatory Documentation

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 Section 13 for a full KPI framework.

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 Section 8.2 and our AI/ML Security Master Course.

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-64 Rev 2, Security Considerations in the System Development Life Cycle. NIST, 2008.
5. OWASP Application Security Verification Standard (ASVS) v4.0.3. OWASP, 2023.
6. OWASP Top 10:2021, The Ten Most Critical Web Application Security Risks. OWASP, 2021.
7. OWASP Software Assurance Maturity Model (SAMM) v2.0. OWASP, 2020.
8. BSIMM12, Building Security In Maturity Model. Synopsys, 2023.
9. PCI DSS v4.0, Payment Card Industry Data Security Standard. PCI SSC, 2022.
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 Threat Model, Microsoft SDL, 2007.
14. PASTA Threat Model, OWASP, 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 Cyber Security Framework, Reserve Bank of India, 2024.
18. SEBI Cybersecurity and Cyber Resilience Framework, Securities and Exchange Board of India, 2023.
19. IRDAI Guidelines on Information and Cybersecurity, Insurance Regulatory and Development Authority of India, 2023.
20. IT Act 2000 (as amended), Ministry of Electronics and Information Technology, India.

Industry Research

21. IBM impact of a Data Breach Report 2024, IBM Security and Ponemon Institute, 2024.
22. Verizon Data Breach Investigations Report 2024, Verizon, 2024.
23. NIST Software Assurance Metrics and Tool Evaluation, NIST, 2022.
24. Forrester TEI of Application Security, Forrester Research, 2023.
25. Gartner Market Guide for Application Security Testing, Gartner, 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, Wiley, 2022.
30. Singahi AI/ML Security Master Course, /