Mapping OWASP ASVS 5.0 to PCI DSS Requirement 6

PCI DSS Requirement 6 tells you to build your own software against industry standards or best practices, then never says which ones. The OWASP® Application Security Verification Standard (ASVS) 5.0 is the obvious candidate for the product side of that requirement. Here is how I map the two, where the mapping stops, and how I would show the result to an assessor.

Requirement 6 of PCI DSS v4.0.1 covers developing and maintaining secure systems and software. It applies to bespoke and custom software: bespoke software is built for you by a third party to your specification, and custom software is built by your own team. My paraphrase of its five sections:

• 6.1, roles and processes. The policies and procedures for Requirement 6 are documented, current and known, and someone is assigned to each activity (6.1.1, 6.1.2).
• 6.2, software developed securely. 6.2.1: build to industry standards or best practices, in line with PCI DSS itself (authentication and logging are the examples), with security considered at every lifecycle stage. 6.2.2: developers are trained at least every 12 months on security for their role and languages. 6.2.3: code is reviewed before release, and 6.2.3.1 adds rules for manual reviews (a qualified reviewer who is not the author, plus management approval). 6.2.4: techniques are defined and in use to prevent common attacks, including injection, cross-site scripting (XSS) and cross-site request forgery (CSRF).
• 6.3, vulnerabilities identified and addressed. 6.3.1: find and risk-rank vulnerabilities. 6.3.2: keep an inventory of your bespoke and custom software and the third-party components inside it. 6.3.3: patch, with critical fixes installed within one month of release and the rest on time frames you set from your risk ranking, as the PCI Security Standards Council (PCI SSC) explains in FAQ 1597.
• 6.4, public-facing web applications. 6.4.2 puts an automated solution in front of them that detects and prevents web attacks; since March 31, 2025 it supersedes 6.4.1, per FAQ 1593. 6.4.3 controls payment page scripts, which part 6 covers in depth.
• 6.5, change management. Documented, approved and tested changes with a way back (6.5.1), checks after significant changes (6.5.2), separated pre-production and production (6.5.3, 6.5.4), no live card numbers in pre-production outside the cardholder data environment (6.5.5), and test data removed before go-live (6.5.6).

If you want a readable copy of the requirement text, Microsoft's Requirement 6 guidance reproduces it next to its own notes. Its text appears to be v4.0, so check the v4.0.1 changes before relying on details such as 6.3.3.

Most of that list is about process and operations, not code, and that ratio decides how far ASVS can take you.

For one of its three parts, yes. ASVS is a list of verifiable security requirements for an application: 345 in version 5.0.0, grouped into 17 chapters and three levels (part 3 walks through them). 6.2.1 bundles three expectations, and ASVS fits them differently.

Industry standard or best practice. This is where ASVS fits best. Each requirement is pass or fail, the IDs are versioned, and the standard describes itself as usable for secure coding references, automated tests, training and procurement.

In line with PCI DSS. ASVS does not know PCI DSS values. Where they differ, PCI DSS sets the bar for in-scope systems. ASVS asks you to document your logging and log the security events you defined (v5.0.0-16.1.1, v5.0.0-16.3.3), while PCI DSS Requirement 10 fixes its own minimum list. Password rules differ too; part 5 works through those conflicts. ASVS encourages organization-specific forks as long as requirement IDs keep their meaning, so a "PCI profile" of ASVS that adds the PCI values is legitimate.

Security at every lifecycle stage. ASVS is explicit that it does not prescribe development lifecycle activities or how you build through CI/CD. It defines outcomes in the product. You need a separate lifecycle description for this part.

Whether that combination satisfies 6.2.1 is your assessor's call. What follows is my interpretation, not guidance from the PCI Security Standards Council or OWASP.

No. ASVS 5.0 removed direct mappings from the standard, no longer maintains its CWE and NIST mappings, and says the aim is a mapping through the OWASP Common Requirement Enumeration project. OpenCRE links security standards through shared "common requirements" instead of one-to-one crosswalks.

When I queried the OpenCRE API in October 2026, its PCI DSS entries were version 4 sections, all linked to common requirements automatically, and every ASVS entry still pointed at 4.0.3. That is a useful starting point for research, not a reviewed ASVS 5.0 to PCI DSS v4.0.1 crosswalk.

So the tables below are mine. If you reuse them, label them as your own interpretation in anything you hand an assessor.

PCI DSS numbers are v4.0.1 and paraphrased. ASVS IDs use the versioned format the standard recommends, with the level in brackets. "None" means no ASVS requirement addresses the item.

6.2.4 is where ASVS earns its place. Its attack categories line up with whole ASVS chapters:

There is a bonus: 6.5.1 asks that changes to bespoke and custom software be tested against 6.2.4 before they reach production. The same tests cover both.

ASVS describes the application. It says little about the organization that builds and runs it, and that is where the rest of Requirement 6 lives.

ASVS has no training requirement. It suggests itself as the structure for a secure development course built on positive controls, which helps with content, but the records of who was trained, when and on what are yours. Review rules are similar: ASVS gives reviewers a checklist, not rules on who may approve what.

On a multi-tenant payment aggregator I work on, I review money-path designs before merge, and platform decisions go into architecture decision records (ADRs): 14 so far, 7 of them mine. An ADR is a short, dated record of one decision, its context and its consequences. That format is also a natural home for the "documented security decisions" ASVS 5.0 places at the start of most chapters.

ASVS asks you to define remediation time frames for third-party components (v5.0.0-15.1.1) and to stay within them (v5.0.0-15.2.1). It does not set the time frames, monitor advisories for you, or rank vulnerabilities. PCI DSS does set one deadline: a month for critical patches. The detection solution in front of public-facing apps (6.4.2) is an operational control that ASVS does not require.

Change records, approvals, environment separation, role separation and keeping live card numbers out of test systems sit outside ASVS. The overlap is at the edges: debug modes off in production (v5.0.0-13.4.2) and no test code or sample functionality shipped (v5.0.0-15.2.3).

OWASP SAMM (Software Assurance Maturity Model) is an open framework for building a software security strategy that fits your risks. Its model has five business functions (Governance, Design, Implementation, Verification, Operations) and 15 practices. Education and Guidance lines up with 6.2.2, Defect Management with 6.3, and Secure Deployment and Environment Management with 6.5. Requirements-driven Testing is where ASVS-tagged tests plug in.

The PCI Secure SLC Standard v2.0 was published on September 28, 2026, with a 12-month transition from v1.1 that starts once assessor training is available. It is a validation program for software vendors, not something PCI DSS asks an in-house team to complete. I read it as a reference for lifecycle controls; part 8 covers the wider PCI Software Security Framework.

Assessors sample. Your job is to make every sample a short walk from a PCI requirement to proof that it held for a specific release.

Open the diagram full size:

Scroll sideways to see the whole diagram. Open full size

Write one decision record per in-scope application: ASVS v5.0.0, the target level, any items pulled up from a higher level and why, and each N/A with a reason. The ASVS assessment chapter expects the same from a verification report: the scope, the level, the requirements checked and the ones that do not apply. ASVS leaves the level to your risk analysis and says most applications should aim for Level 2.

The ASVS assessment chapter notes that application-specific checks can look like the unit and integration tests you already have, and sums it up as "testable using automation != running an off the shelf tool". A pytest marker is enough to make that traceable:

# conftest.py: collect versioned ASVS IDs and outcomes into one evidence file
import json
from collections import defaultdict
from pathlib import Path

import pytest

ASVS_IDS: dict[str, tuple[str, ...]] = {}
OUTCOMES: dict[str, str] = {}


def pytest_configure(config: pytest.Config) -> None:
    config.addinivalue_line("markers", "asvs(*ids): versioned ASVS IDs a test verifies")


def pytest_collection_modifyitems(items: list[pytest.Item]) -> None:
    for item in items:
        ids = tuple(i for mark in item.iter_markers("asvs") for i in mark.args)
        if ids:
            ASVS_IDS[item.nodeid] = ids


def pytest_runtest_logreport(report: pytest.TestReport) -> None:
    if report.nodeid in ASVS_IDS and (report.when == "call" or report.outcome != "passed"):
        OUTCOMES[report.nodeid] = report.outcome


def pytest_sessionfinish(session: pytest.Session) -> None:
    # Single-process run. With pytest-xdist, write one file per worker and merge them.
    evidence: dict[str, list[dict[str, str]]] = defaultdict(list)
    for nodeid, ids in ASVS_IDS.items():
        for asvs_id in ids:
            outcome = OUTCOMES.get(nodeid, "not run")
            evidence[asvs_id].append({"test": nodeid, "outcome": outcome})
    Path("asvs-evidence.json").write_text(json.dumps(evidence, indent=2, sort_keys=True))

# test_payouts.py: the client and token fixtures come from your own test setup
import pytest


@pytest.mark.asvs("v5.0.0-8.2.2")  # PCI DSS 6.2.4: attacks on access control
def test_merchant_cannot_read_another_merchants_payout(
    client, token_merchant_a, payout_id_merchant_b
):
    response = client.get(
        f"/payouts/{payout_id_merchant_b}",
        headers={"Authorization": f"Bearer {token_merchant_a}"},
    )
    assert response.status_code == 404  # 404, not 403: don't confirm the payout exists

v5.0.0-8.2.2 is the Level 1 requirement against insecure direct object references, which in a multi-tenant payments API is one of the bugs I worry about most.

The CI gate reads the required IDs from the level decision and fails the build when one has neither a passing test nor a review record. Documentation requirements need the review path: ASVS treats checking the documentation and checking the implementation as two separate activities.

As a team lead on a wealth management platform with 600K+ verified users, I built Jenkins CI/CD with automated tests, SonarQube code-quality checks and QA gates, and set engineering standards for coding, code reviews, documentation and automated testing that cut production incidents by 35%. The lesson carries over: a gate that runs on every merge produces evidence as a side effect, so nobody assembles it by hand before an assessment.

Store the evidence file, the SBOM (6.3.2), the review approvals (6.2.3) and the change ticket (6.5.1) with each release tag. When the assessor picks a release, everything is in one place.

• Write the level decision for each in-scope application: ASVS v5.0.0, Level 2 as a floor (my preference for payment software), plus the Level 3 items a PCI requirement points at, such as v5.0.0-3.6.1 for payment pages.
• Tag the tests you already have with versioned ASVS IDs, then list the required IDs that have neither a test nor a review record.
• Start with the access control and injection rows of 6.2.4. They map to Level 1 requirements that are cheap to test.
• Keep the mapping table in the repository next to your decision records, versioned and labelled as your own interpretation.
• Give each gap ASVS leaves a named owner: training, review rules, patch windows, change tickets. Rate them with SAMM once a year.

Quoted text from OWASP Application Security Verification Standard 5.0.0, (c) OWASP Foundation, licensed CC BY-SA 4.0.