How continuous DAST supports PCI DSS 4.0.1 audits

Continuous DAST and PCI DSS 4.0.1 essentials

• PCI DSS v4.0 introduced 64 new or updated requirements, including 51 future-dated requirements that became effective on March 31, 2025. PCI DSS v4.0.1 clarified the standard without adding or deleting requirements.
• While PCI DSS does not mandate dynamic application security testing by name, DAST can provide strong and repeatable evidence for application security activities associated with Requirement 6.2.4. DAST can also contribute application-layer evidence for internal vulnerability scanning under Requirement 11.3.1.
• Requirement 6.3.2 concerns inventories of bespoke and custom software and incorporated third-party components. Software composition analysis (SCA) and software bill of materials (SBOM) capabilities can support this requirement.
• External Approved Scanning Vendor scans under Requirement 11.3.2 remain a separate obligation. Invicti provides access to an integrated ASV scanning service delivered through a partner ASV to complement Invicti’s application security testing and reporting features. The two activities produce different evidence for different requirements.
• The most useful PCI DSS audit record is not a single clean scan from the week before an assessment, but a year-long trail showing what was tested, what was found, who owned each finding, when it was fixed, and how the fix was verified.

What does PCI DSS require for application security testing?

PCI DSS v4.0.1 requires organizations to protect payment account data through documented, consistently operated security controls. For bespoke and custom software, Requirement 6 focuses on secure development and the prevention or mitigation of common software attacks.

Requirement 6.2.4 requires software engineering techniques or other methods to be defined and used to prevent or mitigate common software attacks and related vulnerabilities. The listed attack categories include injection, attacks on business logic, attacks on access-control mechanisms, cross-site scripting, cross-site request forgery, broken authentication and session management, and other high-risk vulnerabilities identified through industry sources.

Dynamic application security testing (DAST) supports this objective by testing running applications from an attacker’s perspective. It sends requests to web interfaces and application programming interfaces (APIs), observes responses, and looks for behavior that indicates an exploitable weakness.

This runtime perspective matters because a source-code or component scan can identify potentially vulnerable code without showing whether an attacker can reach or exploit it in the deployed application. DAST tests the application in operation, including configuration, authentication, session handling, routing, and interactions between components.

Verizon’s 2026 Data Breach Investigations Report found that vulnerability exploitation has become the leading initial entry point for breaches, accounting for 31% of breaches in its dataset. While this finding does not relate specifically to PCI DSS or DAST, it reinforces the operational case for identifying and remediating exploitable vulnerabilities before attackers use them.

Which PCI DSS requirements can DAST support?

Continuous DAST is most directly relevant to Requirement 6.2.4 and the application-layer portion of Requirement 11.3.1. When DAST is combined with software composition analysis, application security posture management, and an appropriate ASV service, the resulting program can support a broader evidence strategy for Requirements 6.3.2 and 11.3.2.

Requirement 6.2.4 – preventing common software attacks

Requirement 6.2.4 is often discussed as a secure coding requirement, and secure coding is certainly central to it – QSAs will examine developer training, code review, and secure coding documentation. However, the requirement is broader than only developer training or written standards. Organizations need to show that they have defined and implemented methods for preventing or mitigating common software attacks.

DAST provides valuable supporting evidence that those methods are being applied to running applications. It can test for vulnerabilities such as:

• SQL injection and other injection attacks
• Cross-site scripting (XSS)
• Cross-site request forgery
• Broken authentication and session-management weaknesses
• Security misconfigurations
• Access-control failures
• Insecure direct object references, commonly associated with broken object level authorization (BOLA)
• Vulnerable application and API behavior that is only visible at runtime

A DAST report alone does not prove that every part of Requirement 6.2.4 is satisfied. Assessors may also examine secure development procedures, developer training, code-review processes, testing methods, and evidence that the organization responds to newly identified attack patterns.

DAST strengthens that evidence by showing that applications have been tested against realistic attacks and that identified vulnerabilities were routed into a managed remediation process.

Why authenticated testing matters

Unauthenticated scanning tests the application surfaces available before login. That is still useful, but most payment workflows, customer records, transaction functions, administration interfaces, and APIs sit behind authentication.

A scan that never completes the login process cannot fully test those surfaces. It may miss vulnerabilities involving:

• Access to another customer’s transaction or account data
• Privilege escalation between ordinary and administrative users
• Session-management failures
• Authorization differences between API roles
• Sensitive data exposed only after login
• Payment functions available to authenticated users
• Application behavior that depends on account state

Authenticated DAST uses configured credentials, session tokens, or recorded login sequences to reach protected functionality. For API authorization testing, multiple user identities can help identify cases where one user can access an object that belongs to another.

With Invicti, authenticated testing evidence can include the scan configuration, crawled URLs, sitemap data, and request information showing that post-login surfaces were reached. When Invicti identifies a BOLA or IDOR vulnerability through multi-user testing, the finding can include the relevant request and response evidence.

This is more defensible in an audit process than claiming a generic “authenticated coverage percentage” or “BOLA coverage rate.” Those percentages do not exist as standard report metrics and, in any case, could create a false sense of completeness. The stronger evidence shows what was configured, what the scanner reached, what tests it performed, and what it found.

Requirement 6.3.2 – software and component inventory

Requirement 6.3.2 requires organizations to maintain an inventory of bespoke and custom software and the third-party components incorporated into that software. The purpose is to support vulnerability and patch management.

DAST can identify some runtime technologies, but it does not create a complete component inventory. Software composition analysis (SCA) is the appropriate capability for identifying open-source and third-party dependencies and correlating them with known vulnerabilities.

Invicti’s software composition analysis and application security posture management (ASPM) capabilities can maintain component information and generate software bill of materials data in CSV, CycloneDX, and SPDX formats. This provides a machine-readable foundation for answering questions such as:

• Which third-party components are used in a payment application?
• Which version is currently deployed?
• Which applications depend on an affected component?
• Which component vulnerabilities remain open?
• Who owns remediation?
• Did an application change introduce a new dependency?

This inventory should connect to the broader vulnerability-management process. An SBOM that is generated once and left to age in a document repository is less useful than component data that updates as applications and dependencies change.

Requirement 11.3.1 – internal vulnerability scans

Requirement 11.3.1 requires internal vulnerability scans at least once every three months, after significant changes, and until high-risk and critical vulnerabilities are resolved. The requirement applies to internal system components in the cardholder data environment.

DAST can contribute to this requirement at the application layer. For example, it can test an internally accessible payment administration application or API that is not exposed to the public internet. However, DAST does not replace the broader infrastructure and network vulnerability scanning required for internal system components. It should be treated as one part of the internal scanning program, covering application behavior that a network scanner may not meaningfully test.

Useful application-layer evidence includes:

• Dated scan records for internal applications
• The in-scope targets and scan policies used
• Authenticated scan configuration where applicable
• Identified application vulnerabilities
• Ownership and remediation records
• Re-scan results confirming that high-risk and critical findings were fixed

Requirement 11.3.2 – external ASV scans

Requirement 11.3.2 requires passing external vulnerability scans at least once every three months. These scans must be performed by a PCI Security Standards Council (PCI SSC) Approved Scanning Vendor (ASV) using an approved scanning solution. PCI SSC describes them as “scans of external-facing systems that could expose the cardholder data environment.”

An ASV scan is not the same as a typical DAST scan. Here’s a summary of the differences:

Financial services security teams generally need both activities. Invicti’s application testing capabilities support the broader application security program, while an integrated ASV scanning service delivered through an Invicti partner ASV supports the separate external scanning workflow.

Keeping these records distinct makes an assessment easier. It prevents an organization from handing an assessor an ASV report when asked for application testing evidence, or presenting a DAST report as though it were a formal ASV scan.

What continuous compliance means for DAST programs

PCI SSC guidance has long encouraged organizations to maintain compliance throughout the year rather than treating validation as a once-a-year exercise. The operational implication is straightforward: controls should continue to function between assessments, and the organization should retain evidence of that operation.

For DAST, “continuous” describes an operating model, not a requirement to run full scans without interruption. It means building testing into normal development and vulnerability-management processes. A practical continuous DAST program typically combines several scan types:

Pipeline-triggered scans

Teams can run focused scans when an application reaches a test or staging environment. Invicti provides integration options for Jenkins, GitHub Actions, GitLab CI/CD, Azure Pipelines, and CircleCI, along with command-line options for containerized and customized pipeline workflows.

These scans provide evidence that security testing occurs as part of software delivery rather than only after deployment.

Scheduled scans

Scheduled scans help detect vulnerabilities introduced by configuration changes, environmental changes, newly added scanner checks for emerging attack techniques, or code paths that were not covered by a pipeline scan.

Production frequency should reflect the application’s risk, exposure, release rate, and the organization’s targeted risk analysis. PCI DSS does not impose a universal monthly DAST schedule.

Change-triggered scans

Significant changes should trigger testing appropriate to the affected application. Examples include:

• A new payment workflow
• A change to authentication or session management
• A new API endpoint
• A major framework upgrade
• A new third-party integration
• A revised authorization model
• Deployment into a new environment

Re-tests

A finding should not be considered fixed merely because a ticket was closed or a developer changed the code. A re-test provides evidence that the running application no longer exhibits the vulnerable behavior.

Periodic evidence reviews

Compliance and AppSec teams should periodically compare the application inventory against scan history. This identifies applications that have no recent scan, failed authentication, stopped reporting, or changed ownership.

The result is an audit trail that develops as work happens. When the assessment begins, the evidence is already available.

What QSAs may ask for – an application security evidence checklist

The exact request list depends on the organization, scope, assessment method, and assessor. The following categories reflect the evidence that commonly supports discussions about application security, software inventory, vulnerability management, and internal scanning during reviews by PCI Qualified Security Assessors (QSAs).

1. An inventory of in-scope applications, APIs, and components

An assessor may ask:

“Show us the bespoke and custom software in the cardholder data environment, including relevant third-party components.”

Useful evidence includes:

• Application and API names
• Production and non-production URLs
• Business and technical owners
• CDE scope classification
• Technologies and frameworks
• Last scan dates
• Component inventory and SBOM records
• Links between applications, repositories, and deployed services

A centralized application and API inventory can connect assets with ownership, scan history, and component data, while SCA and SBOM capabilities provide visibility into incorporated components. API discovery can also help identify endpoints that were omitted from a manually maintained inventory, but automated discovery does not define PCI DSS scope on its own. Scope remains the organization’s responsibility, while discovery helps teams validate and maintain it.

2. Evidence that protected application surfaces were reached

An assessor may ask:

“How did you test functionality that is only available after login?”

Useful evidence includes:

• The authenticated scan configuration
• The login sequence or authentication method used
• Scan logs showing successful authentication
• Crawled post-login URLs
• Relevant session cookies or authorization headers
• Records of authentication failures and how they were corrected
• Separate test identities used for authorization testing

Invicti’s crawl and request data can demonstrate that the scanner reached authenticated application areas. The organization should also retain operational records showing that failed authentication did not silently reduce scan coverage.

3. Findings, severity, and affected assets

An assessor may ask:

“Provide the application vulnerabilities identified during the assessment period and their current status.”

Useful evidence includes:

• Vulnerability type
• Affected application and endpoint
• Discovery date
• Severity
• Confirmation status
• Current owner
• Current workflow state
• Remediation deadline
• Acceptance or exception records
• Technical evidence and remediation guidance

Invicti’s PCI DSS compliance report for DAST findings organizes results against relevant compliance categories. For vulnerabilities that can be safely confirmed, proof-based scanning can provide evidence that the issue is exploitable, which helps teams distinguish confirmed risk from results that still require manual validation.

The report should form part of the evidence package but should not be mistaken for the entire package. Workflow, inventory, exception, and re-test records may live in ASPM, issue trackers, or other systems.

4. Remediation timelines and ownership

An assessor may ask:

“How do you ensure that identified vulnerabilities are addressed according to risk?”

PCI DSS expects organizations to define and follow remediation processes. Under Requirement 6.4.1, organizations must define remediation timeframes through a targeted risk analysis.

An organization may choose industry-standard targets such as seven days for critical and 30 days for high-severity findings, but the specific periods should reflect its own policy, risk analysis, and operational capacity.

Useful evidence includes:

• Defined service-level targets by severity or risk
• Finding open and close dates
• Assigned owners
• Overdue findings
• Approved exceptions
• Compensating or interim controls
• Escalation records
• Mean or median time to remediation
• SLA compliance trends

Invicti ASPM can centralize this lifecycle data and automate assignment or ticket creation through systems such as Jira, Azure Boards, GitHub Issues, and GitLab Issues.

5. Evidence of re-testing and closure

An assessor may ask:

“How did you verify that this vulnerability was fixed?”

Useful evidence includes:

• The original finding
• The remediation ticket
• The code or configuration change
• The re-test date
• The re-test result
• The identity of the approving or closing party
• Any remaining related findings

Automated re-testing helps prevent premature closure. It also creates a stronger chain of evidence than a ticket status alone.

Where a finding cannot be reproduced automatically, the organization should document the manual validation method and result.

6. Authorization and BOLA testing evidence

An assessor may ask:

“How do you test whether authenticated users can access data or functions belonging to other users?”

For an API, this may involve testing the same object or function with multiple accounts, roles, or tokens. Evidence can include:

• The user roles configured for testing
• The authentication method
• Example endpoints tested
• Any confirmed cross-user access findings
• Relevant HTTP requests and responses
• Remediation and re-test records

Invicti can perform multi-user testing for BOLA and IDOR behavior and report confirmed vulnerabilities when detected. The evidence should describe the configured testing and resulting findings rather than claim a percentage-based BOLA coverage metric.

7. SDLC integration

An assessor may ask:

“When does application security testing occur, and how do developers participate?”

Useful evidence includes:

• Pipeline scan configuration
• Scan-trigger logs
• Scan timestamps associated with builds or deployments
• Release policies and security gates
• Developer-assigned tickets
• Re-test records
• Documented exceptions where a release proceeded with open risk

Invicti’s native integrations and command-line tooling can help connect testing with existing CI/CD processes. Teams should configure policies according to application risk rather than block every release for every informational finding.

A risk-based gate might stop deployment for a confirmed critical vulnerability while routing lower-priority issues into the standard remediation workflow.

8. Evidence of sustained operation

An assessor may ask:

“Show that these processes operated throughout the assessment period.”

Useful evidence includes:

• Scan history over the full period
• Trends in open and closed vulnerabilities
• SLA performance
• Re-test rates
• Applications with missing or failed scans
• Changes in application inventory
• Exception and risk-acceptance history
• Quarterly or monthly governance reviews

ASPM trend and posture dashboards can help demonstrate sustained activity and reveal where processes weakened during the year.

Common evidence gaps that continuous DAST can help prevent

• Testing takes place only before the assessment: A recent clean scan cannot show that the application remained tested and managed throughout the year. Pipeline scans, scheduled scans, and re-test history provide a more credible record.
• Authentication fails silently: A scan may technically complete while testing only the login page. Teams should monitor authentication status and inspect crawled paths to confirm that protected functionality was reached.
• APIs are missing from scope: Payment applications often depend on APIs that may not appear in the original web application inventory. API discovery and specification-based scanning can help identify and test these endpoints.
• Findings are closed without verification: A closed ticket shows an administrative action. A successful re-test shows that the vulnerability is no longer observable in the running application.
• The component inventory becomes stale: A spreadsheet updated only before the audit may not reflect current production dependencies. SCA and automatically maintained SBOM data provide a more sustainable source of component information.
• ASV and application testing evidence are confused: A passing ASV scan does not demonstrate that authenticated application workflows, APIs, or authorization controls were tested. A DAST report is not a substitute for the required ASV scan. Both records should be available and clearly labeled.
• Reports exist, but ownership does not: An audit trail should show who received a finding, what action they took, whether the deadline was met, and how closure was verified. Centralized workflow data is often as important as the original scan.

How Invicti supports PCI DSS 4.0.1 audits

Invicti brings together DAST, API security, SCA, and application security posture management to help financial services teams operate and document a repeatable application security program.

PCI DSS-mapped DAST reporting

Invicti provides PCI DSS 4.0 compliance report templates for DAST findings. These reports organize relevant scan results by PCI DSS requirement and vulnerability category. This helps compliance and security teams translate technical findings into an assessment-oriented view without claiming that the report itself establishes compliance.

Keep in mind that no product report establishes PCI DSS compliance by itself – the organization and its assessor evaluate the full set of controls and evidence.

Authenticated application and API testing

Invicti can test login-protected application surfaces and APIs using configured authentication. Multi-user testing can identify BOLA and IDOR vulnerabilities that involve improper access between accounts.

Proof of exploitability

For many high-impact vulnerability classes, proof-based scanning can safely confirm that the identified issue is exploitable. Confirmed findings give developers clearer evidence and reduce time spent reproducing scanner results.

Not every vulnerability can or should be exploited automatically. Findings without proof should still be triaged according to their context and potential impact.

Application, API, and component visibility

Invicti’s discovery, API security, SCA, and ASPM capabilities help teams maintain a clearer view of applications, APIs, and software components.

SBOM generation in CSV, CycloneDX, and SPDX formats supports the maintained component inventory needed for effective vulnerability and patch management.

CI/CD and workflow integration

Native integrations support Jenkins, GitHub Actions, GitLab CI/CD, Azure Pipelines, and CircleCI. Issue and workflow integrations can route findings into the tools development teams already use.

This allows security evidence to emerge from the development process rather than being assembled separately for compliance.

Centralized lifecycle evidence

Invicti ASPM maintains compliance-supporting evidence across the vulnerability lifecycle, including ownership, status, SLA performance, remediation dates, re-test results, trends, and scan history.

Invicti ASPM maintains the operational data trail around findings from multiple testing tools, while Invicti’s PCI DSS compliance templates provide a requirement-oriented view of DAST findings. Together, these capabilities help teams connect technical results with ownership, remediation, re-testing, and audit history.

Complementary ASV scanning

Invicti customers can use an integrated ASV scanning service (currently delivered through Clone Systems) for the external scanning process associated with Requirement 11.3.2.

This complements Invicti’s application security testing. It should be presented and retained as a separate ASV activity with its own formal reporting.

Build the evidence before the audit starts

PCI DSS audit preparation is easier when evidence is a product of normal security operations. For continuous DAST, that means:

1. Maintaining an accurate inventory of in-scope applications and APIs.
2. Configuring authentication and verifying that protected surfaces are reached.
3. Running focused scans during development and broader scans at risk-appropriate intervals.
4. Routing findings to named owners.
5. Tracking remediation against defined targets.
6. Re-testing fixes before closure.
7. Retaining scan, workflow, exception, and trend data throughout the assessment period.
8. Keeping ASV scanning and application testing evidence distinct.

With those processes in place, an assessment becomes a review of an operating security program rather than a scramble to reconstruct one.

Conclusion: Turn continuous testing into audit-ready evidence

PCI DSS audit readiness depends less on producing one final report than on showing that application security controls worked throughout the assessment period. Teams need to know which applications and APIs were tested, whether authenticated areas were reached, which vulnerabilities were found, how quickly they were addressed, and whether remediation was verified.

A continuous DAST program creates that record as part of normal security operations. Combined with application and component inventory, structured remediation workflows, re-testing, and separate ASV scanning, it gives security and compliance teams a clearer answer when an assessor asks, “Show me how this control operated during the year.”

Invicti helps build that evidence trail by combining authenticated DAST and API security testing with PCI DSS-mapped reports, proof-based scanning, SBOM generation, CI/CD integrations, and ASPM workflow data. The result is a more defensible application security program and less manual work when an assessment begins.

To see how Invicti can help your team turn continuous application security testing into audit-ready evidence, request a demo.