Framework overlap

Does NIST Special Publication 800-34 Revision 1, Contingency Planning Guide for Federal Information Systems cover PCI P2PE?

You hold NIST Special Publication 800-34 Revision 1, Contingency Planning Guide for Federal Information Systems and have been told to do PCI P2PE. Here is how much overlaps, control by control.

30% of PCI P2PE you already have

NIST Special Publication 800-34 Revision 1, Contingency Planning Guide for Federal Information Systems already covers about 30% of PCI P2PE, leaving 31 of 44 controls as genuinely new work.

Already covered 0 Likely covered 13 New work 31

No control in NIST Special Publication 800-34 Revision 1, Contingency Planning Guide for Federal Information Systems maps directly to one in PCI P2PE. Everything counted as covered is covered because both map to the same third standard, which is what a crosswalk is, but it is an inference rather than a lookup.

What is genuinely new work

Nothing in NIST Special Publication 800-34 Revision 1, Contingency Planning Guide for Federal Information Systems reaches these. This is the list to scope.

Annex-A
Symmetric Key Distribution Using Asymmetric Techniques
Annex-B
Key Injection Facility Requirements
Domain-1.1
POI Device Approval Status
Domain-1.2
Account Data Encryption at POI
Domain-1.3
POI Device Tampering Protection
Domain-2.1
POI Application Security
Domain-2.2
POI Device Authentication
Domain-3.1
POI Device Management
Domain-3.2
Merchant POI Device Deployment
Domain-4.1
Decryption Environment Logical Security
Domain-4.2
Decryption Environment Physical Security
Domain-5.1
Key Generation
Domain-5.2
Key Distribution and Injection
Domain-5.3
Key Storage
Domain-5.4
Key Usage and Cryptoperiods
Domain-5.5
Key Destruction
Domain-6.1
P2PE Solution Documentation
Domain-6.2
Annual Reassessment and Change Management
Domain-6.3
Merchant Self-Assessment Support
PCI-P2PE-01
Information security program management
PCI-P2PE-02
Board and management oversight
PCI-P2PE-03
Risk appetite and tolerance for IT risk
PCI-P2PE-04
Security policy framework
PCI-P2PE-06
Network security and segmentation
PCI-P2PE-07
Endpoint protection and detection
PCI-P2PE-13
Third-party dependency management
PCI-P2PE-15
Communication and escalation procedures
PCI-P2PE-17
Contractual security requirements
PCI-P2PE-20
Exit strategy and transition planning
PCI-P2PE-23
Regulatory reporting requirements
PCI-P2PE-24
Customer notification procedures
Show the 13 you already have
PCI-P2PE-05
Roles and responsibilities definition
PCI-P2PE-08
Application security controls
PCI-P2PE-09
Encryption and key management
PCI-P2PE-10
Secure configuration standards
PCI-P2PE-11
Business continuity planning and testing
PCI-P2PE-12
Disaster recovery procedures
PCI-P2PE-14
Critical service identification
PCI-P2PE-16
Due diligence and onboarding
PCI-P2PE-18
Ongoing monitoring and assessment
PCI-P2PE-19
Concentration risk management
PCI-P2PE-21
Incident detection and classification
PCI-P2PE-22
Incident response and containment
PCI-P2PE-25
Post-incident review and improvement

How this is calculated

Already covered means a mapping runs from a control in NIST Special Publication 800-34 Revision 1, Contingency Planning Guide for Federal Information Systems to that control. Likely covered means no direct mapping exists but both frameworks map to the same control in a third standard. New work means neither. We keep those separate rather than adding them into one friendlier number, because blending them would present a two-hop inference as a verified fact.

Coverage is not symmetric. Run it the other way and you will get a different number; both are correct.

From 332,959 cross-framework control mappings across 723 frameworks, 531 of them verified against their source documents. It does not tell you that you are compliant: a mapped control means the two standards ask for the same thing, not that you have done it.

Try another pair ยท Today's edition