ISO 27001 A.8.29: Security Testing in Development and Acceptance

Quick Reference (60 Seconds)

Control: A.8.29, Security Testing in Development and Acceptance
Purpose: Ensure applications are tested for security vulnerabilities during development and before acceptance into production, catching flaws before they reach live environments.
ISO 27002 attributes: Control type: Preventive · Properties: Confidentiality, Integrity, Availability · Concepts: Identify · Capabilities: Application security, Information security assurance, System and network security · Domains: Protection
Who it applies to: All organizations that develop, acquire, or customize software applications.
Minimum viable actions:

• Define security testing requirements for all applications before acceptance
• Implement SAST in CI/CD for automated code security scanning
• Conduct DAST on staging/pre-production environments
• Perform manual security testing (penetration testing) for critical applications before go-live
• Establish security acceptance criteria that must be met before deployment approval

Key deliverables: Security Test Plan, Security Test Report, Acceptance Criteria Checklist, Vulnerability Remediation Tracker, Security Sign-off Document.

Audit questions you should be able to answer:

• What security testing is performed before applications go live?
• Who approves security testing results?
• Can you show me the security test report for [application name]?
• What happens if security testing finds critical vulnerabilities before go-live?

What the Control Asks For

Do you need this control?

A.8.29 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 or acquire systems that need security testing before acceptance. Buyers of software still need acceptance testing for what they deploy.

Annex A 8.29 asks organizations to define and carry out security testing during the development and acceptance process.

What ISO 27002:2022 Adds

ISO/IEC 27002:2022 (8.29), paraphrased:

• Test thoroughly new systems, upgrades and new versions during development; security testing is part of normal testing.
• Test against requirements (functional and non-functional), including: (a) security functions such as authentication, access restriction and cryptography; (b) secure coding; (c) secure configurations of operating systems, firewalls and other security components.
• Plan tests in proportion to the system's importance and the impact of the change. A test plan includes: (a) a schedule of activities and tests; (b) inputs and expected outputs under a range of conditions; (c) criteria to evaluate results; (d) decisions on further action.
• Automated tools (code analysis, vulnerability scanners) help; verify that security defects have been fixed.
• For in-house development, the development team tests first, then independent acceptance testing checks that the system works as expected and only as expected (5.8). Consider code review (including unexpected inputs), vulnerability scanning and penetration testing.
• For outsourced development and purchased components, follow an acquisition process: put the security requirements in the contract (5.20) and evaluate products against them before buying.
• Test in an environment that matches production as closely as possible (8.31), so tests are reliable and the system does not bring new vulnerabilities into your estate.
• Test and monitor the test environments and tools themselves, as far as the sensitivity of the systems justifies.

What the Standard Does NOT Require

• The standard does not mandate a specific testing methodology (black box, white box, gray box)
• It does not require 100% vulnerability-free code (impossible), but rather systematic testing and acceptable risk
• It does not specify particular tools, but requires that testing be performed and documented
• It does not require manual penetration testing for every minor change, but rather risk-based testing

Why Security Testing in Development and Acceptance Matters

The Cost of Late Discovery

When security testing is skipped or deferred:

• Vulnerabilities reach production where they are exploitable by attackers
• Remediation becomes exponentially more expensive due to production constraints, downtime, and rollback complexity
• Customer trust erodes when security flaws are discovered by customers or attackers rather than internal testing
• Compliance failures occur when auditors discover untested applications in production
• Incident response costs skyrocket because vulnerabilities are unknown and unpatched

The Shift-Left Imperative

"Shift-left" security testing moves testing earlier in the development lifecycle:

Exact multipliers ("100 times" and similar) are widely quoted but hard to trace to primary sources; the direction is what matters. Security testing in development and acceptance is the last line of defense before vulnerabilities reach production. It is where the organization's investment in secure requirements, architecture, and coding is validated.

The Indian Context

Indian organizations face unique security testing challenges:

• Rapid digital transformation: UPI processing 10+ billion transactions monthly requires rigorous testing of payment applications
• Fintech compliance: RBI mandates security testing for payment systems and banking applications
• DPDP Act 2023: Organizations must demonstrate security testing for personal data processing systems
• Startup ecosystem: Limited security budgets mean testing must be efficient and automated
• Outsourced development: Offshore teams may not perform adequate security testing; acceptance testing becomes critical
• AI/ML adoption: New attack surfaces (adversarial examples, model extraction) require specialized testing
• Government Digital India: government applications usually need a security audit by a CERT-In-empanelled auditor before hosting

India Testing Requirements (VAPT)

• CERT-In empanelment. Many Indian regulators and government bodies require vulnerability assessment and penetration testing (VAPT) or security audits by CERT-In-empanelled information security auditing organisations. Check the current empanelled list on the CERT-In website before you appoint a tester.
• SEBI. The Cybersecurity and Cyber Resilience Framework (CSCRF, 2024) requires VAPT by CERT-In-empanelled auditors at the frequency set for your entity category, with findings closed and revalidated within set timelines. Check the circular for your category.
• RBI. The Cyber Security Framework in Banks (2016) and the Master Direction on IT Governance, Risk, Controls and Assurance Practices (2023) expect regular VA/PT of critical and internet-facing systems. Several RBI directions (for example for payment aggregators) ask for audits by CERT-In-empanelled auditors.
• IRDAI and others. The IRDAI Information and Cyber Security Guidelines (2023) and other sector rules set their own audit and testing expectations.
• Government hosting. Applications hosted in government data centres generally need an application security audit and a "safe to host" clearance from a CERT-In-empanelled auditor first.
• Evidence to keep: scope, methodology, the report, the remediation tracker, the retest report and the closure certificate, plus any submission to the regulator.

Scope and Applicability

In Scope

This control applies to:

• All new applications: In-house developed, outsourced, or COTS with customizations
• Major enhancements: New modules, significant feature additions, architecture changes
• Integration projects: APIs, middleware, third-party connectors
• Cloud-native applications: Serverless, containerized, microservices
• Mobile applications: iOS, Android, cross-platform
• AI/ML applications: Models, inference pipelines, training systems
• Infrastructure as Code: Terraform, CloudFormation, Kubernetes manifests
• Database changes: Stored procedures, schema changes, data migration scripts
• Security patch validation: Testing that patches don't introduce new vulnerabilities

Out of Scope (with caveats)

• Minor bug fixes: Patches that don't change security architecture (but security regression testing is recommended)
• Cosmetic changes: UI updates with no security impact
• Configuration-only changes: Settings adjustments (covered by A.8.9)
• Emergency patches: Critical security patches may have expedited testing, but must be tested

Caveat: Even minor changes can introduce security regressions. Automated regression testing should catch these, but manual review of change impact is recommended.

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 security testing in development and acceptance

Phase 1: Foundation (Weeks 1–3)

Week 1: Policy and Scope Definition

• Draft the Security Testing Policy
• Define testing scope (what applications, what types of testing)
• Define testing triggers (new app, major change, periodic, emergency patch)
• Establish risk-based testing tiers

Week 2: Test Strategy and Tool Selection

• Select SAST, DAST, SCA tools for automated testing
• Define manual testing approach (penetration testing, red teaming)
• Create the Security Test Plan template
• Define acceptance criteria and security sign-off process

Week 3: Baseline and Environment Setup

• Establish testing environments (staging, pre-production)
• Run baseline SAST/DAST on existing applications
• Create vulnerability inventory
• Set up testing tools and integrate with CI/CD

Deliverables: Security Testing Policy, Test Strategy, Tool Selection, Baseline Report, Test Environment

Phase 2: Pilot (Weeks 4–6)

Week 4-5: Pilot Application Testing

• Select one critical application for pilot security testing
• Conduct full security testing: SAST, DAST, SCA, manual penetration test
• Document findings and create remediation plan
• Validate acceptance criteria process

Week 6: Process Refinement

• Refine test plan template based on pilot findings
• Update acceptance criteria thresholds
• Improve vulnerability triage process
• Train testers on tools and methodology

Deliverables: Pilot Test Report, Remediation Plan, Updated Templates, Trained Testers

Phase 3: Rollout (Weeks 7–12)

Week 7-9: Organization-Wide Deployment

• Apply security testing to all new applications and major changes
• Integrate SAST/SCA into all CI/CD pipelines
• Establish DAST scheduling for all staging environments
• Implement security acceptance gates

Week 10-12: Manual Testing Program

• Establish penetration testing schedule (quarterly for critical, annually for high)
• Engage external penetration testers for independent validation
• Implement red team exercises for critical applications
• Create vulnerability remediation workflow

Deliverables: Organization-wide testing, CI/CD integration, Penetration Testing Schedule, Remediation Workflow

Phase 4: Optimization (Weeks 13–16)

Week 13-14: Metrics and Monitoring

• Define and collect KPIs (see Section 13)
• Conduct first internal audit of testing process
• Identify gaps and improvement opportunities

Week 15-16: Continuous Improvement

• Implement automated regression testing
• Add fuzzing and advanced testing for critical apps
• Integrate threat intelligence into testing (new CVEs trigger new tests)
• Update testing methodology with emerging techniques

Deliverables: KPI Dashboard, Internal Audit Report, Automated Regression, Updated Methodology

Maturity Model

Detailed Implementation Guidance

Security Testing Lifecycle

The security testing lifecycle follows these phases:

Plan Tests → Prepare Environment → Execute Tests → Analyze Results → 
Report Findings → Remediate Vulnerabilities → Re-test → Sign Off → Deploy

Phase 1: Plan Security Tests

For every application or major change, define:

Testing Scope:

• What components will be tested (frontend, backend, API, database, infrastructure)
• What types of testing will be performed (SAST, DAST, SCA, manual, fuzzing)
• What will NOT be tested (scope exclusions)

Testing Triggers:

• New application: Full testing suite (SAST + DAST + SCA + penetration test)
• Major enhancement: SAST + DAST + targeted manual testing for changed components
• Minor change: SAST + automated regression testing
• Emergency patch: Smoke testing + targeted SAST for patch area
• Periodic: Full DAST + penetration test (quarterly/annually)

Risk-Based Testing Tiers:

Phase 2: Prepare Testing Environment

Environment Requirements:

• Testing environment must mirror production (same OS, same versions, same configurations)
• Test data must be representative but not production data (see A.8.33)
• Testing environment must be isolated from production
• Test environment must have appropriate monitoring and logging
• Access to testing environment must be controlled (testers only)

Test Data Preparation:

• Use synthetic data that covers edge cases, boundary conditions, and attack patterns
• Include known malicious inputs for injection and XSS testing
• Include oversized inputs for buffer overflow and DoS testing
• Include encoded/escaped inputs for filter evasion testing

Tool Configuration:

• SAST rules tuned for the technology stack
• DAST scan configured with authentication credentials
• SCA configured with the organization's vulnerability thresholds
• Penetration testing tools updated to latest versions

Phase 3: Execute Security Tests

Automated Testing (CI/CD):

Developer Commit → Build → Unit Tests → SAST → SCA → Integration Tests → 
Deploy to Staging → DAST → Security Smoke Test → Report Findings

SAST Execution:

• Run on every commit/merge request
• Scan all source files in the application
• Scan infrastructure as code (Terraform, CloudFormation, Kubernetes YAML)
• Generate SARIF output for integration with GitHub/GitLab security dashboards
• Block build on critical/high findings (configurable threshold)

DAST Execution:

• Run on staging environment after deployment
• Authenticated scanning (with test credentials for all user roles)
• Crawl all application paths and API endpoints
• Test for OWASP Top 10 vulnerabilities
• Generate report with exploitability assessment

SCA Execution:

• Run on every build
• Scan all dependency files (package.json, requirements.txt, pom.xml, etc.)
• Check against vulnerability databases (NVD, OSV, GitHub Advisory Database)
• Block build on critical CVEs above threshold
• Generate SBoM for compliance

Manual Testing:

• Penetration Testing: Simulated attack by certified ethical hackers
• Business Logic Testing: Testing for flaws that automated tools cannot find (race conditions, workflow bypasses, privilege escalation)
• API Testing: Specialized testing for REST, GraphQL, SOAP APIs
• Mobile Testing: Testing for mobile-specific vulnerabilities (insecure storage, certificate pinning, code obfuscation)
• Social Engineering Testing: Testing human vulnerabilities (phishing, pretexting) as part of red team exercises

Fuzzing:

• Input fuzzing for API endpoints, file uploads, and form fields
• Protocol fuzzing for network services
• Format fuzzing for file parsers (PDF, XML, JSON, images)
• Memory fuzzing for C/C++ applications (AFL, libFuzzer)

Phase 4: Analyze Results

Vulnerability Triage:

1. Validate findings: Confirm that automated findings are real (not false positives)
2. Assess severity: Use CVSS v3.1 or custom scoring based on exploitability, impact, and likelihood
3. Assess business impact: Consider data sensitivity, regulatory requirements, and business criticality
4. Prioritize for remediation: Critical and high findings first, then medium, then low

Severity Classification:

False Positive Management:

• Document false positives with justification
• Suppress in tool with documented reason
• Review suppression decisions quarterly
• Track false positive rate as a KPI

Phase 5: Report Findings

Security Test Report Contents:

• Executive summary (risk score, critical findings count, go/no-go recommendation)
• Testing scope and methodology
• Findings detailed report (vulnerability description, severity, evidence, impact, remediation)
• Vulnerability matrix (all findings with severity and status)
• Remediation guidance (specific, actionable steps with code examples where applicable)
• Risk acceptance documentation (for findings that will not be fixed)
• Re-testing results (for remediated findings)
• Security sign-off (or conditions for sign-off)

Phase 6: Remediate Vulnerabilities

Remediation Workflow:

1. Vulnerability assigned to development team
2. Developer fixes the vulnerability
3. Fix verified by peer review
4. Re-test to confirm fix (automated or manual)
5. Vulnerability closed in tracking system
6. Metrics updated

Risk Acceptance:

• If a vulnerability cannot be fixed within timeline, risk acceptance is required
• Risk acceptance requires documented justification, compensating controls, and approver
• Critical vulnerabilities require CISO approval for risk acceptance
• Risk acceptance is reviewed quarterly

Phase 7: Re-test

• All remediated critical/high vulnerabilities must be re-tested
• Re-testing can be automated (SAST/DAST) or manual (penetration test)
• Re-test confirms the fix works and doesn't introduce new vulnerabilities
• Re-test results are documented in the final report

Phase 8: Security Sign-off and Deployment

Security Sign-off Criteria:

• All critical vulnerabilities are remediated or risk-accepted with CISO approval
• All high vulnerabilities are remediated or risk-accepted with security lead approval
• Medium and low vulnerabilities are tracked for future remediation
• Security test report is complete and approved
• Acceptance criteria are met

Go/No-Go Decision:

• Go: Security sign-off obtained, application approved for deployment
• No-Go: Critical vulnerabilities remain unaddressed, deployment delayed until fixed
• Go with Conditions: Deployment approved with monitoring, compensating controls, or accelerated remediation timeline

Types of Security Testing

Static Application Security Testing (SAST)

When: During development, on every commit/merge request
What: Source code analysis for vulnerability patterns
Strengths: Finds code-level issues early, integrates into CI/CD, covers all code paths
Weaknesses: High false positive rate, cannot find runtime issues, cannot test business logic
Best Practices:

• Tune rules for your technology stack
• Suppress false positives with documented justification
• Use high-confidence rules for build blocking
• Train developers to interpret and fix SAST findings
• Track SAST coverage (percentage of code scanned)

Dynamic Application Security Testing (DAST)

When: On staging/pre-production environment, after deployment
What: Runtime testing by simulating attacks against running application
Strengths: Finds runtime issues, tests actual deployed configuration, low false positives
Weaknesses: Cannot find code-level issues, limited coverage of application paths, requires running environment
Best Practices:

• Use authenticated scanning for full coverage
• Configure scan to cover all user roles and API endpoints
• Run DAST after every deployment to staging
• Integrate DAST results into vulnerability tracking system
• Use DAST to validate SAST findings (are they actually exploitable?)

Software Composition Analysis (SCA)

When: During build, on every dependency change
What: Analysis of third-party libraries and frameworks for known vulnerabilities
Strengths: Finds known CVEs, easy to automate, low false positives
Weaknesses: Only finds known vulnerabilities, cannot find custom code issues, license compliance focus
Best Practices:

• Integrate into CI/CD pipeline
• Block builds on critical CVEs
• Use automated dependency updates (Dependabot, Renovate)
• Generate SBoM for compliance and audit
• Monitor for new CVEs affecting your dependencies

Interactive Application Security Testing (IAST)

When: During functional testing, in testing environment
What: Instrumented testing that combines SAST and DAST by monitoring application during runtime
Strengths: High accuracy, low false positives, finds both code and runtime issues, integrates with functional testing
Weaknesses: Requires application instrumentation, may impact performance, requires running application
Best Practices:

• Integrate with QA functional testing
• Use for critical applications where accuracy is paramount
• Combine with SAST and DAST for complete coverage
• Monitor performance impact during testing

Manual Penetration Testing

When: Before acceptance for critical/high-risk applications, quarterly/annually for ongoing applications
What: Simulated cyberattack by certified ethical hackers
Strengths: Finds business logic flaws, validates real-world exploitability, tests human factors, provides context
Weaknesses: expensive, time-consuming, point-in-time, cannot test all paths
Best Practices:

• Use certified testers (certified, GPEN, GWAPT)
• Define scope clearly (in-scope/out-of-scope)
• Include both black box (no knowledge) and white box (full knowledge) testing
• Test for business logic vulnerabilities (automated tools cannot find these)
• Include social engineering if scope allows
• Conduct re-test after remediation
• Obtain independent testing for compliance (PCI DSS, RBI)

API Security Testing

When: For every API release, after deployment to staging
What: Specialized testing for REST, GraphQL, SOAP, and gRPC APIs
Focus Areas:

• Authentication and authorization (JWT, OAuth, API keys, mTLS)
• Input validation (JSON schema validation, content-type enforcement)
• Rate limiting and throttling bypass
• Mass assignment, injection, and deserialization
• Business logic flaws (BOLA, Broken Object Level Authorization)
• Error handling and information disclosure Tools: OWASP ZAP, Postman + security tests, Burp Suite, RESTler, Nuclei

Mobile Security Testing

When: For every mobile app release, before app store submission
What: Specialized testing for iOS and Android applications
Focus Areas:

• Local storage security (keychain, shared preferences, SQLite)
• Network security (certificate pinning, TLS, intercepting proxy)
• Code obfuscation and anti-tampering
• Biometric authentication implementation
• Deep linking and intent handling
• Clipboard and keyboard security
• Screenshot and screen recording protection Tools: MobSF, Frida, Objection, Burp Suite Mobile Assistant, QARK

AI/ML Security Testing

When: For every AI/ML model release, before deployment to production
What: Specialized testing for AI/ML applications
Focus Areas:

• Adversarial strength (evasion attacks, poisoning attacks)
• Model extraction and inversion attacks
• Prompt injection (for LLMs)
• Data leakage in training data
• Bias and fairness testing
• Model drift and performance degradation
• RAG/Vector DB security (retrieval filtering, access control) Tools: Foolbox, ART (Adversarial Strength Toolbox), CleverHans, TextAttack, Giskard

Fuzzing

When: For critical input handlers, file parsers, and API endpoints
What: Automated testing with random, malformed, or unexpected inputs
Types:

• Black-box fuzzing: No knowledge of internal structure
• White-box fuzzing: Knowledge of code structure (coverage-guided)
• Mutation-based fuzzing: Mutates existing valid inputs
• Generation-based fuzzing: Generates inputs from protocol/format specification Tools: AFL, libFuzzer, Peach Fuzzer, Boofuzz, RESTler, jsfuzz

Security Regression Testing

When: After every code change, before every deployment
What: Testing to ensure that changes have not broken existing security controls or introduced new vulnerabilities
Approach:

• Automated security unit tests for critical security functions
• Automated DAST baseline comparison (compare current scan to previous scan)
• Automated SAST comparison (new findings since last scan)
• Automated SCA comparison (new vulnerabilities since last build)
• Manual regression testing for security-critical workflows

API and Mobile Testing

Most Indian fintech and edtech products are API- and mobile-first. Add:

• APIs: test against the OWASP API Security Top 10 (broken object-level authorisation, broken authentication, excessive data exposure, lack of rate limiting, mass assignment and others). Test every endpoint with each role, and with no token.
• Mobile: test against OWASP MASVS using the MASTG: local data storage, certificate validation, root/jailbreak handling, hard-coded secrets in the app package, and the APIs the app calls.

Security Acceptance Criteria

Before an application is accepted into production, the following criteria must be met:

Tools, Technologies, and Solutions

SAST Tools

DAST Tools

SCA Tools

IAST Tools

Penetration Testing Tools

API Security Testing Tools

Mobile Security Testing Tools

AI/ML Security Testing Tools

Fuzzing Tools

Policy and Procedure Templates

Security Testing Policy (Template)

Security Test Plan Template (Template)

Risk Assessment and Treatment

Risk Assessment for Security Testing

Risk Treatment Options

Audit and Compliance Checklist

Pre-Audit Self-Assessment

Auditor Interview Questions

Be prepared to answer:

1. "What security testing is performed before applications go live?"
2. "Can you show me the security test report for [application]?"
3. "Who approves security testing results?"
4. "What happens if critical vulnerabilities are found before go-live?"
5. "How do you handle false positives from automated testing?"
6. "Are external penetration testers used? What are their qualifications?"
7. "How do you test API security?"
8. "How do you test mobile application security?"
9. "Are security tests repeated after vulnerability remediation?"
10. "How do you ensure testing environments don't compromise production?"

Common Audit Findings and How to Avoid Them

Metrics and KPIs

Process Metrics

Outcome Metrics

Dashboard Sample

┌─────────────────────────────────────────────────────────────────────┐
│              SECURITY TESTING IN DEVELOPMENT & ACCEPTANCE           │
│                    [Organization] — [Month Year]                    │
├─────────────────────────────────────────────────────────────────────┤
│  TESTING COVERAGE: 100%      ██████████████████████  Target: 100%  │
│  SAST COVERAGE: 100%         ██████████████████████  Target: 100%  │
│  DAST COVERAGE: 98%          ████████████████████░░  Target: 100%  │
│  SCA COVERAGE: 100%          ██████████████████████  Target: 100%  │
│  SIGN-OFF RATE: 100%         ██████████████████████  Target: 100%  │
│  SLA COMPLIANCE: 94%         ███████████████████░░░  Target: 90%  │
│  PROD VULN RATE: 1/q       █░░░░░░░░░░░░░░░░░░░░  Target: <2/q  │
│  MTTR (CRITICAL): 3.2 days  ███░░░░░░░░░░░░░░░░░░  Target: <7   │
│  FALSE POSITIVE: 15%         ███░░░░░░░░░░░░░░░░░░  Target: <20% │
│  TEST PASS RATE: 96%         ████████████████████░░  Target: 95%  │
└─────────────────────────────────────────────────────────────────────┘

Common Pitfalls and How to Avoid Them

Pitfall 1: "Testing Slows Down Deployment"

Symptom: Security testing is skipped or rushed to meet deadlines.

Reality: Testing prevents production vulnerabilities that cost 100x more to fix. Automated testing in CI/CD adds minutes, not hours.

Solution:

• Automate testing in CI/CD (SAST, SCA run in minutes)
• Use parallel testing (DAST on staging while developers work on next feature)
• Streamline manual testing for low-risk changes
• Show time-to-fix data: testing vs. production

Pitfall 2: "We Only Need Penetration Testing"

Symptom: Organization relies solely on annual penetration tests.

Reality: Penetration testing is point-in-time and cannot cover all code changes. Automated testing (SAST, DAST, SCA) provides continuous coverage.

Solution:

• Use automated testing for continuous coverage
• Use penetration testing for deep, adversarial testing
• Combine both for complete security validation
• Test after every major change, not just annually

Pitfall 3: "Automated Tools Find Everything"

Symptom: Organization relies solely on SAST/DAST and skips manual testing.

Reality: Automated tools find known patterns but miss business logic flaws, race conditions, and novel vulnerabilities. Manual testing is essential.

Solution:

• Use automated tools for scale and consistency
• Use manual testing for business logic and adversarial scenarios
• Use red team exercises for realistic attack simulation
• Combine automated and manual for complete coverage

Pitfall 4: "We Tested It Once, It's Fine"

Symptom: Security testing is performed once at launch and never repeated.

Reality: New vulnerabilities are discovered constantly. Code changes, new dependencies, and new attack techniques create new risks.

Solution:

• Continuous testing in CI/CD (SAST on every commit, DAST on every deployment)
• Periodic penetration testing (quarterly for critical apps)
• Re-test when new CVEs affect your stack
• Annual complete security testing

Pitfall 5: "Test Environment Doesn't Matter"

Symptom: Testing is performed on environments that don't mirror production.

Reality: Vulnerabilities may be masked by configuration differences. A vulnerability in production may not be reproducible in a different environment.

Solution:

• Use Infrastructure as Code to ensure environment parity
• Validate environment configuration before testing
• Include configuration security testing in scope
• Test on production-like data volumes and loads

Pitfall 6: "We Only Test Our Code"

Symptom: Third-party components and APIs are not tested.

Reality: Third-party vulnerabilities are the #1 attack vector for many breaches. Log4j, Spring4Shell, and similar vulnerabilities were in third-party components.

Solution:

• SCA for all dependencies (every build)
• Penetration testing of third-party integrations
• Vendor security testing requirements
• Continuous monitoring for new CVEs affecting dependencies

Pitfall 7: "Vulnerabilities Can Wait"

Symptom: Medium and low vulnerabilities are never fixed.

Reality: Attack chains often combine medium vulnerabilities to achieve critical impact. Unpatched vulnerabilities accumulate into technical debt.

Solution:

• Fix all vulnerabilities within SLA, not just critical
• Use risk-based prioritization that considers attack chains
• Track vulnerability age as a KPI
• Include vulnerability remediation in sprint planning

Pitfall 8: "Security Testing Is the Security Team's Job"

Symptom: Developers write code and "throw it over the wall" to security for testing.

Reality: Developers who write code must own its security. Security testing validates developer work; it doesn't replace developer responsibility.

Solution:

• Developer-driven security testing (SAST in IDE, unit security tests)
• Security champion program
• Make security testing results visible to developers
• Reward teams with low vulnerability density

Illustrative Scenarios

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

Scenario 1: Personal-Finance App With No Pre-Release Testing

Situation. A fintech's mobile app and Node.js API have never been tested before release. The first external penetration test finds SQL injection and an authentication bypass in production.

What applying 8.29 looks like.

1. SAST and SCA in CI; DAST against staging on every release candidate.
2. A test plan per major release with inputs, expected outputs and pass criteria, including negative tests ("only as expected") for every API role.
3. Mobile testing against MASVS and API testing against the OWASP API Security Top 10.
4. An external VAPT before major releases; for RBI-regulated work, by a CERT-In-empanelled auditor where the direction requires it; every fix retested and closed.

Lesson. Testing finds problems only if it is planned, run before release, and followed by verified fixes.

Scenario 2: Hospital EHR Integrations

Situation. A hospital group is rolling out a new electronic health record with links to lab, pharmacy and insurer systems. The core application has been tested, but the integrations have not.

What applying 8.29 looks like.

1. Risk-based test tiers: patient-data systems get SAST, DAST, SCA and penetration testing; integrations are tested as separately as the core.
2. Acceptance criteria include logging of every patient-record access and negative tests on each integration.
3. Testing in a production-like environment with masked data (A.8.33).
4. Security sign-off before go-live, and regression tests for every update.

Lesson. Integration points are often the weakest part of a system, so test them as carefully as the core application.

Multi-Framework Mapping

NIST SP 800-53 Rev 5 Mapping

COBIT 2019 Mapping

PCI DSS v4.0.1 Mapping

DPDP Act 2023: Testing Implications

OWASP SAMM Mapping

CIS Controls v8 Mapping

Regulatory and Industry Context

India

International

Roles and Responsibilities (RACI)

RACI Matrix for Security Testing

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 testing coverage, vulnerability density, MTTR, sign-off rate.

Implement: Deploy tests, execute testing, track vulnerabilities, obtain sign-offs.

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

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

Improve: Update test plans, tune tools, enhance training, adopt new techniques, automate.

Improvement Triggers

Maturity Advancement Path

FAQ

Q1: What is the difference between SAST, DAST, and IAST?

A: SAST (Static Application Security Testing) analyzes source code without running it. DAST (Dynamic Application Security Testing) tests running applications by simulating attacks. IAST (Interactive Application Security Testing) instruments the application during runtime to combine the accuracy of SAST with the runtime context of DAST. Use SAST for code-level issues, DAST for runtime issues, and IAST for high-accuracy testing when you need both.

Q2: Do we need manual penetration testing if we have automated testing?

A: Yes. Automated tools find known patterns but miss business logic flaws, race conditions, and novel vulnerabilities. Penetration testing simulates real-world adversaries who think creatively. Both are essential for complete security.

Q3: How often should we conduct penetration testing?

A: Quarterly for critical applications, bi-annually for high-risk, annually for medium-risk. Also conduct penetration testing after major architecture changes, before go-live for new applications, and when new threat intelligence suggests new attack vectors.

Q4: What if security testing finds critical vulnerabilities right before go-live?

A: The application should not go live until critical vulnerabilities are fixed. If business pressure is extreme, implement compensating controls (WAF rules, additional monitoring, restricted access) and obtain CISO risk acceptance. However, the default position is: no go-live with critical vulnerabilities.

Q5: How do we handle false positives from SAST?

A: Document false positives with justification and suppress them in the tool. Tune rules for your technology stack. Train developers to recognize and report false positives. Track false positive rate as a KPI. Review suppression decisions quarterly.

Q6: What is the minimum viable security testing program?

A: For small organizations: SAST in CI/CD (free tools like Semgrep or SonarQube Community), SCA (free tools like OWASP Dependency-Check or Dependabot), manual code review for security-critical code, and annual penetration testing for critical applications.

Q7: How do we test API security?

A: Use API-specific DAST tools (StackHawk, Nuclei), manual API penetration testing (Burp Suite, Postman with security tests), and fuzzing (RESTler). Test all endpoints, all HTTP methods, all authentication mechanisms, and all user roles. Test for BOLA (Broken Object Level Authorization), injection, and rate limiting bypass.

Q8: How do we test mobile application security?

A: Use MobSF for automated scanning, Frida/Objection for runtime analysis, Burp Suite for network interception, and manual testing for business logic. Test local storage, network security, code obfuscation, biometric auth, and deep linking.

Q9: How do we test AI/ML application security?

A: Use adversarial strength testing (Foolbox, ART), prompt injection testing (for LLMs), model extraction testing, data poisoning testing, and bias testing. Test the full pipeline: data ingestion, training, model serving, and inference.

Q10: What is security regression testing?

A: Testing to ensure that code changes have not broken existing security controls or introduced new vulnerabilities. Includes automated security unit tests, DAST baseline comparison, and SAST new findings detection.

Q11: Should we test third-party code?

A: Yes. Use SCA for dependency vulnerabilities. Include third-party integrations in penetration testing scope. Test vendor APIs and webhooks. Require vendors to provide their own security test results.

Q12: What is the difference between vulnerability assessment and penetration testing?

A: Vulnerability assessment uses automated tools to find vulnerabilities. Penetration testing simulates real attacks to determine if vulnerabilities are exploitable and what impact they would have. Vulnerability assessment is broader; penetration testing is deeper and adversarial.

Q13: How do we integrate security testing into Agile/Scrum?

A: SAST and SCA run automatically in CI/CD on every commit. DAST runs after each sprint deployment to staging. Security testing is part of the Definition of Done. Penetration testing is scheduled for major releases. Security findings are tracked as sprint backlog items.

Q14: What is the role of QA in security testing?

A: QA teams can execute DAST, validate security fixes, and perform security regression testing. QA should include security test cases in their test plans. Security testing should be integrated into QA processes, not treated as a separate activity.

Q15: How do we measure security testing effectiveness?

A: Track production vulnerability rate, vulnerability density, MTTR, customer-reported vulnerabilities, compliance audit findings, and testing coverage. See Section 13 for a full KPI framework.

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-115: Technical Guide to Information Security Testing and Assessment. NIST, 2008.
5. OWASP Testing Guide v4.2: Web Security Testing Guide. OWASP, 2020.
6. OWASP Top 10:2025 (final January 2026; the 2021 edition is still widely referenced). OWASP.
7. OWASP Application Security Verification Standard (ASVS) 5.0 (2025); v4.0.3 (2021) is still widely used.
8. OWASP Software Assurance Maturity Model (SAMM) v2.0. OWASP, 2020.
9. CWE Top 25: Most Dangerous Software Weaknesses. MITRE, 2023.
10. PCI DSS v4.0.1: Payment Card Industry Data Security Standard. PCI SSC, 2024. Also: OWASP API Security Top 10 (2023) and OWASP MASVS / MASTG (mobile).
11. CIS Controls v8: Center for Internet Security, 2021.

Testing Methodologies and Books

12. "The Web Application Hacker's Handbook": Dafydd Stuttard and Marcus Pinto, Wiley, 2011.
13. "The Art of Software Security Assessment": Mark Dowd et al., Addison-Wesley, 2006.
14. "Penetration Testing: A Hands-On Introduction to Hacking": Georgia Weidman, No Starch Press, 2014.
15. "Hacking: The Art of Exploitation": Jon Erickson, No Starch Press, 2008.
16. "Metasploit: The Penetration Tester's Guide": David Kennedy et al., No Starch Press, 2011.
17. "The Tangled Web: A Guide to Securing Modern Web Applications": Michal Zalewski, No Starch Press, 2012.
18. OWASP Testing Guide: https://owasp.org/www-project-web-security-testing-guide/
19. OWASP Cheat Sheet Series: https://cheatsheetseries.owasp.org/
20. NIST SP 800-115: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-115.pdf

Training and Certification

21. OSCP (OffSec Certified Professional): OffSec, https://www.offsec.com/
22. CEH (Certified Ethical Hacker): EC-Council, https://www.eccouncil.org/
23. GWAPT (GIAC Web Application Penetration Tester): GIAC, https://www.giac.org/
24. GPEN (GIAC Penetration Tester): GIAC, https://www.giac.org/
25. OSWE (OffSec Web Expert): OffSec, https://www.offsec.com/
26. eWPT (eLearnSecurity Web Application Penetration Tester): INE, https://ine.com/

Indian Regulatory Resources

28. Digital Personal Data Protection Act 2023: Government of India, 2023.
29. 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.
30. SEBI Cybersecurity and Cyber Resilience Framework (CSCRF) for SEBI Regulated Entities, circular of 20 August 2024.
31. IRDAI Guidelines on Information and Cybersecurity: Insurance Regulatory and Development Authority of India, 2023.
32. IT Act 2000 (as amended): Ministry of Electronics and Information Technology, India. Also: CERT-In list of empanelled information security auditing organisations: https://www.cert-in.org.in/

Industry Research

33. IBM Cost of a Data Breach Report 2024: IBM Security and Ponemon Institute, 2024.
34. Verizon Data Breach Investigations Report 2024: Verizon, 2024.
35. BSIMM: Building Security In Maturity Model (use the latest edition).
36. OWASP Testing Guide v4.2: https://owasp.org/www-project-web-security-testing-guide/