foreign [Music] yeah we'll see how the Technologies like AI can help us you know maintain the compliance and how they can help us you know uh there are compliance areas related to PC ideas wherein we can automate the processing and make our life simpler okay going ahead let's quickly look at Agenda so we will look what is PCI DSS compliance definition and its importance an overview of 12 wheel requirements like I said there are 300 plus sub requirements into 12 categories yeah we we will not gonna test that we will see at the goal level achieving PCI DSS compliant how we can break down the big rock into small chunks and then start you know working on each components separately uh future trends like ai's how and in what terms they can help us by automating some of the processes and difference between 3.2.1 and version 4 basically few of the points not entire because it's a it's a you know a 180 page document talking about the sub requirements but yes uh very important why still version 3.2.1 is still very important and white plays a crucial part here uh over 4.0 uh and yeah every Trader is certified uh in whatever domains they are training so yeah well qualified professionals having industry experience and yeah the client speaks for some themselves so if you look at the client base you will find different light clients working in a different areas of their expertise so yeah and when it comes to infrastruct we have touched every domain so yeah every sector basically so yeah it's good to say that yeah we are we are Paramount leaders in training and yes we we offer post training completion support we we offer tailor-made trainings we also do corporate trainings okay and yeah access to recorded sessions so whatever whosoever enrolls for any kind of training yeah they will have access to recordings and see our learning Partners Microsoft commsia iapp Council yeah and the number goes on so without wasting much of the time uh let's get into what is PCI SSC before going into what is PCI TSS okay so PCI SSC stands for payment card industry security standards Council uh this Council was founded on 7th September 2006 by five major payment Brands Visa Discover Mastercard GCB MX which is American Express but why this Council was formed okay first and foremost consistency in this standardization so PCI was created to establish uh accessible established tools you know establish a unified and unconsistent set of security requirements for payment card industry yeah prior to this uh all of these uh payment rights like Visa discover Master JCB and MX they had their own set of security requirements and just imagine if a bank or a service provider is dealing with these uh payment Brands uh he had to comply or they have to comply with several set of different set of security requirement which was not feasible with for them so all of them came together and formed pcasc so that to bring the uniformity and second thing was collaboration in Industry trust obviously when you when you collaborate you get more knowledge and you you build more enhanced standards you get more insights how things are placed in the market what kind of new threats are emerging Visa maybe maybe facing with new kind of threats discover may be facing of new kind of threats and different kind of attacks we have collaboration and Industry trust obviously when we when we you know get together so these were the two major points that that came to you know birth of pcisc 7 September 2006. okay moving ahead let's look at the framework and the glance what pcie SSC means about so this is the Strategic framework at very high level Y and what pcie thinks pcssc thinks and what is the mission of that so Mission itself speaks like to enhance the global payment account data security by developing standards and supporting services that drive education awareness and effective implementation by the stakeholders basically they develop the standards they provide supporting services they maintain the list of the qsys saqs asvs and whatnot so they have very diverse uh you know uh responsibility when it comes to payment card security and those are achieved by four pillars so number one pillar says increase the industry participation and knowledge what does this mean what this will ensure so this will ensure that the standards and the resources reflect and address industry needs and challenges the second pillar says evolve security standard in the validation so it's self-explanatory this ensures that the standards and the resources that support and enable safe Commerce and flexibility to use different approaches to meet those standards yes secure emerging payment channels yeah we know that payment channels are emerging day in day out so this enables safe Commerce in new and emerging card based and card based payment channels such as mobile internet of things and whatever you can think for I mean as a payment Channel increase standards and alignment and consistency basically to to bring homogeneity and to minimize redundancy and support effective implementation so this is the whole strategic framework that pcssc follows moving ahead our core topic what is PCI DSS so pcie DSS stand for payment card industry data security standard okay it's set it is a set of you know six goals and 12 requirements set by PCI SSC which every industry has to comply whosoever stores processes and or transmits account data or it's a card holder data for now account data I'll explain what is what is the account data so any entity or any organization which stores processes or transmits okay it's not about and everywhere it's or it needs to comply with PCI DSS okay now account data here is card holder data plus sensitive authentication data but in the latest like we will see what is what comes under cardholder data and what comes under sensitive authentication data okay so PCI DSS will be applicable to all only to the industries that process transmit our stores card data of these five payment Brands only so yeah if there is a shopper stop uh card or any petrol pump uh card prepaid card which doesn't have these logos or which doesn't transact with any of these five payment Grant PC ideas will not be applicable on that now the question comes where does so there is no authentic or direct circular from RBI which says you have to comply with PCI DSS rather they talk about the security in different circulars which is Master circular for credit card debit card rupee denomination co-branded credit card operations and master direction for issuance and operation of prepaid payment instruments in when you look at these two circulars very closely you will see the requirements that are closely aligned with PCI DSS so in other words if those Industries those Bank who are who are involved in storing processing and transmitting of the cardholder data that belongs to Rupee if they comply with PCI DSS it's it's highly likely that they will comply with those circular from 95 to 99 percent okay now we have seen this on what pcids is applicable so from a big chunk of you know sectors we we now cut down into stores storing transmitting and processing of the cardholder data now see what does a coward looks like and what are the payment elements involved in this card okay so when you when you do shopping uh somewhere let's say online or are on a shop there are two ways where you can present your card either it can be a card present transaction or it can be card not present transaction so card present transaction is very of physically presenting your card to the uh to to let's say the shopkeeper to do the payment and card not present where and you are manually entering your card to to do the transaction now all of you who are thinking about let's say if somebody is using Apple watch or somebody is using uh you know a wallet but you are not physically giving the card those are also card present transaction because you are holding the phone and it holds your card as well in the form okay not in the exactly form of the card but yeah it is a tokenized value that's a later constant but yeah uh you are physically giving your phone over there that that comes under the payment uh card present transaction now what are the payment elements involved in that uh chip obviously you can see your card and whenever you put your card the chip is right from the terminal and then the rest of the process follows then we have pan pan is primary account number which varies from 12 character to 16 19 characters uh this is the this is a number that is printed on the card then we have cardholder name then we have expiration date and we have on the other side of the card we have Cav CID CVV and cvv2 so this is don't get confused with all these terminologies most common word is cvv2 depending upon what card you are using these terminologies are used Cav but all of these are same uh you can consider that these are cbb2 and if it is MX it's four digit character it will be printed uh this this same value will be printed on the front of the card okay uh and we have a magnetic stripe as well at the back of the end of the card it contains three tracks track one two and three basically the tracks that are responsible for the payments at Rack one and two majorly when you insert the car sorry when you swipe the card the track two is read first but for somehow if track 2 is not available or not read then the fallback mechanism is track one and track three is reserved from other for other purposes so this is how a cart looks like and what component it does have here you see the logo so yeah you you can see uh if it is Mastercard Visa JCB something like that uh only then the PCI is applicable so here you from here you can recognize the payment brand all right now we know we we have two flavors of the same standard available in the market is 4.0 and you know it has goals and requirements and then we have 3.2.1 it has also goals and requirements okay now let's closely look at the requirement from from the stand from the goal perspective at least so this is when you look at closely from 3.2.1 and 4.0 what you will see only few of the wordings have been changed just to make clear what we are trying to protect it's not like they have changed the whole requirement we'll also see how many requirements have changed but if you look at closely from from a goal perspective let's see build and maintain a secure network and systems build and secure and maintain any token systems here it talks about cardholder data here it talks about account data but when you closely look at there a few of the requirement has also changed but that's a different topic but let's see at a higher level what these goals means so the first goal is uh build and maintain a secure networking system so this goal focuses on establishing a secure network infrastructure by implementing basically the robust security measure that you can think of like firewalls to protect the card holder data it also involves maintaining and securing system configuration and regularly updating the let's say patches to address the vulnerability the second goal is uh car protecting of the protection of the cardholder data or let's say protect the account data this goal involves implementing strong data protection measures to safeguard the card order data basically card holder data at rest or card doodle data in motion okay so if it's traveling over from one placed location with it with it be it on the same land be it uh over the Internet so the second goal types it defines the requirement for how you can store or how you can transmit it Okay the third goal talks about uh maintain a vulnerability Management program which which emphasizes on you know uh basically doing the vulnerability scans uh patching those vulnerabilities proactively subscribing to the newsletters wherein you will get all information of the weaknesses of different kind of different flavors of system that you have involved are deployed in your environment so those kind of uh requirement come into requirement goal number three and also basically developing your application in a secure way so it does Define some of the requirement that this PCI Council they feel that it needs to be there when you are developing a new application Implement strong access controls or requirement sorry goal number four basically talks about access control be it physical be it logical okay and be it on a need to know basis so 789 requirement that fall into you know uh Implement strong Access Control now with 4.0 they have come up with extra uh sub requirement for for Access Control right MFA requirements additional MFA requirements uh what else uh then then we go to uh goal number five which says uh Monitor and test networks basically this goal emphasizes on audit lock uh testing wherein doing the pen testing uh segmentation testing those kind of activities uh come into goal number four basically you you build your network from one to four and the fifth goal you test your network whether it is working in an efficient way in a secure way uh the way that you have wanted or not so one to four you design your and Implement your all the uh stuff from security from servers from firewalls XYZ and then is the Practical measure whether they are working securely or not and the last uh requirement is uh last goal is maintaining an information security policy basically this goal uh you know defines that all a requirement from 1 to 12 should have been addressed at a policy level at least so that none I mean if you if you want to build a network how and which policy you have to refer so that you can build your network securely so that's a requirement number 12. and by achieving this these uh six goals our mission can significantly enhance security of the payment card transaction and they can also protect the cardholder data in an efficient way and and they can comply to PC its standard and the penalties penalties are very high okay uh if you do not comply with any of these standards so PCI works as binary zero one either you comply to a standard or you do not comply to a standard okay complying to a standard let's say even if you do not tweet any any requirement you can go for compensatory control okay and still you can uh you know comply to this standard the moment any of the sub requirement you say is non-compliant that means you are non-compliant to the standard itself directly now it is up to the acquiring Bank payment brand whether they let you do the business or they do not let you do the business also if you try to hide it uh if if any of the parameter is incorrectly uh you know handled or judged by the qsa QSC stands for qualified security assessor who does the external PCA audits it belongs to they will belong to only a PCI qsa company who are entitled to sign the report let's say by mistake or let's say somebody bribed them to do some false uh control judgment and they say compliant and later on there there would be some some security breach and wherein now the payment grants are involved and they are caught then the penalties are very very high on the qsa company itself and the company who is doing the business over which the bridge has happened so better to comply with all the standards and if you're not complying to any of the requirement clearly tell your qsa or uh tell your bank or who is the supervising uh Authority that yeah this control doesn't meet but yeah we do have risk assessment done we have compensatory controls in place in by so so time we will be able to comply to these particular requirements moving ahead how we can break down uh radius as compliance we know that this is a this is a yearly compliance and it is continuous in nature every year pcis has been needs to happen and at a broader level this can be classified into three phases assess repair and Report what does this mean this mean that SS in the SS phase we assess their scope we do the risk assessment digital Gap assessment and then we fall into a repair phase where in repairing what we do we we apply patches or let's say we apply controls wherein uh wherein we feel that control is not sufficient in is enough and then we report so this is this is at the highest level but when when you you know look at the Key activities at these different levels basically it can be done at uh two levels one is Key activities which involve risk assessment or the entire School the Gap analysis where where you are standing as of now and what does uh and how much you have to still cover to comply with PCI DSS okay and then followed by remediation once you do the remediation you fall into the next next stage which says compliance validation what is compliance validation basically it's self-assessment of uh of the controls that you have implemented let's say we all know about three lines of Defense probably an independent uh you know third line or second line can come and S is the first line and after that go for external audit so in in that a big rock now cut down into small chunks where in different team responsible for different things like risk assessment by uh by a risk manager and after that Gap analysis by independent Wing something like that can be done and it can whatever the shortcomings are those can be fixed and after that go for self-assessments so the big rock now divided into small change so that it can be achieved is in an easier way now going ahead uh one more point that is left here is training above all why what you need to comply with and what not it's very very important there are certain controls which are not applicable to you that may be applicable to uh certain are applicable to a merchant certain are applicable to uh service providers so you need to have trade training and all on all uh standard actually on pcid is a standard whether you're going for 3.2.1 or 4.0 so that's that's there the training is very very important if especially if you are new to PCI DSS because this is Hardcore technical uh training where and every control is a technical controller apart from when you say um physical security controls in requirement number nine I think yeah there you can say some kind of semi technical control but apart from this when it comes to requirement number three four it talks about encryption uh at rest motion everything requirement number one talks about Network hardening and also you you need to be very technically trained so that's why uh to feel that sense of the entire standard training on the standard is very very important now why training is also important that you need to know that there are two categories that are prescribed by PCI DSS that that needs to comply with PC ads standard one is Merchant one is service provider so who is a merchant and who is a service provider so in the context of PCI DSS a merchant refers to any organization that accepts the payment okay from obviously us and they gives goods and services to for example eBay is a is a merchant paytm is a merchant okay Amazon is immersion okay it can be businesses of all sizes from local retailers to multinational corporations Qatar Airways urgent okay now the other category is service provider so who is a service provider so in the context of PC devices a service provider is someone who is supporting the merchants or any other service provider who is involved in the payment card transaction okay it can be a payment processor it can be a hosting provider it can be managed service security provider mssp we call that it can be software as a service provider it can be data surgeon Center service providers okay but yes uh the big myth is sometime it's uh people get confused who whether I fall in a category of a merchant level or should we we fall in in a service provider level So to demystify that a merchant will always have a merchant ID if you do not have a merchant ID from your bank or let's say acquirer you are service provider so either you are a merchant or a service provider that's how presides classifies the entities here so identity can be a merchant and Merchant will always have a merchant ID and a service provider now when it comes to AWS it is a merchant but the company also acts as a service provider so one unit who sells the goods who accept the payment on behalf of you is is a merchant but on behalf of that AWS also offers hosting service service okay wherein you host your infrastructure over there that part comes into service provider and depending there are certain requirements that are only applicable to Merchants and there are some additional requirements that service provider needs to comply with now depending upon the type of number of transactions depending upon the number of transaction there are various levels of merchants and service provider so Merchant drivers are broadly from one to four and the service provider levels are from one to two and this is on the number of transactions not direct transaction let's say if a single transaction is of 6 million no that is not uh not will not be classified as a level one Merchant rather it it it will fall into level four hypothetically daily okay but let's say there are number of transactions like one transaction of one rupee to Rupee three rupee 4 rupee another transaction of four five six something like that so the number of transaction count went while defining the merchant and it's not uh uh let's say per brand of 6 million transaction of Visa only or six million transaction of let's say uh what of MasterCard but it's combined transaction okay same goes with uh you know service providers and depending upon these levels if you are not going for an on-site audit okay these are the saqs that you can follow but this needs to be clearly identified by The Entity itself whether I am a merchant I uh I do not have a 6 billion plus transactions so should I do SAQ a b c d whatever so that's why training of these standards are very much important so as to get yourself clear that under what SAQ will fall if you are not going for level one so only level one uh uh Merchant or level one service provider qualifies for on-site audit rest of them can can do self-assessment questionnaire either can be signed by the c-level executive of the organization or they can onboard a QSC company where in a QSC will attach these seqs and these saqs have more less number of requirements because the transaction level is also always so these are based on risk based approach I would say and and but again you need to be sure that I I have to do seq a aepb bipc CVT and all so these these the and for service provider there is only one seq that is available which is a security so service provider doesn't have a leverage to go into ABC they only have to do a security for service provider which is kind of mini level one assessment that's all but yeah these can uh this does not mandate you to have you know uh calling a qsa on your uh [Music] premise and have them audit your system but the good catch here is it's always good to check with the acquirer uh let's say if there is a bridge some somehow in your organization previously then even if you do not even if you are into let's say level four PCI Council or the acquirer may ask you to go for level one audit so ideally you will fall into SAQ but somehow if there was some breach or the superior Authority then your organization is not convinced with your security control they may ask a qsa and they may ask you to go for level one audit okay we talked too much about audit number one number two let's talk about the places principle what PCI DSS says and what can be stored as a part of PC ads's requirement what cannot be stored now what so uh we we read earlier that uh and we learned that cardholder data and sensitive authentication data together will give account data and pci's responsibility as per goal number two of version 4 says protect the account data and in 3.2.1 they only talked about this one card rooted data which was not clear now they have come up with the updated statement which says protect the account data so this plus this together makes account data okay now sensitive account data cannot be stored after authorization let's let's make it so simple you cannot store a sensitive authentication data which is cvv2 pin your pin the ATM pin and its corresponding pin block basically when you enter the pin on pause or let's say ATM it gets converted into pin block and then it is transferred rather than you know clear transmission so pin and pin block cannot be stored cvv2 cannot be stored and obviously full track data which is track one or track two in the magnetic stripe cannot be stored once the transaction has been authorized okay now comes now comes the card or the data so in cardholder data there are four components span basically primary account number card order name service code and expiration date these can be stored but in that as well uh primary account number uh should not be stored okay if if there is no need to store but if you want to store that yes you can store it but you have to render uh this unreadable the pan needs to be rendered unreadable okay and there are as per PCI Council there are four ways wherein you can render the pan unreadable so number one way is truncation encryption hashing and tokenization so these are the four ways wherein you can you know render the pan unreadable now in truncation you only store first six and last four digit okay yeah this can change when when when uh when you have permission or let's say it depends upon bin as well by uh Bankers identification number uh when the card number nowadays card numbers are going Beyond 16 digit authentic I mean which is traditional way so this can change a little bit but as of now uh truncation means if you're you are rendering the pan unreadable truncation means you are only storing first six and last four digit of a card and you are just omitting and deleting the middle characters okay encryption yeah always it's pretty much a simple encryption risk basically it changes a plain text into Cipher text but you you are not allowed to use weak uh you know encryption algorithm basically uh yeah as of if you're using symmetric one you you need to have as 128 bit as of now but yeah it will go to 256 very very soon uh but it also depends upon qsa I is a qsa when I was doing the audits uh yeah my only recommendation was to go ahead on on the higher bits rather than the lower bets third method is hashing basically taking the pan and just doing a hash of it uh irreversible as like md5 or let's say two and then then storing it and finally is a final is tokenization you you make tokenize the card basically having a different value of the the of the same card uh or you may hire a token service provider where and he can tokenize card we have behalf of you or and instead of giving you the original card he can give you the token to do the transaction so these are the four ways where and you can uh you can make the pan unreadable okay now coming to the point why 3.2.1 is very important so still in demand it's not expired at all okay and still the companies are trying to adapt 4.0 which is not very popular as of now yeah it has made a buzz in the market but yeah companies are still going with 3.2.1 because it has not expired as of now okay multiple requirements are same compared to 3.2.1 when when you compare the goals of 4.0 versus the course of 3.2.1 you will see the goals are you know pretty much the same yeah sub requirements have changed of only few subject moments but yeah it doesn't change the essence of you know the flavor that 3.2.1 brought okay and it still builds the foundation for 4.0 so yeah 4.0 is built on top of 3.2.1 obviously that that should have been there because yeah 3.2.1 was very mature and it it lasted for a quite a time I think 2.3.0 was launched in 2014 I guess and that multiple revisions took place that led to 3.2.1 which was the last standard till 4.0 award and when you look at the timelines here is still 3.2.1 is valid till 31st March uh 30th March because 31st March it will expire 30th March so if any company or any entity who gets compliance in March they will be still compliant till 2025 q1 so that's big time period from for for Trans for transitioning yourself from uh 3.2 Dot uh one to four and still you have I think one year one and a half year okay but yeah somewhere or the other it has to expire so 31st March 2025 all the requirement of 4.0 will be applicable 3.2.1 will expire on 31st March 2024 but still when you see here if you are getting a compliance on let's say 30th March itself your compliance will be still valid the standard will no longer be it needs to be assessed after 2024 31st March but yeah the compliance will be still valid till next year 2025. so since it builds the foundation 3.2.1 and it's it's very much in demand I have seen multiple client which is in the fast as well they are still sticking to 3.2.1 looking and and looking at the numbers they speak for themselves now if anyone is going for pcid SS 4.0 let's see how many requirements have changed so out of all the requirements how many requirements has changed 53. okay 300 plus requirements and only 53 changed okay and additional 11 on service providers okay so 53 plus 11 on service provider out of these 53 I would assume few were few will be not applicable depending upon the nature of the business let's say for example if an entity is not storing their card data uh with them then requirement number three goes away so whatever the requirements they have changed it for requirement number three will go away okay and then talking about the effective dates uh if any entity who is going for 4.0 even they have to just comply for 13 requirements as of now so if I am going for PCI DHS version 4 assessment I have to only work on the 13 requirements not on all the requirements but yeah after 2025 which is still very far away miles away 51 requirement needs to be you know implemented after that I mean you have leverage on 51 requirements so yeah that's that's all this this number supports the previous slide as well why is 3.2.1 is very important because when once you get that sense of 3.2.1 understanding 4.0 uh will not be a tough task now let's talk about the changes what have changed from 3.2.122.2 on a process level this is a major change okay this is the this is where the major shift has happened wherein defined approach which was a traditional way of PCI DSS where and just there was requirement written qsa comes sees the requirement if you're not compliant you're not compliant you are compliant you're compliant that's it in the customized approach we it gives a little bit more flexibility especially to the organization that are more mature you can customize and cause an objective of a control wherein you have different controls to meet the same objective of PCI DSS requirement so this is this this is where it gives the flexibility to adjust your compliance and it suits the larger organization which have more you know risk mature entities basically are flexible to choose between you know Define implementation versus customized implementation also it's not required that for you know if you're going with defined approach you cannot adopt the customized approach you can these two can work in hand in hand for five controls let's say you have defined approach but the sixth control you think that you have designed uh a better control than this one which is meeting the objective you can for that particular uh you know control or objective you can choose the customized implementation now talking about uh the at the control level what has changed here clear definition and documentation of roles and responsibilities which was yeah pretty much not clear when when it was 3.2.1 you will see a lot of overlaps and somewhere the responsibilities are not clear versus when you go to 4.0 uh then and this control has got some maturity and yeah clear documentation who in the company needs to do what is there okay requirement associated with uh stored pen such as updating cryptographic architecture and all uh yeah uh major shift here as well uh you are not allowed to use weak encryption algorithm or all so this is also this is this is where the companies needs to work much because they need to design their entire uh encryption algorithm methodologies as well that how encryption will happen how the decryption will happen yeah how they will call the encryption Keys how they will store the encryption Keys when it comes to automatic uh pan encryption through the source code of the application itself authenticated anti-malware scans uh earlier you just put the IPs over there and scan it and it it gives the uh it gives a list of vulnerabilities but those were not sufficient because you will not get much vulnerabilities over there as compared when when you provide you know authenticated scans so the case scans needs to be authenticated earlier in 3.2.1 it was uh uh best practice here they have mandated it automated technical solution for Wi-Fi facing application earlier this this was an optional and 3.2.1 here it's a mandate to have over there and automated web audit log reviews are automated no longer manual reviews are accepted and key cryptographic hashes so earlier like I told that one of the way was to render the pan and readable was hashing wherein just you take the pan pass it to the hashing algorithm it generates your uh what do you say a hash but here uh those hashes are no longer considered as secure so they have changed it to keyed crypto graphic questions we are in algorithms like hmac becomes pretty much important and much more secure than normal traditional hashing okay so yeah at control level these are the major changes yeah there have been lot more changes at the subcon sub in control level at a higher level these are the major ones we are industry needs to think about that future Trends uh that how I can can be you know useful for us so enhanced cell reduction basically AI can improve the availability ability to detect and respond to security threat by analyzing large volume of real-time data yes we with AI it's such evil it can identify the patterns and anomalies as well AI can be tuned in that way fraud detection and prevention algorithms can be trained to recognize the pattern of fraudulent transaction uh uh enabling more accurate identification and prevention of fraudible activities and this can help organization to comply with PCI DSS requirement related to fraud and monetary prevention there would there are controls related to that then comes data protection and encryption encryption yeah uh with Advanced AIS you you you can do I mean train the engine or let's say program to do this stuff for you automated uh automation of the compliance task wherein you feel that this this is a on a daily basis this is on a weekly basis where and you can just program the AI um and get the things done for you instead of doing manual tasks or an automation of compliances oh let's repeat it uh twice there was something else I'm sorry but yeah despite of all these uh things which AI can offer it does not replace the need for a comprehensive security strategy in a human oversight obviously who is programming it it's it's us who are programming it and if we are too much reliant on AI that means um we are not doing right because yeah it needs a human oversight it may go wrong as well and and AI can be used to compromise uh our AI so yeah more targeted phishing attacks malware's okay more targeted uh let's say tuned AIS can be you know uh utilized to to you know bypass your systems so yeah it's it's it helps but yeah human oversight is always requires so yeah we as a compliance guys that we can see yeah our job is safe for now so that's pretty much it as of now that I think uh and what did we learn today that what and why exist what was this their mission okay and the four pillars applicability of pcidas is basically PCA DSS is basically applicable to any entity that store transmittent processes cardboard and data in a summary of goals and the requirements elements that are involved in the uh you know payments like a chip expiration date and all track data and major changes from 3.2.1 to version 4.0