A protection SDK is only one part of a payment-data architecture. Assess data flows, scope and operational controls against applicable requirements.
Evaluation approach
Map card-data movement through the application and back end. Review storage, service providers, key access and logs. RASP may contribute a technical control against client interference.
Application example
Even if a third-party component receives card data, logs or screenshots may capture sensitive information. Include these secondary paths in tests.
Limits and considerations
Assessment scope and responsibilities depend on the payment architecture. A product brochure's compliance statement is not the organization's own evidence.
Checks and decisions
- Map data flows
- Assign provider responsibilities
- Retain test evidence
Clarify applicable requirements through the authorized assessment process. Do not present a technical control description as an official compliance conclusion.
Sources
The primary references above provide the technical basis. Example workflows and evaluation suggestions are this publication’s explanations, not independent test results for a particular product.