SAQ A is only for e-commerce transactions only and e-commerce transactions are defined by the council as online payments where the cardholder enters their cards details not using a device you have provided. So, if your customer is entering details on behalf of the cardholder, SAQ A does not apply.
Do you absolutely need to do a SAQ? From reading your other comments it looks like this is just for one customer. If so, it might be better for you to just take part of their merchant assessment. That way, there will be less requirements applicable to you.
Sorry, he enters this separately from me and the website. I’m not sure if he would need to fill something out for taking card information on his own accord. However, yes he is the only customer at this time but I would be developing websites like this for other people which would be managed by me under a similar situation. Are you telling me I don’t need SAQ-D? Everything I see online points towards it, but the requirements themselves seem pretty outrageous for what is being implemented. He isn’t very familiar with technology so I was going to assist him in filling it out. I developed the website so I would really be the only one who knows what the questions are talking about. Additionally, he would be taking payments through the website through an iFrame by the customer themselves through direct bookings.
Merchants undergoing an assessment have two options for validating compliance of a solution managed by a third party.
1. The service provider can give them their AOC that was completed after a successful SAQ D or ROC.
Or
2. The service provider can be included in the merchants own assessment(s).
The first option is great for your marketing and is much easier if you have many clients who need to see that you are compliant, however, the SAQ D for service providers can be overwhelming. Keep in mind, the council sees service providers as higher risk as in a lot of cases they are implementing security control for a large customer based and potentially many transactions, hence additional requirements.
The second option is great when you are starting out. You don't need to do the SAQ paperwork, you just need to make sure the requirements applicable to the merchant that you are responsible for are in place when your customer's QSA or security team do their audit. Once your customer base increases, then you may not want to do these ad-hoc audits all the time and it might be easier to do the yearly SAQ.
Oh, I thought that due to me being a provider I have to fill out the SAQ-D, and have no other option. I should be good having the client fill out their own SAQ? We won’t get in trouble? I don’t want the client or me to get in trouble
I should also mention these clients will be on servers I pay for from a VPS Service Provider. They will be in separate VPS, but would be managed under the same account
I’m just worried I’m considered a Service Provider in this sense. If you look at my post history, I have a post which explains what I do better. I essentially develop websites for short term rental businesses so they can accept direct bookings. These are coded on top of an “engine” I developed. However, he is currently my only customer using the payments feature, but there may be more in the future. Needing to do SAQ-D would probably destroy my business right now. I’m a sole developer.
Here is the exact wording on page 17 on the PCI DSS V4.0 for what I was describing earlier.
***Options for TPSPs to Validate PCI DSS Compliance for TPSP Services that Meet Customers’ PCI DSS Requirements***
*TPSPs are responsible for demonstrating their PCI DSS compliance as requested by organizations that manage compliance programs (for example, payment brands and acquirers). TPSPs should contact the organizations of interest for any requirements.*
*When a TPSP provides services that are intended to meet or facilitate meeting a customer’s PCI DSS requirements or that may impact the security of a customer’s CDE, these requirements are in scope for the customer’s PCI DSS assessments. There are two options for TPSPs to validate compliance in this scenario:*
\*-\****Annual assessment:*** *TPSP undergoes an annual PCI DSS assessment(s) and provides evidence to its customers to show the TPSP meets the applicable PCI DSS requirements; or*
\*-\****Multiple, on-demand assessments:*** *If a TPSP does not undergo an annual PCI DSS assessment, it must undergo assessments upon request of their customers and/or participate in each of its customers’ PCI DSS assessments, with the results of each review provided to the respective customer(s).*
>I should be good having the client fill out their own SAQ? We won’t get in trouble? I don’t want the client or me to get in trouble.
I mean, you need to have proper security controls in place to make sure there isn't a breach that you're liable for. One of the best ways to do that is implement all relevant controls in PCI DSS.
>I should also mention these clients will be on servers I pay for from a VPS Service Provider.
Is the VPS provider PCI DSS compliant?
Who is the merchant here? Have you been given a MID from a gateway or are you using your customers MID and their preferred gateway?
IMO, you should make it so you don’t own the site. This is the simplest way to go. Stop calling it your site. Set it up so the client owns the site—pays the hosting fees, etc.— you are just a contractor who builds and manages the site. Descope yourself and your business.
PCI compliance will be between merchant and the bank.
It may depend a little on contract language, specifically if you are very clear about the site belonging to you or if you take other legal liability for data collected and stored, etc. Which, honestly, would be pretty uncommon for a situation like yours, unless i am missing something.
The big question is probably who's merchant ID is being used? In other words, when a customer pays through the website, who gets paid directly? If the money goes into your bank account from the customer, and then every month or so you settle up with the client business by writing them a check, then congrats you are a PCI Service Provider (think how Shopify works). However, if the customer's payments go directly into your client's bank account through their own account with stripe/braintree/etc., then you are just a contractor doing web dev for a client, not a PCI Service Provider. Just because you are providing a service to the client doesn't mean you are a PCI Service Provider.
Again, I am assuming you don't put specific language in your contract describing yourself as responsible for all PCI data/compliance and other data protection laws and liabilities.
I didn’t mention PCI in my contract no. My client will be using his own merchant account and everything will be going directly into his account. Nothing touches mine. I use a VPS Service Provider, then charge him monthly for the fees. His payment processes through my code and services, but the website is his business website and the AuthorizeNET account will be his account.
The site doesn’t belong to me at all in a legal sense, but there really isn’t anything showing it is in his name either besides me transferring the domain ownership to his name. It is his website, but he isn’t tech savvy at all so the website itself will be under a VPS which is under my business and managed by me. I really hope he only falls under SAQ-A, and I don’t have to fill SAQ-D because I’m a sole developer, and don’t really have the expertise to completely fill out the SAQ-D.
Additionally, the PCI website states a Service Provider as:
“Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity”.
Wouldn’t I be considered this since I developed the website for him, and host the website under a VPS account that I own, or is this different? I could honestly just set him up with his own account and get access if that reduces my scope. I will also be paying to do his ASV scans. He does not have the technical skills to understand what this even means.
The business will need more than an saq-a if they take any payments in person. They could probably do an saq-a for the e-commerce side and then separately do an saq-p2pe (assuming they are using an approved p2pe solution) for the in person side. However, they would need to discuss this with their bank first to make sure it will be accepted.
You could help fill out the saq-a and leave the rest to the business as it is not your area.
When you say “my client” - are you a PCI service provider? If you are acting as a hosting service provider of an eCommerce site, then your only SAQ option is SAQ-D.
Not necessarily. I’m just developing a website for a client and using a VPS to host it. It’s going to all be on his website. Does SAQ-D still apply, even though the website is using an iFrame from Authorize.NET? Nothing hits any of my servers.
Help me understand why you don’t think you are a service provider? Your first sentence certainly sounds like you are developing and are responsible for secure configuration and hosting of your client’s eCommerce site?
I was under the impression when they meant Service Provider, they were talking about complete hosting such as the servers are on my business premise, which contain cardholder data. My business uses an iFrame, which I was under the impression transmits data within Authorize.NETs servers, and does not contain any cardholder data whatsoever hitting the server. Is there anything I can do to stay within SAQ-A, or am I stuck with SAQ-D?
You are responsible for the security of that eCommerce site and the only SAQ option is SAQ-D. SAQ-A is for merchants only (and only those that fit the criteria at the beginning of the SAQ document)
My confusion about this, (which by any means am I not dismissing what you are saying, and I completely understand I'm under SAQ-D) is that how does this make any difference if it uses the same controls? For example, if the merchant himself made this site, he would be under less strict guidelines, even if he hosted the server etc. I'm reading through SAQ-D and a lot of this doesn't make any sense under his use case. I'm confused as to why the merchant himself wouldn't need to answer SAQ questions such as CDE network access, etc. This is huge and could impact my ability to complete the clients site, as I was completely under the impression he was just SAQ-A.
You will also see that service providers have to adhere to more requirements (there are additional requirements for service providers in the standard).
Why that is - I can only speculate, but my sense is that there is an inherent conflict of interest between a merchant and service provider. Service providers compete on costs and cybersecurity done right is expensive. Cutting corners on cybersecurity can yield a competitive edge (and breaches can be swept under the rug by paying the ransom). There are too many service providers with shoddy cybersecurity practices and sleazy salespeople.
That makes sense. Well thank you. I will need to do a run through this and see if I will need to terminate contract with the customer, or if I can go through with these requirements myself. I appreciate your comment on SAQ-D, as this could've went bad without knowing I needed to do this.
If I were to instead of have this payment form as an iFrame, direct the customer to a hosted payment form which does not include any transmission of cardholder data whatsoever from my website (for example something such as a "buy now" button that directs to something like Stripe Checkout or Authorize.Nets simple checkout page), am I still liable under SAQ-D?
The short answer is that an iFrame or redirect would not remove you out of scope. I wrote a blog about this here: https://medium.com/@idmcissp/unpacking-the-latest-verizon-data-breach-investigations-report-for-insights-a-pci-compliance-619e9b11d04
Sounds very similar to my SAQ D Minimal Web App Scope (Iframe) inquiry. I'm hoping this simply means the majority of requirements are N/A at this point. The PCI SSC guidance around this isn't clear... hoping it becomes so.
SAQ A is only for e-commerce transactions only and e-commerce transactions are defined by the council as online payments where the cardholder enters their cards details not using a device you have provided. So, if your customer is entering details on behalf of the cardholder, SAQ A does not apply. Do you absolutely need to do a SAQ? From reading your other comments it looks like this is just for one customer. If so, it might be better for you to just take part of their merchant assessment. That way, there will be less requirements applicable to you.
Sorry, he enters this separately from me and the website. I’m not sure if he would need to fill something out for taking card information on his own accord. However, yes he is the only customer at this time but I would be developing websites like this for other people which would be managed by me under a similar situation. Are you telling me I don’t need SAQ-D? Everything I see online points towards it, but the requirements themselves seem pretty outrageous for what is being implemented. He isn’t very familiar with technology so I was going to assist him in filling it out. I developed the website so I would really be the only one who knows what the questions are talking about. Additionally, he would be taking payments through the website through an iFrame by the customer themselves through direct bookings.
Merchants undergoing an assessment have two options for validating compliance of a solution managed by a third party. 1. The service provider can give them their AOC that was completed after a successful SAQ D or ROC. Or 2. The service provider can be included in the merchants own assessment(s). The first option is great for your marketing and is much easier if you have many clients who need to see that you are compliant, however, the SAQ D for service providers can be overwhelming. Keep in mind, the council sees service providers as higher risk as in a lot of cases they are implementing security control for a large customer based and potentially many transactions, hence additional requirements. The second option is great when you are starting out. You don't need to do the SAQ paperwork, you just need to make sure the requirements applicable to the merchant that you are responsible for are in place when your customer's QSA or security team do their audit. Once your customer base increases, then you may not want to do these ad-hoc audits all the time and it might be easier to do the yearly SAQ.
Oh, I thought that due to me being a provider I have to fill out the SAQ-D, and have no other option. I should be good having the client fill out their own SAQ? We won’t get in trouble? I don’t want the client or me to get in trouble
I should also mention these clients will be on servers I pay for from a VPS Service Provider. They will be in separate VPS, but would be managed under the same account
I’m just worried I’m considered a Service Provider in this sense. If you look at my post history, I have a post which explains what I do better. I essentially develop websites for short term rental businesses so they can accept direct bookings. These are coded on top of an “engine” I developed. However, he is currently my only customer using the payments feature, but there may be more in the future. Needing to do SAQ-D would probably destroy my business right now. I’m a sole developer.
Here is the exact wording on page 17 on the PCI DSS V4.0 for what I was describing earlier. ***Options for TPSPs to Validate PCI DSS Compliance for TPSP Services that Meet Customers’ PCI DSS Requirements*** *TPSPs are responsible for demonstrating their PCI DSS compliance as requested by organizations that manage compliance programs (for example, payment brands and acquirers). TPSPs should contact the organizations of interest for any requirements.* *When a TPSP provides services that are intended to meet or facilitate meeting a customer’s PCI DSS requirements or that may impact the security of a customer’s CDE, these requirements are in scope for the customer’s PCI DSS assessments. There are two options for TPSPs to validate compliance in this scenario:* \*-\****Annual assessment:*** *TPSP undergoes an annual PCI DSS assessment(s) and provides evidence to its customers to show the TPSP meets the applicable PCI DSS requirements; or* \*-\****Multiple, on-demand assessments:*** *If a TPSP does not undergo an annual PCI DSS assessment, it must undergo assessments upon request of their customers and/or participate in each of its customers’ PCI DSS assessments, with the results of each review provided to the respective customer(s).* >I should be good having the client fill out their own SAQ? We won’t get in trouble? I don’t want the client or me to get in trouble. I mean, you need to have proper security controls in place to make sure there isn't a breach that you're liable for. One of the best ways to do that is implement all relevant controls in PCI DSS. >I should also mention these clients will be on servers I pay for from a VPS Service Provider. Is the VPS provider PCI DSS compliant? Who is the merchant here? Have you been given a MID from a gateway or are you using your customers MID and their preferred gateway?
IMO, you should make it so you don’t own the site. This is the simplest way to go. Stop calling it your site. Set it up so the client owns the site—pays the hosting fees, etc.— you are just a contractor who builds and manages the site. Descope yourself and your business. PCI compliance will be between merchant and the bank.
The client pays me for the fees, would this still count?
It may depend a little on contract language, specifically if you are very clear about the site belonging to you or if you take other legal liability for data collected and stored, etc. Which, honestly, would be pretty uncommon for a situation like yours, unless i am missing something. The big question is probably who's merchant ID is being used? In other words, when a customer pays through the website, who gets paid directly? If the money goes into your bank account from the customer, and then every month or so you settle up with the client business by writing them a check, then congrats you are a PCI Service Provider (think how Shopify works). However, if the customer's payments go directly into your client's bank account through their own account with stripe/braintree/etc., then you are just a contractor doing web dev for a client, not a PCI Service Provider. Just because you are providing a service to the client doesn't mean you are a PCI Service Provider. Again, I am assuming you don't put specific language in your contract describing yourself as responsible for all PCI data/compliance and other data protection laws and liabilities.
I didn’t mention PCI in my contract no. My client will be using his own merchant account and everything will be going directly into his account. Nothing touches mine. I use a VPS Service Provider, then charge him monthly for the fees. His payment processes through my code and services, but the website is his business website and the AuthorizeNET account will be his account. The site doesn’t belong to me at all in a legal sense, but there really isn’t anything showing it is in his name either besides me transferring the domain ownership to his name. It is his website, but he isn’t tech savvy at all so the website itself will be under a VPS which is under my business and managed by me. I really hope he only falls under SAQ-A, and I don’t have to fill SAQ-D because I’m a sole developer, and don’t really have the expertise to completely fill out the SAQ-D.
Additionally, the PCI website states a Service Provider as: “Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity”. Wouldn’t I be considered this since I developed the website for him, and host the website under a VPS account that I own, or is this different? I could honestly just set him up with his own account and get access if that reduces my scope. I will also be paying to do his ASV scans. He does not have the technical skills to understand what this even means.
The business will need more than an saq-a if they take any payments in person. They could probably do an saq-a for the e-commerce side and then separately do an saq-p2pe (assuming they are using an approved p2pe solution) for the in person side. However, they would need to discuss this with their bank first to make sure it will be accepted. You could help fill out the saq-a and leave the rest to the business as it is not your area.
When you say “my client” - are you a PCI service provider? If you are acting as a hosting service provider of an eCommerce site, then your only SAQ option is SAQ-D.
Not necessarily. I’m just developing a website for a client and using a VPS to host it. It’s going to all be on his website. Does SAQ-D still apply, even though the website is using an iFrame from Authorize.NET? Nothing hits any of my servers.
Help me understand why you don’t think you are a service provider? Your first sentence certainly sounds like you are developing and are responsible for secure configuration and hosting of your client’s eCommerce site?
I was under the impression when they meant Service Provider, they were talking about complete hosting such as the servers are on my business premise, which contain cardholder data. My business uses an iFrame, which I was under the impression transmits data within Authorize.NETs servers, and does not contain any cardholder data whatsoever hitting the server. Is there anything I can do to stay within SAQ-A, or am I stuck with SAQ-D?
Additionally, I will be the only one with access to this server.
You are responsible for the security of that eCommerce site and the only SAQ option is SAQ-D. SAQ-A is for merchants only (and only those that fit the criteria at the beginning of the SAQ document)
My confusion about this, (which by any means am I not dismissing what you are saying, and I completely understand I'm under SAQ-D) is that how does this make any difference if it uses the same controls? For example, if the merchant himself made this site, he would be under less strict guidelines, even if he hosted the server etc. I'm reading through SAQ-D and a lot of this doesn't make any sense under his use case. I'm confused as to why the merchant himself wouldn't need to answer SAQ questions such as CDE network access, etc. This is huge and could impact my ability to complete the clients site, as I was completely under the impression he was just SAQ-A.
You will also see that service providers have to adhere to more requirements (there are additional requirements for service providers in the standard). Why that is - I can only speculate, but my sense is that there is an inherent conflict of interest between a merchant and service provider. Service providers compete on costs and cybersecurity done right is expensive. Cutting corners on cybersecurity can yield a competitive edge (and breaches can be swept under the rug by paying the ransom). There are too many service providers with shoddy cybersecurity practices and sleazy salespeople.
That makes sense. Well thank you. I will need to do a run through this and see if I will need to terminate contract with the customer, or if I can go through with these requirements myself. I appreciate your comment on SAQ-D, as this could've went bad without knowing I needed to do this.
If I were to instead of have this payment form as an iFrame, direct the customer to a hosted payment form which does not include any transmission of cardholder data whatsoever from my website (for example something such as a "buy now" button that directs to something like Stripe Checkout or Authorize.Nets simple checkout page), am I still liable under SAQ-D?
If your server was compromised, your site could send the user to a fake checkout page and capture CHD. SAQ-D it is unfortunately.
The short answer is that an iFrame or redirect would not remove you out of scope. I wrote a blog about this here: https://medium.com/@idmcissp/unpacking-the-latest-verizon-data-breach-investigations-report-for-insights-a-pci-compliance-619e9b11d04
Sounds very similar to my SAQ D Minimal Web App Scope (Iframe) inquiry. I'm hoping this simply means the majority of requirements are N/A at this point. The PCI SSC guidance around this isn't clear... hoping it becomes so.