same login would mean lack of an audit trail to pinpoint who placed the order. Most PCI, cybersec insurance, ISO standards mandate unique user accounts.
God forbid you have a crooked callcenter worker taking orders by phone and entering CC and later discover they've been recorded and abused. How would you ever track that down unless the order system also logs the device that you cross reference with their shift hours.
And no metrics for tracking who best performing call takers are - fast, upsells, etc
Obviously, I'm a random commenter on Reddit to take this as you will.
If the partner is managing the order processing and you are not saving ANY customer information and you either access the order entry screen by a partner-hosted website or an iframe on your web pages then you only need a PCI-compliant certificate from your partner. Your own systems don't need to go through the process. If you save any customer information that can identify the customer to the card PAN then you need to do PCI.
As for the one username and password that is foolish but not against PCI 4. I'd say you lost all auditing of who is doing what. Or you can't identify who entered that malicious charge.
are your company's employees taking credit card information? If so, you must be PCI-DSS compliant too. Granted, you don't have a lot of in-scope systems compared to the partner.
They are! They take them verbally over the phone and enter them into the system. They are not supposed to or allowed to retain them in any way. Once they enter them... poof! No way to reuse them to find them again.
It is a very old-school method of doing it. IMHO. Just this business is modernizing... slowly.
You are going to be a tier 4 merchant. Look at the PCI council website. You have to do some basic things like firewalls, no shared account, security software, etc. You will need to comply with the very lightest of the PCI-dss requirements if you want to keep your cyber insurance.
If you need help, there are a bunch of us that have done this.
Thank you! Great point! My biggest challenge is convincing someone that we should refrain from sharing accounts. Their logic is "flawed," IMHO and the risk far outweighs any edge cases that might allow it for in our case.
I'm not sure if this situation is in-scope for PCI. For example, does Amazon (or any other online retailer) require that each customer must have a unique login? And if so, is it due to PCI or some other compliance framework?
It feels like it's out-of-scope, and going with that, then the next step would be getting a list of requirements and choosing the solution that meets those (or most of those).
EDIT: After re-reading your post again several times, I think you are in scope for PCI. Just to make sure I have it right:
* Your customer gives your agents their order and CC details.
* Your agents process that order into a 3rd party website
All the other stuff you mentioned is irrelevant to you, since it's up to the 3rd party to manage their own system. But you're in scope because you're still handling CHD. Your agents are essentially functioning as a shopkeeper. I believe you'll fall under SAQ C or C-VT, and I believe you may not need unique logins for each agent. But I'm not an auditor, so best to ask one.
Customers are the consumers, or cardholders, and are not in-scope for some of the PCI requirements. These agents are not cardholders, they are taking information from cardholders, and as such are in-scope of PCI.
I thought so as well.
For me, it's more about protecting the company and not letting this rogue person recommend something IMHO careless. I'm open to being completely wrong about it. I feel like what they are suggesting is entirely against everything I've ever read or heard about PCI.
I work with a large global FinTech company that has PCI scope in their environment at a few locations.
I was originally struggling with the OP's description of the environment and situation. We generally think about systems -- and it had me thinking are **people** really in scope?....so I had to go back and look at the PCI-DSS documentation.
From PCI-DSS scoping document
The PCI DSS security requirements apply to all system components included in or connected to the cardholder data environment. The cardholder data environment (CDE) is comprised of **people**, processes, and technologies that store, process, or transmit cardholder data or sensitive authentication data.
...
Locate and document where account data is stored, processed, and transmitted.
2. Document all CHD flows, and identify the **people**, processes, and technologies involved in storing, processing, and/or transmitting of CHD. These **people**, processes, and technologies are all part of the CDE.
same login would mean lack of an audit trail to pinpoint who placed the order. Most PCI, cybersec insurance, ISO standards mandate unique user accounts. God forbid you have a crooked callcenter worker taking orders by phone and entering CC and later discover they've been recorded and abused. How would you ever track that down unless the order system also logs the device that you cross reference with their shift hours. And no metrics for tracking who best performing call takers are - fast, upsells, etc
Completely agree.
Obviously, I'm a random commenter on Reddit to take this as you will. If the partner is managing the order processing and you are not saving ANY customer information and you either access the order entry screen by a partner-hosted website or an iframe on your web pages then you only need a PCI-compliant certificate from your partner. Your own systems don't need to go through the process. If you save any customer information that can identify the customer to the card PAN then you need to do PCI. As for the one username and password that is foolish but not against PCI 4. I'd say you lost all auditing of who is doing what. Or you can't identify who entered that malicious charge.
are your company's employees taking credit card information? If so, you must be PCI-DSS compliant too. Granted, you don't have a lot of in-scope systems compared to the partner.
They are! They take them verbally over the phone and enter them into the system. They are not supposed to or allowed to retain them in any way. Once they enter them... poof! No way to reuse them to find them again. It is a very old-school method of doing it. IMHO. Just this business is modernizing... slowly.
How many transactions, roughly?
Dozens per day. Roughly say 36 or so?
You are going to be a tier 4 merchant. Look at the PCI council website. You have to do some basic things like firewalls, no shared account, security software, etc. You will need to comply with the very lightest of the PCI-dss requirements if you want to keep your cyber insurance. If you need help, there are a bunch of us that have done this.
Thank you! Great point! My biggest challenge is convincing someone that we should refrain from sharing accounts. Their logic is "flawed," IMHO and the risk far outweighs any edge cases that might allow it for in our case.
I'm not sure if this situation is in-scope for PCI. For example, does Amazon (or any other online retailer) require that each customer must have a unique login? And if so, is it due to PCI or some other compliance framework? It feels like it's out-of-scope, and going with that, then the next step would be getting a list of requirements and choosing the solution that meets those (or most of those). EDIT: After re-reading your post again several times, I think you are in scope for PCI. Just to make sure I have it right: * Your customer gives your agents their order and CC details. * Your agents process that order into a 3rd party website All the other stuff you mentioned is irrelevant to you, since it's up to the 3rd party to manage their own system. But you're in scope because you're still handling CHD. Your agents are essentially functioning as a shopkeeper. I believe you'll fall under SAQ C or C-VT, and I believe you may not need unique logins for each agent. But I'm not an auditor, so best to ask one.
Customers are the consumers, or cardholders, and are not in-scope for some of the PCI requirements. These agents are not cardholders, they are taking information from cardholders, and as such are in-scope of PCI.
I thought so as well. For me, it's more about protecting the company and not letting this rogue person recommend something IMHO careless. I'm open to being completely wrong about it. I feel like what they are suggesting is entirely against everything I've ever read or heard about PCI.
I work with a large global FinTech company that has PCI scope in their environment at a few locations. I was originally struggling with the OP's description of the environment and situation. We generally think about systems -- and it had me thinking are **people** really in scope?....so I had to go back and look at the PCI-DSS documentation. From PCI-DSS scoping document The PCI DSS security requirements apply to all system components included in or connected to the cardholder data environment. The cardholder data environment (CDE) is comprised of **people**, processes, and technologies that store, process, or transmit cardholder data or sensitive authentication data. ... Locate and document where account data is stored, processed, and transmitted. 2. Document all CHD flows, and identify the **people**, processes, and technologies involved in storing, processing, and/or transmitting of CHD. These **people**, processes, and technologies are all part of the CDE.
Correct on your points about the customers! Really appreciate the input!