I am designing a system that uses a certain biometric vector as a secondary user identification step before authorizing a payment. My system does not handle payment card details, rather the payment card processor consumes my service to authenticate the user (as an additional step). In order to do this, my system needs to register a biometric vector of the user in its database, for comparison against subsequent authentication requests.
Following is a definition of what entities come under PCI scope.
The PCI DSS applies to all entities involved in payment card processing, including merchants, processors, acquirers, issuers and service providers. It also applies to all other entities that store, process or transmit cardholder data or sensitive authentication data.
Since my system does not store or process card holder data AND it is located in a separate environment (a remote REST service), the only possibility of it coming under PCI scope would be if it is hosting sensitive authentication data (SAD).
By PCI's definition, SAD is:
Security-related information (including but not limited to card validation codes/values, full track data (from the magnetic stripe or equivalent on a chip), PINs, and PIN blocks) used to authenticate cardholders and/or authorize payment card transactions. Source: Pg 19 of https://www.pcisecuritystandards.org/documents/PCI_DSS_Glossary_v3-2.pdf
Sources such as this one indicate that SAD is data that is available on the card itself.
However, the PCI definition does not clearly indicate whether SAD is only considered as data available on the card itself or not.
Can anyone provide any direction or guidance on this matter? Would such biometric vectors be considered as SAD in the PCI scope?
I'd say no. SAD is information relied on by the card issuer to authenticate a transaction. So PINs/PIN Blocks, full track data and CVC2 are all placed on the card by the issuer (OK, that is simplistic for PIN) and only used by the issuer to validate the card and the customer during the authorization process.
The table on P7 of v3.2.1 of PCI DSS is the authoritative reference, the glossary is not normative.
However, technically you are a service provider to the processor, and they may require you to comply with PCI DSS as a contractual measure because that what allows them to be comfortable about your security, whether or not it strictly applies from a card brand perspective.
External links referenced by this document: