TheArtOfService
NIST SP 800-218PCI DSS 4.0

NIST SP 800-218 covers 4.4% of PCI DSS 4.0

11 of the 249 controls in PCI DSS 4.0 are already satisfied by evidence you collected for NIST SP 800-218. 238 are genuine gaps. Every claim below was judged against both control sets and then argued against; the ones that did not survive are published further down with the reason each failed.

4.4%
of the target already covered
11
controls evidenced
238
genuine gaps
0
claims rejected in review

This number is directional. It says how much of PCI DSS 4.0 your NIST SP 800-218 evidence satisfies. The reverse pair is a different number, often very different, because a security standard has enormous depth for access control and almost none for lawful basis or data subject rights.

34 candidate mappings were examined and 0 were removed. Signed off 2026-08-19, review level machine verified. Mappings were judged by Claude Code rather than read line by line by a practitioner. Every claim shows its reasoning so you can check it. Ask and a practitioner will review this pair.

Where the gaps are

Coverage is never evenly spread. A source standard usually satisfies one part of a target almost completely and barely touches another, and which part is which is the thing worth knowing before you plan the work.

Req 6: Secure Systems and Software11 of 19 evidenced, 8 to do
Req 1: Network Security Controls0 of 19 evidenced, 19 to do
Req 10: Logging and Monitoring0 of 27 evidenced, 27 to do
Req 11: Test Security Regularly0 of 21 evidenced, 21 to do
Req 12: Information Security Policies0 of 37 evidenced, 37 to do
Req 2: Secure Configurations0 of 11 evidenced, 11 to do
Req 3: Protect Stored Account Data0 of 29 evidenced, 29 to do
Req 4: Protect Cardholder Data in Transit0 of 6 evidenced, 6 to do
Req 5: Anti-Malware0 of 13 evidenced, 13 to do
Req 7: Restrict Access by Need to Know0 of 12 evidenced, 12 to do
Req 8: Identify and Authenticate Users0 of 29 evidenced, 29 to do
Req 9: Restrict Physical Access0 of 26 evidenced, 26 to do

Theme level, not control level, deliberately. The per-control list of what is evidenced and what is a gap is the report itself, so publishing it here would be publishing the thing being sold.

Claims that held

A sample. Each one names the control whose evidence does the work, the control it satisfies, and why.

SP800-218-PO.3.26.1.1argued against and upheld
All security policies and operational procedures that are identified in Requirement 6 are: • Documented. • Kept up to date. • In use. • Known to all affected parties

Toolchain configured to enforce the secure development policy evidences procedures actually in use.

SP800-218-PO.1.16.1.1argued against and upheld
All security policies and operational procedures that are identified in Requirement 6 are: • Documented. • Kept up to date. • In use. • Known to all affected parties

Requirements documented, accessible to teams and updated as threats change meets this requirement.

SP800-218-PO.2.16.1.2argued against and upheld
Roles and responsibilities for performing activities in Requirement 6 are documented, assigned, and understood

Defined and assigned secure development roles with measurable ownership is this requirement directly.

SP800-218-PW.5.16.2.1argued against and upheld
Bespoke and custom software are developed securely, as follows: • Based on industry standards and/or best practices for secure development. • In accordance with PCI DSS (for example, secure authentication and logging). • Incorporating

Secure coding practices applied consistently are the industry standard practices this requirement names.

SP800-218-PW.1.16.2.1argued against and upheld
Bespoke and custom software are developed securely, as follows: • Based on industry standards and/or best practices for secure development. • In accordance with PCI DSS (for example, secure authentication and logging). • Incorporating

Designing software to meet security requirements builds security in from the start.

SP800-218-PO.4.16.2.1argued against and upheld
Bespoke and custom software are developed securely, as follows: • Based on industry standards and/or best practices for secure development. • In accordance with PCI DSS (for example, secure authentication and logging). • Incorporating

Release criteria tied to risk incorporate security throughout the development life cycle.

SP800-218-PO.1.16.2.1argued against and upheld
Bespoke and custom software are developed securely, as follows: • Based on industry standards and/or best practices for secure development. • In accordance with PCI DSS (for example, secure authentication and logging). • Incorporating

Documented security requirements accessible to development teams are the basis for developing software securely.

SP800-218-PO.2.26.2.2argued against and upheld
Software development personnel working on bespoke and custom software are trained at least once every 12 months as follows: • On software security relevant to their job function and development languages. • Including secure

Role appropriate secure development training with tracked completion is exactly this requirement.

Claims that did not hold

Nothing proposed for this pair was rejected in review. That is unusual and worth knowing rather than hiding: it means the candidate set was small and every candidate held.

The full report

Everything above is a sample. The report is every evidenced control and every gap, with the reasoning and the source document behind each one, in a form you can hand to an assessor. $299, emailed immediately.

Buy this crosswalk