Penetration Testing Within the Systems Development Lifecycle (SDLC)

Defines how risk-based penetration testing should be planned, authorized, performed, evidenced, and governed throughout the SDLC as a specialized Security Verification and Assurance Activity rather than as an automatic standalone phase.

Best Practice: Use Penetration Testing to Produce Decision-Ready Security Evidence

Penetration testing evaluates whether authorized testers can exploit weaknesses in a defined Solution scope under controlled conditions. It contributes evidence about attack paths, control effectiveness, exposure, and residual Security Risk, but it does not replace secure Architecture, threat modeling, code review, vulnerability management, or other Security V&V.

Benefits: Understanding that penetration testing evaluates exploitability under controlled conditions — and does not replace secure Architecture or code review — keeps teams from treating a clean penetration-test report as a substitute for the upstream Security practices that actually prevent most vulnerabilities from being introduced in the first place.

Best Practice: Scale Penetration Testing to Risk and Exposure

Testing depth should reflect criticality, exposure, sensitive information, privilege, trust boundaries, regulatory or contractual obligations, novelty, major Architecture change, supplier dependence, and consequence of compromise. Not every low-risk Release requires a full independent penetration test.

Benefits: Reserving a full independent penetration test for Releases whose criticality and exposure actually warrant it means Security’s limited testing capacity goes where compromise would matter most. Applying the same testing depth to every Release regardless of Risk would either overwhelm the Security team or force it to test superficially everywhere.

Best Practice: Plan Penetration Testing Early

Planning should identify scope, objectives, rules of engagement, authorization, tester independence and competence, target baseline, Environment, test data, prohibited actions, contacts, evidence handling, stop conditions, supplier coordination, and remediation expectations. Contractual rights should be established before acquired or hosted Solutions become indispensable.

Benefits: Establishing rules of engagement, tester independence, and stop conditions before testing begins — rather than improvising them once testing starts — prevents a test from causing unintended Production disruption or producing evidence no one can trust because the ground rules were unclear.

Best Practice: Use a Representative and Authorized Test Environment

Testing should use a sufficiently representative and isolated Environment. Production testing should occur only under explicit authorization, controlled windows, monitoring, rollback, stakeholder communication, and safety constraints. Differences between the tested Environment and Production should be documented as limitations.

Benefits: Documenting exactly how the tested Environment differs from Production turns those differences into a known limitation reviewers can weigh, rather than an unstated assumption that quietly inflates confidence in the test’s conclusions. Explicit Production-testing authorization and rollback readiness also keep an authorized test from becoming an unauthorized incident.

Best Practice: Execute Testing and Preserve Reproducible Evidence

Testing may include external, internal, authenticated, unauthenticated, Application, API, cloud, network, identity, social-engineering, wireless, hardware, or AI attack scenarios where applicable. Evidence should identify the tested baseline, methods, findings, exploitability, affected assets, business consequence, limitations, and tester attribution.

Benefits: Recording the exact tested baseline, methods, and limitations alongside each finding is what lets a later reviewer judge whether the test still applies to the current Release, rather than treating an undated finding as evidence of unknown vintage. This traceability is often the difference between a test that ages gracefully and one that becomes unusable within a quarter.

Best Practice: Govern Penetration-Test Findings Through Closure

Findings should be validated, severity-assessed in context, assigned, remediated, retested, excepted, deferred, or accepted through authorized Risk governance. A clean summary should not conceal testing limitations, untested areas, or conditions that prevented exploitation.

Benefits: Requiring findings to be severity-assessed, assigned, and retested through closure — rather than filed away once discovered — is what actually reduces exposure. A vulnerability that’s identified but never remediated provides no more protection than one that was never found.

Best Practice: Connect Penetration-Test Results to Release Decisions

Penetration-test evidence should inform Security assurance, Readiness Gates, Production authorization, conditional rollout, monitoring, and follow-up obligations. A test performed against a materially different configuration or older Release should not be treated as current evidence without justified reuse analysis.

Benefits: Feeding penetration-test evidence directly into Readiness Gates and Production authorization decisions means a serious unresolved finding can actually block a Release, rather than sitting in a report that no decision-maker consults. Refusing to treat an older test as current evidence closes the gap where a since-changed configuration quietly invalidates a prior clean result.

Best Practice: Apply Penetration Testing to Acquired and Composite Solutions

For acquired Solutions, supplier reports and certifications are inputs, not complete enterprise evidence. The enterprise should evaluate Product version, tenant configuration, integrations, data, hosting, and contractual limitations. Composite Solutions require end-to-end testing across trust and supplier boundaries where feasible.

Benefits: Evaluating the enterprise’s actual tenant configuration and integrations — not just accepting a supplier’s certification — catches the vulnerabilities that only emerge from how the enterprise specifically deployed and connected an acquired Product. A supplier’s clean report says nothing about a misconfigured integration the supplier never tested.

Best Practice: Advance Penetration-Testing Maturity Deliberately

At Crawl maturity, define scope, authorization, competent testers, findings, remediation, and retest. At Walk maturity, use risk-based triggers, standard rules of engagement, integrated tracking, and evidence reuse criteria. At Run maturity, combine continuous attack-surface intelligence, automated validation, threat-informed scenarios, and independent testing for material decisions.

Benefits: Starting with clearly scoped, authorized testing and basic remediation tracking at Crawl maturity builds the discipline needed before layering on risk-based triggers and continuous attack-surface intelligence at Walk and Run maturity. Attempting continuous automated testing before basic scope and remediation practices are solid tends to generate noise no one has the discipline to act on.

Example

An internet-facing portal undergoes penetration testing after core functionality is stable but before production approval. Testers identify an authorization flaw and several lower-severity findings. The Release team corrects the flaw, retests the affected paths, and records evidence of closure. Two low-risk findings are accepted temporarily by an authorized risk owner with remediation dates and monitoring. Production approval considers the final report, retest results, residual risk, and operating controls rather than treating completion of the test itself as sufficient.

Best Practice: Avoid Common Antipatterns in Penetration Testing Within the Systems Development Lifecycle (SDLC)

Enterprises should avoid reusing an outdated penetration test as current evidence. A test performed against a materially different configuration or an earlier Release does not demonstrate the security posture of the current Solution, and treating it as current evidence creates false confidence.

Benefits: Avoiding this antipattern keeps Production authorization decisions grounded in evidence that actually reflects the Solution as it exists today. It prevents a since-changed configuration from quietly inheriting a clean result that no longer applies.

Connections to Related IF4IT Practices and Inventories

Use Technology Portfolio Management (TPM) Best Practices, the Software Technologies Inventory and Attributes, and IT Operating Environments Best Practices to ensure builds and tests use governed technologies and representative environments.

Apply the Non-Functional Requirements (NFRs) Framework for Software Systems so quality expectations stay connected to validation methods, test evidence, acceptance criteria, readiness gates, and Production assurance.

Apply security, privacy, Risk, compliance, audit, and authorization controls throughout this chapter’s decisions and responsibilities to keep required evidence, exceptions, residual Risk, and accountable approvals visible and governed.