[{"data":1,"prerenderedAt":6946},["ShallowReactive",2],{"framework-topics-pci":3,"framework-pci":3552,"related-glossary-asv-pci-dss-pci-scope-vulnerability-management":4055,"explore-glossary-pci-\u002Fframeworks\u002Fpci\u002Fasv-program":4878,"explore-topics-pci-\u002Fframeworks\u002Fpci\u002Fasv-program":5582,"explore-hub-pci":6090,"explore-compare-vs-\u002Fframeworks\u002Fpci\u002Fasv-program":6378,"explore-compare-\u002Fframeworks\u002Fpci\u002Fasv-program":6544,"explore-blog-pci-\u002Fframeworks\u002Fpci\u002Fasv-program":6665,"explore-industry-pci":6862},[4,314,705,1077,1337,1631,1853,2185,2554,2918,3205],{"id":5,"title":6,"body":7,"description":278,"extension":279,"faq":280,"frameworkSlug":294,"lastUpdated":295,"meta":296,"navigation":297,"path":298,"relatedTerms":299,"relatedTopics":304,"seo":309,"stem":312,"__hash__":313},"frameworkTopics\u002F5.frameworks\u002Fpci\u002Fasv-program.md","PCI DSS ASV Program and Quarterly External Scans",{"type":8,"value":9,"toc":266},"minimark",[10,15,19,22,26,29,32,48,51,55,58,104,107,111,114,176,179,183,186,189,193,196,199,203,253,257],[11,12,14],"h2",{"id":13},"what-the-pci-dss-asv-program-is","What the PCI DSS ASV program is",[16,17,18],"p",{},"The Approved Scanning Vendor (ASV) program is the PCI Security Standards Council's accreditation scheme for firms that perform the external vulnerability scans PCI DSS requires. Under PCI DSS Requirement 11.3.2, every organization with internet-facing systems in the cardholder data environment must run external vulnerability scans at least quarterly and after any significant change, and those scans must be performed by an ASV. Only firms listed on the PCI SSC's public ASV list can produce reports that satisfy PCI DSS; scans from unaccredited scanners or purely internal tooling do not count.",[16,20,21],{},"ASVs earn their status by passing an annual PCI SSC qualification, running their scanning tooling through a rigorous validation environment, and employing certified ASV employees. The PCI SSC maintains the master list of ASVs and publishes updates as firms are added, renewed, or removed. Selecting an ASV is therefore both a PCI DSS compliance decision and a security decision: the ASV's scanners, processes, and analyst capacity materially shape the quality of your external vulnerability data.",[11,23,25],{"id":24},"how-quarterly-external-scans-work","How quarterly external scans work",[16,27,28],{},"PCI DSS Requirement 11.3.2 mandates external vulnerability scanning at least once every three months, with every quarterly scan producing a passing result. The ASV configures scanning against the internet-facing IP ranges and fully qualified domain names in the cardholder data environment. The ASV runs automated vulnerability checks, produces a scan report, and works with you through dispute and remediation until the scan passes.",[16,30,31],{},"A passing PCI DSS ASV scan has:",[33,34,35,39,42,45],"ul",{},[36,37,38],"li",{},"No vulnerabilities rated CVSS 4.0 or higher that remain exploitable after validation",[36,40,41],{},"No \"automatic failure\" findings such as SQL injection, cross-site scripting on sensitive pages, insecure remote access, or default passwords on any accessible service",[36,43,44],{},"No evidence that the scan was inappropriately restricted by firewall rules, rate limiting, or intrusion prevention systems",[36,46,47],{},"All in-scope hosts successfully scanned, not marked as unreachable without documented justification",[16,49,50],{},"If any of those conditions fail, the scan fails. You remediate the finding, request a rescan, and repeat until the quarter closes with a clean result. The PCI DSS rule of four is strict: you need four passing quarterly ASV scans per reporting period, not four attempted scans. Missing a quarter is a PCI DSS finding your QSA will flag.",[11,52,54],{"id":53},"remediation-timelines-and-workflow","Remediation timelines and workflow",[16,56,57],{},"A realistic PCI DSS ASV cadence looks like this:",[59,60,61,68,74,80,86,92,98],"ol",{},[36,62,63,67],{},[64,65,66],"strong",{},"Scan window opens"," at the start of each quarter. You schedule the scan with your ASV, confirm the IP ranges and domains in scope, and update any authentication material the scanner needs.",[36,69,70,73],{},[64,71,72],{},"Initial scan runs"," -- typically overnight or over a weekend to avoid business impact.",[36,75,76,79],{},[64,77,78],{},"Results are delivered"," within a few business days. Your team reviews findings with the ASV.",[36,81,82,85],{},[64,83,84],{},"Disputes are raised"," for false positives, compensating controls, or findings that do not apply in context. The ASV evaluates evidence and either accepts the dispute (the finding is suppressed) or rejects it (you remediate).",[36,87,88,91],{},[64,89,90],{},"Remediation"," -- you patch, reconfigure, or retire affected components.",[36,93,94,97],{},[64,95,96],{},"Rescan"," -- the ASV reruns the scan or a targeted subset. If clean, the quarter passes. If not, loop back.",[36,99,100,103],{},[64,101,102],{},"Final passing report"," is archived for your QSA and retained for at least 12 months.",[16,105,106],{},"PCI DSS does not prescribe an absolute remediation deadline inside a quarter, but practical limits apply: the quarter itself is the deadline. If you cannot remediate and rescan to a passing result before the next quarter begins, you have a PCI DSS finding. Well-run programs aim to pass the first scan of every quarter within two to three weeks, leaving buffer for unexpected findings.",[11,108,110],{"id":109},"selecting-an-asv","Selecting an ASV",[16,112,113],{},"The PCI SSC does not rank ASVs, so selection is up to you. Evaluate prospective ASVs against the following criteria:",[33,115,116,122,128,134,140,146,152,158,164,170],{},[36,117,118,121],{},[64,119,120],{},"PCI SSC listing"," -- confirm the firm is on the current ASV list. Accreditation lapses.",[36,123,124,127],{},[64,125,126],{},"Scanning technology"," -- ask which engine powers their scanning (commercial, open source, proprietary) and how frequently their vulnerability signatures update.",[36,129,130,133],{},[64,131,132],{},"Coverage of your stack"," -- if you run container workloads, serverless functions, or unusual platforms, confirm the ASV can scan them.",[36,135,136,139],{},[64,137,138],{},"Authenticated scan support"," -- most PCI DSS ASV scans are unauthenticated, but some findings require credentialed validation during dispute.",[36,141,142,145],{},[64,143,144],{},"Analyst depth"," -- an ASV with strong analysts accelerates dispute resolution dramatically. Ask how many certified ASV employees they have and what response SLAs they offer.",[36,147,148,151],{},[64,149,150],{},"Reporting portal"," -- review the portal used to schedule scans, review findings, manage disputes, and download attestations. Clunky portals waste security team time every quarter.",[36,153,154,157],{},[64,155,156],{},"Integration options"," -- API, SSO, ticketing integrations (Jira, ServiceNow), and export formats that feed your evidence system of record.",[36,159,160,163],{},[64,161,162],{},"Pricing model"," -- per-IP, per-domain, or flat-rate. Confirm rescan fees and what \"significant change\" scans cost.",[36,165,166,169],{},[64,167,168],{},"Dispute and escalation process"," -- how quickly can you get an analyst on a call when a finding is blocking a passing scan?",[36,171,172,175],{},[64,173,174],{},"References"," -- ask for references from organizations of similar size and stack.",[16,177,178],{},"Many organizations pair their ASV with the same firm that provides their QSA services, though they are distinct programs with distinct accreditations. If you choose the same firm, confirm they can operationally keep the two functions independent.",[11,180,182],{"id":181},"internal-scanning-and-the-bigger-pci-dss-picture","Internal scanning and the bigger PCI DSS picture",[16,184,185],{},"External ASV scans are only half of PCI DSS Requirement 11.3. You must also perform internal vulnerability scans at least quarterly and after significant change, re-scanning until all high-risk vulnerabilities are resolved. Internal scans can be performed by your own staff with commercial scanning tools -- they do not require an ASV. PCI DSS v4.0 tightens expectations on internal scan coverage, authenticated scanning, and risk-ranking of findings.",[16,187,188],{},"Together, ASV scans, internal scans, penetration testing, and segmentation testing make up the testing stack that Requirement 11 demands. ASV reports feed your Attestation of Compliance, your QSA's testing procedures, and your own board reporting on vulnerability posture.",[11,190,192],{"id":191},"how-this-fits-into-pci-dss-compliance","How this fits into PCI DSS compliance",[16,194,195],{},"Quarterly ASV scans are one of the most visible artifacts in a PCI DSS program. Your acquirer often reviews ASV attestations alongside your SAQ or ROC, card brands may audit ASV records during a breach investigation, and QSAs use ASV history as an early signal of program maturity. A clean ASV history with promptly resolved findings tells a compelling story. A history of missed quarters, unresolved disputes, or gaps in coverage does the opposite and almost always triggers deeper testing during an assessment.",[16,197,198],{},"ASV scanning is also closely tied to PCI DSS scope. Every time your external attack surface changes -- new domains, new public IPs, new cloud environments -- the ASV scope must be updated. Organizations that treat the ASV contract as set-and-forget often discover during an assessment that their ASV has been scanning a stale inventory for quarters, invalidating the PCI DSS evidence they thought they had.",[11,200,202],{"id":201},"common-mistakes","Common mistakes",[33,204,205,211,217,223,229,235,241,247],{},[36,206,207,210],{},[64,208,209],{},"Scoping the ASV to a subset of internet-facing assets",", leaving cardholder-data-affecting systems unscanned.",[36,212,213,216],{},[64,214,215],{},"Ignoring new domains and cloud resources"," until the ASV renewal, creating gaps that a QSA will discover.",[36,218,219,222],{},[64,220,221],{},"Allowing firewall or WAF rules to block the ASV scanner",", producing \"unable to scan\" findings that invalidate the scan.",[36,224,225,228],{},[64,226,227],{},"Suppressing findings without documented compensating controls"," -- ASV disputes must be evidence-backed.",[36,230,231,234],{},[64,232,233],{},"Missing a quarter because a rescan slipped",", which produces a PCI DSS finding that carries into the ROC.",[36,236,237,240],{},[64,238,239],{},"Treating ASV scans as a substitute for internal scans or penetration testing"," -- they are not interchangeable under PCI DSS.",[36,242,243,246],{},[64,244,245],{},"Relying on default credentials or test accounts"," on any internet-facing system, which is an automatic ASV failure.",[36,248,249,252],{},[64,250,251],{},"Procuring ASV services purely on price",", then discovering the support model cannot keep up with dispute volume.",[11,254,256],{"id":255},"how-episki-helps","How episki helps",[16,258,259,260,265],{},"episki centralizes every ASV scan, dispute, and remediation ticket against the specific PCI DSS requirement it supports, so quarter-over-quarter evidence is always at hand. We connect to your ASV portal, reconcile scanned assets against your cloud inventory, and route findings to engineering owners with remediation SLAs tied back to the PCI DSS requirement they satisfy. See how we support continuous PCI DSS evidence on the ",[261,262,264],"a",{"href":263},"\u002Fframeworks\u002Fpci","PCI DSS hub",".",{"title":267,"searchDepth":268,"depth":268,"links":269},"",2,[270,271,272,273,274,275,276,277],{"id":13,"depth":268,"text":14},{"id":24,"depth":268,"text":25},{"id":53,"depth":268,"text":54},{"id":109,"depth":268,"text":110},{"id":181,"depth":268,"text":182},{"id":191,"depth":268,"text":192},{"id":201,"depth":268,"text":202},{"id":255,"depth":268,"text":256},"A practical guide to the PCI DSS Approved Scanning Vendor (ASV) program, quarterly external vulnerability scans, remediation timelines, and how to select the right ASV.","md",{"items":281},[282,285,288,291],{"label":283,"content":284},"What is a PCI DSS ASV?","An Approved Scanning Vendor (ASV) is an organization certified by the PCI Security Standards Council to perform the external vulnerability scans required by PCI DSS Requirement 11.3.2. Only ASVs on the PCI SSC's published list can produce scan reports that satisfy PCI DSS.",{"label":286,"content":287},"How often are PCI DSS ASV scans required?","PCI DSS requires external ASV scans at least quarterly, plus an additional scan after any significant change to the in-scope environment. All four quarterly scans must have a passing result during the reporting period.",{"label":289,"content":290},"What counts as a passing ASV scan?","A passing ASV scan has no vulnerabilities rated CVSS 4.0 or higher after validation and no automatic failures such as default credentials or cross-site scripting on accessible pages. Failed scans must be remediated and rescanned until a clean, passing result is produced.",{"label":292,"content":293},"Who needs PCI DSS ASV scans?","Any organization with internet-facing systems in the cardholder data environment must run quarterly ASV scans. This includes most merchants accepting card-not-present transactions and all service providers that handle cardholder data over the internet.","pci","2026-04-16",{},true,"\u002Fframeworks\u002Fpci\u002Fasv-program",[300,301,302,303],"asv","pci-dss","pci-scope","vulnerability-management",[305,306,307,308],"requirements","penetration-testing","scope-reduction","qsa-selection",{"title":310,"description":311},"PCI DSS ASV Program: Quarterly Scans, Remediation & Vendor Selection","Everything you need to know about the PCI DSS ASV program — quarterly external vulnerability scans, passing thresholds, remediation timelines, and selecting an Approved Scanning Vendor.","5.frameworks\u002Fpci\u002Fasv-program","czpbkV8MpfNBucbxY5kpFREMCUA70p5n94ntk8vGlFY",{"id":315,"title":316,"body":317,"description":678,"extension":279,"faq":679,"frameworkSlug":294,"lastUpdated":295,"meta":693,"navigation":297,"path":694,"relatedTerms":695,"relatedTopics":697,"seo":700,"stem":703,"__hash__":704},"frameworkTopics\u002F5.frameworks\u002Fpci\u002Fcompliance-levels.md","PCI DSS Compliance Levels",{"type":8,"value":318,"toc":656},[319,323,326,333,337,342,348,353,367,372,386,394,398,403,407,418,426,430,435,439,448,451,455,460,464,474,477,481,484,488,494,498,508,512,517,521,528,531,535,538,570,573,577,581,584,588,595,599,602,606,614,618,621,653],[11,320,322],{"id":321},"how-pci-dss-compliance-levels-work","How PCI DSS compliance levels work",[16,324,325],{},"PCI DSS applies universally to any organization that stores, processes, or transmits cardholder data. However, the validation requirements -- how you demonstrate compliance -- vary based on your transaction volume and business type. The payment card brands (Visa, Mastercard, American Express, Discover, and JCB) each define their own compliance level thresholds, though the levels are broadly similar.",[16,327,328,329,332],{},"Understanding your compliance level is essential for planning your ",[261,330,331],{"href":263},"PCI DSS compliance"," program. Your level determines whether you need a formal on-site assessment by a Qualified Security Assessor (QSA) or can self-validate using a Self-Assessment Questionnaire (SAQ).",[11,334,336],{"id":335},"merchant-compliance-levels","Merchant compliance levels",[338,339,341],"h3",{"id":340},"level-1-largest-merchants","Level 1 - Largest merchants",[16,343,344,347],{},[64,345,346],{},"Transaction threshold:"," More than 6 million card transactions per year across all channels (Visa and Mastercard). American Express sets this at 2.5 million transactions.",[16,349,350],{},[64,351,352],{},"Validation requirements:",[33,354,355,358,361,364],{},[36,356,357],{},"Annual Report on Compliance (ROC) completed by a Qualified Security Assessor (QSA) or Internal Security Assessor (ISA)",[36,359,360],{},"Quarterly network vulnerability scans by an Approved Scanning Vendor (ASV)",[36,362,363],{},"Attestation of Compliance (AOC) signed by the QSA and an officer of the organization",[36,365,366],{},"Annual penetration test",[16,368,369],{},[64,370,371],{},"Who falls into Level 1:",[33,373,374,377,380,383],{},[36,375,376],{},"Major retailers, airlines, and hospitality chains",[36,378,379],{},"Large e-commerce platforms",[36,381,382],{},"Any merchant that has experienced a data breach resulting in account data compromise (regardless of transaction volume)",[36,384,385],{},"Any merchant that a payment brand identifies as Level 1 at its discretion",[16,387,388,389,393],{},"Level 1 assessments are the most rigorous and expensive. The ROC process involves detailed evidence review, on-site interviews, system sampling, and testing of every applicable control across all 12 ",[261,390,392],{"href":391},"\u002Fframeworks\u002Fpci\u002Frequirements","PCI DSS requirements",". Assessments typically take several weeks to several months depending on the size and complexity of the cardholder data environment.",[338,395,397],{"id":396},"level-2-mid-size-merchants","Level 2 - Mid-size merchants",[16,399,400,402],{},[64,401,346],{}," 1 million to 6 million card transactions per year (Visa and Mastercard).",[16,404,405],{},[64,406,352],{},[33,408,409,412,415],{},[36,410,411],{},"Annual Self-Assessment Questionnaire (SAQ) appropriate to the merchant's payment processing environment",[36,413,414],{},"Quarterly ASV vulnerability scans",[36,416,417],{},"Attestation of Compliance (AOC)",[16,419,420,421,425],{},"Some acquiring banks may require Level 2 merchants to complete a ROC or engage a QSA to validate their SAQ, particularly if the merchant operates in a high-risk industry or has experienced security incidents. The specific SAQ type depends on how the merchant processes payments -- see the ",[261,422,424],{"href":423},"\u002Fframeworks\u002Fpci\u002Fself-assessment-questionnaire","SAQ guide"," for details.",[338,427,429],{"id":428},"level-3-e-commerce-merchants","Level 3 - E-commerce merchants",[16,431,432,434],{},[64,433,346],{}," 20,000 to 1 million e-commerce transactions per year (Visa). Mastercard defines Level 3 as merchants processing 20,000 to 1 million total transactions.",[16,436,437],{},[64,438,352],{},[33,440,441,444,446],{},[36,442,443],{},"Annual SAQ appropriate to the merchant's environment",[36,445,414],{},[36,447,417],{},[16,449,450],{},"Level 3 was originally designed to address e-commerce merchants specifically, recognizing the elevated risk of card-not-present transactions. In practice, the validation requirements are similar to Level 2, but the threshold is significantly lower for online-only merchants.",[338,452,454],{"id":453},"level-4-smallest-merchants","Level 4 - Smallest merchants",[16,456,457,459],{},[64,458,346],{}," Fewer than 20,000 e-commerce transactions per year and fewer than 1 million total transactions across all channels.",[16,461,462],{},[64,463,352],{},[33,465,466,469,472],{},[36,467,468],{},"Annual SAQ appropriate to the merchant's environment (recommended but determined by acquirer)",[36,470,471],{},"Quarterly ASV vulnerability scans (if applicable to the SAQ type)",[36,473,417],{},[16,475,476],{},"Level 4 encompasses the vast majority of merchants worldwide. While the validation requirements are the least demanding, the PCI DSS requirements themselves still apply in full. A data breach at a Level 4 merchant carries the same consequences as one at a Level 1 merchant. Many acquiring banks set their own requirements for Level 4 merchants, and some may not actively enforce SAQ completion, which unfortunately leads to gaps in security.",[11,478,480],{"id":479},"service-provider-compliance-levels","Service provider compliance levels",[16,482,483],{},"Service providers -- organizations that store, process, or transmit cardholder data on behalf of other entities, or that could affect the security of cardholder data -- have their own compliance levels.",[338,485,487],{"id":486},"service-provider-level-1","Service provider Level 1",[16,489,490,493],{},[64,491,492],{},"Threshold:"," More than 300,000 card transactions per year (Visa) or any service provider that stores, processes, or transmits more than 300,000 Mastercard transactions.",[16,495,496],{},[64,497,352],{},[33,499,500,503,505],{},[36,501,502],{},"Annual ROC by a QSA",[36,504,414],{},[36,506,507],{},"Semi-annual segmentation penetration testing (more frequent than merchant requirements)",[338,509,511],{"id":510},"service-provider-level-2","Service provider Level 2",[16,513,514,516],{},[64,515,492],{}," Fewer than 300,000 card transactions per year.",[16,518,519],{},[64,520,352],{},[33,522,523,526],{},[36,524,525],{},"Annual SAQ-D for Service Providers",[36,527,414],{},[16,529,530],{},"Service providers face additional PCI DSS requirements beyond those for merchants, including change detection mechanisms, penetration testing of segmentation controls every six months, and documented responsibilities in customer agreements. Many payment brands maintain public registries of validated service providers that merchants can reference.",[11,532,534],{"id":533},"payment-brand-variations","Payment brand variations",[16,536,537],{},"While the levels described above represent the general framework, each payment brand has specific nuances:",[33,539,540,546,552,558,564],{},[36,541,542,545],{},[64,543,544],{},"Visa"," distinguishes between e-commerce and total transaction counts for Levels 3 and 4",[36,547,548,551],{},[64,549,550],{},"Mastercard"," includes a \"Site Data Protection\" (SDP) program with registration requirements",[36,553,554,557],{},[64,555,556],{},"American Express"," uses a lower Level 1 threshold (2.5 million transactions) and refers to its program as the Data Security Operating Policy (DSOP)",[36,559,560,563],{},[64,561,562],{},"Discover"," follows a similar four-level structure but determines levels based on Discover-brand transactions specifically",[36,565,566,569],{},[64,567,568],{},"JCB"," follows a structure aligned with Visa but with its own compliance program requirements",[16,571,572],{},"Organizations that accept multiple card brands must meet the most stringent level applicable across all brands. If you process 3 million Visa transactions (Level 2 for Visa) but 3 million American Express transactions (Level 1 for Amex), you would need to meet Level 1 validation requirements.",[11,574,576],{"id":575},"how-compliance-levels-affect-your-program","How compliance levels affect your program",[338,578,580],{"id":579},"assessment-cost-and-effort","Assessment cost and effort",[16,582,583],{},"Level 1 assessments involving a QSA engagement can cost anywhere from $50,000 to over $500,000 depending on the complexity of the environment, the number of locations, and the maturity of existing controls. Self-assessment at Levels 2 through 4 is less expensive but still requires significant internal effort to gather evidence, complete the questionnaire accurately, and maintain documentation.",[338,585,587],{"id":586},"scope-reduction-benefits","Scope reduction benefits",[16,589,590,594],{},[261,591,593],{"href":592},"\u002Fframeworks\u002Fpci\u002Fscope-reduction","PCI DSS scope reduction"," techniques benefit organizations at every level. For Level 1 merchants, a smaller cardholder data environment means a shorter, less expensive QSA engagement. For Level 2 through 4 merchants, scope reduction may qualify you for a simpler SAQ type, reducing the number of questions from over 300 (SAQ D) to as few as 22 (SAQ A).",[338,596,598],{"id":597},"acquirer-requirements","Acquirer requirements",[16,600,601],{},"Your acquiring bank (the bank that processes card transactions on your behalf) is ultimately responsible for ensuring your compliance. Acquirers may impose requirements beyond the minimum defined by the payment brands. Some acquirers require Level 2 merchants to undergo QSA assessments, mandate specific SAQ types, or set deadlines for compliance validation that differ from the payment brand's timelines.",[338,603,605],{"id":604},"breach-consequences-by-level","Breach consequences by level",[16,607,608,609,613],{},"A data breach can result in escalation to a higher compliance level, significant fines from payment brands (ranging from $5,000 to $100,000 per month of non-compliance), forensic investigation costs, and potential loss of the ability to process card payments. These consequences apply regardless of compliance level, which is why organizations at every level in the ",[261,610,612],{"href":611},"\u002Findustry\u002Ffinance","fintech industry"," and beyond should invest in robust security controls rather than treating compliance as a box-checking exercise.",[11,615,617],{"id":616},"determining-your-level","Determining your level",[16,619,620],{},"To determine your compliance level:",[59,622,623,629,635,641,647],{},[36,624,625,628],{},[64,626,627],{},"Count your annual transactions"," across all channels and all payment brands",[36,630,631,634],{},[64,632,633],{},"Identify which payment brands you accept"," and check each brand's specific thresholds",[36,636,637,640],{},[64,638,639],{},"Consult your acquiring bank"," for any additional requirements or level assignments",[36,642,643,646],{},[64,644,645],{},"Consider breach history"," -- a prior breach may automatically place you at Level 1",[36,648,649,652],{},[64,650,651],{},"Plan for growth"," -- if you are approaching a threshold, plan for the next level's validation requirements proactively",[16,654,655],{},"Your compliance level is not static. As transaction volumes grow, you may move to a higher level with more demanding validation requirements. Building a mature compliance program early ensures a smoother transition when that time comes.",{"title":267,"searchDepth":268,"depth":268,"links":657},[658,659,666,670,671,677],{"id":321,"depth":268,"text":322},{"id":335,"depth":268,"text":336,"children":660},[661,663,664,665],{"id":340,"depth":662,"text":341},3,{"id":396,"depth":662,"text":397},{"id":428,"depth":662,"text":429},{"id":453,"depth":662,"text":454},{"id":479,"depth":268,"text":480,"children":667},[668,669],{"id":486,"depth":662,"text":487},{"id":510,"depth":662,"text":511},{"id":533,"depth":268,"text":534},{"id":575,"depth":268,"text":576,"children":672},[673,674,675,676],{"id":579,"depth":662,"text":580},{"id":586,"depth":662,"text":587},{"id":597,"depth":662,"text":598},{"id":604,"depth":662,"text":605},{"id":616,"depth":268,"text":617},"An explanation of PCI DSS merchant and service provider compliance levels, transaction thresholds, and validation requirements for each level.",{"items":680},[681,684,687,690],{"label":682,"content":683},"How do I determine my PCI DSS compliance level?","Your level is based on annual card transaction volume across all channels and payment brands. Merchant Level 1 is 6+ million transactions, Level 2 is 1–6 million, Level 3 is 20,000–1 million e-commerce transactions, and Level 4 is everything below those thresholds. Your acquiring bank may also assign a higher level.",{"label":685,"content":686},"What is the difference between SAQ and ROC in PCI DSS?","A Self-Assessment Questionnaire (SAQ) is a self-validation tool used by Level 2–4 merchants. A Report on Compliance (ROC) is a formal assessment conducted by a Qualified Security Assessor (QSA) and is required for Level 1 merchants. ROC assessments are significantly more rigorous and expensive.",{"label":688,"content":689},"Can a data breach change my PCI compliance level?","Yes. Any merchant that experiences a data breach resulting in account data compromise is automatically escalated to Level 1 regardless of transaction volume. Payment brands can also assign Level 1 status at their discretion.",{"label":691,"content":692},"How much does a PCI DSS Level 1 assessment cost?","Level 1 QSA assessments typically cost $50,000 to over $500,000 depending on environment complexity, number of locations, and control maturity. Self-assessment at Levels 2–4 is less expensive but still requires significant internal effort for evidence gathering and documentation.",{},"\u002Fframeworks\u002Fpci\u002Fcompliance-levels",[301,696],"grc",[305,698,699],"self-assessment-questionnaire","v4-changes",{"title":701,"description":702},"PCI DSS Compliance Levels Explained: Merchant Level 1–4 & Service Provider Requirements","PCI DSS merchant levels 1–4 and service provider levels explained — transaction thresholds, SAQ vs ROC validation, and what each level requires.","5.frameworks\u002Fpci\u002Fcompliance-levels","q9VxhLQLRZBdJPmHYvuWAhLc8o4cKzw19jyXrfSQ5Ww",{"id":706,"title":707,"body":708,"description":1049,"extension":279,"faq":1050,"frameworkSlug":294,"lastUpdated":295,"meta":1064,"navigation":297,"path":1065,"relatedTerms":1066,"relatedTopics":1070,"seo":1072,"stem":1075,"__hash__":1076},"frameworkTopics\u002F5.frameworks\u002Fpci\u002Fnetwork-segmentation.md","PCI DSS Network Segmentation",{"type":8,"value":709,"toc":1037},[710,714,717,720,724,727,753,756,760,763,783,786,790,793,831,834,838,841,885,888,892,895,898,912,915,919,922,960,963,965,968,971,973,1029,1031],[11,711,713],{"id":712},"why-pci-dss-network-segmentation-matters","Why PCI DSS network segmentation matters",[16,715,716],{},"Without network segmentation, every system that can reach any CDE system is in PCI DSS scope. That typically means a flat corporate network with thousands of endpoints and servers, all of them pulled into the assessment. Network segmentation is the architectural pattern that draws a firm boundary around the cardholder data environment, isolates it, and allows the rest of the corporate network to remain out of PCI DSS scope.",[16,718,719],{},"Segmentation is not strictly required by PCI DSS. You can choose to run a flat network and put every system through PCI DSS testing. Almost no one does. The cost savings from segmentation are usually 10x or more across the life of a PCI DSS program -- fewer controls to implement, fewer systems to scan, fewer owners to interview, fewer evidence items to maintain. Segmentation is therefore the first design conversation in every PCI DSS program and the first architectural pattern a QSA will review.",[11,721,723],{"id":722},"what-pci-dss-segmentation-must-enforce","What PCI DSS segmentation must enforce",[16,725,726],{},"PCI DSS segmentation must:",[33,728,729,735,741,747],{},[36,730,731,734],{},[64,732,733],{},"Isolate the CDE from out-of-scope networks."," Traffic between the two is denied by default.",[36,736,737,740],{},[64,738,739],{},"Allow only explicitly approved, business-justified traffic."," Every exception is documented, owned, and reviewed.",[36,742,743,746],{},[64,744,745],{},"Use technical controls, not just policy."," Segmentation must be enforced by firewalls, ACLs, network security groups, or equivalent controls -- not by trust or convention.",[36,748,749,752],{},[64,750,751],{},"Be validated."," Penetration testing confirms the isolation holds in practice.",[16,754,755],{},"A segmentation design is not \"we put the CDE on VLAN 200.\" It is a documented set of trust zones, a firewall ruleset that enforces traffic between them, a change process that governs rule modifications, a regular review cadence for the rules, and a testing program that validates the whole system every six or twelve months.",[11,757,759],{"id":758},"vlan-isolation-in-on-premise-networks","VLAN isolation in on-premise networks",[16,761,762],{},"The classic on-premise PCI DSS segmentation pattern is VLAN-based isolation:",[33,764,765,768,771,774,777,780],{},[36,766,767],{},"Dedicated VLANs for CDE systems, typically one per function (payment application servers, databases, jump hosts).",[36,769,770],{},"Dedicated VLANs for CDE management traffic, separate from CDE data plane traffic.",[36,772,773],{},"Stateful firewalls enforcing traffic policy between CDE VLANs and non-CDE VLANs.",[36,775,776],{},"Access control lists or micro-segmentation within the CDE to limit lateral traffic.",[36,778,779],{},"No routed paths from corporate VLANs to the CDE except through documented chokepoints.",[36,781,782],{},"Separate DNS, NTP, and authentication services for the CDE where feasible.",[16,784,785],{},"Wireless networks deserve special attention. PCI DSS treats wireless access to the CDE as high-risk and requires strong authentication, unique credentials, and specific testing. Many organizations exclude wireless from the CDE entirely by routing wireless through a dedicated zone that has no direct path to cardholder data.",[11,787,789],{"id":788},"cloud-segmentation-patterns","Cloud segmentation patterns",[16,791,792],{},"PCI DSS segmentation in the cloud is conceptually identical but uses cloud-native primitives:",[33,794,795,801,807,813,819,825],{},[36,796,797,800],{},[64,798,799],{},"Dedicated VPCs or projects"," for the CDE, with explicit peering or transit rules to the rest of the environment.",[36,802,803,806],{},[64,804,805],{},"Tight security groups and network ACLs"," that enforce least-privilege traffic between the CDE and everything else.",[36,808,809,812],{},[64,810,811],{},"Private endpoints"," so cloud services consumed by CDE workloads do not traverse the public internet.",[36,814,815,818],{},[64,816,817],{},"Service mesh or identity-based network policies"," that enforce workload-level segmentation within the CDE.",[36,820,821,824],{},[64,822,823],{},"No shared accounts or projects"," between the CDE and non-CDE workloads unless explicitly in scope.",[36,826,827,830],{},[64,828,829],{},"Cloud provider landing-zone patterns"," that codify segmentation through infrastructure-as-code.",[16,832,833],{},"Cloud environments introduce their own risks. Misconfigured security groups, overly broad IAM roles that cross CDE boundaries, shared logging and monitoring services that collect CDE data into out-of-scope buckets -- all of these can undo segmentation. PCI DSS does not care whether segmentation is implemented with a physical firewall or a cloud security group; it cares whether the isolation actually holds.",[11,835,837],{"id":836},"firewall-rule-design-and-review","Firewall rule design and review",[16,839,840],{},"PCI DSS Requirement 1 governs network security controls including firewall and equivalent rules. A strong segmentation program maintains:",[33,842,843,849,855,861,867,873,879],{},[36,844,845,848],{},[64,846,847],{},"Documented ruleset"," with business justification for every allow rule.",[36,850,851,854],{},[64,852,853],{},"Deny-by-default"," posture with explicit allow rules.",[36,856,857,860],{},[64,858,859],{},"Rule review"," at least every six months, removing stale rules and validating business justification.",[36,862,863,866],{},[64,864,865],{},"Change management"," with documented approvals for every rule change.",[36,868,869,872],{},[64,870,871],{},"Separation of duties"," so the person requesting a rule change is not the person approving it or the person implementing it.",[36,874,875,878],{},[64,876,877],{},"Egress filtering"," -- outbound rules from the CDE to the internet and to non-CDE networks are explicitly defined.",[36,880,881,884],{},[64,882,883],{},"Ingress filtering"," from the internet into the CDE follows the same allow-list approach.",[16,886,887],{},"The PCI DSS v4.0 revisions of Requirement 1 explicitly cover \"network security controls\" rather than just firewalls, recognizing that modern environments use a variety of technologies. What does not change is the substance: deny by default, justify every exception, review regularly.",[11,889,891],{"id":890},"validation-testing-requirement-1145","Validation testing (Requirement 11.4.5)",[16,893,894],{},"Segmentation only counts if it is validated. PCI DSS Requirement 11.4.5 requires penetration testing of segmentation controls at least every 12 months for merchants and every six months for service providers, plus after any change to segmentation.",[16,896,897],{},"A sound segmentation test:",[33,899,900,903,906,909],{},[36,901,902],{},"Places the tester on every out-of-scope network segment that is supposed to be isolated from the CDE.",[36,904,905],{},"Attempts every protocol and every CDE IP from each out-of-scope segment.",[36,907,908],{},"Documents what was and was not reachable.",[36,910,911],{},"Escalates any unexpected reachability to remediation, then retests.",[16,913,914],{},"Testing is not a tabletop. It is hands-on, from real network positions. Evidence is the pen-test report, the tester's qualifications, and the retest results.",[11,916,918],{"id":917},"operational-risks-that-undo-segmentation","Operational risks that undo segmentation",[16,920,921],{},"Most segmentation failures are not architectural -- they are operational. Common patterns:",[33,923,924,930,936,942,948,954],{},[36,925,926,929],{},[64,927,928],{},"Jump hosts that drift"," out of hardening baselines and become lateral-movement paths.",[36,931,932,935],{},[64,933,934],{},"Monitoring and logging tools"," that collect CDE data into out-of-scope systems, dragging those systems back into scope.",[36,937,938,941],{},[64,939,940],{},"Backup and recovery infrastructure"," that bridges the CDE to out-of-scope storage.",[36,943,944,947],{},[64,945,946],{},"Remote access vendors"," whose connections traverse segmentation boundaries because an exception was never formally reviewed.",[36,949,950,953],{},[64,951,952],{},"CI\u002FCD pipelines"," that deploy to the CDE from out-of-scope build agents, creating a direct path that segmentation did not account for.",[36,955,956,959],{},[64,957,958],{},"Ephemeral compute"," that spins up into the wrong network segment because infrastructure-as-code templates drifted.",[16,961,962],{},"Treat segmentation as a product, not a project. Build segmentation reviews into every major change, every new vendor, and every architectural decision.",[11,964,192],{"id":191},[16,966,967],{},"Network segmentation is the force multiplier of a PCI DSS program. Requirement 1 (network security controls) is where segmentation is built. Requirement 2 (secure configurations) hardens the systems on either side of the boundary. Requirement 4 (cryptography in transit) protects any cross-boundary traffic. Requirement 7 and 8 (access control and authentication) govern who can cross. Requirement 10 (logging) records crossings. Requirement 11 (testing) validates isolation. A well-designed segmentation architecture pays dividends in every PCI DSS requirement you subsequently evaluate.",[16,969,970],{},"For mature PCI DSS programs, segmentation also becomes the substrate for broader security. A CDE segmentation pattern that works for PCI DSS is often reused for HIPAA-regulated data, for export-controlled environments, and for sensitive customer datasets. The investment compounds.",[11,972,202],{"id":201},[33,974,975,981,987,993,999,1005,1011,1017,1023],{},[36,976,977,980],{},[64,978,979],{},"Flat networks"," where CDE and non-CDE systems coexist on the same subnet.",[36,982,983,986],{},[64,984,985],{},"Overly permissive firewall rules"," that negate the benefit of segmentation.",[36,988,989,992],{},[64,990,991],{},"Unreviewed rulesets"," that accumulate stale exceptions over years.",[36,994,995,998],{},[64,996,997],{},"Segmentation that stops at the network layer"," but ignores identity-based lateral movement.",[36,1000,1001,1004],{},[64,1002,1003],{},"Monitoring and backup systems"," that bridge the CDE into out-of-scope storage.",[36,1006,1007,1010],{},[64,1008,1009],{},"Missing segmentation testing"," or testing that does not cover every out-of-scope segment.",[36,1012,1013,1016],{},[64,1014,1015],{},"Cloud security groups and VPCs"," that look segmented but are reachable via misconfigured peering or shared identity.",[36,1018,1019,1022],{},[64,1020,1021],{},"VPN and remote access"," tools that punch holes through the boundary without documented justification.",[36,1024,1025,1028],{},[64,1026,1027],{},"Shadow IT"," -- unsanctioned services on out-of-scope subnets that need CDE access and create undocumented exceptions.",[11,1030,256],{"id":255},[16,1032,1033,1034,1036],{},"episki connects to your firewalls, cloud security groups, and network tooling, continuously reconciling your segmentation design against the traffic that is actually flowing. Drift in firewall rules, new exceptions, and unexpected cross-segment traffic surface as PCI DSS findings before your next assessment. Explore the ",[261,1035,264],{"href":263}," for how this fits into the broader program.",{"title":267,"searchDepth":268,"depth":268,"links":1038},[1039,1040,1041,1042,1043,1044,1045,1046,1047,1048],{"id":712,"depth":268,"text":713},{"id":722,"depth":268,"text":723},{"id":758,"depth":268,"text":759},{"id":788,"depth":268,"text":789},{"id":836,"depth":268,"text":837},{"id":890,"depth":268,"text":891},{"id":917,"depth":268,"text":918},{"id":191,"depth":268,"text":192},{"id":201,"depth":268,"text":202},{"id":255,"depth":268,"text":256},"Network segmentation for PCI DSS scope reduction — VLAN isolation, firewall rules, validation testing, and building an isolated cardholder data environment.",{"items":1051},[1052,1055,1058,1061],{"label":1053,"content":1054},"Is network segmentation required for PCI DSS?","Network segmentation is not strictly required by PCI DSS, but without it the entire network is in scope. Segmentation is how almost every organization achieves a manageable PCI DSS scope, and once implemented, segmentation controls must be tested at least annually (every six months for service providers).",{"label":1056,"content":1057},"What counts as effective PCI DSS network segmentation?","Effective segmentation isolates the cardholder data environment on dedicated network segments with firewall or equivalent controls that enforce a deny-by-default policy between the CDE and out-of-scope networks. Only explicitly approved, business-justified traffic is permitted, and the segmentation is validated through penetration testing.",{"label":1059,"content":1060},"Does cloud segmentation work for PCI DSS?","Yes. Cloud-native constructs like VPCs, security groups, subnets, service meshes, and identity-based network policies can satisfy PCI DSS segmentation if configured and validated to enforce CDE isolation. The evidence expectations are the same as for on-premise segmentation — documented design, rule review, and penetration testing.",{"label":1062,"content":1063},"How often must PCI DSS segmentation be validated?","At least every 12 months for merchants, every 6 months for service providers, and after any change that affects segmentation. Penetration testing is the PCI DSS-required method of validation — scans and configuration reviews are not a substitute.",{},"\u002Fframeworks\u002Fpci\u002Fnetwork-segmentation",[1067,1068,302,1069],"firewall","network-security","cardholder-data-environment",[307,305,306,1071],"tokenization-vs-encryption",{"title":1073,"description":1074},"PCI DSS Network Segmentation Guide: VLANs, Firewalls & Validation Testing","A practical PCI DSS network segmentation guide. VLAN isolation, firewall rules, cloud segmentation patterns, and how to validate segmentation controls under Requirement 11.4.5.","5.frameworks\u002Fpci\u002Fnetwork-segmentation","SAuRb-ng3K_g04a_zAnsH9mIJp97SR-DqG6t8qAwMII",{"id":1078,"title":1079,"body":1080,"description":1311,"extension":279,"faq":1312,"frameworkSlug":294,"lastUpdated":295,"meta":1326,"navigation":297,"path":1327,"relatedTerms":1328,"relatedTopics":1329,"seo":1332,"stem":1335,"__hash__":1336},"frameworkTopics\u002F5.frameworks\u002Fpci\u002Fpenetration-testing.md","PCI DSS Penetration Testing (Requirement 11.4)",{"type":8,"value":1081,"toc":1300},[1082,1086,1089,1092,1096,1099,1143,1146,1150,1153,1159,1165,1168,1172,1175,1178,1192,1195,1199,1202,1205,1209,1212,1223,1226,1228,1231,1234,1236,1292,1294],[11,1083,1085],{"id":1084},"why-pci-dss-penetration-testing-matters","Why PCI DSS penetration testing matters",[16,1087,1088],{},"PCI DSS treats penetration testing as the ground-truth check on every other control in the program. ASV scans are automated and narrow. Internal vulnerability scans are deeper but still automated. Penetration testing puts a human adversary's perspective on your cardholder data environment and answers the only question that really matters: can an attacker actually reach cardholder data? PCI DSS Requirement 11.4 operationalizes that question into a set of testing obligations that apply to every organization subject to PCI DSS -- not just Level 1 merchants.",[16,1090,1091],{},"Penetration testing is also the requirement most often misinterpreted during a PCI DSS assessment. Organizations substitute vulnerability scans for penetration tests. They test application layers but skip the network layer. They skip segmentation validation. They engage a firm that produces a generic report with no evidence of hands-on testing. Each of these shortcuts is visible to a trained QSA and becomes a PCI DSS finding.",[11,1093,1095],{"id":1094},"what-requirement-114-actually-demands","What Requirement 11.4 actually demands",[16,1097,1098],{},"PCI DSS Requirement 11.4 has several sub-requirements:",[33,1100,1101,1107,1113,1119,1125,1131,1137],{},[36,1102,1103,1106],{},[64,1104,1105],{},"11.4.1"," -- a documented penetration testing methodology that is industry-accepted (NIST SP 800-115, OWASP Testing Guide, PTES, OSSTMM), covers the entire CDE perimeter and critical systems, includes testing from inside and outside the network, validates segmentation and scope-reduction controls, covers application-layer testing (at minimum, the OWASP Top 10 risks), and accounts for threats and vulnerabilities encountered in the past 12 months.",[36,1108,1109,1112],{},[64,1110,1111],{},"11.4.2"," -- internal penetration testing at least annually and after any significant change.",[36,1114,1115,1118],{},[64,1116,1117],{},"11.4.3"," -- external penetration testing at least annually and after any significant change.",[36,1120,1121,1124],{},[64,1122,1123],{},"11.4.4"," -- exploitable vulnerabilities found during penetration testing are corrected and the testing is repeated to verify the corrections.",[36,1126,1127,1130],{},[64,1128,1129],{},"11.4.5"," -- for organizations using network segmentation to reduce PCI DSS scope, segmentation controls are tested at least every 12 months for merchants and every 6 months for service providers, and after any change to segmentation controls.",[36,1132,1133,1136],{},[64,1134,1135],{},"11.4.6"," -- additional service-provider testing obligations for multi-tenant environments.",[36,1138,1139,1142],{},[64,1140,1141],{},"11.4.7"," -- multi-tenant service providers support customer penetration testing.",[16,1144,1145],{},"Every one of those sub-requirements has dedicated testing procedures that your QSA follows. Evidence includes the documented methodology, scoping documentation, tester qualifications, the final report, remediation tracking, and the rescan or retest results.",[11,1147,1149],{"id":1148},"internal-vs-external-penetration-testing","Internal vs external penetration testing",[16,1151,1152],{},"PCI DSS splits penetration testing into two perspectives.",[16,1154,1155,1158],{},[64,1156,1157],{},"External penetration testing"," simulates an adversary on the public internet. The tester has only what an outsider would have: public IP ranges, domain names, public-facing applications, and open-source intelligence. External tests exercise the perimeter -- firewalls, web applications, remote access portals, e-commerce checkouts -- and map what an attacker can reach from outside your network. External testing must cover the entire CDE perimeter plus any critical systems exposed to the internet.",[16,1160,1161,1164],{},[64,1162,1163],{},"Internal penetration testing"," simulates an adversary who has already gained a foothold inside the network, whether through a phished employee, a compromised contractor, or an insider threat. Internal testing exercises the defenses that stand between that foothold and the cardholder data environment: segmentation, privileged access controls, lateral-movement detection, hardening of jump hosts, and monitoring. Internal testing is where segmentation actually gets validated.",[16,1166,1167],{},"PCI DSS requires both perspectives. An organization that only runs external testing is missing half of the Requirement 11.4 obligation and creating a blind spot for exactly the attack path most commonly used in card-data breaches.",[11,1169,1171],{"id":1170},"segmentation-testing-requirement-1145","Segmentation testing (Requirement 11.4.5)",[16,1173,1174],{},"If you rely on network segmentation to reduce your PCI DSS scope, segmentation testing is non-negotiable. PCI DSS Requirement 11.4.5 requires that the segmentation controls isolating the CDE are tested at least annually for merchants, at least every six months for service providers, and after any change to segmentation. The testing must confirm that out-of-scope networks cannot reach the CDE and that the segmentation controls are operating as documented.",[16,1176,1177],{},"A good segmentation test looks like this:",[33,1179,1180,1183,1186,1189],{},[36,1181,1182],{},"The tester is placed on every out-of-scope network segment that is supposed to be isolated from the CDE.",[36,1184,1185],{},"From each segment, the tester attempts to reach every CDE system by any protocol.",[36,1187,1188],{},"Any connectivity discovered is flagged as a segmentation finding.",[36,1190,1191],{},"Findings are remediated, and the test is repeated until isolation is confirmed.",[16,1193,1194],{},"Segmentation testing does not require an attempt to compromise the CDE -- it is about reachability. A segmentation test where the tester merely ran a port scan from one corporate subnet is not sufficient. The test must cover every out-of-scope segment that could affect CDE isolation.",[11,1196,1198],{"id":1197},"frequency-change-driven-testing-and-retesting","Frequency, change-driven testing, and retesting",[16,1200,1201],{},"PCI DSS penetration testing is at least annual. But the real test frequency is driven by change. Any significant change to the CDE -- architecture changes, major software releases, new third-party integrations, new locations, new acquisition integrations, material infrastructure migration -- triggers a new test. Service providers have shorter mandatory cycles on segmentation testing (every six months).",[16,1203,1204],{},"Retesting is a specific PCI DSS obligation. Once a penetration test finds an exploitable vulnerability, you remediate it and then retest to confirm the fix. A report that lists findings but never shows retesting results is incomplete evidence under PCI DSS Requirement 11.4.4.",[11,1206,1208],{"id":1207},"tester-qualifications","Tester qualifications",[16,1210,1211],{},"PCI DSS does not name specific certifications but requires testers to be \"qualified\" and \"organizationally independent.\" In practice that means:",[33,1213,1214,1217,1220],{},[36,1215,1216],{},"Certifications such as OSCP, OSEP, OSWE, GPEN, GWAPT, GXPN, CRTO, or CREST tester grades, backed by evidence of real engagement experience.",[36,1218,1219],{},"Organizational independence -- testers do not test systems they built, manage, or rely on day to day.",[36,1221,1222],{},"Methodology discipline -- the tester follows the documented methodology and produces evidence of hands-on testing, not just tool output.",[16,1224,1225],{},"For internal teams, separation between build and test functions plus documented qualifications can satisfy PCI DSS. For external engagements, request the CVs and certifications of the specific individuals who will do the testing, not just the firm's credentials.",[11,1227,192],{"id":191},[16,1229,1230],{},"Penetration testing is where every other PCI DSS control gets pressure-tested. Requirement 1 firewalls are validated during external testing. Requirement 2 hardening and Requirement 6 secure development are validated during application and internal testing. Requirement 8 authentication is validated at every stage. Requirement 10 logging and monitoring is validated when the tester's activity is (or is not) detected. Requirement 11.3 scanning programs are validated by comparing scan output to pen-test findings. A well-run PCI DSS penetration test is therefore not just a 11.4 artifact -- it is the feedback loop for the entire PCI DSS program.",[16,1232,1233],{},"Your QSA will pay particular attention to the pen-test report during every PCI DSS assessment. They will compare the scope to your documented CDE, check that findings have been remediated and retested, and look for the patterns that signal low-quality testing (no evidence of exploitation, no enumeration of internal hosts, no segmentation testing, boilerplate executive summary).",[11,1235,202],{"id":201},[33,1237,1238,1244,1250,1256,1262,1268,1274,1280,1286],{},[36,1239,1240,1243],{},[64,1241,1242],{},"Substituting vulnerability scanning for penetration testing."," Scans detect vulnerabilities; tests exploit them to produce impact evidence. PCI DSS distinguishes the two.",[36,1245,1246,1249],{},[64,1247,1248],{},"Skipping internal testing"," and presenting only external pen-test reports.",[36,1251,1252,1255],{},[64,1253,1254],{},"Segmentation testing that does not cover every out-of-scope segment"," -- a subset test is not a PCI DSS segmentation test.",[36,1257,1258,1261],{},[64,1259,1260],{},"Missing change-driven retests"," after material CDE changes throughout the year.",[36,1263,1264,1267],{},[64,1265,1266],{},"Failing to retest remediated findings",", leaving a gap in Requirement 11.4.4 evidence.",[36,1269,1270,1273],{},[64,1271,1272],{},"Engaging testers without verifying qualifications"," or organizational independence.",[36,1275,1276,1279],{},[64,1277,1278],{},"Pen-test reports that lack evidence of hands-on testing"," -- the report must show what the tester did, not just what the tools found.",[36,1281,1282,1285],{},[64,1283,1284],{},"Treating PCI DSS pen testing as a once-a-year event"," disconnected from vulnerability management, change control, and application security.",[36,1287,1288,1291],{},[64,1289,1290],{},"Limiting scope to the easiest systems to test"," rather than the full CDE perimeter and critical systems.",[11,1293,256],{"id":255},[16,1295,1296,1297,1299],{},"episki maps every penetration testing finding to the specific PCI DSS requirement it affects, routes remediation tasks to the right engineering owner, and tracks retesting evidence automatically. Your QSA sees a clean chain from finding to fix to retest, without you digging through email or shared drives. See the ",[261,1298,264],{"href":263}," to learn more.",{"title":267,"searchDepth":268,"depth":268,"links":1301},[1302,1303,1304,1305,1306,1307,1308,1309,1310],{"id":1084,"depth":268,"text":1085},{"id":1094,"depth":268,"text":1095},{"id":1148,"depth":268,"text":1149},{"id":1170,"depth":268,"text":1171},{"id":1197,"depth":268,"text":1198},{"id":1207,"depth":268,"text":1208},{"id":191,"depth":268,"text":192},{"id":201,"depth":268,"text":202},{"id":255,"depth":268,"text":256},"PCI DSS Requirement 11.4 penetration testing — internal vs external testing, segmentation validation, frequency, scope, and methodology.",{"items":1313},[1314,1317,1320,1323],{"label":1315,"content":1316},"How often is PCI DSS penetration testing required?","PCI DSS requires penetration testing at least annually and after any significant change to the in-scope environment. Segmentation controls must be tested at least every six months for service providers and at least annually for merchants.",{"label":1318,"content":1319},"What is the difference between PCI DSS internal and external penetration testing?","External penetration testing simulates an attacker on the public internet attempting to breach the cardholder data environment. Internal penetration testing simulates an attacker who has already gained access to the internal network attempting to compromise CDE systems. PCI DSS Requirement 11.4 requires both.",{"label":1321,"content":1322},"Does PCI DSS penetration testing require a specific methodology?","PCI DSS Requirement 11.4.1 requires a documented methodology based on industry-accepted approaches such as NIST SP 800-115, OWASP, PTES, or OSSTMM. The methodology must be kept current, reviewed annually, and followed by a qualified tester.",{"label":1324,"content":1325},"Can internal staff perform PCI DSS penetration tests?","Yes, but the tester must be organizationally independent from the systems being tested and must be demonstrably qualified through certifications, experience, and training. Most organizations choose a third-party testing firm to satisfy independence and qualification requirements cleanly.",{},"\u002Fframeworks\u002Fpci\u002Fpenetration-testing",[306,301,302,1069],[305,1330,1331,307],"asv-program","network-segmentation",{"title":1333,"description":1334},"PCI DSS Penetration Testing: Requirement 11.4 Guide (Internal, External, Segmentation)","A practical guide to PCI DSS Requirement 11.4 penetration testing. Covers internal vs external scope, segmentation testing, frequency, methodology, and common pitfalls.","5.frameworks\u002Fpci\u002Fpenetration-testing","AxYyZa_L84eQvUEexqB2owrLAbcN4NXkPORzLu8yejg",{"id":1338,"title":1339,"body":1340,"description":1604,"extension":279,"faq":1605,"frameworkSlug":294,"lastUpdated":295,"meta":1619,"navigation":297,"path":1620,"relatedTerms":1621,"relatedTopics":1624,"seo":1626,"stem":1629,"__hash__":1630},"frameworkTopics\u002F5.frameworks\u002Fpci\u002Fqsa-selection.md","How to Select a PCI DSS QSA",{"type":8,"value":1341,"toc":1585},[1342,1346,1349,1352,1356,1359,1363,1366,1370,1373,1377,1380,1384,1387,1391,1394,1398,1401,1405,1408,1412,1415,1419,1422,1454,1457,1461,1464,1508,1511,1515,1518,1521,1523,1526,1528,1578,1580],[11,1343,1345],{"id":1344},"why-qsa-selection-matters","Why QSA selection matters",[16,1347,1348],{},"For any PCI DSS program that requires a Report on Compliance -- typically Level 1 merchants and service providers -- the Qualified Security Assessor (QSA) is the single most important third party you will engage. The QSA signs the Attestation of Compliance that your acquirer relies on, interprets ambiguous PCI DSS requirements in the context of your environment, and sets the tone for how smoothly the assessment runs. A strong QSA makes your PCI DSS program sharper. A weak QSA makes every control feel punitive and every evidence request ambiguous. Selecting the right QSA is therefore a multi-year decision that shapes cost, risk, and internal credibility.",[16,1350,1351],{},"PCI DSS QSAs are individuals; QSA Companies (QSACs) are firms. The PCI SSC accredits both. Individual QSAs pass annual training and requalification, and QSACs carry firm-level accreditation, quality assurance obligations, and reporting duties. The PCI SSC publishes the master list of QSACs and the regions each is authorized to work in. Your first filter is straightforward: the firm must be an active QSAC authorized in your geography.",[11,1353,1355],{"id":1354},"criteria-for-evaluating-pci-dss-qsa-firms","Criteria for evaluating PCI DSS QSA firms",[16,1357,1358],{},"Look beyond the PCI SSC list when choosing a QSA. The firms on it vary dramatically in size, philosophy, and operational approach. Evaluate candidates on the following:",[338,1360,1362],{"id":1361},"industry-and-technology-fit","Industry and technology fit",[16,1364,1365],{},"Does the QSA firm regularly assess organizations like yours -- same transaction volume, same acceptance channels, same cloud and data stack? A QSA that has signed a hundred AWS-native SaaS ROCs will understand your PCI DSS scoping questions in ways a QSA fresh from brick-and-mortar retail will not. Ask for two or three references with similar profiles, and talk to them.",[338,1367,1369],{"id":1368},"qsa-tenure-and-turnover","QSA tenure and turnover",[16,1371,1372],{},"Individual QSAs carry the assessment experience. Ask who specifically will be assigned to your engagement, how long they have been a certified QSA, and what their history is with payment technologies relevant to you. High turnover at a QSAC is a yellow flag because the person who scoped your program in year one may not be there in year three.",[338,1374,1376],{"id":1375},"methodology-and-deliverables","Methodology and deliverables",[16,1378,1379],{},"Request a redacted sample ROC and sample evidence requests. A well-written ROC is clear, precise, and tells your story without padding. Watch for generic narratives that could describe any merchant -- that is a sign of a firm running every client through the same template.",[338,1381,1383],{"id":1382},"technology-support","Technology support",[16,1385,1386],{},"Modern QSA firms use assessment platforms, evidence portals, and integrations into GRC tooling. If your program runs on a GRC platform (like episki), ask how they collaborate via that tool rather than an email chain of spreadsheets. The QSA experience improves dramatically when evidence lives in one system.",[338,1388,1390],{"id":1389},"geographic-coverage","Geographic coverage",[16,1392,1393],{},"PCI DSS assessments often require on-site testing at data centers, retail stores, or call centers. Confirm that the QSAC can reach every site you need assessed without stacking excessive travel fees.",[338,1395,1397],{"id":1396},"pricing-transparency","Pricing transparency",[16,1399,1400],{},"Ask for a written scoping questionnaire and a fixed or capped fee. Beware of open-ended time-and-materials contracts where the QSA's incentive is to expand hours. Confirm what is included: scoping, readiness, the ROC, the AOC, rescans, and remediation advisory. Clarify what is billed separately: additional sites, pen testing support, scope expansion.",[338,1402,1404],{"id":1403},"quality-assurance-program","Quality assurance program",[16,1406,1407],{},"The PCI SSC requires QSACs to maintain QA processes over their ROCs. Ask how the firm's QA works, who reviews the ROC before it leaves the firm, and what their error rate has been in PCI SSC audits.",[338,1409,1411],{"id":1410},"red-flags","Red flags",[16,1413,1414],{},"Avoid QSAs that promise to \"make the assessment easier\" in ways that would compromise independence. Avoid firms that pitch aggressive advisory services alongside the assessment engagement -- the PCI SSC has rules on independence that can be violated when advisory work gets too close to the assessment scope. Walk away from QSAs who will not share a sample ROC or references.",[11,1416,1418],{"id":1417},"engagement-scope-and-phases","Engagement scope and phases",[16,1420,1421],{},"A standard PCI DSS QSA engagement runs in five phases:",[59,1423,1424,1430,1436,1442,1448],{},[36,1425,1426,1429],{},[64,1427,1428],{},"Scoping"," -- the QSA works with you to confirm the CDE, the in-scope systems, the card acceptance channels, the controls that apply, and the testing approach. Scoping is where customized approach decisions get documented, targeted risk analyses are reviewed, and segmentation boundaries are walked through. Skipping or rushing scoping is the most expensive PCI DSS mistake a program can make.",[36,1431,1432,1435],{},[64,1433,1434],{},"Readiness or gap assessment"," -- optional but common. The QSA reviews your existing evidence against every applicable PCI DSS requirement and produces a prioritized findings list. Readiness gives you a runway to remediate before fieldwork begins.",[36,1437,1438,1441],{},[64,1439,1440],{},"Evidence collection and fieldwork"," -- the bulk of the engagement. The QSA requests evidence, interviews control owners, reviews configurations, watches live demonstrations, and samples systems. Fieldwork can be on-site, remote, or hybrid.",[36,1443,1444,1447],{},[64,1445,1446],{},"Drafting and QA"," -- the QSA writes the ROC, the QSAC performs internal QA, and you review for factual accuracy. This phase usually surfaces last-minute evidence gaps.",[36,1449,1450,1453],{},[64,1451,1452],{},"Final deliverables"," -- the QSA issues the final ROC, the AOC, and any supporting attestations. You submit to your acquirer.",[16,1455,1456],{},"Each phase has its own effort profile. Scoping is a few weeks. Readiness is typically a month. Evidence collection and fieldwork is the longest phase and can span two to four months in Level 1 environments. Drafting is a few weeks.",[11,1458,1460],{"id":1459},"cost-drivers-for-pci-dss-qsa-engagements","Cost drivers for PCI DSS QSA engagements",[16,1462,1463],{},"PCI DSS QSA costs are driven by complexity, not just size. The major drivers are:",[33,1465,1466,1472,1478,1484,1490,1496,1502],{},[36,1467,1468,1471],{},[64,1469,1470],{},"CDE size and heterogeneity"," -- more systems, more platforms, more clouds, more cost.",[36,1473,1474,1477],{},[64,1475,1476],{},"Number of physical sites"," requiring on-site testing.",[36,1479,1480,1483],{},[64,1481,1482],{},"Acceptance channels"," -- e-commerce, card-present, MOTO, mobile, and call center each require testing.",[36,1485,1486,1489],{},[64,1487,1488],{},"Third parties"," -- each service provider in scope adds evidence review effort.",[36,1491,1492,1495],{},[64,1493,1494],{},"Program maturity"," -- mature programs with strong evidence and automation burn less QSA time than programs that assemble evidence manually.",[36,1497,1498,1501],{},[64,1499,1500],{},"Customized approach usage"," -- customized approach requirements require targeted risk analyses and additional testing that add cost.",[36,1503,1504,1507],{},[64,1505,1506],{},"Remediation support"," -- advisory and rescans between fieldwork and ROC delivery can add meaningful cost if not explicit in the SOW.",[16,1509,1510],{},"A rough range: small service providers with a tight CDE might pay $40,000 to $80,000 for an annual ROC. Mid-size SaaS providers typically land between $100,000 and $250,000. Large multinational retailers with thousands of stores routinely exceed $500,000 per year.",[11,1512,1514],{"id":1513},"what-to-expect-during-the-assessment","What to expect during the assessment",[16,1516,1517],{},"Expect the PCI DSS QSA to ask for evidence directly from source systems rather than summary spreadsheets. Expect live walkthroughs of SIEM dashboards, patch management consoles, identity systems, and firewall managers. Expect sampling: the QSA will pick a subset of systems, users, or change tickets and test them in depth. Expect questions on exceptions -- every control has edge cases, and the QSA will probe how you handle them.",[16,1519,1520],{},"Plan for a dedicated PCI DSS program lead who is the single point of contact for the QSA. That lead aligns internal subject-matter experts to evidence requests, tracks outstanding items, and keeps the assessment on schedule. A part-time owner trying to juggle the QSA with other duties is the most common cause of schedule slip.",[11,1522,192],{"id":191},[16,1524,1525],{},"The QSA is the custodian of your PCI DSS attestation. Everything else in your PCI DSS program -- your ASV scans, penetration tests, policies, segmentation, control automation -- exists to be evaluated through the QSA's lens. Choosing the right QSA multiplies the effectiveness of every PCI DSS investment you have already made. Choosing poorly introduces friction, rework, and interpretation disputes that drain PCI DSS program capacity all year.",[11,1527,202],{"id":201},[33,1529,1530,1536,1542,1548,1554,1560,1566,1572],{},[36,1531,1532,1535],{},[64,1533,1534],{},"Shopping on price alone"," and ending up with a QSA whose methodology drives months of avoidable rework.",[36,1537,1538,1541],{},[64,1539,1540],{},"Skipping references"," and discovering only after signing that the QSA has no experience with your technology stack.",[36,1543,1544,1547],{},[64,1545,1546],{},"Not locking down scope"," in the SOW, letting the engagement drift into unbudgeted advisory work.",[36,1549,1550,1553],{},[64,1551,1552],{},"Giving the QSA raw access to production systems"," instead of a prepared evidence package, burning time on discovery instead of assessment.",[36,1555,1556,1559],{},[64,1557,1558],{},"Treating the readiness phase as optional"," when meaningful remediation is needed before fieldwork.",[36,1561,1562,1565],{},[64,1563,1564],{},"Rotating QSAs too often",", losing the institutional context that makes year two and beyond faster.",[36,1567,1568,1571],{},[64,1569,1570],{},"Holding the QSA at arm's length"," instead of making them a collaborative partner through the engagement.",[36,1573,1574,1577],{},[64,1575,1576],{},"Failing to align the QSA and ASV"," so findings from one program contradict or duplicate the other.",[11,1579,256],{"id":255},[16,1581,1582,1583,265],{},"episki gives your QSA a scoped, read-only workspace where they can see every PCI DSS control, its evidence, and its testing history without chasing spreadsheets and screenshots. That shortens fieldwork, reduces QSA hours, and helps your assessment team focus on the handful of PCI DSS controls that actually need discussion. Learn more on the ",[261,1584,264],{"href":263},{"title":267,"searchDepth":268,"depth":268,"links":1586},[1587,1588,1598,1599,1600,1601,1602,1603],{"id":1344,"depth":268,"text":1345},{"id":1354,"depth":268,"text":1355,"children":1589},[1590,1591,1592,1593,1594,1595,1596,1597],{"id":1361,"depth":662,"text":1362},{"id":1368,"depth":662,"text":1369},{"id":1375,"depth":662,"text":1376},{"id":1382,"depth":662,"text":1383},{"id":1389,"depth":662,"text":1390},{"id":1396,"depth":662,"text":1397},{"id":1403,"depth":662,"text":1404},{"id":1410,"depth":662,"text":1411},{"id":1417,"depth":268,"text":1418},{"id":1459,"depth":268,"text":1460},{"id":1513,"depth":268,"text":1514},{"id":191,"depth":268,"text":192},{"id":201,"depth":268,"text":202},{"id":255,"depth":268,"text":256},"A practical guide to selecting a Qualified Security Assessor (QSA) for PCI DSS — evaluating firms, cost drivers, engagement scope, and what to expect during the assessment.",{"items":1606},[1607,1610,1613,1616],{"label":1608,"content":1609},"What is a PCI DSS QSA?","A Qualified Security Assessor (QSA) is a professional certified by the PCI Security Standards Council to perform on-site PCI DSS assessments and produce the Report on Compliance (ROC). QSAs work for QSA companies (QSACs) that carry their own PCI SSC accreditation.",{"label":1611,"content":1612},"How much does a PCI DSS QSA assessment cost?","PCI DSS QSA engagements typically cost $40,000 to over $500,000 depending on cardholder data environment complexity, number of locations, existing program maturity, and whether significant remediation support is needed. Boutique firms are often less expensive than Big Four, though the quality gap is narrower than for other audits.",{"label":1614,"content":1615},"How long does a PCI DSS QSA engagement take?","A typical Level 1 ROC takes 3 to 6 months from kickoff to signed Attestation of Compliance. Highly complex environments or significant remediation can stretch that to 9-12 months. Most QSAs structure the engagement as a scoping phase, a readiness or gap phase, an evidence-collection phase, on-site or virtual fieldwork, and a drafting and QA phase.",{"label":1617,"content":1618},"Should I reuse the same QSA year over year?","It is permitted and common to keep the same PCI DSS QSA for multiple years — continuity accelerates every subsequent assessment. That said, many mature programs rotate QSAs every few years to get fresh perspective, benchmark pricing, and avoid auditor complacency.",{},"\u002Fframeworks\u002Fpci\u002Fqsa-selection",[1622,301,302,1623],"qsa","saq",[305,1625,1330,307],"compliance-levels",{"title":1627,"description":1628},"How to Select a PCI DSS QSA: Evaluation, Cost & Engagement Guide","Pick the right PCI DSS Qualified Security Assessor. Learn how to evaluate QSA firms, understand cost drivers, scope the engagement, and know what to expect during the assessment.","5.frameworks\u002Fpci\u002Fqsa-selection","TCqcgoA9A-ILcnGPf_ZopgYEk7ZkGqmRKvOtr79s920",{"id":1632,"title":1633,"body":1634,"description":1843,"extension":279,"faq":1844,"frameworkSlug":294,"lastUpdated":295,"meta":1845,"navigation":297,"path":391,"relatedTerms":1846,"relatedTopics":1847,"seo":1848,"stem":1851,"__hash__":1852},"frameworkTopics\u002F5.frameworks\u002Fpci\u002Frequirements.md","PCI DSS Requirements",{"type":8,"value":1635,"toc":1814},[1636,1640,1646,1649,1653,1657,1660,1664,1667,1671,1675,1678,1682,1685,1689,1693,1696,1700,1703,1707,1711,1714,1718,1721,1725,1728,1732,1736,1739,1743,1746,1750,1754,1757,1761,1764,1796,1804,1808],[11,1637,1639],{"id":1638},"overview-of-the-12-pci-dss-requirements","Overview of the 12 PCI DSS requirements",[16,1641,1642,1643,1645],{},"The Payment Card Industry Data Security Standard (PCI DSS) organizes its controls into 12 high-level requirements. These requirements apply to every entity that stores, processes, or transmits cardholder data, and they form the backbone of every ",[261,1644,331],{"href":263}," assessment. Understanding each requirement is the first step toward building a sustainable compliance program.",[16,1647,1648],{},"The requirements are grouped into six overarching goals that progress from building a secure network to maintaining an information security policy. Whether you are a Level 1 merchant completing a Report on Compliance or a smaller merchant filing a Self-Assessment Questionnaire, the same 12 requirements apply.",[11,1650,1652],{"id":1651},"goal-1-build-and-maintain-a-secure-network-and-systems","Goal 1: build and maintain a secure network and systems",[338,1654,1656],{"id":1655},"requirement-1-install-and-maintain-network-security-controls","Requirement 1 - Install and maintain network security controls",[16,1658,1659],{},"Requirement 1 mandates that organizations deploy firewalls, network security appliances, and segmentation controls to protect the cardholder data environment (CDE). In PCI DSS v4.0, the language shifted from \"firewalls\" to \"network security controls\" to acknowledge modern architectures such as cloud-native security groups, micro-segmentation, and software-defined networking. Organizations must document all network connections into and out of the CDE, review rule sets at least every six months, and restrict traffic to only what is business-justified.",[338,1661,1663],{"id":1662},"requirement-2-apply-secure-configurations-to-all-system-components","Requirement 2 - Apply secure configurations to all system components",[16,1665,1666],{},"Default passwords, unnecessary services, and insecure protocols create easy attack vectors. Requirement 2 requires organizations to harden every system component by removing defaults, disabling unnecessary services, and configuring security parameters according to industry-accepted hardening standards such as CIS Benchmarks. PCI DSS v4.0 expanded this to explicitly cover all system components, not just vendor-supplied defaults.",[11,1668,1670],{"id":1669},"goal-2-protect-account-data","Goal 2: protect account data",[338,1672,1674],{"id":1673},"requirement-3-protect-stored-account-data","Requirement 3 - Protect stored account data",[16,1676,1677],{},"If your organization stores cardholder data, Requirement 3 dictates how it must be protected. This includes encryption, truncation, masking, and hashing. Sensitive authentication data such as full track data, CVV codes, and PINs must never be stored after authorization. PCI DSS v4.0 introduced more prescriptive guidance on keyed cryptographic hashes and disk-level encryption limitations, reinforcing that storage should be minimized wherever possible.",[338,1679,1681],{"id":1680},"requirement-4-protect-cardholder-data-with-strong-cryptography-during-transmission","Requirement 4 - Protect cardholder data with strong cryptography during transmission",[16,1683,1684],{},"Cardholder data transmitted over open, public networks must be encrypted using strong cryptography. Requirement 4 specifies the use of trusted certificates and secure protocols such as TLS 1.2 or higher. PCI DSS v4.0 clarified that this applies to all networks where data could be intercepted, including internal networks where risk is present, and deprecated older protocols like early TLS and SSL.",[11,1686,1688],{"id":1687},"goal-3-maintain-a-vulnerability-management-program","Goal 3: maintain a vulnerability management program",[338,1690,1692],{"id":1691},"requirement-5-protect-all-systems-and-networks-from-malicious-software","Requirement 5 - Protect all systems and networks from malicious software",[16,1694,1695],{},"Anti-malware solutions must be deployed on all systems commonly affected by malicious software. Requirement 5 in v4.0 expanded its scope beyond traditional endpoints to include any system component that could be impacted. Organizations must ensure that anti-malware mechanisms are actively running, generating audit logs, and cannot be disabled by users without authorization. Phishing protections were also added as a new focus area.",[338,1697,1699],{"id":1698},"requirement-6-develop-and-maintain-secure-systems-and-software","Requirement 6 - Develop and maintain secure systems and software",[16,1701,1702],{},"Requirement 6 addresses secure software development and timely patching. Critical security patches must be applied within one month of release. Organizations developing payment applications must follow a secure development lifecycle. PCI DSS v4.0 introduced a significant new sub-requirement mandating that public-facing web applications be protected by automated technical solutions that detect and prevent web-based attacks, such as web application firewalls (WAFs).",[11,1704,1706],{"id":1705},"goal-4-implement-strong-access-control-measures","Goal 4: implement strong access control measures",[338,1708,1710],{"id":1709},"requirement-7-restrict-access-to-system-components-and-cardholder-data-by-business-need-to-know","Requirement 7 - Restrict access to system components and cardholder data by business need to know",[16,1712,1713],{},"Access to cardholder data and CDE systems must follow the principle of least privilege. Only personnel whose job functions require access should have it, and access must be granted through a formal authorization process. PCI DSS v4.0 requires that access reviews occur at least every six months and that all access is revoked promptly when no longer needed.",[338,1715,1717],{"id":1716},"requirement-8-identify-users-and-authenticate-access-to-system-components","Requirement 8 - Identify users and authenticate access to system components",[16,1719,1720],{},"Every user must have a unique identifier, and authentication mechanisms must be strong enough to prevent unauthorized access. PCI DSS v4.0 significantly expanded multi-factor authentication (MFA) requirements, mandating MFA for all access into the CDE rather than just remote access. Password requirements were also updated to a minimum of 12 characters, with encouragement to adopt passphrases.",[338,1722,1724],{"id":1723},"requirement-9-restrict-physical-access-to-cardholder-data","Requirement 9 - Restrict physical access to cardholder data",[16,1726,1727],{},"Physical security controls protect servers, workstations, paper records, and networking equipment within the CDE. Requirement 9 covers visitor management, media destruction, and point-of-interaction device inspections. Organizations must maintain logs of physical access and periodically inspect POS devices for tampering or unauthorized substitution.",[11,1729,1731],{"id":1730},"goal-5-regularly-monitor-and-test-networks","Goal 5: regularly monitor and test networks",[338,1733,1735],{"id":1734},"requirement-10-log-and-monitor-all-access-to-system-components-and-cardholder-data","Requirement 10 - Log and monitor all access to system components and cardholder data",[16,1737,1738],{},"Comprehensive logging is essential for detecting breaches and supporting forensic investigations. Requirement 10 mandates that audit trails capture all individual user access to cardholder data, all actions by administrators, and all access to audit trails themselves. PCI DSS v4.0 introduced automated mechanisms for reviewing audit logs and detecting anomalies, moving beyond manual log review toward security information and event management (SIEM) integration.",[338,1740,1742],{"id":1741},"requirement-11-test-security-of-systems-and-networks-regularly","Requirement 11 - Test security of systems and networks regularly",[16,1744,1745],{},"Vulnerability scanning and penetration testing validate that security controls are functioning as intended. Requirement 11 specifies quarterly internal and external vulnerability scans (external scans by an Approved Scanning Vendor), annual penetration tests, and intrusion detection or prevention systems. PCI DSS v4.0 added authenticated internal scanning requirements and a new mandate for detecting and alerting on unauthorized changes to payment pages, addressing the growing threat of Magecart-style attacks on e-commerce sites.",[11,1747,1749],{"id":1748},"goal-6-maintain-an-information-security-policy","Goal 6: maintain an information security policy",[338,1751,1753],{"id":1752},"requirement-12-support-information-security-with-organizational-policies-and-programs","Requirement 12 - Support information security with organizational policies and programs",[16,1755,1756],{},"Requirement 12 requires a comprehensive information security policy that addresses all PCI DSS requirements. It covers security awareness training, incident response planning, risk assessments, and third-party service provider management. PCI DSS v4.0 expanded the risk assessment requirements and introduced a targeted risk analysis approach where organizations perform formal risk analyses to determine the frequency of certain recurring activities.",[11,1758,1760],{"id":1759},"key-changes-in-pci-dss-v40","Key changes in PCI DSS v4.0",[16,1762,1763],{},"PCI DSS v4.0 brought several cross-cutting changes that affect multiple requirements:",[33,1765,1766,1772,1778,1784,1790],{},[36,1767,1768,1771],{},[64,1769,1770],{},"Customized approach"," - Organizations can now meet requirement objectives through alternative controls validated by a customized approach, rather than following only the defined prescriptive approach.",[36,1773,1774,1777],{},[64,1775,1776],{},"Targeted risk analysis"," - A new methodology lets organizations determine the appropriate frequency for activities like log reviews and password changes based on documented risk analysis.",[36,1779,1780,1783],{},[64,1781,1782],{},"Expanded MFA"," - Multi-factor authentication is now required for all access into the CDE, not just remote access.",[36,1785,1786,1789],{},[64,1787,1788],{},"E-commerce protections"," - New requirements address script integrity monitoring and management for payment pages.",[36,1791,1792,1795],{},[64,1793,1794],{},"Phishing defenses"," - Explicit requirements for anti-phishing mechanisms were added under Requirement 5.",[16,1797,1798,1799,1803],{},"For a complete walkthrough of the transition, see the ",[261,1800,1802],{"href":1801},"\u002Fframeworks\u002Fpci\u002Fv4-changes","PCI DSS v4.0 changes"," topic.",[11,1805,1807],{"id":1806},"building-a-sustainable-compliance-program","Building a sustainable compliance program",[16,1809,1810,1811,1813],{},"Meeting the 12 PCI DSS requirements is not a one-time project. Organizations in the ",[261,1812,612],{"href":611}," and beyond should treat compliance as an ongoing program with continuous monitoring, regular training, and periodic reassessment. Automating evidence collection, mapping controls to specific requirements, and integrating compliance workflows with engineering tools reduces the burden on security teams and ensures readiness for every assessment cycle.",{"title":267,"searchDepth":268,"depth":268,"links":1815},[1816,1817,1821,1825,1829,1834,1838,1841,1842],{"id":1638,"depth":268,"text":1639},{"id":1651,"depth":268,"text":1652,"children":1818},[1819,1820],{"id":1655,"depth":662,"text":1656},{"id":1662,"depth":662,"text":1663},{"id":1669,"depth":268,"text":1670,"children":1822},[1823,1824],{"id":1673,"depth":662,"text":1674},{"id":1680,"depth":662,"text":1681},{"id":1687,"depth":268,"text":1688,"children":1826},[1827,1828],{"id":1691,"depth":662,"text":1692},{"id":1698,"depth":662,"text":1699},{"id":1705,"depth":268,"text":1706,"children":1830},[1831,1832,1833],{"id":1709,"depth":662,"text":1710},{"id":1716,"depth":662,"text":1717},{"id":1723,"depth":662,"text":1724},{"id":1730,"depth":268,"text":1731,"children":1835},[1836,1837],{"id":1734,"depth":662,"text":1735},{"id":1741,"depth":662,"text":1742},{"id":1748,"depth":268,"text":1749,"children":1839},[1840],{"id":1752,"depth":662,"text":1753},{"id":1759,"depth":268,"text":1760},{"id":1806,"depth":268,"text":1807},"A detailed overview of all 12 PCI DSS requirements, what each covers, and how they changed in version 4.0.",null,{},[301,696],[1625,699,698],{"title":1849,"description":1850},"PCI DSS Requirements - All 12 Requirements Explained","Understand the 12 PCI DSS requirements covering network security, data protection, access control, and monitoring. Includes PCI DSS v4.0 changes.","5.frameworks\u002Fpci\u002Frequirements","_FMxxQDWNJKBVtzBrnEdLKJcPrFtGwmwaW8TAFQOEkA",{"id":1854,"title":1855,"body":1856,"description":2161,"extension":279,"faq":2162,"frameworkSlug":294,"lastUpdated":295,"meta":2176,"navigation":297,"path":2177,"relatedTerms":2178,"relatedTopics":2179,"seo":2180,"stem":2183,"__hash__":2184},"frameworkTopics\u002F5.frameworks\u002Fpci\u002Fsaq-types-explained.md","PCI DSS SAQ Types Explained (A, A-EP, B, B-IP, C, C-VT, D, P2PE)",{"type":8,"value":1857,"toc":2147},[1858,1862,1865,1868,1872,1875,2015,2018,2022,2025,2028,2032,2035,2039,2042,2045,2049,2052,2056,2059,2063,2066,2070,2073,2075,2078,2081,2083,2139,2141],[11,1859,1861],{"id":1860},"choosing-the-right-pci-dss-saq","Choosing the right PCI DSS SAQ",[16,1863,1864],{},"The PCI SSC publishes nine Self-Assessment Questionnaires (SAQs) to give eligible merchants and service providers a validation path that is scoped to their actual card acceptance profile. The right SAQ is the one that matches how card data actually enters, flows through, and leaves your environment. Picking the wrong SAQ is a common PCI DSS mistake -- one that becomes visible during breach investigation, acquirer review, or a subsequent move to a Report on Compliance.",[16,1866,1867],{},"SAQ selection starts with three questions: which channels do you use to accept cards, what technology handles card data on each channel, and do you store any cardholder data after the transaction. The answers drive which SAQ you are eligible for and which controls apply.",[11,1869,1871],{"id":1870},"all-saq-types-at-a-glance","All SAQ types at a glance",[16,1873,1874],{},"The table below summarizes the current PCI DSS v4.0 SAQ family. Question counts are approximate and vary slightly between minor revisions of PCI DSS; always confirm with the current SAQ document on the PCI SSC website. Each SAQ includes an Attestation of Compliance that must accompany it.",[1876,1877,1878,1894],"table",{},[1879,1880,1881],"thead",{},[1882,1883,1884,1888,1891],"tr",{},[1885,1886,1887],"th",{},"SAQ",[1885,1889,1890],{},"Eligibility summary",[1885,1892,1893],{},"Approx. questions",[1895,1896,1897,1911,1924,1937,1950,1963,1976,1989,2002],"tbody",{},[1882,1898,1899,1905,1908],{},[1900,1901,1902],"td",{},[64,1903,1904],{},"A",[1900,1906,1907],{},"Card-not-present merchants (e-commerce or mail\u002Ftelephone order) who fully outsource all cardholder data functions to PCI DSS-validated third parties. Your systems do not store, process, or transmit cardholder data.",[1900,1909,1910],{},"~31",[1882,1912,1913,1918,1921],{},[1900,1914,1915],{},[64,1916,1917],{},"A-EP",[1900,1919,1920],{},"E-commerce merchants who partially outsource payment processing but whose website could impact the security of the payment transaction -- for example, hosting the page that embeds a processor's iframe or JavaScript.",[1900,1922,1923],{},"~152",[1882,1925,1926,1931,1934],{},[1900,1927,1928],{},[64,1929,1930],{},"B",[1900,1932,1933],{},"Merchants using only imprint machines or standalone, dial-out terminals. No e-commerce, no electronic cardholder data storage.",[1900,1935,1936],{},"~41",[1882,1938,1939,1944,1947],{},[1900,1940,1941],{},[64,1942,1943],{},"B-IP",[1900,1945,1946],{},"Merchants using only standalone, PTS-approved payment terminals with an IP connection to the payment processor. No e-commerce, no electronic cardholder data storage.",[1900,1948,1949],{},"~86",[1882,1951,1952,1957,1960],{},[1900,1953,1954],{},[64,1955,1956],{},"C-VT",[1900,1958,1959],{},"Merchants entering a single transaction at a time into a web-based virtual payment terminal hosted by a PCI DSS-validated service provider. No e-commerce, no electronic cardholder data storage.",[1900,1961,1962],{},"~80",[1882,1964,1965,1970,1973],{},[1900,1966,1967],{},[64,1968,1969],{},"C",[1900,1971,1972],{},"Merchants with payment application systems connected to the internet (for example, integrated POS) that do not store electronic cardholder data.",[1900,1974,1975],{},"~160",[1882,1977,1978,1983,1986],{},[1900,1979,1980],{},[64,1981,1982],{},"P2PE",[1900,1984,1985],{},"Merchants using an approved PCI SSC-listed Point-to-Point Encryption (P2PE) solution for all payment acceptance. No other card acceptance channels and no storage of electronic cardholder data.",[1900,1987,1988],{},"~35",[1882,1990,1991,1996,1999],{},[1900,1992,1993],{},[64,1994,1995],{},"D for Merchants",[1900,1997,1998],{},"Merchants that do not fit any other SAQ, or that store cardholder data. Covers the full set of applicable PCI DSS requirements.",[1900,2000,2001],{},"~330+",[1882,2003,2004,2009,2012],{},[1900,2005,2006],{},[64,2007,2008],{},"D for Service Providers",[1900,2010,2011],{},"Service providers eligible to self-assess rather than complete a full ROC. Covers the full set of service-provider PCI DSS requirements.",[1900,2013,2014],{},"~370+",[16,2016,2017],{},"Exact question counts vary across PCI DSS revisions and between the defined and customized approaches.",[11,2019,2021],{"id":2020},"saq-a-fully-outsourced-e-commerce-and-moto","SAQ A - fully outsourced e-commerce and MOTO",[16,2023,2024],{},"SAQ A is the shortest SAQ and the target of most e-commerce scope reduction efforts. To qualify for SAQ A your website must either redirect customers entirely to the processor's hosted page or use a direct post or hosted iframe where the processor's infrastructure handles all cardholder data. Your servers never see the PAN. SAQ A applies only to card-not-present channels; card-present merchants cannot use SAQ A.",[16,2026,2027],{},"PCI DSS v4.0 expanded SAQ A to include controls that protect the payment page from e-skimming and script-tampering attacks. Even when the PAN never touches your servers, a compromised script on the page can capture card data before it ever reaches the processor. SAQ A now includes testing procedures related to Requirement 6.4.3 and 11.6.1 to address this risk.",[11,2029,2031],{"id":2030},"saq-a-ep-partial-outsourcing-with-payment-page-influence","SAQ A-EP - partial outsourcing with payment-page influence",[16,2033,2034],{},"SAQ A-EP is longer than SAQ A because the merchant has more ability to affect payment security. An A-EP merchant typically hosts the checkout page that loads the processor's iframe or JavaScript. The PAN never transits merchant infrastructure in a meaningful way, but scripts and pages hosted by the merchant are in a position to intercept or manipulate card data if compromised. SAQ A-EP applies e-commerce-relevant PCI DSS controls across access control, vulnerability management, network security, and logging -- roughly five times the work of SAQ A.",[11,2036,2038],{"id":2037},"saq-b-and-saq-b-ip-standalone-terminals","SAQ B and SAQ B-IP - standalone terminals",[16,2040,2041],{},"SAQ B is designed for very low-complexity card-present merchants using only imprint machines or standalone dial-out terminals. It is rare today and largely a legacy artifact.",[16,2043,2044],{},"SAQ B-IP covers merchants using only standalone IP-connected terminals approved under the PCI PTS program, where the terminals connect to the processor over IP but do not route through a merchant's payment application. The merchant environment around the terminal is smaller than C, but IP-connected terminals carry more risk than dial-out devices, so the SAQ is longer than SAQ B.",[11,2046,2048],{"id":2047},"saq-c-vt-virtual-terminals","SAQ C-VT - virtual terminals",[16,2050,2051],{},"SAQ C-VT is for merchants who key in transactions one at a time on a web-based virtual payment terminal operated by a PCI DSS-validated service provider. Typical users are professional services firms or small service businesses that take occasional card-present transactions through a computer and a web browser. SAQ C-VT has specific eligibility conditions -- including that the computer used for virtual terminal access is isolated and dedicated to that purpose.",[11,2053,2055],{"id":2054},"saq-c-integrated-payment-applications","SAQ C - integrated payment applications",[16,2057,2058],{},"SAQ C is for merchants with integrated payment applications that connect to the internet. The PAN transits merchant systems in transit but is not stored. SAQ C is substantially longer than SAQ B-IP because the merchant's environment includes more components that can affect payment security -- the POS, the network, the supporting infrastructure. SAQ C is common for small-to-mid-size brick-and-mortar retailers with integrated POS platforms.",[11,2060,2062],{"id":2061},"saq-p2pe-validated-point-to-point-encryption","SAQ P2PE - validated point-to-point encryption",[16,2064,2065],{},"SAQ P2PE is the payoff for adopting a PCI SSC-listed Point-to-Point Encryption solution. When all card acceptance flows through a listed P2PE solution, the merchant's environment between terminal and processor is removed from PCI DSS scope and SAQ P2PE covers the remaining obligations -- primarily terminal management, physical security, and incident response. SAQ P2PE is one of the shortest SAQs and a favorite of retail chains that can standardize on a single P2PE platform.",[11,2067,2069],{"id":2068},"saq-d-the-catch-all","SAQ D - the catch-all",[16,2071,2072],{},"SAQ D applies when the merchant or service provider does not fit any other SAQ, or when cardholder data is stored. SAQ D for Merchants covers every applicable PCI DSS requirement; SAQ D for Service Providers adds service-provider-specific obligations. SAQ D is the longest self-assessment questionnaire and, in effort terms, is close to a Report on Compliance without the QSA signature. Many Level 2 merchants and smaller service providers complete SAQ D annually.",[11,2074,192],{"id":191},[16,2076,2077],{},"The SAQ is your PCI DSS validation deliverable. Every merchant and service provider that does not owe a Report on Compliance owes one of the SAQs plus its Attestation of Compliance. The SAQ must be signed by an executive officer and submitted to your acquirer on the cadence your acquirer specifies -- typically annually. Getting the SAQ wrong has material consequences: your acquirer may reject it, your card brands may revalidate your level, or a breach investigation may discover that the SAQ you filed did not match your actual environment.",[16,2079,2080],{},"The SAQ also drives control effort. A merchant eligible for SAQ A can often run a PCI DSS program with a handful of controls and a tight scoping narrative. A merchant on SAQ D is running essentially the same program a Level 1 merchant runs, minus the QSA on-site. The difference between SAQ tiers is often more impactful than the difference between merchant levels.",[11,2082,202],{"id":201},[33,2084,2085,2091,2097,2103,2109,2115,2121,2127,2133],{},[36,2086,2087,2090],{},[64,2088,2089],{},"Self-selecting a simpler SAQ than your architecture supports"," -- for example, filing SAQ A while hosting scripts that influence the payment page.",[36,2092,2093,2096],{},[64,2094,2095],{},"Ignoring e-skimming controls"," introduced under PCI DSS v4.0 for SAQ A and A-EP merchants.",[36,2098,2099,2102],{},[64,2100,2101],{},"Confusing hosted-page with iframe-hosted"," checkouts. They are not always the same SAQ.",[36,2104,2105,2108],{},[64,2106,2107],{},"Missing PTS validation"," for standalone terminals claimed under SAQ B or B-IP.",[36,2110,2111,2114],{},[64,2112,2113],{},"Using non-dedicated workstations"," for virtual terminal access under SAQ C-VT.",[36,2116,2117,2120],{},[64,2118,2119],{},"Failing to revalidate the SAQ"," when channels change -- a new mobile app, a new acquisition, or a new recurring-billing capability can all move you to a different SAQ.",[36,2122,2123,2126],{},[64,2124,2125],{},"Treating SAQ D as a checkbox"," instead of a full PCI DSS program. SAQ D scope is nearly the same as a ROC.",[36,2128,2129,2132],{},[64,2130,2131],{},"Using outdated SAQ versions"," when the PCI SSC has released an updated SAQ aligned with the current PCI DSS version.",[36,2134,2135,2138],{},[64,2136,2137],{},"Signing the Attestation of Compliance without reviewing every answer"," with the control owners.",[11,2140,256],{"id":255},[16,2142,2143,2144,2146],{},"episki keeps your SAQ answers alive throughout the year, linking each question to the evidence and control owner that supports it. When the year-end SAQ is due, you are not assembling answers from memory -- you are confirming the position the platform has been maintaining all along. See the ",[261,2145,264],{"href":263}," for how SAQ workflows fit into a year-round PCI DSS program.",{"title":267,"searchDepth":268,"depth":268,"links":2148},[2149,2150,2151,2152,2153,2154,2155,2156,2157,2158,2159,2160],{"id":1860,"depth":268,"text":1861},{"id":1870,"depth":268,"text":1871},{"id":2020,"depth":268,"text":2021},{"id":2030,"depth":268,"text":2031},{"id":2037,"depth":268,"text":2038},{"id":2047,"depth":268,"text":2048},{"id":2054,"depth":268,"text":2055},{"id":2061,"depth":268,"text":2062},{"id":2068,"depth":268,"text":2069},{"id":191,"depth":268,"text":192},{"id":201,"depth":268,"text":202},{"id":255,"depth":268,"text":256},"Every PCI DSS Self-Assessment Questionnaire explained — eligibility, question counts, and typical use cases for SAQ A, A-EP, B, B-IP, C, C-VT, D, and P2PE.",{"items":2163},[2164,2167,2170,2173],{"label":2165,"content":2166},"Which PCI DSS SAQ should I use?","The right SAQ depends on your acceptance channel, the technology you use to accept cards, and whether you store cardholder data. Start by identifying how card data enters your environment — hosted page, iframe, POS terminal, virtual terminal, or direct — then match to the SAQ whose eligibility criteria fit exactly.",{"label":2168,"content":2169},"Can I change SAQ types between reporting periods?","Yes. If your acceptance channels or technology change, you must reassess which SAQ applies. Changing from SAQ D to SAQ A after outsourcing payment capture, for example, is a common scope reduction outcome. Document the change and the supporting architectural change with your acquirer.",{"label":2171,"content":2172},"What is the difference between SAQ A and SAQ A-EP?","SAQ A is for e-commerce merchants who fully outsource card capture (redirect or processor-hosted page) so their systems never touch card data. SAQ A-EP is for merchants whose website forwards card data but could affect the security of the payment page — for example, merchants using processor iframes or JavaScript that they host.",{"label":2174,"content":2175},"Do service providers use SAQs?","Some service providers use SAQ D for Service Providers to self-validate. Most service providers that handle cardholder data on behalf of merchants are required by their customers or card brands to complete a full Report on Compliance instead. Confirm with each card brand and with your customers.",{},"\u002Fframeworks\u002Fpci\u002Fsaq-types-explained",[1623,301,302,1069],[698,1625,307,1071],{"title":2181,"description":2182},"PCI DSS SAQ Types Explained: A, A-EP, B, B-IP, C, C-VT, D, P2PE","All PCI DSS SAQ types compared — eligibility rules, approximate question counts, use cases, and how to choose the right SAQ for your business.","5.frameworks\u002Fpci\u002Fsaq-types-explained","EMfWsZqyfCcQTPgSq1kcz0blcoyDJSBIgwItWr1oyzw",{"id":2186,"title":2187,"body":2188,"description":2531,"extension":279,"faq":2532,"frameworkSlug":294,"lastUpdated":295,"meta":2546,"navigation":297,"path":592,"relatedTerms":2547,"relatedTopics":2548,"seo":2549,"stem":2552,"__hash__":2553},"frameworkTopics\u002F5.frameworks\u002Fpci\u002Fscope-reduction.md","PCI DSS Scope Reduction",{"type":8,"value":2189,"toc":2514},[2190,2194,2200,2206,2210,2213,2217,2220,2224,2227,2231,2234,2238,2241,2244,2249,2263,2266,2271,2285,2289,2292,2297,2311,2316,2330,2334,2337,2342,2356,2361,2375,2379,2382,2387,2407,2413,2417,2420,2425,2442,2446,2449,2472,2475,2479,2482,2508],[11,2191,2193],{"id":2192},"why-scope-reduction-matters","Why scope reduction matters",[16,2195,2196,2197,2199],{},"The scope of a PCI DSS assessment is determined by the cardholder data environment (CDE) -- every system, network segment, person, and process that stores, processes, or transmits cardholder data, plus any component connected to or that could impact the security of those systems. The larger the CDE, the more controls you must implement, the more evidence you must collect, and the more expensive and time-consuming your ",[261,2198,331],{"href":263}," program becomes.",[16,2201,2202,2203,2205],{},"Scope reduction is the practice of shrinking the CDE through architectural and operational changes. A smaller scope means fewer systems to assess, fewer vulnerabilities to manage, and a faster path to compliance. For organizations in the ",[261,2204,612],{"href":611}," handling high transaction volumes, effective scope reduction can be the difference between a manageable compliance program and an overwhelming one.",[11,2207,2209],{"id":2208},"understanding-the-cardholder-data-environment","Understanding the cardholder data environment",[16,2211,2212],{},"Before reducing scope, you must define it. The CDE includes three categories of systems:",[338,2214,2216],{"id":2215},"cde-systems","CDE systems",[16,2218,2219],{},"These are systems that directly store, process, or transmit cardholder data (CHD) or sensitive authentication data (SAD). Examples include payment application servers, databases containing card numbers, and point-of-sale terminals.",[338,2221,2223],{"id":2222},"connected-to-systems","Connected-to systems",[16,2225,2226],{},"Systems that have network connectivity to CDE systems, even if they do not handle cardholder data themselves, are considered \"connected to\" the CDE and are in scope. A domain controller that authenticates users accessing a payment server is a connected-to system. An application server on the same network segment as a payment processor is also in scope.",[338,2228,2230],{"id":2229},"security-impacting-systems","Security-impacting systems",[16,2232,2233],{},"Systems that could affect the security of the CDE are in scope even without direct connectivity. This includes SIEM servers that collect logs from CDE systems, anti-malware management consoles, and vulnerability scanners used against CDE components.",[11,2235,2237],{"id":2236},"scope-reduction-strategies","Scope reduction strategies",[338,2239,2240],{"id":1331},"Network segmentation",[16,2242,2243],{},"Network segmentation is the most fundamental scope reduction technique. By isolating the CDE on a dedicated network segment with strict access controls, you prevent other systems from being classified as \"connected to\" the CDE.",[16,2245,2246],{},[64,2247,2248],{},"Effective segmentation requires:",[33,2250,2251,2254,2257,2260],{},[36,2252,2253],{},"Dedicated VLANs or network segments for all CDE components",[36,2255,2256],{},"Firewall rules that restrict traffic between the CDE and the rest of the corporate network to only what is business-justified",[36,2258,2259],{},"Separate management interfaces for CDE networking equipment where feasible",[36,2261,2262],{},"Regular validation that segmentation controls are functioning correctly, including penetration testing that specifically targets segmentation boundaries",[16,2264,2265],{},"PCI DSS v4.0 requires that segmentation controls be tested at least every six months for service providers and annually for merchants. This testing must verify that the segmentation is effective at isolating the CDE from out-of-scope networks.",[16,2267,2268],{},[64,2269,2270],{},"Common segmentation mistakes:",[33,2272,2273,2276,2279,2282],{},[36,2274,2275],{},"Flat networks where CDE and non-CDE systems share the same subnet",[36,2277,2278],{},"Overly permissive firewall rules that negate the benefit of segmentation",[36,2280,2281],{},"Forgetting to segment management and monitoring networks",[36,2283,2284],{},"Allowing VPN or remote access solutions to bridge CDE and non-CDE segments",[338,2286,2288],{"id":2287},"tokenization","Tokenization",[16,2290,2291],{},"Tokenization replaces cardholder data with a surrogate value (a token) that has no exploitable meaning. When implemented correctly, systems that only handle tokens are not in scope for PCI DSS, because tokens are not considered cardholder data.",[16,2293,2294],{},[64,2295,2296],{},"How tokenization reduces scope:",[33,2298,2299,2302,2305,2308],{},[36,2300,2301],{},"Your application stores and processes tokens instead of primary account numbers (PANs)",[36,2303,2304],{},"The token vault, where tokens map back to real card numbers, remains in scope but is isolated to a dedicated, hardened environment",[36,2306,2307],{},"All other systems that interact with tokens (your CRM, analytics platform, order management system) are removed from scope",[36,2309,2310],{},"You can use tokens for recurring transactions, refunds, and customer lookups without touching real card data",[16,2312,2313],{},[64,2314,2315],{},"Tokenization considerations:",[33,2317,2318,2321,2324,2327],{},[36,2319,2320],{},"The tokenization system itself is in scope and must be PCI DSS compliant",[36,2322,2323],{},"Tokens must not be reversible through mathematical means without the token vault",[36,2325,2326],{},"If you use a third-party tokenization service provider, that provider must be PCI DSS validated",[36,2328,2329],{},"Format-preserving tokens that resemble card numbers may create confusion about whether real card data is present -- clear documentation is essential",[338,2331,2333],{"id":2332},"point-to-point-encryption-p2pe","Point-to-point encryption (P2PE)",[16,2335,2336],{},"PCI-validated Point-to-Point Encryption (P2PE) solutions encrypt cardholder data at the point of interaction (the payment terminal) and keep it encrypted until it reaches the decryption environment at the payment processor. When using a PCI-listed P2PE solution, the merchant's environment between the terminal and the processor is removed from scope.",[16,2338,2339],{},[64,2340,2341],{},"Scope reduction benefits of P2PE:",[33,2343,2344,2347,2350,2353],{},[36,2345,2346],{},"The encrypted data passing through your network is not considered cardholder data for scoping purposes",[36,2348,2349],{},"Network infrastructure between the P2PE terminal and the internet is not in scope",[36,2351,2352],{},"You may qualify for SAQ P2PE, which contains approximately 33 questions -- significantly fewer than other SAQ types",[36,2354,2355],{},"Physical security of terminals and P2PE device management become the primary compliance focus",[16,2357,2358],{},[64,2359,2360],{},"P2PE requirements:",[33,2362,2363,2366,2369,2372],{},[36,2364,2365],{},"The solution must be listed on the PCI SSC's list of validated P2PE solutions",[36,2367,2368],{},"Terminal management must follow the P2PE Instruction Manual (PIM) provided by the solution vendor",[36,2370,2371],{},"You cannot access the decryption keys or decrypted data at any point",[36,2373,2374],{},"Any deviation from the PIM may invalidate the scope reduction benefits",[338,2376,2378],{"id":2377},"outsourcing-payment-processing","Outsourcing payment processing",[16,2380,2381],{},"Fully outsourcing payment processing to a PCI DSS-validated service provider is another effective scope reduction strategy. By redirecting customers to a hosted payment page or using an iframe provided by the processor, your systems never touch cardholder data.",[16,2383,2384],{},[64,2385,2386],{},"Outsourcing approaches:",[33,2388,2389,2395,2401],{},[36,2390,2391,2394],{},[64,2392,2393],{},"URL redirect"," - The customer is redirected to the payment processor's website to enter card details, then returned to your site after payment. Your systems never handle cardholder data.",[36,2396,2397,2400],{},[64,2398,2399],{},"Embedded iframe"," - An iframe from the payment processor is embedded in your checkout page. The card data is submitted directly to the processor, bypassing your servers.",[36,2402,2403,2406],{},[64,2404,2405],{},"JavaScript tokenization"," - A JavaScript library from the processor captures card data in the browser and sends it directly to the processor, returning a token to your server.",[16,2408,2409,2410,2412],{},"Each approach has different scope implications. A URL redirect may qualify you for SAQ A, while an embedded iframe or JavaScript approach may require SAQ A-EP due to the risk that compromised scripts on your page could intercept card data. See the ",[261,2411,424],{"href":423}," for detailed eligibility criteria.",[338,2414,2416],{"id":2415},"data-minimization","Data minimization",[16,2418,2419],{},"The simplest scope reduction technique is to stop storing cardholder data you do not need. Many organizations retain full card numbers for convenience rather than necessity.",[16,2421,2422],{},[64,2423,2424],{},"Data minimization practices:",[33,2426,2427,2430,2433,2436,2439],{},[36,2428,2429],{},"Delete stored cardholder data that has no ongoing business or legal requirement",[36,2431,2432],{},"Truncate PANs to the first six and last four digits where full numbers are not needed",[36,2434,2435],{},"Never store sensitive authentication data (CVV, PIN, full track data) after authorization",[36,2437,2438],{},"Implement data retention policies with automated purging",[36,2440,2441],{},"Audit databases, log files, and backups for unintended cardholder data storage",[11,2443,2445],{"id":2444},"combining-strategies-for-maximum-reduction","Combining strategies for maximum reduction",[16,2447,2448],{},"The most effective scope reduction programs layer multiple strategies. A typical approach might combine:",[59,2450,2451,2456,2461,2466],{},[36,2452,2453,2455],{},[64,2454,2288],{}," for application-layer scope reduction, ensuring your databases and application servers only handle tokens",[36,2457,2458,2460],{},[64,2459,2240],{}," to isolate the remaining CDE systems (token vault, any systems that interact with the payment processor)",[36,2462,2463,2465],{},[64,2464,1982],{}," for in-store payment terminals, removing the retail network from scope",[36,2467,2468,2471],{},[64,2469,2470],{},"Outsourced payment pages"," for e-commerce, redirecting card data capture to a validated processor",[16,2473,2474],{},"This layered approach can reduce a CDE from hundreds of systems to a handful, dramatically simplifying the compliance assessment.",[11,2476,2478],{"id":2477},"validating-scope-reduction","Validating scope reduction",[16,2480,2481],{},"Scope reduction is only effective if it is properly validated. PCI DSS requires:",[33,2483,2484,2490,2496,2502],{},[36,2485,2486,2489],{},[64,2487,2488],{},"Documented data flows"," showing where cardholder data enters, moves through, and exits the environment",[36,2491,2492,2495],{},[64,2493,2494],{},"Network diagrams"," that clearly delineate CDE boundaries and segmentation controls",[36,2497,2498,2501],{},[64,2499,2500],{},"Penetration testing"," that validates segmentation effectiveness by attempting to access the CDE from out-of-scope networks",[36,2503,2504,2507],{},[64,2505,2506],{},"Annual scope confirmation"," as part of the assessment process, verifying that no new systems or data flows have expanded the CDE",[16,2509,2510,2511,2513],{},"Scope reduction is not a one-time project. As your architecture evolves, new integrations, cloud migrations, and business changes can inadvertently expand the CDE. Building scope reviews into your change management process ensures that reductions remain effective over time and your ",[261,2512,392],{"href":391}," stay manageable.",{"title":267,"searchDepth":268,"depth":268,"links":2515},[2516,2517,2522,2529,2530],{"id":2192,"depth":268,"text":2193},{"id":2208,"depth":268,"text":2209,"children":2518},[2519,2520,2521],{"id":2215,"depth":662,"text":2216},{"id":2222,"depth":662,"text":2223},{"id":2229,"depth":662,"text":2230},{"id":2236,"depth":268,"text":2237,"children":2523},[2524,2525,2526,2527,2528],{"id":1331,"depth":662,"text":2240},{"id":2287,"depth":662,"text":2288},{"id":2332,"depth":662,"text":2333},{"id":2377,"depth":662,"text":2378},{"id":2415,"depth":662,"text":2416},{"id":2444,"depth":268,"text":2445},{"id":2477,"depth":268,"text":2478},"Strategies for reducing PCI DSS scope through network segmentation, tokenization, point-to-point encryption, and cardholder data environment management.",{"items":2533},[2534,2537,2540,2543],{"label":2535,"content":2536},"What is PCI DSS scope reduction?","Scope reduction is the practice of shrinking your cardholder data environment (CDE) through architectural changes like network segmentation, tokenization, and P2PE. A smaller CDE means fewer systems to assess, fewer controls to implement, and lower audit costs.",{"label":2538,"content":2539},"Does network segmentation remove systems from PCI scope?","Yes. Properly implemented network segmentation isolates the CDE on dedicated segments, preventing other systems from being classified as connected-to the CDE. Segmentation must be validated through penetration testing — every six months for service providers and annually for merchants.",{"label":2541,"content":2542},"Can tokenization eliminate PCI DSS requirements?","Tokenization removes systems that only handle tokens from PCI scope, since tokens are not cardholder data. However, the tokenization system itself (the token vault) remains in scope and must be PCI DSS compliant. The net effect is a dramatically smaller assessment footprint.",{"label":2544,"content":2545},"What is the fastest way to reduce PCI scope?","The quickest wins are outsourcing payment processing via hosted payment pages or iframes (potentially qualifying for SAQ A with only 22 questions) and implementing data minimization — deleting stored cardholder data you no longer need and truncating PANs to first six and last four digits.",{},[301,696],[305,1625,698],{"title":2550,"description":2551},"PCI DSS Scope Reduction: Network Segmentation, Tokenization & P2PE Guide","Reduce your PCI DSS audit scope and cost with network segmentation, tokenization, and P2PE. Practical strategies to minimize your cardholder data environment.","5.frameworks\u002Fpci\u002Fscope-reduction","VzMDMDIV4pDU3BgqGQmyJduhNJ7aCQrCZNKxAbJ2xjk",{"id":2555,"title":2556,"body":2557,"description":2909,"extension":279,"faq":1844,"frameworkSlug":294,"lastUpdated":295,"meta":2910,"navigation":297,"path":423,"relatedTerms":2911,"relatedTopics":2912,"seo":2913,"stem":2916,"__hash__":2917},"frameworkTopics\u002F5.frameworks\u002Fpci\u002Fself-assessment-questionnaire.md","PCI DSS Self-Assessment Questionnaire (SAQ)",{"type":8,"value":2558,"toc":2890},[2559,2563,2569,2575,2579,2582,2586,2589,2594,2608,2611,2615,2618,2622,2633,2636,2640,2643,2647,2661,2664,2668,2671,2675,2690,2693,2697,2700,2704,2716,2719,2723,2726,2731,2745,2748,2752,2755,2790,2794,2797,2801,2804,2808,2811,2837,2840,2844,2847,2851,2854,2858,2884],[11,2560,2562],{"id":2561},"what-is-a-pci-dss-self-assessment-questionnaire","What is a PCI DSS Self-Assessment Questionnaire?",[16,2564,2565,2566,2568],{},"The Self-Assessment Questionnaire (SAQ) is a validation tool provided by the PCI Security Standards Council for merchants and service providers who are not required to undergo a full on-site assessment by a Qualified Security Assessor (QSA). It allows organizations to self-evaluate their adherence to the ",[261,2567,392],{"href":391}," and report their compliance status to their acquiring bank or payment brand.",[16,2570,2571,2572,2574],{},"The SAQ is a critical component of ",[261,2573,331],{"href":263}," for the vast majority of merchants. While Level 1 merchants must complete a formal Report on Compliance (ROC), merchants at Levels 2 through 4 typically validate compliance through the appropriate SAQ type. Choosing the correct SAQ is one of the most important early decisions in your compliance journey.",[11,2576,2578],{"id":2577},"saq-types-and-eligibility","SAQ types and eligibility",[16,2580,2581],{},"The PCI SSC publishes several SAQ types, each tailored to a specific payment processing environment. Selecting the wrong SAQ can result in wasted effort or gaps in your compliance validation.",[338,2583,2585],{"id":2584},"saq-a-card-not-present-merchants-fully-outsourced","SAQ A - Card-not-present merchants (fully outsourced)",[16,2587,2588],{},"SAQ A is the shortest and simplest questionnaire. It applies to e-commerce or mail\u002Ftelephone-order merchants that have fully outsourced all cardholder data functions to PCI DSS-validated third-party service providers. Your website must not directly receive, process, store, or transmit cardholder data at any point.",[16,2590,2591],{},[64,2592,2593],{},"Eligibility criteria:",[33,2595,2596,2599,2602,2605],{},[36,2597,2598],{},"All payment processing is entirely outsourced to validated third parties",[36,2600,2601],{},"Your website does not receive cardholder data, even transiently",[36,2603,2604],{},"No electronic storage, processing, or transmission of cardholder data on your systems",[36,2606,2607],{},"You have confirmed your third-party providers are PCI DSS compliant",[16,2609,2610],{},"SAQ A contains approximately 22 questions and focuses primarily on policies, procedures, and service provider management.",[338,2612,2614],{"id":2613},"saq-a-ep-e-commerce-merchants-with-partial-outsourcing","SAQ A-EP - E-commerce merchants with partial outsourcing",[16,2616,2617],{},"SAQ A-EP applies to e-commerce merchants that outsource payment processing but whose website could still impact the security of the payment transaction. This commonly applies when your website hosts the payment page but uses an iframe or redirect to a third-party processor, or when your site includes scripts that could be manipulated to capture cardholder data.",[16,2619,2620],{},[64,2621,2593],{},[33,2623,2624,2627,2630],{},[36,2625,2626],{},"Payment processing is outsourced to a PCI DSS-validated third party",[36,2628,2629],{},"Your website does not receive cardholder data directly, but it can affect the security of the transaction",[36,2631,2632],{},"No electronic storage of cardholder data",[16,2634,2635],{},"SAQ A-EP is significantly longer than SAQ A, containing approximately 139 questions. It covers vulnerability scanning, penetration testing, and web application security, reflecting the risk that compromised website code could intercept payment data.",[338,2637,2639],{"id":2638},"saq-b-imprint-or-standalone-terminal-merchants","SAQ B - Imprint or standalone terminal merchants",[16,2641,2642],{},"SAQ B applies to merchants that process cardholder data only through imprint machines or standalone, dial-out payment terminals. These terminals must not be connected to the internet or any other systems in your environment.",[16,2644,2645],{},[64,2646,2593],{},[33,2648,2649,2652,2655,2658],{},[36,2650,2651],{},"Only imprint machines or standalone dial-out terminals are used",[36,2653,2654],{},"Terminals are not connected to the internet",[36,2656,2657],{},"No electronic cardholder data storage",[36,2659,2660],{},"No e-commerce channel",[16,2662,2663],{},"SAQ B contains approximately 41 questions and focuses primarily on physical security, terminal management, and policies.",[338,2665,2667],{"id":2666},"saq-c-merchants-with-payment-application-systems","SAQ C - Merchants with payment application systems",[16,2669,2670],{},"SAQ C applies to merchants that process cardholder data through payment application systems connected to the internet but do not store cardholder data electronically. This is common for brick-and-mortar retailers using point-of-sale systems with IP connectivity.",[16,2672,2673],{},[64,2674,2593],{},[33,2676,2677,2680,2683,2686,2688],{},[36,2678,2679],{},"Payment application system is connected to the internet for payment processing",[36,2681,2682],{},"Payment application system is not connected to any other systems within the environment",[36,2684,2685],{},"The physical store and POS environment are not connected to other locations",[36,2687,2657],{},[36,2689,2660],{},[16,2691,2692],{},"SAQ C contains approximately 160 questions and covers network segmentation, system hardening, access controls, and vulnerability management relevant to the payment application environment.",[338,2694,2696],{"id":2695},"saq-c-vt-virtual-terminal-merchants","SAQ C-VT - Virtual terminal merchants",[16,2698,2699],{},"SAQ C-VT is a variant for merchants that manually enter a single transaction at a time through a virtual terminal provided by a PCI DSS-validated third-party service provider. This applies to call center or mail-order operations where an operator keys in card data via a web browser.",[16,2701,2702],{},[64,2703,2593],{},[33,2705,2706,2709,2712,2714],{},[36,2707,2708],{},"Payment processing occurs only via a virtual terminal accessed through a web browser",[36,2710,2711],{},"The virtual terminal is provided by a PCI DSS-validated service provider",[36,2713,2657],{},[36,2715,2660],{},[16,2717,2718],{},"SAQ C-VT contains approximately 79 questions.",[338,2720,2722],{"id":2721},"saq-d-all-other-merchants-and-service-providers","SAQ D - All other merchants and service providers",[16,2724,2725],{},"SAQ D is the most comprehensive questionnaire and serves as the catch-all for any merchant or service provider that does not meet the eligibility criteria for the other SAQ types. SAQ D comes in two versions: SAQ D for Merchants and SAQ D for Service Providers.",[16,2727,2728],{},[64,2729,2730],{},"When SAQ D applies:",[33,2732,2733,2736,2739,2742],{},[36,2734,2735],{},"You store cardholder data electronically",[36,2737,2738],{},"You do not meet the eligibility criteria for any other SAQ type",[36,2740,2741],{},"Your acquiring bank or payment brand requires it",[36,2743,2744],{},"You are a service provider",[16,2746,2747],{},"SAQ D contains approximately 329 questions and covers all 12 PCI DSS requirements comprehensively. It essentially mirrors the scope of a full ROC assessment but is completed as a self-assessment.",[11,2749,2751],{"id":2750},"how-to-determine-your-saq-type","How to determine your SAQ type",[16,2753,2754],{},"Choosing the correct SAQ requires a thorough understanding of how cardholder data flows through your environment:",[59,2756,2757,2763,2769,2775,2781],{},[36,2758,2759,2762],{},[64,2760,2761],{},"Map your payment flows"," - Document exactly how cardholder data enters, moves through, and exits your environment. Include all channels: e-commerce, in-store, phone orders, and mobile.",[36,2764,2765,2768],{},[64,2766,2767],{},"Identify data touchpoints"," - Determine whether your systems receive, process, store, or transmit cardholder data at any stage.",[36,2770,2771,2774],{},[64,2772,2773],{},"Evaluate your technology"," - Assess whether you use outsourced payment pages, iframes, redirects, standalone terminals, virtual terminals, or payment applications.",[36,2776,2777,2780],{},[64,2778,2779],{},"Consult your acquirer"," - Your acquiring bank may have specific requirements or preferences regarding which SAQ type you should complete.",[36,2782,2783,2786,2787,2789],{},[64,2784,2785],{},"Consider scope reduction"," - Techniques like tokenization, point-to-point encryption (P2PE), and network segmentation can simplify your environment and potentially qualify you for a shorter SAQ. See ",[261,2788,593],{"href":592}," for more detail.",[11,2791,2793],{"id":2792},"completing-the-saq","Completing the SAQ",[16,2795,2796],{},"Once you have identified the correct SAQ type, the completion process involves several steps:",[338,2798,2800],{"id":2799},"gather-evidence","Gather evidence",[16,2802,2803],{},"For each applicable question, you will need to demonstrate that the corresponding control is in place. This includes policies, configuration screenshots, scan reports, access reviews, training records, and other artifacts. Automating evidence collection through a compliance platform reduces the time and effort required.",[338,2805,2807],{"id":2806},"answer-each-question","Answer each question",[16,2809,2810],{},"Every question in the SAQ requires one of four responses:",[33,2812,2813,2819,2825,2831],{},[36,2814,2815,2818],{},[64,2816,2817],{},"Yes"," - The control is fully in place",[36,2820,2821,2824],{},[64,2822,2823],{},"Yes with CCW"," - The control is in place with a compensating control worksheet",[36,2826,2827,2830],{},[64,2828,2829],{},"No"," - The control is not in place",[36,2832,2833,2836],{},[64,2834,2835],{},"N\u002FA"," - The question does not apply to your environment (with justification)",[16,2838,2839],{},"Any \"No\" response indicates a gap that must be remediated before you can attest to compliance.",[338,2841,2843],{"id":2842},"compensating-controls","Compensating controls",[16,2845,2846],{},"If you cannot meet a specific requirement as stated, PCI DSS allows compensating controls that mitigate the associated risk to an acceptable level. Compensating controls must be documented in a Compensating Control Worksheet and meet specific criteria: they must address the risk of the original requirement, provide a similar level of defense, and go above and beyond other PCI DSS requirements.",[338,2848,2850],{"id":2849},"attestation-of-compliance","Attestation of Compliance",[16,2852,2853],{},"After completing the SAQ, an authorized officer of the organization must sign the Attestation of Compliance (AOC), confirming the accuracy of the self-assessment. The completed SAQ and AOC are then submitted to your acquiring bank.",[11,2855,2857],{"id":2856},"common-pitfalls","Common pitfalls",[33,2859,2860,2866,2872,2878],{},[36,2861,2862,2865],{},[64,2863,2864],{},"Selecting the wrong SAQ type"," - Choosing a simpler SAQ than your environment warrants leaves gaps in your validation and may result in non-compliance findings.",[36,2867,2868,2871],{},[64,2869,2870],{},"Incomplete scoping"," - Failing to account for all payment channels, third-party integrations, or data flows leads to an inaccurate assessment.",[36,2873,2874,2877],{},[64,2875,2876],{},"Point-in-time mindset"," - The SAQ validates your compliance posture at a moment in time, but PCI DSS v4.0 emphasizes continuous compliance. Build processes that maintain controls year-round.",[36,2879,2880,2883],{},[64,2881,2882],{},"Ignoring third-party risk"," - Even with outsourced payment processing, you remain responsible for ensuring your service providers maintain their PCI DSS compliance.",[16,2885,2886,2887,2889],{},"Organizations in the ",[261,2888,612],{"href":611}," often manage complex payment flows across multiple channels, making SAQ selection and scoping particularly important. A well-structured compliance program with automated evidence collection helps ensure that the SAQ process is efficient and accurate.",{"title":267,"searchDepth":268,"depth":268,"links":2891},[2892,2893,2901,2902,2908],{"id":2561,"depth":268,"text":2562},{"id":2577,"depth":268,"text":2578,"children":2894},[2895,2896,2897,2898,2899,2900],{"id":2584,"depth":662,"text":2585},{"id":2613,"depth":662,"text":2614},{"id":2638,"depth":662,"text":2639},{"id":2666,"depth":662,"text":2667},{"id":2695,"depth":662,"text":2696},{"id":2721,"depth":662,"text":2722},{"id":2750,"depth":268,"text":2751},{"id":2792,"depth":268,"text":2793,"children":2903},[2904,2905,2906,2907],{"id":2799,"depth":662,"text":2800},{"id":2806,"depth":662,"text":2807},{"id":2842,"depth":662,"text":2843},{"id":2849,"depth":662,"text":2850},{"id":2856,"depth":268,"text":2857},"A guide to the PCI DSS Self-Assessment Questionnaire types, which SAQ applies to your business, and how to complete the process.",{},[301,696],[1625,305,307],{"title":2914,"description":2915},"PCI DSS Self-Assessment Questionnaire (SAQ) - Types and Guide","Learn which PCI DSS SAQ type applies to your business. Covers SAQ A, A-EP, B, C, and D with eligibility criteria and completion tips.","5.frameworks\u002Fpci\u002Fself-assessment-questionnaire","fozwUUWkod2HnMs8U2bAQeRSNlpEyMLo1qnB1s3dJZI",{"id":2919,"title":2920,"body":2921,"description":3177,"extension":279,"faq":3178,"frameworkSlug":294,"lastUpdated":295,"meta":3192,"navigation":297,"path":3193,"relatedTerms":3194,"relatedTopics":3198,"seo":3200,"stem":3203,"__hash__":3204},"frameworkTopics\u002F5.frameworks\u002Fpci\u002Ftokenization-vs-encryption.md","Tokenization vs Encryption for PCI DSS PAN Protection",{"type":8,"value":2922,"toc":3166},[2923,2927,2935,2938,2942,2945,2948,2968,2971,2975,2978,2981,3001,3004,3008,3011,3014,3028,3031,3035,3038,3058,3061,3065,3091,3094,3096,3099,3102,3104,3159,3161],[11,2924,2926],{"id":2925},"two-tools-two-problems","Two tools, two problems",[16,2928,2929,2930,2934],{},"Tokenization and encryption both protect the primary account number (",[261,2931,2933],{"href":2932},"\u002Fglossary\u002Fpan","PAN","), but they solve different PCI DSS problems. Encryption protects PAN that you still need to retain. Tokenization replaces PAN you do not need to retain with a non-sensitive surrogate. Mature PCI DSS programs use both: tokenize everywhere you can to shrink the cardholder data environment, and encrypt everywhere you must actually store PAN.",[16,2936,2937],{},"Under PCI DSS, this distinction matters for scope. A system that stores encrypted PAN is still in scope for PCI DSS because the ciphertext, when decrypted, is cardholder data. A system that stores only tokens is generally out of PCI DSS scope because tokens are not cardholder data -- provided the tokenization implementation meets the PCI SSC's guidance on token generation, mapping, and vault isolation. The scope implication is why tokenization is such a powerful lever in a PCI DSS program and why most CFOs quickly support tokenization projects even when the implementation cost looks high.",[11,2939,2941],{"id":2940},"how-pci-dss-encryption-works","How PCI DSS encryption works",[16,2943,2944],{},"PCI DSS Requirement 3 governs stored account data. Acceptable methods for rendering PAN unreadable include one-way hashing, truncation, strong cryptography with associated key management (encryption), and index tokens. Encryption is by far the most common -- AES-256 in authenticated modes is the baseline, with RSA or elliptic-curve key wrapping for key management.",[16,2946,2947],{},"Encryption as a PCI DSS control brings along a whole key-management program:",[33,2949,2950,2953,2956,2959,2962,2965],{},[36,2951,2952],{},"Unique keys per environment and purpose.",[36,2954,2955],{},"Documented key lifecycle -- generation, distribution, storage, rotation, retirement, and destruction.",[36,2957,2958],{},"Hardware security module (HSM) or equivalent cryptographic module for root keys.",[36,2960,2961],{},"Key custodians with documented responsibilities and signed key custodian agreements.",[36,2963,2964],{},"Annual cryptographic key rotation or a cryptoperiod driven by documented risk analysis.",[36,2966,2967],{},"Access controls that enforce dual control and split knowledge for the most sensitive keys.",[16,2969,2970],{},"All of this is covered by PCI DSS Requirement 3, with supporting testing in Requirements 8 (authentication) and 10 (logging). Encryption is the right tool when the business truly needs the PAN -- card-on-file payments for recurring billing, payment processors performing settlement, or issuers generating card numbers. Encryption does not take the encrypted data out of PCI DSS scope.",[11,2972,2974],{"id":2973},"how-pci-dss-tokenization-works","How PCI DSS tokenization works",[16,2976,2977],{},"Tokenization replaces a PAN with a surrogate value that has no exploitable mathematical relationship to the original. The mapping from token to PAN is stored in a separate, highly protected system called the token vault. Systems that need to process the PAN (payment gateways, fraud tools, issuer systems) talk to the token vault; every other system holds only the token.",[16,2979,2980],{},"A PCI DSS-compliant tokenization program typically has:",[33,2982,2983,2986,2989,2992,2995,2998],{},[36,2984,2985],{},"A centralized token vault operated either in-house on PCI-assessed infrastructure or by a PCI DSS-validated tokenization service provider.",[36,2987,2988],{},"Strong cryptographic or non-deterministic mapping so tokens cannot be reversed without the vault.",[36,2990,2991],{},"Unique tokens per PAN, or per PAN plus merchant, or per PAN plus purpose, depending on business need.",[36,2993,2994],{},"Access controls that limit detokenization to a narrow set of service identities and humans.",[36,2996,2997],{},"Logging of every detokenization event.",[36,2999,3000],{},"Documented procedures for token issuance, rotation, and invalidation.",[16,3002,3003],{},"Systems that only hold tokens and never interact with the vault can typically be treated as out of PCI DSS scope. In practice, those systems often include CRM platforms, analytics warehouses, order-management systems, customer support tools, email and marketing platforms, and much of the operational infrastructure that would otherwise be pulled into PCI DSS scope simply because it touches PAN. The net effect is often an order-of-magnitude reduction in the PCI DSS footprint.",[11,3005,3007],{"id":3006},"format-preserving-tokens","Format-preserving tokens",[16,3009,3010],{},"Some applications expect a value that looks like a PAN -- 16 digits, the right leading BIN, Luhn-valid. Format-preserving tokens (sometimes called FPE tokens) satisfy those constraints by producing surrogates that pass PAN-shape validation. Format-preserving tokens are popular for retrofitting tokenization into legacy systems that would otherwise need invasive schema changes.",[16,3012,3013],{},"Format-preserving tokens come with care-and-feeding issues:",[33,3015,3016,3019,3022,3025],{},[36,3017,3018],{},"They can be confused with real PANs by testers, developers, and incident responders. Clear documentation and distinct BIN ranges help.",[36,3020,3021],{},"They must not be trivially reversible -- format-preserving encryption (FPE) is different from format-preserving tokenization, and PCI DSS treats them differently.",[36,3023,3024],{},"Detection rules (DLP, log scrubbing) must handle format-preserving tokens differently from real PANs to avoid noise.",[36,3026,3027],{},"Logs and audit trails should clearly indicate whether a value is a token or a real PAN.",[16,3029,3030],{},"Used well, format-preserving tokens let you deploy tokenization without re-architecting systems. Used poorly, they recreate PCI DSS confusion.",[11,3032,3034],{"id":3033},"vault-management","Vault management",[16,3036,3037],{},"The token vault is the highest-value asset in a tokenization program. It sits squarely in the PCI DSS cardholder data environment and deserves the strongest controls in the program:",[33,3039,3040,3043,3046,3049,3052,3055],{},[36,3041,3042],{},"Dedicated network segment with the fewest possible connections in and out.",[36,3044,3045],{},"Strict allow-list of service identities and humans authorized to detokenize.",[36,3047,3048],{},"Hardware-backed cryptography for the vault's encryption keys.",[36,3050,3051],{},"Comprehensive logging of every token-to-PAN lookup.",[36,3053,3054],{},"Rate limiting and anomaly detection on detokenization requests -- a compromised service account that starts detokenizing at unusual volume is one of the clearest intrusion signals.",[36,3056,3057],{},"Robust disaster recovery and backup controls that preserve the confidentiality of the vault's contents.",[16,3059,3060],{},"Whether you run the vault yourself or buy from a tokenization service provider, you need evidence that these controls are in place. If you use a service provider, their PCI DSS AOC and Responsibility Matrix are required evidence.",[11,3062,3064],{"id":3063},"when-each-applies","When each applies",[33,3066,3067,3073,3079,3085],{},[36,3068,3069,3072],{},[64,3070,3071],{},"Tokenize"," everywhere PAN is not strictly needed for business function. This usually covers customer service tooling, CRM, analytics, marketing, order management, and most of your application stack.",[36,3074,3075,3078],{},[64,3076,3077],{},"Encrypt"," PAN in the systems that must retain it -- payment processors, settlement systems, recurring-billing engines, and the token vault itself.",[36,3080,3081,3084],{},[64,3082,3083],{},"Use P2PE"," for card-present environments to remove the merchant's internal network from PCI DSS scope entirely.",[36,3086,3087,3090],{},[64,3088,3089],{},"Truncate or hash"," PAN where you only need the last four or a reference value -- receipts, reports, analytics dashboards. Truncation is free scope reduction.",[16,3092,3093],{},"The strategic question is rarely \"tokenize or encrypt\" but \"how do we combine tokenization, encryption, truncation, and P2PE to arrive at the smallest possible PCI DSS scope with the strongest possible protection.\"",[11,3095,192],{"id":191},[16,3097,3098],{},"Tokenization and encryption interact with a majority of PCI DSS requirements. Requirement 3 covers stored account data protection. Requirement 4 covers PAN transmitted over open, public networks. Requirement 6 covers the secure development of the tokenization and encryption systems themselves. Requirement 7 and 8 cover access to the token vault and to decryption keys. Requirement 10 covers logging of detokenization and key use. Requirement 11 validates that the controls actually work.",[16,3100,3101],{},"Most importantly, tokenization directly affects PCI DSS scoping -- and scope drives everything else in the PCI DSS program. A solid tokenization rollout is often the single highest-ROI PCI DSS investment a program can make, because it compounds across every subsequent control, every subsequent assessment, and every subsequent ASV scan.",[11,3103,202],{"id":201},[33,3105,3106,3112,3118,3124,3130,3136,3142,3147,3153],{},[36,3107,3108,3111],{},[64,3109,3110],{},"Treating encryption as scope reduction."," Encrypted PAN is still cardholder data and the system remains in PCI DSS scope.",[36,3113,3114,3117],{},[64,3115,3116],{},"Shipping tokens alongside PAN in logs or analytics"," because the application is not consistently tokenizing on the way in.",[36,3119,3120,3123],{},[64,3121,3122],{},"Deploying format-preserving tokens without distinguishing them from real PANs",", leading to confusion during investigation.",[36,3125,3126,3129],{},[64,3127,3128],{},"Leaving legacy databases with residual PAN"," after a tokenization rollout, creating PCI DSS findings years later.",[36,3131,3132,3135],{},[64,3133,3134],{},"Weak key management"," that puts encryption controls out of compliance with PCI DSS Requirement 3.6 and 3.7.",[36,3137,3138,3141],{},[64,3139,3140],{},"Running the token vault on shared infrastructure"," that lacks the segmentation and hardening PCI DSS expects.",[36,3143,3144],{},[64,3145,3146],{},"Relying on a tokenization service provider without confirming their PCI DSS validation and Responsibility Matrix.",[36,3148,3149,3152],{},[64,3150,3151],{},"Skipping detokenization rate limiting",", leaving the vault vulnerable to bulk extraction through a compromised service account.",[36,3154,3155,3158],{},[64,3156,3157],{},"Tokenizing only the happy path"," and leaving batch jobs, exports, or backup pipelines handling real PAN.",[11,3160,256],{"id":255},[16,3162,3163,3164,265],{},"episki maps your tokenization and encryption controls to every affected PCI DSS requirement, collects evidence from vaults and HSMs, and flags drift before your QSA does. We make it easy to prove to an assessor that tokens stay tokens, keys are managed, and the vault is airtight. Learn more on the ",[261,3165,264],{"href":263},{"title":267,"searchDepth":268,"depth":268,"links":3167},[3168,3169,3170,3171,3172,3173,3174,3175,3176],{"id":2925,"depth":268,"text":2926},{"id":2940,"depth":268,"text":2941},{"id":2973,"depth":268,"text":2974},{"id":3006,"depth":268,"text":3007},{"id":3033,"depth":268,"text":3034},{"id":3063,"depth":268,"text":3064},{"id":191,"depth":268,"text":192},{"id":201,"depth":268,"text":202},{"id":255,"depth":268,"text":256},"Tokenization vs encryption for protecting the primary account number (PAN) under PCI DSS — when each applies, vault management, format-preserving tokens, and scope impact.",{"items":3179},[3180,3183,3186,3189],{"label":3181,"content":3182},"Does tokenization remove data from PCI DSS scope?","Systems that only handle tokens are generally out of PCI DSS scope because tokens are not cardholder data. The token vault itself remains in scope and must be PCI DSS compliant. Tokenization does not eliminate PCI DSS — it reduces the footprint significantly.",{"label":3184,"content":3185},"Is encryption alone sufficient for PCI DSS PAN protection?","Encryption satisfies PCI DSS Requirement 3.5 for protecting stored PAN, but it does not remove the encrypted data from scope. Every system that stores, processes, or transmits the encrypted PAN remains in scope, along with all systems involved in key management.",{"label":3187,"content":3188},"What is a format-preserving token?","A format-preserving token is a surrogate value that looks like a PAN — same length, same leading digits, same Luhn validity — so it can flow through systems that expect a real card number. Format-preserving tokens must be clearly distinguishable from real PANs during testing and investigation to avoid confusion.",{"label":3190,"content":3191},"Which is better for PCI DSS — tokenization or encryption?","They solve different problems. Tokenization is about scope reduction: remove PAN data from systems that do not need it. Encryption is about protection: secure PAN data in systems that must retain it. Most mature PCI DSS programs use both, tokenizing everywhere they can and encrypting everywhere they must store PAN.",{},"\u002Fframeworks\u002Fpci\u002Ftokenization-vs-encryption",[2287,3195,301,3196,3197],"pan","encryption","key-management",[307,305,1331,3199],"saq-types-explained",{"title":3201,"description":3202},"Tokenization vs Encryption for PCI DSS: PAN Protection Compared","Compare tokenization and encryption for PCI DSS PAN protection. Learn when to use each, how token vaults work, format-preserving tokens, and the impact on PCI DSS scope.","5.frameworks\u002Fpci\u002Ftokenization-vs-encryption","G8BDoH76VayKEaIUTnuuGD0hRsBi7OXVbd1sK9vWLus",{"id":3206,"title":3207,"body":3208,"description":3543,"extension":279,"faq":1844,"frameworkSlug":294,"lastUpdated":295,"meta":3544,"navigation":297,"path":1801,"relatedTerms":3545,"relatedTopics":3546,"seo":3547,"stem":3550,"__hash__":3551},"frameworkTopics\u002F5.frameworks\u002Fpci\u002Fv4-changes.md","PCI DSS v4.0 Changes",{"type":8,"value":3209,"toc":3525},[3210,3214,3217,3223,3227,3231,3234,3240,3245,3248,3262,3265,3268,3271,3285,3288,3292,3296,3299,3313,3316,3320,3323,3327,3330,3344,3347,3351,3354,3358,3361,3365,3368,3372,3375,3449,3452,3456,3459,3470,3477,3481,3484,3520],[11,3211,3213],{"id":3212},"the-transition-from-v321-to-v40","The transition from v3.2.1 to v4.0",[16,3215,3216],{},"PCI DSS v4.0 was published in March 2022 and represents the most significant update to the standard since its inception. The PCI Security Standards Council designed v4.0 to address the evolving threat landscape, accommodate modern security technologies, and shift the compliance mindset from point-in-time validation to continuous security.",[16,3218,3219,3220,3222],{},"PCI DSS v3.2.1 was retired on March 31, 2024. All assessments conducted after that date must use PCI DSS v4.0. Additionally, a set of future-dated requirements originally designated as best practices became mandatory on March 31, 2025. Organizations that have not already adapted their ",[261,3221,331],{"href":263}," programs to v4.0 face immediate compliance gaps.",[11,3224,3226],{"id":3225},"key-structural-changes","Key structural changes",[338,3228,3230],{"id":3229},"the-customized-approach","The customized approach",[16,3232,3233],{},"The most significant structural change in PCI DSS v4.0 is the introduction of the customized approach as a formal validation method. Under v3.2.1, organizations had two options: meet the defined requirement as stated or implement a compensating control. PCI DSS v4.0 adds a third path.",[16,3235,3236,3239],{},[64,3237,3238],{},"Defined approach"," - Meet the requirement exactly as stated, using the prescribed testing procedures. This is the traditional approach and remains available for all requirements.",[16,3241,3242,3244],{},[64,3243,1770],{}," - Meet the stated security objective of a requirement using alternative controls or methods that the organization designs. The assessor validates that the customized implementation achieves the same security outcome as the defined requirement.",[16,3246,3247],{},"The customized approach provides flexibility for organizations with mature security programs that have implemented innovative controls not contemplated by the prescriptive requirements. However, it comes with additional documentation requirements:",[33,3249,3250,3253,3256,3259],{},[36,3251,3252],{},"A controls matrix documenting how the custom implementation meets the security objective",[36,3254,3255],{},"A targeted risk analysis supporting the approach",[36,3257,3258],{},"Testing procedures defined by the assessor to validate the implementation",[36,3260,3261],{},"More detailed documentation than the defined approach requires",[16,3263,3264],{},"The customized approach is not available for all requirements. Certain foundational requirements, such as not storing sensitive authentication data after authorization, must be met using the defined approach.",[338,3266,1776],{"id":3267},"targeted-risk-analysis",[16,3269,3270],{},"PCI DSS v4.0 introduces a formal targeted risk analysis methodology that allows organizations to determine the appropriate frequency for certain recurring activities. Under v3.2.1, many frequencies were prescriptively defined (for example, quarterly reviews). Under v4.0, organizations can perform a documented risk analysis to justify different frequencies for activities such as:",[33,3272,3273,3276,3279,3282],{},[36,3274,3275],{},"Log review frequency",[36,3277,3278],{},"Password change intervals",[36,3280,3281],{},"Detection mechanism alert tuning",[36,3283,3284],{},"Review of user accounts and access privileges",[16,3286,3287],{},"Each targeted risk analysis must be documented, approved by management, and reviewed at least annually. The analysis must consider threat likelihood, potential impact, and the effectiveness of existing controls. This approach acknowledges that a one-size-fits-all frequency may not be appropriate for every organization.",[11,3289,3291],{"id":3290},"new-and-expanded-requirements","New and expanded requirements",[338,3293,3295],{"id":3294},"multi-factor-authentication-expansion","Multi-factor authentication expansion",[16,3297,3298],{},"PCI DSS v3.2.1 required multi-factor authentication (MFA) for remote access to the CDE and for non-console administrative access. PCI DSS v4.0 expands MFA requirements significantly:",[33,3300,3301,3304,3307,3310],{},[36,3302,3303],{},"MFA is now required for all access into the cardholder data environment, not just remote access",[36,3305,3306],{},"This applies to all personnel, not just administrators",[36,3308,3309],{},"MFA systems must be resistant to replay attacks and cannot be bypassed by any user, including administrators, without explicit exception documentation",[36,3311,3312],{},"MFA implementations must use at least two different authentication factors (something you know, something you have, something you are)",[16,3314,3315],{},"This change reflects the reality that credential theft is a leading attack vector and that internal network access alone should not be sufficient to reach cardholder data systems.",[338,3317,3319],{"id":3318},"enhanced-password-requirements","Enhanced password requirements",[16,3321,3322],{},"Minimum password length increased from 7 characters to 12 characters (or 8 characters if the system cannot support 12). PCI DSS v4.0 also encourages the use of passphrases and reduces the emphasis on forced periodic password changes when other compensating controls (such as MFA) are in place. This aligns with modern guidance from NIST SP 800-63B.",[338,3324,3326],{"id":3325},"e-commerce-and-payment-page-protections","E-commerce and payment page protections",[16,3328,3329],{},"PCI DSS v4.0 added multiple requirements targeting e-commerce security, driven by the rise of Magecart-style attacks that inject malicious scripts into payment pages:",[33,3331,3332,3338],{},[36,3333,3334,3337],{},[64,3335,3336],{},"Requirement 6.4.3"," - All payment page scripts that are loaded and executed in the consumer's browser must be managed. Organizations must maintain an inventory of scripts, justify each script's presence, and implement a method to ensure script integrity.",[36,3339,3340,3343],{},[64,3341,3342],{},"Requirement 11.6.1"," - A change and tamper detection mechanism must monitor payment pages for unauthorized modifications. HTTP headers and scripts on payment pages must be evaluated for changes at least weekly or through an automated mechanism.",[16,3345,3346],{},"These requirements apply to any organization whose website hosts or influences payment pages, even if actual card data processing is outsourced to a third party.",[338,3348,3350],{"id":3349},"anti-phishing-mechanisms","Anti-phishing mechanisms",[16,3352,3353],{},"Requirement 5.4.1 introduced an explicit mandate for mechanisms to detect and protect personnel against phishing attacks. This includes technical controls such as email filtering, link analysis, and domain-based authentication (DMARC, DKIM, SPF), along with security awareness training specifically addressing phishing threats.",[338,3355,3357],{"id":3356},"automated-log-review","Automated log review",[16,3359,3360],{},"Requirement 10.4.1.1 introduced automated mechanisms for performing audit log reviews. While v3.2.1 allowed manual log review processes, v4.0 acknowledges that the volume and velocity of modern log data makes manual review impractical. Organizations should implement SIEM solutions or equivalent tools that can automatically detect anomalies and generate alerts.",[338,3362,3364],{"id":3363},"encryption-and-key-management-updates","Encryption and key management updates",[16,3366,3367],{},"PCI DSS v4.0 strengthened requirements around encryption, clarifying that disk-level or partition-level encryption alone is no longer acceptable for protecting stored cardholder data on electronic media (Requirement 3.5.1.2). This requirement specifically targets environments that relied solely on full-disk encryption solutions like BitLocker or FileVault without additional application-layer encryption.",[11,3369,3371],{"id":3370},"future-dated-requirements-now-mandatory","Future-dated requirements now mandatory",[16,3373,3374],{},"Several requirements in PCI DSS v4.0 were initially classified as best practices with a future effective date of March 31, 2025. These are now mandatory for all assessments:",[33,3376,3377,3383,3389,3395,3401,3407,3413,3419,3425,3431,3437,3443],{},[36,3378,3379,3382],{},[64,3380,3381],{},"Req 3.5.1.2"," - Disk-level encryption restrictions for removable electronic media",[36,3384,3385,3388],{},[64,3386,3387],{},"Req 5.3.3"," - Anti-malware scans for removable electronic media",[36,3390,3391,3394],{},[64,3392,3393],{},"Req 5.4.1"," - Anti-phishing mechanisms",[36,3396,3397,3400],{},[64,3398,3399],{},"Req 6.4.3"," - Payment page script management and integrity",[36,3402,3403,3406],{},[64,3404,3405],{},"Req 7.2.5"," - Application and system account access review",[36,3408,3409,3412],{},[64,3410,3411],{},"Req 8.3.6"," - Minimum 12-character passwords",[36,3414,3415,3418],{},[64,3416,3417],{},"Req 8.4.2"," - MFA for all CDE access",[36,3420,3421,3424],{},[64,3422,3423],{},"Req 8.6.3"," - Passwords for application and system accounts managed per defined criteria",[36,3426,3427,3430],{},[64,3428,3429],{},"Req 10.4.1.1"," - Automated log review mechanisms",[36,3432,3433,3436],{},[64,3434,3435],{},"Req 10.7.2"," - Detection and alerting for critical security control failures",[36,3438,3439,3442],{},[64,3440,3441],{},"Req 11.6.1"," - Payment page change and tamper detection",[36,3444,3445,3448],{},[64,3446,3447],{},"Req 12.3.1"," - Targeted risk analysis documentation for flexible requirement frequencies",[16,3450,3451],{},"Organizations that deferred these requirements during the transition period must now have them fully implemented and operational.",[11,3453,3455],{"id":3454},"impact-on-saqs-and-compliance-levels","Impact on SAQs and compliance levels",[16,3457,3458],{},"PCI DSS v4.0 updated all SAQ types to reflect the new and modified requirements. Key changes for self-assessing merchants include:",[33,3460,3461,3464,3467],{},[36,3462,3463],{},"SAQ A-EP now includes questions related to payment page script management and integrity monitoring",[36,3465,3466],{},"SAQ C and SAQ D incorporate the expanded MFA and password requirements",[36,3468,3469],{},"All SAQ types reflect the updated requirement numbering and language",[16,3471,3472,3473,3476],{},"For organizations at different ",[261,3474,3475],{"href":694},"PCI DSS compliance levels",", the impact varies. Level 1 merchants undergoing ROC assessments face the most comprehensive changes, while Level 4 merchants using SAQ A may see minimal impact if their payment processing is fully outsourced.",[11,3478,3480],{"id":3479},"preparing-for-ongoing-compliance","Preparing for ongoing compliance",[16,3482,3483],{},"The shift in PCI DSS v4.0 toward continuous security rather than annual compliance validation requires organizations to rethink their approach:",[33,3485,3486,3492,3498,3504,3514],{},[36,3487,3488,3491],{},[64,3489,3490],{},"Build monitoring into daily operations"," rather than scrambling before assessments",[36,3493,3494,3497],{},[64,3495,3496],{},"Automate evidence collection"," to maintain continuous compliance readiness",[36,3499,3500,3503],{},[64,3501,3502],{},"Invest in targeted risk analysis"," documentation as a core compliance activity",[36,3505,3506,3509,3510,3513],{},[64,3507,3508],{},"Review and update scope"," regularly, leveraging ",[261,3511,3512],{"href":592},"scope reduction"," strategies to minimize the compliance burden",[36,3515,3516,3519],{},[64,3517,3518],{},"Train teams"," on the new requirements, particularly around script management and MFA changes",[16,3521,2886,3522,3524],{},[261,3523,612],{"href":611}," that handle payment data should treat the v4.0 transition as an opportunity to mature their security programs. The flexibility offered by the customized approach and targeted risk analysis rewards organizations that invest in understanding their threat landscape and building security controls tailored to their specific risks.",{"title":267,"searchDepth":268,"depth":268,"links":3526},[3527,3528,3532,3540,3541,3542],{"id":3212,"depth":268,"text":3213},{"id":3225,"depth":268,"text":3226,"children":3529},[3530,3531],{"id":3229,"depth":662,"text":3230},{"id":3267,"depth":662,"text":1776},{"id":3290,"depth":268,"text":3291,"children":3533},[3534,3535,3536,3537,3538,3539],{"id":3294,"depth":662,"text":3295},{"id":3318,"depth":662,"text":3319},{"id":3325,"depth":662,"text":3326},{"id":3349,"depth":662,"text":3350},{"id":3356,"depth":662,"text":3357},{"id":3363,"depth":662,"text":3364},{"id":3370,"depth":268,"text":3371},{"id":3454,"depth":268,"text":3455},{"id":3479,"depth":268,"text":3480},"A comprehensive overview of the key changes from PCI DSS v3.2.1 to v4.0, including new requirements, the customized approach, and the transition timeline.",{},[301,696],[305,1625,698],{"title":3548,"description":3549},"PCI DSS v4.0 Changes - What's New from v3.2.1 to v4.0","Key changes in PCI DSS v4.0 including the customized approach, expanded MFA, e-commerce protections, and transition timeline from v3.2.1.","5.frameworks\u002Fpci\u002Fv4-changes","rydeRDOBvcQ4xyt3B5VsbQT5QlreXALBiFnGLa7oCUo",{"id":3553,"title":3554,"advantages":3555,"body":3577,"checklist":3980,"cta":3989,"description":267,"extension":279,"faq":3992,"hero":4010,"meta":4026,"name":3589,"navigation":297,"path":263,"resources":4027,"seo":4040,"slug":294,"stats":4043,"stem":4053,"__hash__":4054},"frameworks\u002F5.frameworks\u002Fpci.md","Pci",[3556,3563,3570],{"title":3557,"description":3558,"bullets":3559},"Cardholder data mapped","Visualize systems, networks, and data flows tied to each DSS requirement.",[3560,3561,3562],"Track segmentation documentation and approvals","Connect SIEM and log tools for retention evidence","Link vulnerability scans and pen tests to controls",{"title":3564,"description":3565,"bullets":3566},"Task orchestration for engineering","Send prioritized remediation tasks to Jira or Linear with context.",[3567,3568,3569],"Auto-created tickets with required evidence","SLA tracking ensures high-risk remediations close on time","Change management logs sync back automatically",{"title":3571,"description":3572,"bullets":3573},"QSA-ready collaboration","Centralize requests, walkthroughs, and findings with secure file sharing.",[3574,3575,3576],"QSA comments resolve next to each control","Expiring links for sensitive diagrams","Exportable ROC narrative drafts",{"type":8,"value":3578,"toc":3967},[3579,3583,3591,3594,3597,3601,3608,3693,3696,3699,3705,3709,3721,3725,3733,3787,3798,3802,3813,3816,3819,3821,3834,3838,3841,3877,3884,3888,3891,3895,3907,3911,3914,3964],[11,3580,3582],{"id":3581},"what-is-pci-dss","What is PCI DSS?",[16,3584,3585,3586,3590],{},"The Payment Card Industry Data Security Standard -- universally known as ",[261,3587,3589],{"href":3588},"\u002Fglossary\u002Fpci-dss","PCI DSS"," -- is the global baseline for protecting payment card data. Any organization that stores, processes, or transmits cardholder data is expected to meet PCI DSS, from a mom-and-pop e-commerce store to a Fortune 500 retailer and every payment processor in between. PCI DSS exists because card data is one of the most monetizable targets on the internet, and a single breach can expose millions of account numbers, trigger steep fines, and end businesses. PCI DSS translates decades of hard-won lessons into a prescriptive framework that security, engineering, and finance teams can operationalize.",[16,3592,3593],{},"PCI DSS is maintained by the Payment Card Industry Security Standards Council (PCI SSC), an independent standards body founded in 2006 by the five major payment brands: Visa, Mastercard, American Express, Discover, and JCB. The PCI SSC writes and publishes the standard, accredits assessors and scanning vendors, and runs supporting programs such as PA-DSS (now replaced by the PCI Secure Software Standard) and P2PE. While the PCI SSC owns the standard itself, it does not enforce PCI DSS. Enforcement is delegated to the card brands, which in turn push obligations down through acquiring banks and payment processors to merchants and service providers. In practice, your acquirer is the entity that tells you which PCI DSS validation path you owe and what happens if you fail it.",[16,3595,3596],{},"PCI DSS emerged from a patchwork of brand-specific programs in the early 2000s, including Visa's Cardholder Information Security Program (CISP) and Mastercard's Site Data Protection (SDP). PCI DSS v1.0 launched in December 2004. PCI DSS v2.0 arrived in 2010, v3.0 in 2013, v3.1 in 2015, v3.2 in 2016, v3.2.1 in 2018, and the long-anticipated PCI DSS v4.0 in March 2022, followed by v4.0.1 clarifications in June 2024. Organizations have until March 31, 2025 to fully meet the new \"future-dated\" PCI DSS v4.0 requirements. Each revision tightens controls around emerging threats: phishing-resistant authentication, e-commerce script tampering, automated log review, and customized approaches for mature security programs.",[11,3598,3600],{"id":3599},"the-12-pci-dss-requirements","The 12 PCI DSS requirements",[16,3602,3603,3604,3607],{},"PCI DSS organizes technical and operational controls across twelve core requirements grouped into six objectives. The full set of PCI DSS requirements is detailed on the ",[261,3605,3606],{"href":391},"PCI DSS requirements page","; at a glance they are:",[59,3609,3610,3620,3626,3639,3645,3651,3657,3663,3669,3675,3681,3687],{},[36,3611,3612,3615,3616,265],{},[64,3613,3614],{},"Install and maintain network security controls"," -- firewalls and equivalent controls around the ",[261,3617,3619],{"href":3618},"\u002Fglossary\u002Fcardholder-data-environment","cardholder data environment",[36,3621,3622,3625],{},[64,3623,3624],{},"Apply secure configurations to all system components"," -- hardening standards, default credential elimination, and secure build baselines.",[36,3627,3628,3631,3632,3635,3636,3638],{},[64,3629,3630],{},"Protect stored account data"," -- encryption, truncation, hashing, or ",[261,3633,2287],{"href":3634},"\u002Fglossary\u002Ftokenization"," of the ",[261,3637,2933],{"href":2932}," and prohibition on storing sensitive authentication data.",[36,3640,3641,3644],{},[64,3642,3643],{},"Protect cardholder data with strong cryptography during transmission"," over open, public networks.",[36,3646,3647,3650],{},[64,3648,3649],{},"Protect all systems and networks from malicious software"," -- anti-malware on in-scope systems and defenses against script-based threats.",[36,3652,3653,3656],{},[64,3654,3655],{},"Develop and maintain secure systems and software"," -- secure SDLC, patching, and vulnerability management for in-scope systems.",[36,3658,3659,3662],{},[64,3660,3661],{},"Restrict access to system components and cardholder data by business need to know"," -- least-privilege role design.",[36,3664,3665,3668],{},[64,3666,3667],{},"Identify users and authenticate access to system components"," -- unique IDs, strong authentication, and phishing-resistant MFA.",[36,3670,3671,3674],{},[64,3672,3673],{},"Restrict physical access to cardholder data"," -- physical security for facilities, media, and devices.",[36,3676,3677,3680],{},[64,3678,3679],{},"Log and monitor all access to system components and cardholder data"," -- centralized logging, daily review, and tamper protection.",[36,3682,3683,3686],{},[64,3684,3685],{},"Test security of systems and networks regularly"," -- ASV scans, internal scans, pen tests, and segmentation validation.",[36,3688,3689,3692],{},[64,3690,3691],{},"Support information security with organizational policies and programs"," -- governance, awareness, incident response, and third-party oversight.",[16,3694,3695],{},"Each PCI DSS requirement is broken into numbered sub-requirements with explicit testing procedures that an assessor follows line by line. The \"defined approach\" dictates specific controls; PCI DSS v4.0 also introduces a \"customized approach\" where mature organizations can meet a requirement's objective through alternative controls, documented in a controls matrix and targeted risk analysis.",[11,3697,1802],{"id":3698},"pci-dss-v40-changes",[16,3700,3701,3702,265],{},"PCI DSS v4.0 is the largest revision in more than a decade. Its headline shifts include a customized-approach validation path, mandatory multi-factor authentication for all access into the CDE, expanded requirements to detect and respond to e-commerce script tampering, targeted risk analyses replacing prescriptive frequencies, and stronger expectations for continuous security rather than point-in-time compliance. Several of the most material v4.0 controls became mandatory on March 31, 2025 after a two-year grace period. The full changelog, new testing procedures, and a migration checklist are covered in the ",[261,3703,3704],{"href":1801},"PCI DSS v4.0 changes guide",[11,3706,3708],{"id":3707},"merchant-compliance-levels-1-4","Merchant compliance levels 1-4",[16,3710,3711,3712,3716,3717,3720],{},"Every merchant is assigned to one of four PCI DSS compliance levels based on annual card transaction volume across all channels. PCI DSS Level 1 covers merchants processing more than 6 million transactions per year and requires a formal Report on Compliance (ROC) signed by a ",[261,3713,3715],{"href":3714},"\u002Fglossary\u002Fqsa","QSA",". Level 2 covers 1-6 million transactions. Level 3 covers 20,000 to 1 million e-commerce transactions. Level 4 covers everything below those thresholds. Service providers have their own two-level structure. Your acquiring bank can also assign you a higher PCI DSS level at its discretion -- particularly after a breach. The ",[261,3718,3719],{"href":694},"PCI DSS compliance levels page"," breaks down every threshold by card brand and the validation path each level owes.",[11,3722,3724],{"id":3723},"self-assessment-questionnaires-saqs","Self-Assessment Questionnaires (SAQs)",[16,3726,3727,3728,3732],{},"Merchants and service providers that are not required to complete a full PCI DSS Report on Compliance validate using a ",[261,3729,3731],{"href":3730},"\u002Fglossary\u002Fsaq","Self-Assessment Questionnaire",", or SAQ. The PCI SSC publishes nine SAQ types, each tailored to a specific acceptance channel and technology profile:",[33,3734,3735,3741,3747,3753,3759,3765,3771,3777],{},[36,3736,3737,3740],{},[64,3738,3739],{},"SAQ A"," -- card-not-present merchants that fully outsource all cardholder data functions.",[36,3742,3743,3746],{},[64,3744,3745],{},"SAQ A-EP"," -- e-commerce merchants that partially outsource payment processing but host pages that could affect payment page security.",[36,3748,3749,3752],{},[64,3750,3751],{},"SAQ B"," -- merchants using only imprint machines or standalone dial-out terminals.",[36,3754,3755,3758],{},[64,3756,3757],{},"SAQ B-IP"," -- merchants using only standalone IP-connected POI devices.",[36,3760,3761,3764],{},[64,3762,3763],{},"SAQ C-VT"," -- merchants entering transactions into a virtual payment terminal.",[36,3766,3767,3770],{},[64,3768,3769],{},"SAQ C"," -- merchants with payment application systems connected to the internet.",[36,3772,3773,3776],{},[64,3774,3775],{},"SAQ P2PE"," -- merchants using PCI-listed point-to-point encryption solutions.",[36,3778,3779,3782,3783,3786],{},[64,3780,3781],{},"SAQ D for Merchants"," and ",[64,3784,3785],{},"SAQ D for Service Providers"," -- the catch-all SAQs for entities that store cardholder data or do not qualify for a simpler SAQ.",[16,3788,3789,3790,3793,3794,3797],{},"Eligibility is narrow and precise. Picking the wrong SAQ is one of the most common PCI DSS mistakes -- and one that an acquiring bank or breach investigation can expose instantly. The ",[261,3791,3792],{"href":423},"SAQ reference"," and the ",[261,3795,3796],{"href":2177},"SAQ types explained"," page walk through each SAQ's eligibility, question count, and typical pitfalls.",[11,3799,3801],{"id":3800},"cardholder-data-environment-cde-and-scoping","Cardholder data environment (CDE) and scoping",[16,3803,3804,3805,3807,3808,3812],{},"Every PCI DSS program begins with scoping. The ",[261,3806,3619],{"href":3618},", or CDE, is the set of people, processes, and technologies that store, process, or transmit cardholder data or sensitive authentication data, plus any system component that is connected to or could impact the security of those components. Determining what is in ",[261,3809,3811],{"href":3810},"\u002Fglossary\u002Fpci-scope","PCI scope"," is the single highest-leverage activity in a PCI DSS program -- it drives how many controls apply, how much evidence you collect, and how much your QSA engagement costs.",[16,3814,3815],{},"PCI DSS scoping has three categories: CDE systems that directly handle card data; connected-to systems that can route traffic to the CDE, authenticate CDE users, or otherwise interact with CDE components; and security-impacting systems that could affect CDE security even without direct connectivity (think SIEM, patch management, or anti-malware consoles). All three categories are in scope for PCI DSS.",[16,3817,3818],{},"Document your CDE with an annotated network diagram and a data-flow diagram for every payment channel. PCI DSS v4.0 makes these diagrams a requirement, not a nice-to-have, and your assessor will test them during every assessment.",[11,3820,2237],{"id":2236},[16,3822,3823,3824,3826,3827,3830,3831,3833],{},"Because PCI DSS obligations scale with the CDE, shrinking the CDE is the fastest way to cut PCI DSS cost and risk. Effective ",[261,3825,593],{"href":592}," typically combines four levers: strong ",[261,3828,3829],{"href":1065},"network segmentation"," that isolates the CDE onto dedicated VLANs with tightly controlled firewall rules; ",[261,3832,2287],{"href":3193}," that replaces stored PANs with non-sensitive surrogates; PCI-listed point-to-point encryption (P2PE) that removes in-store networks from PCI scope; and outsourcing card capture to a validated service provider so your systems never touch real card data. Layered correctly, these strategies can reduce a PCI DSS assessment from hundreds of in-scope systems to a handful.",[11,3835,3837],{"id":3836},"key-pci-dss-roles-qsas-asvs-and-isas","Key PCI DSS roles: QSAs, ASVs, and ISAs",[16,3839,3840],{},"Three accredited roles support every PCI DSS program:",[33,3842,3843,3857,3871],{},[36,3844,3845,3852,3853,3856],{},[64,3846,3847,3848,3851],{},"Qualified Security Assessors (",[261,3849,3850],{"href":3714},"QSAs",")"," -- individuals and firms certified by the PCI SSC to perform on-site PCI DSS assessments, produce the ROC, and sign the Attestation of Compliance. Selecting the right QSA shapes your PCI DSS experience for years; the ",[261,3854,3855],{"href":1620},"QSA selection guide"," covers how to evaluate firms, cost drivers, and red flags.",[36,3858,3859,3866,3867,3870],{},[64,3860,3861,3862,3851],{},"Approved Scanning Vendors (",[261,3863,3865],{"href":3864},"\u002Fglossary\u002Fasv","ASVs"," -- PCI SSC-approved firms that run the quarterly external vulnerability scans required by PCI DSS Requirement 11.3.2. The ",[261,3868,3869],{"href":298},"ASV program guide"," covers vendor selection, scanning cadence, passing thresholds, and remediation workflows.",[36,3872,3873,3876],{},[64,3874,3875],{},"Internal Security Assessors (ISAs)"," -- employees who have completed PCI SSC training and can complete certain internal PCI DSS assessments or support a QSA engagement. ISAs are a cost-effective way to build PCI DSS capability inside large programs.",[16,3878,3879,3880,3883],{},"Penetration testing (Requirement 11.4) sits alongside ASV scanning and is a frequent source of PCI DSS findings. The ",[261,3881,3882],{"href":1327},"PCI DSS penetration testing guide"," covers internal vs external scope, segmentation testing, and frequency.",[11,3885,3887],{"id":3886},"penalties-for-non-compliance","Penalties for non-compliance",[16,3889,3890],{},"PCI DSS is not law, but non-compliance carries material financial consequences. Acquirers can levy fines of $5,000 to $100,000 per month for PCI DSS violations, pass fines down to merchants, raise transaction fees, or revoke payment processing privileges outright. After a confirmed breach of card data, a merchant typically faces a forensic PFI investigation, card brand fines, assessments for fraud losses, reissuance costs for compromised cards, and mandatory Level 1 PCI DSS validation going forward. Regulators and state attorneys general may also get involved, and the organization almost always faces litigation. In short, PCI DSS fines are rarely the largest line item -- the true cost of a breach is reputational damage, customer churn, and the fully loaded cost of breach response.",[11,3892,3894],{"id":3893},"pci-dss-vs-other-frameworks","PCI DSS vs other frameworks",[16,3896,3897,3898,3901,3902,3906],{},"PCI DSS is narrower and more prescriptive than most security frameworks. ISO 27001 is a management-system standard focused on the process of running an ISMS; it tells you how to manage risk but does not specify controls the way PCI DSS does. SOC 2 is an attestation framework where you define your own controls against the Trust Services Criteria; PCI DSS prescribes them. HIPAA and HITECH cover protected health information, not cardholder data. NIST CSF and NIST SP 800-53 offer control catalogues and risk management guidance that many organizations map into their PCI DSS program, especially under the v4.0 customized approach. PCI DSS is also one of the few frameworks with ongoing external validation -- ASV scans every quarter, penetration tests at least annually, and a full assessment every year. For businesses in the ",[261,3899,3900],{"href":611},"finance industry"," or running ",[261,3903,3905],{"href":3904},"\u002Findustry\u002Fecommerce","e-commerce"," platforms, PCI DSS almost always becomes the binding constraint that the rest of the security program organizes around.",[11,3908,3910],{"id":3909},"getting-pci-compliant","Getting PCI compliant",[16,3912,3913],{},"A typical path to PCI DSS compliance looks like this:",[59,3915,3916,3922,3928,3934,3940,3946,3952,3958],{},[36,3917,3918,3921],{},[64,3919,3920],{},"Define scope"," -- inventory every place card data lives, moves, or could move. Produce annotated network and data-flow diagrams.",[36,3923,3924,3927],{},[64,3925,3926],{},"Reduce scope"," -- apply segmentation, tokenization, P2PE, and outsourcing to shrink the CDE before assessment.",[36,3929,3930,3933],{},[64,3931,3932],{},"Select your validation path"," -- confirm your PCI DSS level with your acquirer and determine whether you owe a ROC or an SAQ.",[36,3935,3936,3939],{},[64,3937,3938],{},"Gap assess"," -- map your current controls to every applicable PCI DSS requirement and prioritize remediation.",[36,3941,3942,3945],{},[64,3943,3944],{},"Remediate and document"," -- close gaps, write the policies and procedures PCI DSS expects, and stand up the logging, monitoring, scanning, and testing programs.",[36,3947,3948,3951],{},[64,3949,3950],{},"Engage your QSA or ASV"," -- commission the ASV scans, book the penetration test, and (for Level 1) schedule your QSA engagement early enough to allow remediation cycles.",[36,3953,3954,3957],{},[64,3955,3956],{},"Validate and attest"," -- produce the ROC or SAQ plus Attestation of Compliance, and submit to your acquirer on the required cadence.",[36,3959,3960,3963],{},[64,3961,3962],{},"Operate continuously"," -- PCI DSS v4.0 expects continuous monitoring, targeted risk analyses, and evidence that controls stay effective between assessments.",[16,3965,3966],{},"episki automates the bulk of the evidence collection, control testing, and QSA collaboration work so your PCI DSS program is audit-ready year-round instead of scrambling at the end of each cycle. If you are starting a new PCI DSS program or rebuilding an existing one, episki can shorten your path from scoping through Report on Compliance.",{"title":267,"searchDepth":268,"depth":268,"links":3968},[3969,3970,3971,3972,3973,3974,3975,3976,3977,3978,3979],{"id":3581,"depth":268,"text":3582},{"id":3599,"depth":268,"text":3600},{"id":3698,"depth":268,"text":1802},{"id":3707,"depth":268,"text":3708},{"id":3723,"depth":268,"text":3724},{"id":3800,"depth":268,"text":3801},{"id":2236,"depth":268,"text":2237},{"id":3836,"depth":268,"text":3837},{"id":3886,"depth":268,"text":3887},{"id":3893,"depth":268,"text":3894},{"id":3909,"depth":268,"text":3910},{"title":3981,"description":3982,"items":3983},"PCI DSS playbook","Follow structured milestones from scoping through ROC submission.",[3984,3985,3986,3987,3988],"Automated scope confirmation questionnaires","Connector-backed logging and monitoring checks","Quarterly vulnerability and penetration testing tracker","Change-management evidence capture","ROC narrative template and artifact index",{"title":3990,"description":3991},"Keep PCI DSS audit-ready around the clock","Spin up your trial, sync evidence, and invite your QSA in a single day.",{"title":3993,"items":3994},"PCI DSS frequently asked questions",[3995,3998,4001,4004,4007],{"label":3996,"content":3997},"What are the PCI DSS compliance levels?","PCI DSS has four merchant levels based on annual transaction volume. Level 1 (over 6 million transactions) requires a formal Report on Compliance by a QSA. Levels 2-4 may self-assess using the appropriate Self-Assessment Questionnaire (SAQ). Service providers have two levels with different validation requirements.",{"label":3999,"content":4000},"What changed in PCI DSS 4.0?","PCI DSS 4.0 introduced a customized validation approach allowing organizations to meet objectives with alternative controls, expanded multi-factor authentication requirements, strengthened e-commerce and phishing protections, and added emphasis on continuous security rather than point-in-time compliance.",{"label":4002,"content":4003},"Who needs PCI DSS compliance?","Any organization that stores, processes, or transmits cardholder data must comply with PCI DSS. This includes merchants, payment processors, acquirers, issuers, and service providers. The scope is determined by your cardholder data environment (CDE).",{"label":4005,"content":4006},"How often is a PCI DSS assessment required?","PCI DSS assessments are required annually. Level 1 merchants and service providers must complete a formal assessment by a Qualified Security Assessor (QSA). Additionally, quarterly network vulnerability scans by an Approved Scanning Vendor (ASV) are required.",{"label":4008,"content":4009},"What is a cardholder data environment (CDE)?","The CDE includes all people, processes, and technologies that store, process, or transmit cardholder data or sensitive authentication data, plus any systems connected to those components. Accurate CDE scoping is the foundation of an efficient PCI DSS assessment.",{"headline":4011,"title":4012,"description":4013,"links":4014},"PCI controls that stay current","Keep PCI DSS requirements passing even as your CDE evolves","episki maps DSS requirements, automates testing, and keeps QSAs collaborating in one secure workspace.",[4015,4019],{"label":4016,"icon":4017,"to":4018},"Start PCI trial","i-lucide-rocket","https:\u002F\u002Fepiski.app\u002Fauth\u002Fregister",{"label":4020,"icon":4021,"color":4022,"variant":4023,"to":4024,"target":4025},"Book a demo","i-lucide-calendar","neutral","subtle","https:\u002F\u002Fcalendly.com\u002Fjustinleapline\u002Fepiski-demo","_blank",{},{"headline":4028,"title":4028,"description":4029,"items":4030},"PCI enablement kit","Give leadership, ops, and QSAs a single source of truth.",[4031,4034,4037],{"title":4032,"description":4033},"CDE architecture report","Share sanitized diagrams and segmentation notes with prospects.",{"title":4035,"description":4036},"Risk and remediation digest","Weekly summary of open items, owners, and due dates.",{"title":4038,"description":4039},"Assessor workspace","Prebuilt template keeps every requirement, artifact, and note aligned.",{"title":4041,"description":4042},"PCI DSS Compliance Tool","Automate PCI DSS evidence collection, manage QSA collaboration, and keep cardholder data controls current. Start your free 14-day trial with episki.",[4044,4047,4050],{"value":4045,"description":4046},"90% automation","Evidence coverage across access, logging, segmentation, and monitoring.",{"value":4048,"description":4049},"QSA portal","Scoped access keeps your assessor in sync without endless spreadsheets.",{"value":4051,"description":4052},"Weekly drift checks","Automated alerts highlight misconfigurations before audits.","5.frameworks\u002Fpci","CLd_USSJYVGuYbFc7G7BM7AyRBX9rMAIVS8DpYE2SPU",[4056,4275,4439,4687],{"id":4057,"title":4058,"body":4059,"description":267,"extension":279,"lastUpdated":295,"meta":4267,"navigation":297,"path":3864,"relatedFrameworks":4268,"relatedTerms":4269,"seo":4270,"slug":300,"stem":4273,"term":4064,"__hash__":4274},"glossary\u002F8.glossary\u002Fasv.md","Asv",{"type":8,"value":4060,"toc":4256},[4061,4065,4068,4072,4075,4092,4096,4099,4131,4135,4138,4180,4184,4187,4198,4201,4205,4208,4221,4224,4228,4231,4248,4250],[11,4062,4064],{"id":4063},"what-is-an-approved-scanning-vendor-asv","What is an Approved Scanning Vendor (ASV)?",[16,4066,4067],{},"An Approved Scanning Vendor (ASV) is a company certified by the PCI Security Standards Council to perform external vulnerability scans of internet-facing systems that are part of the cardholder data environment. ASV scans are a specific PCI DSS requirement (Requirement 11.3.2) and must be conducted quarterly by a PCI SSC-approved vendor.",[338,4069,4071],{"id":4070},"purpose-of-asv-scans","Purpose of ASV scans",[16,4073,4074],{},"ASV scans serve as an independent check on the security of externally facing systems that could be used to access cardholder data. The scans identify:",[33,4076,4077,4080,4083,4086,4089],{},[36,4078,4079],{},"Known vulnerabilities in operating systems, applications, and network devices",[36,4081,4082],{},"Misconfigurations that could expose systems to attack",[36,4084,4085],{},"Weak or default credentials on internet-facing services",[36,4087,4088],{},"Missing security patches",[36,4090,4091],{},"Other security weaknesses visible from the external network",[338,4093,4095],{"id":4094},"asv-scan-requirements","ASV scan requirements",[16,4097,4098],{},"PCI DSS requires:",[33,4100,4101,4107,4113,4119,4125],{},[36,4102,4103,4106],{},[64,4104,4105],{},"Quarterly scans"," — external vulnerability scans must be performed at least once every 90 days",[36,4108,4109,4112],{},[64,4110,4111],{},"Passing results"," — scans must achieve a passing status, meaning no vulnerabilities with a CVSS score of 4.0 or higher remain unresolved",[36,4114,4115,4118],{},[64,4116,4117],{},"Scan coverage"," — all externally facing IP addresses and domains in scope must be included",[36,4120,4121,4124],{},[64,4122,4123],{},"Rescans after remediation"," — if a scan fails, vulnerabilities must be remediated and a rescan performed to confirm resolution",[36,4126,4127,4130],{},[64,4128,4129],{},"Scan after significant changes"," — additional scans may be required after significant infrastructure changes",[338,4132,4134],{"id":4133},"how-asv-scans-work","How ASV scans work",[16,4136,4137],{},"The ASV scan process typically follows these steps:",[59,4139,4140,4146,4152,4158,4164,4169,4174],{},[36,4141,4142,4145],{},[64,4143,4144],{},"Scope definition"," — the organization identifies all external IP addresses and domains in the cardholder data environment",[36,4147,4148,4151],{},[64,4149,4150],{},"Scan execution"," — the ASV performs automated vulnerability scanning against the defined scope",[36,4153,4154,4157],{},[64,4155,4156],{},"Results review"," — the ASV provides a report detailing identified vulnerabilities, their severity, and remediation guidance",[36,4159,4160,4163],{},[64,4161,4162],{},"Dispute resolution"," — if the organization believes a finding is a false positive, it can submit a dispute to the ASV with supporting evidence",[36,4165,4166,4168],{},[64,4167,90],{}," — the organization addresses identified vulnerabilities",[36,4170,4171,4173],{},[64,4172,96],{}," — if needed, the ASV performs additional scans to confirm remediation",[36,4175,4176,4179],{},[64,4177,4178],{},"Attestation"," — the ASV provides a scan attestation confirming the results",[338,4181,4183],{"id":4182},"passing-vs-failing-scans","Passing vs failing scans",[16,4185,4186],{},"A scan is considered passing when:",[33,4188,4189,4192,4195],{},[36,4190,4191],{},"No vulnerabilities with a CVSS base score of 4.0 or higher are present",[36,4193,4194],{},"No automatic failure conditions exist (such as DNS zone transfers, unrestricted SQL access, or use of SSL\u002Fearly TLS)",[36,4196,4197],{},"All components in scope have been successfully scanned",[16,4199,4200],{},"Failing scans must be addressed before the organization can demonstrate compliance for that quarter.",[338,4202,4204],{"id":4203},"asv-vs-penetration-testing","ASV vs penetration testing",[16,4206,4207],{},"ASV scans and penetration testing serve different purposes:",[33,4209,4210,4216],{},[36,4211,4212,4215],{},[64,4213,4214],{},"ASV scans"," are automated external vulnerability scans required quarterly, focused on identifying known vulnerabilities",[36,4217,4218,4220],{},[64,4219,2500],{}," involves manual testing by skilled testers who attempt to exploit vulnerabilities and chain findings together",[16,4222,4223],{},"Both are required by PCI DSS, but they serve complementary functions. ASV scans provide broad, frequent coverage while penetration tests provide deeper, more targeted analysis.",[338,4225,4227],{"id":4226},"choosing-an-asv","Choosing an ASV",[16,4229,4230],{},"The PCI SSC maintains a list of approved scanning vendors on its website. When selecting an ASV, consider:",[33,4232,4233,4236,4239,4242,4245],{},[36,4234,4235],{},"Quality and usability of scan reports",[36,4237,4238],{},"False positive rates and dispute resolution processes",[36,4240,4241],{},"Customer support responsiveness",[36,4243,4244],{},"Integration capabilities with your security tools",[36,4246,4247],{},"Pricing structure",[338,4249,256],{"id":255},[16,4251,4252,4253,265],{},"episki tracks your ASV scan schedule, stores scan results, and monitors remediation of identified vulnerabilities. The platform alerts you when quarterly scans are due and flags overdue remediation items. Learn more on our ",[261,4254,4255],{"href":263},"PCI DSS compliance page",{"title":267,"searchDepth":268,"depth":268,"links":4257},[4258],{"id":4063,"depth":268,"text":4064,"children":4259},[4260,4261,4262,4263,4264,4265,4266],{"id":4070,"depth":662,"text":4071},{"id":4094,"depth":662,"text":4095},{"id":4133,"depth":662,"text":4134},{"id":4182,"depth":662,"text":4183},{"id":4203,"depth":662,"text":4204},{"id":4226,"depth":662,"text":4227},{"id":255,"depth":662,"text":256},{},[294],[301,1622,1069,306,302],{"title":4271,"description":4272},"Approved Scanning Vendor (ASV): PCI DSS Scan Requirements","An ASV is a PCI SSC-certified company that runs external vulnerability scans. Learn when ASV scans are required, how to pass, and what happens if you fail.","8.glossary\u002Fasv","Oa2VQvYMXQ37mrmR7oxsGJQ_kr13xw_bKDI5-EAKAKQ",{"id":4276,"title":4277,"body":4278,"description":267,"extension":279,"lastUpdated":295,"meta":4431,"navigation":297,"path":3588,"relatedFrameworks":4432,"relatedTerms":4433,"seo":4434,"slug":301,"stem":4437,"term":3582,"__hash__":4438},"glossary\u002F8.glossary\u002Fpci-dss.md","Pci Dss",{"type":8,"value":4279,"toc":4423},[4280,4282,4285,4289,4292,4318,4321,4324,4383,4387,4390,4414,4418],[11,4281,3582],{"id":3581},[16,4283,4284],{},"PCI DSS (Payment Card Industry Data Security Standard) is a set of security requirements designed to ensure that all organizations that accept, process, store, or transmit credit card information maintain a secure environment. It is managed by the PCI Security Standards Council (PCI SSC).",[338,4286,4288],{"id":4287},"the-12-requirements","The 12 requirements",[16,4290,4291],{},"PCI DSS organizes controls into 12 high-level requirements:",[59,4293,4294,4296,4298,4300,4302,4304,4306,4308,4310,4312,4314,4316],{},[36,4295,3614],{},[36,4297,3624],{},[36,4299,3630],{},[36,4301,3643],{},[36,4303,3649],{},[36,4305,3655],{},[36,4307,3661],{},[36,4309,3667],{},[36,4311,3673],{},[36,4313,3679],{},[36,4315,3685],{},[36,4317,3691],{},[338,4319,4320],{"id":1625},"Compliance levels",[16,4322,4323],{},"PCI DSS defines four merchant levels based on annual transaction volume:",[1876,4325,4326,4339],{},[1879,4327,4328],{},[1882,4329,4330,4333,4336],{},[1885,4331,4332],{},"Level",[1885,4334,4335],{},"Transactions per year",[1885,4337,4338],{},"Validation",[1895,4340,4341,4352,4363,4373],{},[1882,4342,4343,4346,4349],{},[1900,4344,4345],{},"1",[1900,4347,4348],{},"Over 6 million",[1900,4350,4351],{},"Annual on-site audit by QSA",[1882,4353,4354,4357,4360],{},[1900,4355,4356],{},"2",[1900,4358,4359],{},"1-6 million",[1900,4361,4362],{},"Annual SAQ + quarterly network scan",[1882,4364,4365,4368,4371],{},[1900,4366,4367],{},"3",[1900,4369,4370],{},"20,000-1 million (e-commerce)",[1900,4372,4362],{},[1882,4374,4375,4378,4381],{},[1900,4376,4377],{},"4",[1900,4379,4380],{},"Under 20,000 (e-commerce) or up to 1 million (other)",[1900,4382,4362],{},[338,4384,4386],{"id":4385},"pci-dss-40","PCI DSS 4.0",[16,4388,4389],{},"Version 4.0, released in March 2022, introduced significant changes:",[33,4391,4392,4397,4402,4408],{},[36,4393,4394,4396],{},[64,4395,1770],{}," — organizations can meet objectives with alternative controls if they can demonstrate equivalent security",[36,4398,4399,4401],{},[64,4400,1776],{}," — more flexibility in defining control frequencies based on risk",[36,4403,4404,4407],{},[64,4405,4406],{},"Enhanced authentication"," — multi-factor authentication required for all access to the cardholder data environment",[36,4409,4410,4413],{},[64,4411,4412],{},"Expanded scope"," — additional requirements for e-commerce, phishing protections, and automated log reviews",[338,4415,4417],{"id":4416},"how-episki-helps-with-pci-dss","How episki helps with PCI DSS",[16,4419,4420,4421,265],{},"episki maps controls to PCI DSS requirements, tracks evidence for QSA reviews, and connects cardholder data environment documentation to relevant controls. Learn more on our ",[261,4422,4255],{"href":263},{"title":267,"searchDepth":268,"depth":268,"links":4424},[4425],{"id":3581,"depth":268,"text":3582,"children":4426},[4427,4428,4429,4430],{"id":4287,"depth":662,"text":4288},{"id":1625,"depth":662,"text":4320},{"id":4385,"depth":662,"text":4386},{"id":4416,"depth":662,"text":4417},{},[294],[1623,1622,300,1069,2287],{"title":4435,"description":4436},"What is PCI DSS? Payment Card Compliance Explained","PCI DSS is the security standard for organizations that handle credit card data. Learn about compliance levels, requirements, and what changed in PCI DSS 4.0.","8.glossary\u002Fpci-dss","ebce8K0nT3kaj2Vq-hviYHxPOETWVmT0sXNo1lFTKV8",{"id":4440,"title":4441,"body":4442,"description":267,"extension":279,"lastUpdated":295,"meta":4679,"navigation":297,"path":3810,"relatedFrameworks":4680,"relatedTerms":4681,"seo":4682,"slug":302,"stem":4685,"term":4447,"__hash__":4686},"glossary\u002F8.glossary\u002Fpci-scope.md","Pci Scope",{"type":8,"value":4443,"toc":4669},[4444,4448,4451,4455,4458,4463,4477,4482,4496,4501,4515,4519,4522,4566,4570,4573,4603,4607,4610,4641,4645,4648,4662,4664],[11,4445,4447],{"id":4446},"what-is-pci-scope","What is PCI Scope?",[16,4449,4450],{},"PCI scope refers to the collection of systems, people, processes, and technologies that are subject to PCI DSS requirements for a given assessment. Accurately defining scope is one of the most consequential decisions in PCI DSS compliance — it determines the extent of controls required, the volume of evidence to collect, and the cost of the assessment.",[338,4452,4454],{"id":4453},"what-falls-in-scope","What falls in scope",[16,4456,4457],{},"PCI DSS scope includes three categories of systems:",[16,4459,4460,4462],{},[64,4461,2216],{}," — systems that directly store, process, or transmit cardholder data:",[33,4464,4465,4468,4471,4474],{},[36,4466,4467],{},"Payment processing servers",[36,4469,4470],{},"Databases containing PAN",[36,4472,4473],{},"Point-of-sale terminals",[36,4475,4476],{},"Payment applications",[16,4478,4479,4481],{},[64,4480,2223],{}," — systems that connect to or could affect the security of the CDE:",[33,4483,4484,4487,4490,4493],{},[36,4485,4486],{},"Firewalls and routers protecting the CDE",[36,4488,4489],{},"Authentication and directory servers used by CDE systems",[36,4491,4492],{},"Security monitoring systems (SIEM, IDS\u002FIPS)",[36,4494,4495],{},"Administrative workstations used to manage CDE systems",[16,4497,4498,4500],{},[64,4499,2230],{}," — systems that could impact the security of the CDE even without direct connectivity:",[33,4502,4503,4506,4509,4512],{},[36,4504,4505],{},"DNS servers",[36,4507,4508],{},"NTP servers",[36,4510,4511],{},"Patch management systems",[36,4513,4514],{},"Configuration management tools",[338,4516,4518],{"id":4517},"scoping-methodology","Scoping methodology",[16,4520,4521],{},"Defining PCI scope follows a structured approach:",[59,4523,4524,4530,4536,4542,4548,4554,4560],{},[36,4525,4526,4529],{},[64,4527,4528],{},"Identify all cardholder data flows"," — trace every path that cardholder data takes through your environment",[36,4531,4532,4535],{},[64,4533,4534],{},"Identify all data storage"," — locate every place where cardholder data is stored, including backups and logs",[36,4537,4538,4541],{},[64,4539,4540],{},"Identify all processing systems"," — document every system that processes cardholder data",[36,4543,4544,4547],{},[64,4545,4546],{},"Map network connectivity"," — determine which systems have network access to the CDE",[36,4549,4550,4553],{},[64,4551,4552],{},"Identify supporting systems"," — find systems that provide security services or administration to the CDE",[36,4555,4556,4559],{},[64,4557,4558],{},"Document scope boundaries"," — clearly define what is in scope and what is out of scope",[36,4561,4562,4565],{},[64,4563,4564],{},"Validate with data discovery"," — use tools to verify that cardholder data does not exist outside the defined scope",[338,4567,4569],{"id":4568},"reducing-scope","Reducing scope",[16,4571,4572],{},"Scope reduction is a primary strategy for managing PCI DSS compliance costs and complexity:",[33,4574,4575,4580,4585,4591,4597],{},[36,4576,4577,4579],{},[64,4578,2240],{}," — isolate the CDE on dedicated network segments, preventing other systems from being in scope",[36,4581,4582,4584],{},[64,4583,2288],{}," — replace PAN with tokens so downstream systems never handle actual cardholder data",[36,4586,4587,4590],{},[64,4588,4589],{},"Point-to-point encryption"," — encrypt cardholder data from the point of interaction, reducing the number of systems that handle unencrypted data",[36,4592,4593,4596],{},[64,4594,4595],{},"Outsourcing"," — shift payment processing to PCI-compliant third-party providers",[36,4598,4599,4602],{},[64,4600,4601],{},"Eliminating unnecessary storage"," — stop storing cardholder data that is not required for business purposes",[338,4604,4606],{"id":4605},"common-scoping-mistakes","Common scoping mistakes",[16,4608,4609],{},"Organizations frequently make errors that expand scope unnecessarily:",[33,4611,4612,4617,4623,4629,4635],{},[36,4613,4614,4616],{},[64,4615,979],{}," — without proper segmentation, the entire network may be in scope",[36,4618,4619,4622],{},[64,4620,4621],{},"Unnecessary data retention"," — storing PAN when it is no longer needed",[36,4624,4625,4628],{},[64,4626,4627],{},"Shared infrastructure"," — running CDE systems on shared infrastructure with non-CDE systems",[36,4630,4631,4634],{},[64,4632,4633],{},"Overlooked data locations"," — PAN in log files, test environments, or email",[36,4636,4637,4640],{},[64,4638,4639],{},"Incomplete flow diagrams"," — missing data flows that bring additional systems into scope",[338,4642,4644],{"id":4643},"scope-validation","Scope validation",[16,4646,4647],{},"PCI DSS requires organizations to confirm their scope at least annually and after any significant changes. A QSA or ISA should review and validate scope as part of each assessment. Scope validation includes:",[33,4649,4650,4653,4656,4659],{},[36,4651,4652],{},"Reviewing data flow diagrams for accuracy",[36,4654,4655],{},"Confirming network segmentation controls",[36,4657,4658],{},"Performing data discovery scans",[36,4660,4661],{},"Verifying that scope documentation reflects the current environment",[338,4663,256],{"id":255},[16,4665,4666,4667,265],{},"episki maintains your PCI scope documentation including data flow diagrams, system inventories, and segmentation records. The platform flags changes that could affect scope and prompts validation reviews. Learn more on our ",[261,4668,4255],{"href":263},{"title":267,"searchDepth":268,"depth":268,"links":4670},[4671],{"id":4446,"depth":268,"text":4447,"children":4672},[4673,4674,4675,4676,4677,4678],{"id":4453,"depth":662,"text":4454},{"id":4517,"depth":662,"text":4518},{"id":4568,"depth":662,"text":4569},{"id":4605,"depth":662,"text":4606},{"id":4643,"depth":662,"text":4644},{"id":255,"depth":662,"text":256},{},[294],[301,1069,3195,2287,1622],{"title":4683,"description":4684},"What is PCI Scope? Definition & Compliance Guide","PCI scope defines which systems, people, and processes are subject to PCI DSS requirements. Learn how to accurately determine and reduce your PCI scope.","8.glossary\u002Fpci-scope","3tv2i32arnuRHsx8mX1_uiEwJsX3_rR4-CmjejECCh0",{"id":4688,"title":4689,"body":4690,"description":267,"extension":279,"lastUpdated":295,"meta":4862,"navigation":297,"path":4863,"relatedFrameworks":4864,"relatedTerms":4869,"seo":4873,"slug":303,"stem":4876,"term":4695,"__hash__":4877},"glossary\u002F8.glossary\u002Fvulnerability-management.md","Vulnerability Management",{"type":8,"value":4691,"toc":4853},[4692,4696,4699,4703,4706,4743,4747,4750,4781,4785,4811,4815,4818,4844,4846],[11,4693,4695],{"id":4694},"what-is-vulnerability-management","What is Vulnerability Management?",[16,4697,4698],{},"Vulnerability management is the continuous process of identifying, classifying, prioritizing, and remediating security vulnerabilities in an organization's systems, software, and infrastructure. Unlike one-time assessments, vulnerability management is an ongoing program that adapts as new threats emerge and your environment changes.",[338,4700,4702],{"id":4701},"the-vulnerability-management-lifecycle","The vulnerability management lifecycle",[16,4704,4705],{},"An effective program follows a repeating cycle:",[59,4707,4708,4714,4720,4726,4731,4737],{},[36,4709,4710,4713],{},[64,4711,4712],{},"Asset discovery"," — maintain an accurate inventory of all hardware, software, and cloud resources in scope",[36,4715,4716,4719],{},[64,4717,4718],{},"Vulnerability scanning"," — use automated tools to detect known vulnerabilities across your environment on a regular schedule",[36,4721,4722,4725],{},[64,4723,4724],{},"Prioritization"," — rank findings by severity (CVSS score), exploitability, asset criticality, and business context — not every \"critical\" CVE is critical to your organization",[36,4727,4728,4730],{},[64,4729,90],{}," — apply patches, configuration changes, or compensating controls to address vulnerabilities within defined SLAs",[36,4732,4733,4736],{},[64,4734,4735],{},"Verification"," — rescan to confirm that remediation was effective and didn't introduce new issues",[36,4738,4739,4742],{},[64,4740,4741],{},"Reporting"," — track metrics like mean time to remediate (MTTR), vulnerability aging, and coverage rates",[338,4744,4746],{"id":4745},"vulnerability-management-in-compliance-frameworks","Vulnerability management in compliance frameworks",[16,4748,4749],{},"Most security frameworks require a formal vulnerability management program:",[33,4751,4752,4757,4763,4769,4775],{},[36,4753,4754,4756],{},[64,4755,3589],{}," — Requirement 6.3 requires patching critical vulnerabilities within defined timeframes; Requirement 11.3 requires internal and external vulnerability scanning",[36,4758,4759,4762],{},[64,4760,4761],{},"SOC 2"," — CC7.1 covers detection of vulnerabilities and CC8.1 addresses change management for remediation",[36,4764,4765,4768],{},[64,4766,4767],{},"ISO 27001"," — A.8.8 (management of technical vulnerabilities) requires timely identification and remediation of vulnerabilities",[36,4770,4771,4774],{},[64,4772,4773],{},"NIST CSF"," — ID.RA (risk assessment) and PR.IP (information protection) directly relate to vulnerability identification and remediation",[36,4776,4777,4780],{},[64,4778,4779],{},"CMMC"," — RA.L2-3.11.2 requires remediation of vulnerabilities in accordance with risk assessments",[338,4782,4784],{"id":4783},"common-vulnerability-scanning-tools","Common vulnerability scanning tools",[33,4786,4787,4793,4799,4805],{},[36,4788,4789,4792],{},[64,4790,4791],{},"Infrastructure scanners"," — Nessus, Qualys, Rapid7 InsightVM for network and host-level vulnerabilities",[36,4794,4795,4798],{},[64,4796,4797],{},"Application scanners"," — OWASP ZAP, Burp Suite for web application vulnerabilities",[36,4800,4801,4804],{},[64,4802,4803],{},"Dependency scanners"," — Snyk, Dependabot, Trivy for software composition analysis (SCA)",[36,4806,4807,4810],{},[64,4808,4809],{},"Cloud security posture"," — AWS Inspector, Azure Defender, GCP Security Command Center for cloud misconfigurations",[338,4812,4814],{"id":4813},"sla-best-practices","SLA best practices",[16,4816,4817],{},"Define remediation timelines based on severity:",[33,4819,4820,4826,4832,4838],{},[36,4821,4822,4825],{},[64,4823,4824],{},"Critical"," — remediate within 24–72 hours",[36,4827,4828,4831],{},[64,4829,4830],{},"High"," — remediate within 7–14 days",[36,4833,4834,4837],{},[64,4835,4836],{},"Medium"," — remediate within 30 days",[36,4839,4840,4843],{},[64,4841,4842],{},"Low"," — remediate within 90 days or accept risk with documented justification",[338,4845,256],{"id":255},[16,4847,4848,4849,265],{},"episki tracks vulnerability findings, manages remediation workflows with due dates and ownership, and maps vulnerabilities to compliance framework requirements. The platform provides dashboards showing remediation progress and aging metrics for auditors. Learn more on our ",[261,4850,4852],{"href":4851},"\u002Fframeworks","compliance platform",{"title":267,"searchDepth":268,"depth":268,"links":4854},[4855],{"id":4694,"depth":268,"text":4695,"children":4856},[4857,4858,4859,4860,4861],{"id":4701,"depth":662,"text":4702},{"id":4745,"depth":662,"text":4746},{"id":4783,"depth":662,"text":4784},{"id":4813,"depth":662,"text":4814},{"id":255,"depth":662,"text":256},{},"\u002Fglossary\u002Fvulnerability-management",[4865,4866,294,4867,4868],"soc2","iso27001","nistcsf","cmmc",[306,4870,4871,4872],"remediation","continuous-monitoring","web-application-security",{"title":4874,"description":4875},"What is Vulnerability Management? Definition & Compliance Guide","Vulnerability management is the ongoing process of identifying, classifying, prioritizing, and remediating security vulnerabilities across your systems and applications.","8.glossary\u002Fvulnerability-management","trqOInljYh6e_TV2H4ad-4rWHiLRpTTPS2g6EvKbZCc",[4879,5432],{"id":4880,"title":4881,"body":4882,"description":267,"extension":279,"lastUpdated":295,"meta":5418,"navigation":297,"path":5419,"relatedFrameworks":5420,"relatedTerms":5422,"seo":5426,"slug":5429,"stem":5430,"term":4887,"__hash__":5431},"glossary\u002F8.glossary\u002Faccess-control.md","Access Control",{"type":8,"value":4883,"toc":5404},[4884,4888,4891,4895,4898,4923,4927,4933,4939,4945,4951,4955,4958,4964,4981,4987,5001,5007,5018,5022,5025,5077,5081,5084,5098,5102,5105,5128,5132,5135,5184,5188,5191,5304,5307,5310,5339,5343,5349,5352,5388,5391,5394,5397,5399],[11,4885,4887],{"id":4886},"what-is-access-control","What is Access Control?",[16,4889,4890],{},"Access control is the set of policies, procedures, and technical mechanisms that regulate who can access systems, data, and resources within an organization. It ensures that only authorized individuals can view, modify, or interact with sensitive information and critical systems. Access control is one of the most fundamental and universally required security controls across every major compliance framework.",[338,4892,4894],{"id":4893},"core-principles","Core principles",[16,4896,4897],{},"Access control is built on several foundational principles:",[33,4899,4900,4906,4911,4917],{},[36,4901,4902,4905],{},[64,4903,4904],{},"Least privilege"," — users are granted only the minimum access necessary to perform their job functions",[36,4907,4908,4910],{},[64,4909,871],{}," — critical tasks are divided among multiple individuals to prevent any single person from having unchecked authority",[36,4912,4913,4916],{},[64,4914,4915],{},"Need to know"," — access to information is restricted to those who require it for a specific purpose",[36,4918,4919,4922],{},[64,4920,4921],{},"Default deny"," — access is denied by default unless explicitly granted",[338,4924,4926],{"id":4925},"types-of-access-control","Types of access control",[16,4928,4929,4932],{},[64,4930,4931],{},"Role-Based Access Control (RBAC)"," — access is determined by the user's role within the organization. Roles are defined with specific permissions, and users are assigned to roles. This is the most common model in enterprise environments.",[16,4934,4935,4938],{},[64,4936,4937],{},"Attribute-Based Access Control (ABAC)"," — access decisions are based on attributes of the user, the resource, and the environment (e.g., department, location, time of day, device type).",[16,4940,4941,4944],{},[64,4942,4943],{},"Discretionary Access Control (DAC)"," — resource owners decide who can access their resources. Common in file systems where owners set permissions.",[16,4946,4947,4950],{},[64,4948,4949],{},"Mandatory Access Control (MAC)"," — access is controlled by the system based on security labels and clearance levels. Common in government and military environments.",[338,4952,4954],{"id":4953},"access-control-components","Access control components",[16,4956,4957],{},"A complete access control program addresses:",[16,4959,4960,4963],{},[64,4961,4962],{},"Authentication"," — verifying the identity of users:",[33,4965,4966,4969,4972,4975,4978],{},[36,4967,4968],{},"Passwords and passphrases",[36,4970,4971],{},"Multi-factor authentication (MFA)",[36,4973,4974],{},"Single sign-on (SSO)",[36,4976,4977],{},"Biometric authentication",[36,4979,4980],{},"Certificate-based authentication",[16,4982,4983,4986],{},[64,4984,4985],{},"Authorization"," — determining what authenticated users can do:",[33,4988,4989,4992,4995,4998],{},[36,4990,4991],{},"Permission assignments",[36,4993,4994],{},"Role definitions",[36,4996,4997],{},"Access control lists",[36,4999,5000],{},"Policy enforcement points",[16,5002,5003,5006],{},[64,5004,5005],{},"Access lifecycle management"," — managing access throughout the user lifecycle:",[33,5008,5009,5012,5015],{},[36,5010,5011],{},"Provisioning (granting access when hired or role changes)",[36,5013,5014],{},"Review (periodic access certification)",[36,5016,5017],{},"Deprovisioning (revoking access upon termination or role change)",[338,5019,5021],{"id":5020},"access-control-in-compliance-frameworks","Access control in compliance frameworks",[16,5023,5024],{},"Every major framework requires access control:",[33,5026,5027,5035,5048,5062,5069],{},[36,5028,5029,5034],{},[64,5030,5031],{},[261,5032,4761],{"href":5033},"\u002Fframeworks\u002Fsoc2"," — CC6.1 through CC6.8 cover logical and physical access controls",[36,5036,5037,5042,5043,5047],{},[64,5038,5039],{},[261,5040,4767],{"href":5041},"\u002Fframeworks\u002Fiso27001"," — ",[261,5044,5046],{"href":5045},"\u002Fglossary\u002Fannex-a","Annex A"," controls A.5.15 through A.5.18 and A.8.2 through A.8.5 address access management",[36,5049,5050,5056,5057,5061],{},[64,5051,5052],{},[261,5053,5055],{"href":5054},"\u002Fframeworks\u002Fhipaa","HIPAA"," — the ",[261,5058,5060],{"href":5059},"\u002Fframeworks\u002Fhipaa\u002Fsecurity-rule","Security Rule"," requires access controls for ePHI (45 CFR 164.312(a))",[36,5063,5064,5068],{},[64,5065,5066],{},[261,5067,3589],{"href":263}," — Requirements 7 and 8 address access restriction and user identification",[36,5070,5071,5076],{},[64,5072,5073],{},[261,5074,4773],{"href":5075},"\u002Fframeworks\u002Fnistcsf"," — PR.AC covers identity management, authentication, and access control",[338,5078,5080],{"id":5079},"access-reviews","Access reviews",[16,5082,5083],{},"Regular access reviews (also called access certifications) are a critical control:",[33,5085,5086,5089,5092,5095],{},[36,5087,5088],{},"Review user access rights periodically (quarterly is common for sensitive systems)",[36,5090,5091],{},"Verify that access aligns with current job responsibilities",[36,5093,5094],{},"Identify and remove excessive or unnecessary access",[36,5096,5097],{},"Document review results and remediation actions",[338,5099,5101],{"id":5100},"common-access-control-weaknesses","Common access control weaknesses",[16,5103,5104],{},"Even well-designed access control programs can degrade over time without ongoing attention. Watch for these common issues:",[33,5106,5107,5110,5113,5116,5119,5122,5125],{},[36,5108,5109],{},"Excessive permissions that accumulate over time (privilege creep)",[36,5111,5112],{},"Shared or generic accounts that prevent individual accountability",[36,5114,5115],{},"Delayed deprovisioning when employees leave or change roles",[36,5117,5118],{},"Lack of MFA on critical systems and remote access paths",[36,5120,5121],{},"Inconsistent access review processes with no documented remediation",[36,5123,5124],{},"Service accounts with standing privileged access and no rotation schedule",[36,5126,5127],{},"Lack of visibility into SaaS application access outside the corporate IdP",[338,5129,5131],{"id":5130},"implementing-access-control-in-practice","Implementing access control in practice",[16,5133,5134],{},"Effective access control programs start with planning and build toward automation. The following steps provide a practical roadmap for organizations at any maturity level:",[59,5136,5137,5143,5149,5155,5161,5167,5178],{},[36,5138,5139,5142],{},[64,5140,5141],{},"Map your environment"," — inventory all systems, applications, and data repositories that require access controls. You cannot protect what you have not identified. Include SaaS applications, cloud infrastructure, on-premises servers, databases, file shares, and third-party integrations.",[36,5144,5145,5148],{},[64,5146,5147],{},"Define roles based on job functions"," — create roles that reflect organizational responsibilities, not individual users. Align roles to the principle of least privilege so each role includes only the permissions required for that function. Review role definitions annually and whenever organizational structure changes.",[36,5150,5151,5154],{},[64,5152,5153],{},"Centralize authentication with SSO"," — implement single sign-on using SAML 2.0 or OpenID Connect (OIDC) to unify identity across cloud and on-premises systems. Centralized authentication reduces password sprawl and gives security teams a single point of enforcement. Ensure all business-critical applications are integrated with your SSO provider before considering the rollout complete.",[36,5156,5157,5160],{},[64,5158,5159],{},"Layer MFA on all critical systems"," — require multi-factor authentication for remote access, privileged accounts, email, cloud consoles, and any system that touches sensitive data. Phishing-resistant methods such as FIDO2 hardware keys are preferred over SMS-based codes. At a minimum, enforce MFA on identity providers, admin consoles, and VPN access.",[36,5162,5163,5166],{},[64,5164,5165],{},"Automate provisioning and deprovisioning"," — connect your HR system to your identity provider (IdP) and use SCIM or directory sync to automate account creation, role assignment, and account removal. When an employee is terminated in the HR system, access should be revoked within minutes, not days. Automation eliminates the human error that leads to orphaned accounts and privilege creep.",[36,5168,5169,5172,5173,5177],{},[64,5170,5171],{},"Build an access request and approval workflow"," — establish a formal process where users request access with documented business justification, managers approve, and the request is logged for audit. This creates an ",[261,5174,5176],{"href":5175},"\u002Fglossary\u002Faudit-trail","audit trail"," that satisfies compliance requirements.",[36,5179,5180,5183],{},[64,5181,5182],{},"Monitor and log access events"," — collect authentication and authorization logs centrally. Monitor for anomalies such as failed login attempts, access from unusual locations, and privilege escalation. Logs are essential for incident response and audit evidence.",[338,5185,5187],{"id":5186},"access-control-requirements-by-framework","Access control requirements by framework",[16,5189,5190],{},"Different frameworks address the same access control concepts with different control references. The table below maps common requirements to their framework-specific identifiers:",[1876,5192,5193,5210],{},[1879,5194,5195],{},[1882,5196,5197,5200,5202,5204,5206,5208],{},[1885,5198,5199],{},"Requirement",[1885,5201,4761],{},[1885,5203,4767],{},[1885,5205,5055],{},[1885,5207,3589],{},[1885,5209,4773],{},[1895,5211,5212,5232,5251,5270,5287],{},[1882,5213,5214,5217,5220,5223,5226,5229],{},[1900,5215,5216],{},"Unique user IDs",[1900,5218,5219],{},"CC6.1",[1900,5221,5222],{},"A.5.16",[1900,5224,5225],{},"§164.312(a)(2)(i)",[1900,5227,5228],{},"Req 8.2.1",[1900,5230,5231],{},"PR.AC-1",[1882,5233,5234,5237,5239,5242,5245,5248],{},[1900,5235,5236],{},"MFA",[1900,5238,5219],{},[1900,5240,5241],{},"A.8.5",[1900,5243,5244],{},"Addressable",[1900,5246,5247],{},"Req 8.4",[1900,5249,5250],{},"PR.AC-7",[1882,5252,5253,5255,5258,5261,5264,5267],{},[1900,5254,5080],{},[1900,5256,5257],{},"CC6.2",[1900,5259,5260],{},"A.5.18",[1900,5262,5263],{},"§164.312(a)(1)",[1900,5265,5266],{},"Req 7.2",[1900,5268,5269],{},"PR.AC-4",[1882,5271,5272,5274,5277,5280,5282,5285],{},[1900,5273,4904],{},[1900,5275,5276],{},"CC6.3",[1900,5278,5279],{},"A.5.15",[1900,5281,5263],{},[1900,5283,5284],{},"Req 7.1",[1900,5286,5269],{},[1882,5288,5289,5292,5294,5296,5299,5302],{},[1900,5290,5291],{},"Deprovisioning",[1900,5293,5257],{},[1900,5295,5260],{},[1900,5297,5298],{},"§164.312(a)(2)(ii)",[1900,5300,5301],{},"Req 8.2.6",[1900,5303,5231],{},[16,5305,5306],{},"Organizations subject to multiple frameworks can use this mapping to build a unified access control program that satisfies overlapping requirements without duplicating effort.",[16,5308,5309],{},"A few notes on framework-specific nuances:",[33,5311,5312,5317,5325,5332],{},[36,5313,5314,5316],{},[64,5315,5055],{}," treats MFA as an \"addressable\" implementation specification, meaning covered entities must implement it or document why an equivalent alternative is reasonable. In practice, most organizations implement MFA because the risk of not doing so is difficult to justify.",[36,5318,5319,5324],{},[64,5320,5321,5323],{},[261,5322,3589],{"href":263}," v4.0"," expanded MFA requirements (Req 8.4) to include all access into the cardholder data environment, not just remote access. Organizations processing card data should verify their MFA coverage meets the updated scope.",[36,5326,5327,5331],{},[64,5328,5329],{},[261,5330,4761],{"href":5033}," does not prescribe specific technologies but evaluates whether the controls in place are suitably designed and operating effectively. Auditors will look for evidence that access control policies are enforced consistently.",[36,5333,5334,5338],{},[64,5335,5336],{},[261,5337,4773],{"href":5075}," provides a flexible, risk-based approach. The PR.AC subcategory identifiers map to more detailed controls in NIST SP 800-53, which organizations can reference for implementation guidance.",[338,5340,5342],{"id":5341},"zero-trust-and-access-control","Zero trust and access control",[16,5344,5345,5346,265],{},"Traditional access control models assume that users inside the network perimeter can be trusted. Zero trust architecture rejects that assumption entirely: ",[64,5347,5348],{},"never trust, always verify",[16,5350,5351],{},"In a zero trust model, every access request is authenticated, authorized, and encrypted regardless of where it originates. Key principles include:",[33,5353,5354,5360,5366,5376,5382],{},[36,5355,5356,5359],{},[64,5357,5358],{},"Continuous verification"," — access decisions are re-evaluated throughout a session, not just at login. Changes in user behavior, location, or risk score can trigger step-up authentication or session termination.",[36,5361,5362,5365],{},[64,5363,5364],{},"Micro-segmentation"," — network resources are divided into small, isolated zones so that compromising one segment does not grant lateral access to others.",[36,5367,5368,5371,5372,5375],{},[64,5369,5370],{},"Device posture checks"," — the security state of the connecting device (patch level, endpoint protection status, disk ",[261,5373,3196],{"href":5374},"\u002Fglossary\u002Fencryption",") is evaluated before access is granted.",[36,5377,5378,5381],{},[64,5379,5380],{},"Identity-centric perimeter"," — the network perimeter is replaced by identity as the primary security boundary. Every user, device, and workload must prove its identity before accessing any resource.",[36,5383,5384,5387],{},[64,5385,5386],{},"Least privilege enforcement at the session level"," — access grants are scoped to the specific resource and action needed, and they expire when the session ends or conditions change.",[16,5389,5390],{},"NIST SP 800-207 defines the zero trust architecture and provides guidance on implementation. Many compliance frameworks are increasingly aligning their access control requirements with zero trust principles, making it a forward-looking strategy for organizations building or modernizing their access control programs.",[16,5392,5393],{},"Zero trust is not a single product but an architectural approach that spans identity, network, endpoints, and data.",[16,5395,5396],{},"Adopting zero trust does not require replacing your existing access control infrastructure overnight. Most organizations begin by enforcing MFA universally, segmenting their most sensitive assets, and adding device posture checks to their conditional access policies. Over time, these incremental improvements compound into a mature zero trust posture.",[338,5398,256],{"id":255},[16,5400,5401,5402,265],{},"episki tracks access control policies, monitors review schedules, and documents access provisioning and deprovisioning activities. The platform sends reminders for periodic access reviews and maintains evidence for auditors. Learn more on our ",[261,5403,4852],{"href":4851},{"title":267,"searchDepth":268,"depth":268,"links":5405},[5406],{"id":4886,"depth":268,"text":4887,"children":5407},[5408,5409,5410,5411,5412,5413,5414,5415,5416,5417],{"id":4893,"depth":662,"text":4894},{"id":4925,"depth":662,"text":4926},{"id":4953,"depth":662,"text":4954},{"id":5020,"depth":662,"text":5021},{"id":5079,"depth":662,"text":5080},{"id":5100,"depth":662,"text":5101},{"id":5130,"depth":662,"text":5131},{"id":5186,"depth":662,"text":5187},{"id":5341,"depth":662,"text":5342},{"id":255,"depth":662,"text":256},{},"\u002Fglossary\u002Faccess-control",[4868,4865,4866,5421,294,4867],"hipaa",[5423,5424,3196,5425],"minimum-necessary-rule","audit-trail","user-entity-controls",{"title":5427,"description":5428},"Access Control in Compliance: RBAC, MFA & Least Privilege","Access control restricts system and data access to authorized users. Learn RBAC, MFA, least privilege, and requirements across SOC 2, ISO 27001, HIPAA, and PCI DSS.","access-control","8.glossary\u002Faccess-control","aw9J1nXzlNuRVpTr3vx46B0ijrBB9hLxb3SnjmXE6cE",{"id":4057,"title":4058,"body":5433,"description":267,"extension":279,"lastUpdated":295,"meta":5578,"navigation":297,"path":3864,"relatedFrameworks":5579,"relatedTerms":5580,"seo":5581,"slug":300,"stem":4273,"term":4064,"__hash__":4274},{"type":8,"value":5434,"toc":5567},[5435,5437,5439,5441,5443,5455,5457,5459,5481,5483,5485,5515,5517,5519,5527,5529,5531,5533,5543,5545,5547,5549,5561,5563],[11,5436,4064],{"id":4063},[16,5438,4067],{},[338,5440,4071],{"id":4070},[16,5442,4074],{},[33,5444,5445,5447,5449,5451,5453],{},[36,5446,4079],{},[36,5448,4082],{},[36,5450,4085],{},[36,5452,4088],{},[36,5454,4091],{},[338,5456,4095],{"id":4094},[16,5458,4098],{},[33,5460,5461,5465,5469,5473,5477],{},[36,5462,5463,4106],{},[64,5464,4105],{},[36,5466,5467,4112],{},[64,5468,4111],{},[36,5470,5471,4118],{},[64,5472,4117],{},[36,5474,5475,4124],{},[64,5476,4123],{},[36,5478,5479,4130],{},[64,5480,4129],{},[338,5482,4134],{"id":4133},[16,5484,4137],{},[59,5486,5487,5491,5495,5499,5503,5507,5511],{},[36,5488,5489,4145],{},[64,5490,4144],{},[36,5492,5493,4151],{},[64,5494,4150],{},[36,5496,5497,4157],{},[64,5498,4156],{},[36,5500,5501,4163],{},[64,5502,4162],{},[36,5504,5505,4168],{},[64,5506,90],{},[36,5508,5509,4173],{},[64,5510,96],{},[36,5512,5513,4179],{},[64,5514,4178],{},[338,5516,4183],{"id":4182},[16,5518,4186],{},[33,5520,5521,5523,5525],{},[36,5522,4191],{},[36,5524,4194],{},[36,5526,4197],{},[16,5528,4200],{},[338,5530,4204],{"id":4203},[16,5532,4207],{},[33,5534,5535,5539],{},[36,5536,5537,4215],{},[64,5538,4214],{},[36,5540,5541,4220],{},[64,5542,2500],{},[16,5544,4223],{},[338,5546,4227],{"id":4226},[16,5548,4230],{},[33,5550,5551,5553,5555,5557,5559],{},[36,5552,4235],{},[36,5554,4238],{},[36,5556,4241],{},[36,5558,4244],{},[36,5560,4247],{},[338,5562,256],{"id":255},[16,5564,4252,5565,265],{},[261,5566,4255],{"href":263},{"title":267,"searchDepth":268,"depth":268,"links":5568},[5569],{"id":4063,"depth":268,"text":4064,"children":5570},[5571,5572,5573,5574,5575,5576,5577],{"id":4070,"depth":662,"text":4071},{"id":4094,"depth":662,"text":4095},{"id":4133,"depth":662,"text":4134},{"id":4182,"depth":662,"text":4183},{"id":4203,"depth":662,"text":4204},{"id":4226,"depth":662,"text":4227},{"id":255,"depth":662,"text":256},{},[294],[301,1622,1069,306,302],{"title":4271,"description":4272},[5583,5845],{"id":315,"title":316,"body":5584,"description":678,"extension":279,"faq":5835,"frameworkSlug":294,"lastUpdated":295,"meta":5841,"navigation":297,"path":694,"relatedTerms":5842,"relatedTopics":5843,"seo":5844,"stem":703,"__hash__":704},{"type":8,"value":5585,"toc":5814},[5586,5588,5590,5594,5596,5598,5602,5606,5616,5620,5630,5634,5636,5640,5644,5652,5656,5658,5662,5666,5674,5676,5678,5682,5686,5694,5696,5698,5700,5702,5706,5710,5718,5720,5724,5728,5734,5736,5738,5740,5762,5764,5766,5768,5770,5772,5776,5778,5780,5782,5786,5788,5790,5812],[11,5587,322],{"id":321},[16,5589,325],{},[16,5591,328,5592,332],{},[261,5593,331],{"href":263},[11,5595,336],{"id":335},[338,5597,341],{"id":340},[16,5599,5600,347],{},[64,5601,346],{},[16,5603,5604],{},[64,5605,352],{},[33,5607,5608,5610,5612,5614],{},[36,5609,357],{},[36,5611,360],{},[36,5613,363],{},[36,5615,366],{},[16,5617,5618],{},[64,5619,371],{},[33,5621,5622,5624,5626,5628],{},[36,5623,376],{},[36,5625,379],{},[36,5627,382],{},[36,5629,385],{},[16,5631,388,5632,393],{},[261,5633,392],{"href":391},[338,5635,397],{"id":396},[16,5637,5638,402],{},[64,5639,346],{},[16,5641,5642],{},[64,5643,352],{},[33,5645,5646,5648,5650],{},[36,5647,411],{},[36,5649,414],{},[36,5651,417],{},[16,5653,420,5654,425],{},[261,5655,424],{"href":423},[338,5657,429],{"id":428},[16,5659,5660,434],{},[64,5661,346],{},[16,5663,5664],{},[64,5665,352],{},[33,5667,5668,5670,5672],{},[36,5669,443],{},[36,5671,414],{},[36,5673,417],{},[16,5675,450],{},[338,5677,454],{"id":453},[16,5679,5680,459],{},[64,5681,346],{},[16,5683,5684],{},[64,5685,352],{},[33,5687,5688,5690,5692],{},[36,5689,468],{},[36,5691,471],{},[36,5693,417],{},[16,5695,476],{},[11,5697,480],{"id":479},[16,5699,483],{},[338,5701,487],{"id":486},[16,5703,5704,493],{},[64,5705,492],{},[16,5707,5708],{},[64,5709,352],{},[33,5711,5712,5714,5716],{},[36,5713,502],{},[36,5715,414],{},[36,5717,507],{},[338,5719,511],{"id":510},[16,5721,5722,516],{},[64,5723,492],{},[16,5725,5726],{},[64,5727,352],{},[33,5729,5730,5732],{},[36,5731,525],{},[36,5733,414],{},[16,5735,530],{},[11,5737,534],{"id":533},[16,5739,537],{},[33,5741,5742,5746,5750,5754,5758],{},[36,5743,5744,545],{},[64,5745,544],{},[36,5747,5748,551],{},[64,5749,550],{},[36,5751,5752,557],{},[64,5753,556],{},[36,5755,5756,563],{},[64,5757,562],{},[36,5759,5760,569],{},[64,5761,568],{},[16,5763,572],{},[11,5765,576],{"id":575},[338,5767,580],{"id":579},[16,5769,583],{},[338,5771,587],{"id":586},[16,5773,5774,594],{},[261,5775,593],{"href":592},[338,5777,598],{"id":597},[16,5779,601],{},[338,5781,605],{"id":604},[16,5783,608,5784,613],{},[261,5785,612],{"href":611},[11,5787,617],{"id":616},[16,5789,620],{},[59,5791,5792,5796,5800,5804,5808],{},[36,5793,5794,628],{},[64,5795,627],{},[36,5797,5798,634],{},[64,5799,633],{},[36,5801,5802,640],{},[64,5803,639],{},[36,5805,5806,646],{},[64,5807,645],{},[36,5809,5810,652],{},[64,5811,651],{},[16,5813,655],{},{"title":267,"searchDepth":268,"depth":268,"links":5815},[5816,5817,5823,5827,5828,5834],{"id":321,"depth":268,"text":322},{"id":335,"depth":268,"text":336,"children":5818},[5819,5820,5821,5822],{"id":340,"depth":662,"text":341},{"id":396,"depth":662,"text":397},{"id":428,"depth":662,"text":429},{"id":453,"depth":662,"text":454},{"id":479,"depth":268,"text":480,"children":5824},[5825,5826],{"id":486,"depth":662,"text":487},{"id":510,"depth":662,"text":511},{"id":533,"depth":268,"text":534},{"id":575,"depth":268,"text":576,"children":5829},[5830,5831,5832,5833],{"id":579,"depth":662,"text":580},{"id":586,"depth":662,"text":587},{"id":597,"depth":662,"text":598},{"id":604,"depth":662,"text":605},{"id":616,"depth":268,"text":617},{"items":5836},[5837,5838,5839,5840],{"label":682,"content":683},{"label":685,"content":686},{"label":688,"content":689},{"label":691,"content":692},{},[301,696],[305,698,699],{"title":701,"description":702},{"id":706,"title":707,"body":5846,"description":1049,"extension":279,"faq":6080,"frameworkSlug":294,"lastUpdated":295,"meta":6086,"navigation":297,"path":1065,"relatedTerms":6087,"relatedTopics":6088,"seo":6089,"stem":1075,"__hash__":1076},{"type":8,"value":5847,"toc":6068},[5848,5850,5852,5854,5856,5858,5876,5878,5880,5882,5896,5898,5900,5902,5928,5930,5932,5934,5964,5966,5968,5970,5972,5982,5984,5986,5988,6014,6016,6018,6020,6022,6024,6062,6064],[11,5849,713],{"id":712},[16,5851,716],{},[16,5853,719],{},[11,5855,723],{"id":722},[16,5857,726],{},[33,5859,5860,5864,5868,5872],{},[36,5861,5862,734],{},[64,5863,733],{},[36,5865,5866,740],{},[64,5867,739],{},[36,5869,5870,746],{},[64,5871,745],{},[36,5873,5874,752],{},[64,5875,751],{},[16,5877,755],{},[11,5879,759],{"id":758},[16,5881,762],{},[33,5883,5884,5886,5888,5890,5892,5894],{},[36,5885,767],{},[36,5887,770],{},[36,5889,773],{},[36,5891,776],{},[36,5893,779],{},[36,5895,782],{},[16,5897,785],{},[11,5899,789],{"id":788},[16,5901,792],{},[33,5903,5904,5908,5912,5916,5920,5924],{},[36,5905,5906,800],{},[64,5907,799],{},[36,5909,5910,806],{},[64,5911,805],{},[36,5913,5914,812],{},[64,5915,811],{},[36,5917,5918,818],{},[64,5919,817],{},[36,5921,5922,824],{},[64,5923,823],{},[36,5925,5926,830],{},[64,5927,829],{},[16,5929,833],{},[11,5931,837],{"id":836},[16,5933,840],{},[33,5935,5936,5940,5944,5948,5952,5956,5960],{},[36,5937,5938,848],{},[64,5939,847],{},[36,5941,5942,854],{},[64,5943,853],{},[36,5945,5946,860],{},[64,5947,859],{},[36,5949,5950,866],{},[64,5951,865],{},[36,5953,5954,872],{},[64,5955,871],{},[36,5957,5958,878],{},[64,5959,877],{},[36,5961,5962,884],{},[64,5963,883],{},[16,5965,887],{},[11,5967,891],{"id":890},[16,5969,894],{},[16,5971,897],{},[33,5973,5974,5976,5978,5980],{},[36,5975,902],{},[36,5977,905],{},[36,5979,908],{},[36,5981,911],{},[16,5983,914],{},[11,5985,918],{"id":917},[16,5987,921],{},[33,5989,5990,5994,5998,6002,6006,6010],{},[36,5991,5992,929],{},[64,5993,928],{},[36,5995,5996,935],{},[64,5997,934],{},[36,5999,6000,941],{},[64,6001,940],{},[36,6003,6004,947],{},[64,6005,946],{},[36,6007,6008,953],{},[64,6009,952],{},[36,6011,6012,959],{},[64,6013,958],{},[16,6015,962],{},[11,6017,192],{"id":191},[16,6019,967],{},[16,6021,970],{},[11,6023,202],{"id":201},[33,6025,6026,6030,6034,6038,6042,6046,6050,6054,6058],{},[36,6027,6028,980],{},[64,6029,979],{},[36,6031,6032,986],{},[64,6033,985],{},[36,6035,6036,992],{},[64,6037,991],{},[36,6039,6040,998],{},[64,6041,997],{},[36,6043,6044,1004],{},[64,6045,1003],{},[36,6047,6048,1010],{},[64,6049,1009],{},[36,6051,6052,1016],{},[64,6053,1015],{},[36,6055,6056,1022],{},[64,6057,1021],{},[36,6059,6060,1028],{},[64,6061,1027],{},[11,6063,256],{"id":255},[16,6065,1033,6066,1036],{},[261,6067,264],{"href":263},{"title":267,"searchDepth":268,"depth":268,"links":6069},[6070,6071,6072,6073,6074,6075,6076,6077,6078,6079],{"id":712,"depth":268,"text":713},{"id":722,"depth":268,"text":723},{"id":758,"depth":268,"text":759},{"id":788,"depth":268,"text":789},{"id":836,"depth":268,"text":837},{"id":890,"depth":268,"text":891},{"id":917,"depth":268,"text":918},{"id":191,"depth":268,"text":192},{"id":201,"depth":268,"text":202},{"id":255,"depth":268,"text":256},{"items":6081},[6082,6083,6084,6085],{"label":1053,"content":1054},{"label":1056,"content":1057},{"label":1059,"content":1060},{"label":1062,"content":1063},{},[1067,1068,302,1069],[307,305,306,1071],{"title":1073,"description":1074},{"id":3553,"title":3554,"advantages":6091,"body":6098,"checklist":6353,"cta":6355,"description":267,"extension":279,"faq":6356,"hero":6363,"meta":6367,"name":3589,"navigation":297,"path":263,"resources":6368,"seo":6373,"slug":294,"stats":6374,"stem":4053,"__hash__":4054},[6092,6094,6096],{"title":3557,"description":3558,"bullets":6093},[3560,3561,3562],{"title":3564,"description":3565,"bullets":6095},[3567,3568,3569],{"title":3571,"description":3572,"bullets":6097},[3574,3575,3576],{"type":8,"value":6099,"toc":6340},[6100,6102,6106,6108,6110,6112,6116,6172,6174,6176,6180,6182,6188,6190,6194,6230,6236,6238,6244,6246,6248,6250,6258,6260,6262,6284,6288,6290,6292,6294,6300,6302,6304,6338],[11,6101,3582],{"id":3581},[16,6103,3585,6104,3590],{},[261,6105,3589],{"href":3588},[16,6107,3593],{},[16,6109,3596],{},[11,6111,3600],{"id":3599},[16,6113,3603,6114,3607],{},[261,6115,3606],{"href":391},[59,6117,6118,6124,6128,6136,6140,6144,6148,6152,6156,6160,6164,6168],{},[36,6119,6120,3615,6122,265],{},[64,6121,3614],{},[261,6123,3619],{"href":3618},[36,6125,6126,3625],{},[64,6127,3624],{},[36,6129,6130,3631,6132,3635,6134,3638],{},[64,6131,3630],{},[261,6133,2287],{"href":3634},[261,6135,2933],{"href":2932},[36,6137,6138,3644],{},[64,6139,3643],{},[36,6141,6142,3650],{},[64,6143,3649],{},[36,6145,6146,3656],{},[64,6147,3655],{},[36,6149,6150,3662],{},[64,6151,3661],{},[36,6153,6154,3668],{},[64,6155,3667],{},[36,6157,6158,3674],{},[64,6159,3673],{},[36,6161,6162,3680],{},[64,6163,3679],{},[36,6165,6166,3686],{},[64,6167,3685],{},[36,6169,6170,3692],{},[64,6171,3691],{},[16,6173,3695],{},[11,6175,1802],{"id":3698},[16,6177,3701,6178,265],{},[261,6179,3704],{"href":1801},[11,6181,3708],{"id":3707},[16,6183,3711,6184,3716,6186,3720],{},[261,6185,3715],{"href":3714},[261,6187,3719],{"href":694},[11,6189,3724],{"id":3723},[16,6191,3727,6192,3732],{},[261,6193,3731],{"href":3730},[33,6195,6196,6200,6204,6208,6212,6216,6220,6224],{},[36,6197,6198,3740],{},[64,6199,3739],{},[36,6201,6202,3746],{},[64,6203,3745],{},[36,6205,6206,3752],{},[64,6207,3751],{},[36,6209,6210,3758],{},[64,6211,3757],{},[36,6213,6214,3764],{},[64,6215,3763],{},[36,6217,6218,3770],{},[64,6219,3769],{},[36,6221,6222,3776],{},[64,6223,3775],{},[36,6225,6226,3782,6228,3786],{},[64,6227,3781],{},[64,6229,3785],{},[16,6231,3789,6232,3793,6234,3797],{},[261,6233,3792],{"href":423},[261,6235,3796],{"href":2177},[11,6237,3801],{"id":3800},[16,6239,3804,6240,3807,6242,3812],{},[261,6241,3619],{"href":3618},[261,6243,3811],{"href":3810},[16,6245,3815],{},[16,6247,3818],{},[11,6249,2237],{"id":2236},[16,6251,3823,6252,3826,6254,3830,6256,3833],{},[261,6253,593],{"href":592},[261,6255,3829],{"href":1065},[261,6257,2287],{"href":3193},[11,6259,3837],{"id":3836},[16,6261,3840],{},[33,6263,6264,6272,6280],{},[36,6265,6266,3852,6270,3856],{},[64,6267,3847,6268,3851],{},[261,6269,3850],{"href":3714},[261,6271,3855],{"href":1620},[36,6273,6274,3866,6278,3870],{},[64,6275,3861,6276,3851],{},[261,6277,3865],{"href":3864},[261,6279,3869],{"href":298},[36,6281,6282,3876],{},[64,6283,3875],{},[16,6285,3879,6286,3883],{},[261,6287,3882],{"href":1327},[11,6289,3887],{"id":3886},[16,6291,3890],{},[11,6293,3894],{"id":3893},[16,6295,3897,6296,3901,6298,3906],{},[261,6297,3900],{"href":611},[261,6299,3905],{"href":3904},[11,6301,3910],{"id":3909},[16,6303,3913],{},[59,6305,6306,6310,6314,6318,6322,6326,6330,6334],{},[36,6307,6308,3921],{},[64,6309,3920],{},[36,6311,6312,3927],{},[64,6313,3926],{},[36,6315,6316,3933],{},[64,6317,3932],{},[36,6319,6320,3939],{},[64,6321,3938],{},[36,6323,6324,3945],{},[64,6325,3944],{},[36,6327,6328,3951],{},[64,6329,3950],{},[36,6331,6332,3957],{},[64,6333,3956],{},[36,6335,6336,3963],{},[64,6337,3962],{},[16,6339,3966],{},{"title":267,"searchDepth":268,"depth":268,"links":6341},[6342,6343,6344,6345,6346,6347,6348,6349,6350,6351,6352],{"id":3581,"depth":268,"text":3582},{"id":3599,"depth":268,"text":3600},{"id":3698,"depth":268,"text":1802},{"id":3707,"depth":268,"text":3708},{"id":3723,"depth":268,"text":3724},{"id":3800,"depth":268,"text":3801},{"id":2236,"depth":268,"text":2237},{"id":3836,"depth":268,"text":3837},{"id":3886,"depth":268,"text":3887},{"id":3893,"depth":268,"text":3894},{"id":3909,"depth":268,"text":3910},{"title":3981,"description":3982,"items":6354},[3984,3985,3986,3987,3988],{"title":3990,"description":3991},{"title":3993,"items":6357},[6358,6359,6360,6361,6362],{"label":3996,"content":3997},{"label":3999,"content":4000},{"label":4002,"content":4003},{"label":4005,"content":4006},{"label":4008,"content":4009},{"headline":4011,"title":4012,"description":4013,"links":6364},[6365,6366],{"label":4016,"icon":4017,"to":4018},{"label":4020,"icon":4021,"color":4022,"variant":4023,"to":4024,"target":4025},{},{"headline":4028,"title":4028,"description":4029,"items":6369},[6370,6371,6372],{"title":4032,"description":4033},{"title":4035,"description":4036},{"title":4038,"description":4039},{"title":4041,"description":4042},[6375,6376,6377],{"value":4045,"description":4046},{"value":4048,"description":4049},{"value":4051,"description":4052},{"id":6379,"title":6380,"body":6381,"comparison":6472,"competitorA":6516,"competitorB":6517,"cta":6518,"description":267,"extension":279,"faq":1844,"hero":6521,"meta":6530,"navigation":297,"path":6531,"seo":6532,"slug":6535,"slugA":6536,"slugB":6537,"stem":6538,"verdict":6539,"__hash__":6543},"compareVs\u002F7.compare\u002Fvs\u002Fdrata-vs-secureframe.md","Drata Vs Secureframe",{"type":8,"value":6382,"toc":6462},[6383,6387,6390,6394,6397,6403,6406,6410,6413,6416,6419,6423,6426,6429,6433,6436,6439,6443,6446,6449,6453,6456,6459],[11,6384,6386],{"id":6385},"drata-vs-secureframe-the-closest-comparison-in-compliance","Drata vs Secureframe: the closest comparison in compliance",[16,6388,6389],{},"If Vanta is the 800-pound gorilla, Drata and Secureframe are the two challengers most often compared against each other. They target similar buyers, cover similar frameworks, and offer similar automation. The differences are real but subtle — and they matter most in how your team experiences the platform day to day.",[338,6391,6393],{"id":6392},"feature-parity-with-different-emphasis","Feature parity with different emphasis",[16,6395,6396],{},"On paper, Drata and Secureframe look nearly identical. Both automate evidence collection, monitor your compliance posture continuously, support 15+ frameworks, and provide auditor-facing portals. The overlap is so significant that choosing between them often comes down to three factors: onboarding style, dashboard experience, and pricing.",[16,6398,6399,6402],{},[64,6400,6401],{},"Onboarding style"," is the clearest differentiator. Drata leans toward self-serve. The platform guides you through integration setup, control mapping, and evidence configuration with in-app workflows. For teams with compliance experience, this speed is an advantage — you can be operational in 1–2 weeks without waiting for a human to walk you through every step.",[16,6404,6405],{},"Secureframe takes the opposite approach. Every customer gets access to dedicated compliance managers who help interpret requirements, map controls to your environment, and prepare for audit. This white-glove model adds a week or two to implementation but dramatically reduces the learning curve for first-time audit teams.",[338,6407,6409],{"id":6408},"the-dashboard-question","The dashboard question",[16,6411,6412],{},"Drata's compliance dashboard is one of its signature features. The real-time posture view shows passing and failing controls across every framework, with compliance percentages and trend data. For compliance leads who report to a CISO or board, this visual layer simplifies status updates and makes it easy to demonstrate progress.",[16,6414,6415],{},"Secureframe also provides dashboards, but they feel more functional than visual. The platform surfaces actionable items — controls that need attention, evidence that's expiring, gaps to remediate — in a task-oriented format. It's effective, but it doesn't deliver the same at-a-glance executive view that Drata provides.",[16,6417,6418],{},"For teams that need board-ready compliance reporting, Drata has the edge. For teams that care more about daily workflow and task management, Secureframe's approach may feel more productive.",[338,6420,6422],{"id":6421},"integration-depth","Integration depth",[16,6424,6425],{},"Secureframe holds a slight advantage in integration count, with 150+ connections compared to Drata's 100+. The extra integrations primarily cover developer tools, identity providers, and security platforms. For teams running complex stacks with multiple CI\u002FCD pipelines, vulnerability scanners, and endpoint management tools, Secureframe's broader integration library means less manual evidence collection.",[16,6427,6428],{},"Drata's integrations, while fewer in number, tend to offer deeper configuration options for the platforms they do support. If your stack is standard — AWS or GCP, Okta or Google Workspace, GitHub, and a common HR tool — both platforms will serve you equally well.",[338,6430,6432],{"id":6431},"pricing-opacity","Pricing opacity",[16,6434,6435],{},"Neither Drata nor Secureframe publishes pricing. Both require a sales conversation to get a quote, and both scale based on team size, framework count, and contract terms. Based on market data, Drata typically starts around $10,000–$15,000\u002Fyr while Secureframe starts slightly lower at $8,000–$12,000\u002Fyr. At scale, both reach $30,000–$50,000\u002Fyr for larger organizations.",[16,6437,6438],{},"This pricing opacity creates a frustrating buying experience. You can't model costs internally before engaging sales. You can't easily compare options. And renewal conversations often involve price increases that are hard to predict at the time of initial purchase.",[338,6440,6442],{"id":6441},"where-both-platforms-struggle","Where both platforms struggle",[16,6444,6445],{},"The irony of comparing Drata and Secureframe is that their most significant limitations are shared. Both use pricing models that punish team growth. Both rely on templated control libraries that resist customization. Both treat policy documentation as a secondary concern — something generated through forms rather than crafted through a proper writing experience.",[16,6447,6448],{},"And both lock you into their workflow assumptions. If your compliance program doesn't map cleanly to their templates — if you run hybrid frameworks, need custom controls, or want to structure programs differently than the default — you'll spend time working around the platform instead of working within it.",[338,6450,6452],{"id":6451},"the-case-for-a-different-approach","The case for a different approach",[16,6454,6455],{},"When two products are this similar, the deciding factor often isn't which one is better — it's whether either one is the right category of tool for your needs. If you want maximum automation and are comfortable with enterprise pricing, Drata and Secureframe both deliver.",[16,6457,6458],{},"But if you want flat pricing at $500\u002Fmo, a Notion-like editor for compliance documentation, and the freedom to build programs that reflect how your team actually operates — episki offers something neither Drata nor Secureframe provides. No per-seat scaling. No opaque quotes. No templated policies that read like every other company's.",[16,6460,6461],{},"Just a workspace your compliance team will use daily, at a price that doesn't make your CFO wince.",{"title":267,"searchDepth":268,"depth":268,"links":6463},[6464],{"id":6385,"depth":268,"text":6386,"children":6465},[6466,6467,6468,6469,6470,6471],{"id":6392,"depth":662,"text":6393},{"id":6408,"depth":662,"text":6409},{"id":6421,"depth":662,"text":6422},{"id":6431,"depth":662,"text":6432},{"id":6441,"depth":662,"text":6442},{"id":6451,"depth":662,"text":6452},[6473,6477,6481,6486,6491,6496,6501,6506,6511],{"feature":162,"competitorA":6474,"competitorB":6475,"episki":6476},"Custom pricing, typically starting around $10,000–$15,000\u002Fyr","Custom pricing, typically starting around $8,000–$12,000\u002Fyr","Flat $500\u002Fmo or $5,000\u002Fyr with unlimited seats",{"feature":6478,"competitorA":6479,"competitorB":6479,"episki":6480},"Framework coverage","SOC 2, ISO 27001, HIPAA, PCI DSS, GDPR, and 15+ frameworks","SOC 2, ISO 27001, HIPAA, PCI DSS, NIST CSF, and custom frameworks",{"feature":6482,"competitorA":6483,"competitorB":6484,"episki":6485},"Automation depth","Automated evidence collection with real-time compliance dashboards","Automated monitoring with continuous evidence collection and alerts","AI-assisted drafting and structured workflows with manual evidence uploads",{"feature":6487,"competitorA":6488,"competitorB":6489,"episki":6490},"Integration count","100+ integrations covering major cloud and SaaS platforms","150+ integrations covering cloud, identity, HR, and developer tools","Growing integration library with focus on structured evidence reuse",{"feature":6492,"competitorA":6493,"competitorB":6494,"episki":6495},"Auditor collaboration","Auditor-facing portal with read-only access and evidence downloads","Auditor-ready evidence rooms with structured access controls","Built-in auditor portal with scoped access and Q&A threads",{"feature":6497,"competitorA":6498,"competitorB":6499,"episki":6500},"AI features","AI-assisted control mapping and compliance recommendations","AI-driven compliance recommendations and automated risk scoring","AI drafts policies, narratives, remediation steps, and questionnaire answers",{"feature":6502,"competitorA":6503,"competitorB":6504,"episki":6505},"Implementation time","1–3 weeks with self-serve setup and optional guided onboarding","2–3 weeks with guided onboarding and compliance expertise","Same-day setup with self-serve onboarding and optional demo",{"feature":6507,"competitorA":6508,"competitorB":6509,"episki":6510},"Support model","In-app chat, email support, and dedicated CSM for larger accounts","Dedicated compliance managers, email, and in-app support","Direct founder access, in-app chat, and shared Slack channels",{"feature":6512,"competitorA":6513,"competitorB":6514,"episki":6515},"Free trial","Demo-based sales process, limited free trial availability","Demo-based sales process, no public free trial","14-day free trial with full access, no credit card required","Drata","Secureframe",{"title":6519,"description":6520},"Skip the comparison. Try episki free.","14-day trial with full access. No credit card required.",{"headline":6522,"title":6523,"description":6524,"links":6525},"Drata vs Secureframe","Similar features, different approaches to compliance automation","Compare Drata and Secureframe across pricing, onboarding, and compliance workflows. Two closely matched platforms with subtle but important differences for your team.",[6526,6528],{"label":6527,"icon":4017,"to":4018},"Try episki free",{"label":4020,"icon":6529,"color":4022,"variant":4023,"to":4024,"target":4025},"i-lucide-message-circle",{},"\u002Fcompare\u002Fvs\u002Fdrata-vs-secureframe",{"title":6533,"description":6534},"Drata vs Secureframe (2026): Pricing, Features & Honest Comparison","Drata vs Secureframe compared on pricing, onboarding, framework coverage, and compliance automation. See which platform fits your team — or why neither might be the best choice.","drata-vs-secureframe","drata","secureframe","7.compare\u002Fvs\u002Fdrata-vs-secureframe",{"chooseA":6540,"chooseB":6541,"chooseEpiski":6542},"Choose Drata if you value self-serve speed and visual compliance dashboards. Drata gets you operational faster and provides the clearest real-time view of your compliance posture — ideal for teams with in-house compliance knowledge.","Choose Secureframe if you want more hands-on guidance from dedicated compliance managers. Secureframe's human-led onboarding is better for teams running their first audit without experienced GRC staff.","Choose episki if you want transparent pricing, a writing-first editor, and the flexibility to structure programs your way. episki is for teams that want to own their compliance narrative without paying enterprise prices.","HuA5a0qhJVkEPHNLT6GY_VEempd7yA1ONnXItxDt-ZQ",{"id":6545,"title":6516,"advantages":6546,"body":6568,"comparison":6619,"competitor":6516,"cta":6646,"description":267,"extension":279,"hero":6649,"meta":6658,"navigation":297,"path":6659,"seo":6660,"slug":6536,"stem":6663,"__hash__":6664},"compare\u002F7.compare\u002Fdrata.md",[6547,6554,6561],{"title":6548,"description":6549,"bullets":6550},"One flat price for everything","episki includes unlimited frameworks, teammates, and portals for a single monthly or annual fee. No tiers, no negotiations.",[6551,6552,6553],"Add frameworks without upgrading to a higher tier","Invite auditors, customers, and stakeholders at no extra cost","Predictable billing that does not scale with headcount",{"title":6555,"description":6556,"bullets":6557},"Connected programs and assessments","episki treats compliance as connected work. Programs, assessments, controls, tasks, and issues link together so nothing falls through the cracks.",[6558,6559,6560],"Run recurring programs and one-time assessments side by side","Tasks inherit context from parent controls and programs","Evidence attaches once and stays available across every framework",{"title":6562,"description":6563,"bullets":6564},"Fast, keyboard-driven workspace","episki is built for people who spend hours in the tool. Keyboard shortcuts, global search, and a rich editor make daily compliance work feel fast.",[6565,6566,6567],"Navigate between programs, controls, and evidence without lifting your hands","Inline editing for policies, narratives, and response drafts","Dark mode and responsive layout for any screen",{"type":8,"value":6569,"toc":6614},[6570,6574,6577,6580,6600,6604,6607,6611],[11,6571,6573],{"id":6572},"why-teams-evaluate-drata-alternatives","Why teams evaluate Drata alternatives",[16,6575,6576],{},"Drata has built a comprehensive compliance automation platform with strong automated evidence collection and a wide library of supported frameworks. It works well for organizations that want continuous monitoring with minimal manual intervention.",[16,6578,6579],{},"Some teams look for alternatives when they need:",[33,6581,6582,6588,6594],{},[36,6583,6584,6587],{},[64,6585,6586],{},"Simpler pricing"," — Drata's tiered pricing based on framework count and company size can make budgeting unpredictable, especially for organizations running multiple frameworks or growing quickly.",[36,6589,6590,6593],{},[64,6591,6592],{},"Unified program management"," — teams managing overlapping compliance programs want controls, evidence, and tasks connected across frameworks in a single workspace rather than managed as separate compliance tracks.",[36,6595,6596,6599],{},[64,6597,6598],{},"A daily-use workspace"," — compliance teams that spend significant time writing, reviewing, and collaborating want an editor and navigation experience that feels productive rather than transactional.",[11,6601,6603],{"id":6602},"when-drata-might-be-the-better-fit","When Drata might be the better fit",[16,6605,6606],{},"Drata is a strong choice for teams that prioritize automated continuous monitoring and need a platform with deep integration coverage across cloud, identity, HR, and development tools. If your primary concern is automating evidence collection and you operate in a well-defined framework like SOC 2 or ISO 27001, Drata's automation depth is compelling.",[11,6608,6610],{"id":6609},"when-episki-shines","When episki shines",[16,6612,6613],{},"episki is designed for teams that view compliance as ongoing, cross-functional work rather than a monitoring dashboard. If you run multiple programs, collaborate with auditors directly in the tool, and want a workspace that feels as fast as your engineering tools, episki delivers a different kind of compliance experience.",{"title":267,"searchDepth":268,"depth":268,"links":6615},[6616,6617,6618],{"id":6572,"depth":268,"text":6573},{"id":6602,"depth":268,"text":6603},{"id":6609,"depth":268,"text":6610},[6620,6622,6623,6627,6631,6634,6638,6642],{"feature":162,"episki":6476,"competitor":6621},"Tiered pricing based on framework count and company size",{"feature":6478,"episki":6480,"competitor":6479},{"feature":6624,"episki":6625,"competitor":6626},"Control management","Linked control graph with cross-framework reuse and ownership","Control library with automated testing and monitoring",{"feature":6628,"episki":6629,"competitor":6630},"Evidence collection","Manual uploads with structured ownership and reuse across frameworks","Automated evidence collection with 100+ integrations",{"feature":6632,"episki":6500,"competitor":6633},"AI assistance","AI-powered compliance automation",{"feature":6635,"episki":6636,"competitor":6637},"Risk management","Risk registers with remediation tracking tied to controls","Built-in risk management with scoring and treatment plans",{"feature":6639,"episki":6640,"competitor":6641},"Editor experience","Notion-like rich text editor with inline editing","Structured forms and workflow-based interface",{"feature":6643,"episki":6644,"competitor":6645},"Collaboration","Built-in auditor portal, customer portals, and team workspaces","Auditor-facing dashboards and team collaboration features",{"title":6647,"description":6648},"Try episki side by side with Drata","Start a free trial with all features enabled. Import your controls and see the difference.",{"headline":6650,"title":6651,"description":6652,"links":6653},"episki vs Drata","How episki compares to Drata for compliance teams","A head-to-head on pricing, workflow design, and framework flexibility. See why teams that want a faster, more collaborative compliance workspace switch from Drata to episki.",[6654,6656],{"label":6655,"icon":4017,"to":4018},"Start free trial",{"label":6657,"icon":6529,"color":4022,"variant":4023,"to":4024,"target":4025},"See a live demo",{},"\u002Fcompare\u002Fdrata",{"title":6661,"description":6662},"episki vs Drata (2026): Pricing, Flexibility & Why Teams Switch","Compare episki and Drata on pricing, workflow design, and framework flexibility. See why compliance teams switch from Drata to episki.","7.compare\u002Fdrata","rehdI9NC6n1m3mFaD-M9xGliPjg5awlPauCt-LCW_es",{"id":6666,"title":6667,"api":1844,"authors":6668,"body":6674,"category":6851,"date":6852,"description":6853,"extension":279,"features":1844,"fixes":1844,"highlight":1844,"image":6854,"improvements":1844,"meta":6856,"navigation":297,"path":6858,"seo":6859,"stem":6860,"__hash__":6861},"posts\u002F3.now\u002Fdefined-roles-pci-compliance-mistakes.md","Defined Roles in PCI: The Compliance Mistakes That Fly Under the Radar",[6669],{"name":6670,"to":6671,"avatar":6672},"Justin Leapline","https:\u002F\u002Fwww.linkedin.com\u002Fin\u002Fjustinleapline\u002F",{"src":6673},"\u002Fimages\u002Fjustinleapline.png",{"type":8,"value":6675,"toc":6843},[6676,6682,6685,6688,6691,6694,6697,6699,6703,6711,6714,6717,6720,6722,6726,6729,6732,6735,6738,6740,6744,6752,6755,6758,6761,6763,6767,6770,6773,6776,6778,6782,6785,6788,6791,6794,6796,6800,6803,6806,6809,6811,6816,6828,6835,6837],[6677,6678,6679],"blockquote",{},[16,6680,6681],{},"When it comes to PCI DSS, most organizations focus on the technical controls — encryption, access management, logging. But one of the most persistent failure points isn't technical at all. It's the question of who owns what. Undefined or poorly assigned roles quietly undermine even the most well-resourced compliance programs. This post breaks down the most common role-related mistakes security leaders make in PCI — and what to do differently.",[6683,6684],"hr",{},[16,6686,6687],{},"Most PCI compliance failures don't happen because teams don't know the standard.",[16,6689,6690],{},"They happen because nobody agreed on who was responsible for following it.",[16,6692,6693],{},"It sounds simple. In practice, it's one of the hardest problems in compliance programs — and one of the least discussed. When a QSA walks in for an assessment and finds gaps, the root cause is often not a missing control. It's a missing owner.",[16,6695,6696],{},"For CISOs leading PCI programs, role clarity isn't a nice-to-have. It's the foundation everything else sits on.",[6683,6698],{},[11,6700,6702],{"id":6701},"mistake-1-treating-pci-ownership-as-an-it-problem","Mistake #1: Treating PCI Ownership as an IT Problem",[16,6704,6705,6707,6708,6710],{},[261,6706,3589],{"href":263}," governs the entire ",[261,6709,3619],{"href":3618}," — and the cardholder data environment touches far more than IT.",[16,6712,6713],{},"It includes how sales teams handle card data over the phone. How finance processes refunds. How third-party vendors connect to your systems. How HR onboards employees who access payment infrastructure. And yet, in most organizations, PCI ownership sits almost exclusively with the security or IT team — while the business units that handle cardholder data daily operate with little awareness of their own obligations.",[16,6715,6716],{},"This creates a structural gap. Controls get implemented technically but not operationally. Policies exist on paper but aren't followed in practice because the people they govern don't know they apply to them.",[16,6718,6719],{},"The fix isn't adding more controls. It's expanding the ownership model. Every team that touches cardholder data needs a defined role in the compliance program — with accountability, not just awareness.",[6683,6721],{},[11,6723,6725],{"id":6724},"mistake-2-confusing-responsible-with-accountable","Mistake #2: Confusing \"Responsible\" with \"Accountable\"",[16,6727,6728],{},"One of the most reliable ways to spot a broken compliance program is to ask two people on the same team who owns a specific PCI requirement. If you get two different answers — or two blank stares — you have an accountability problem.",[16,6730,6731],{},"The distinction between responsibility and accountability matters here. Responsibility is operational: this person performs the task. Accountability is governance: this person owns the outcome. In PCI, these roles are often blurred or duplicated, which means that when something goes wrong, nobody is clearly on the hook — and when audits come around, multiple people claim ownership of the same control without any of them actually running it.",[16,6733,6734],{},"The RACI model (Responsible, Accountable, Consulted, Informed) is a well-worn solution to this problem — but only when applied with rigor. A RACI matrix that was built two years ago and hasn't been updated since an acquisition, a reorg, or a new product launch is often worse than no RACI at all. It creates false confidence.",[16,6736,6737],{},"PCI role assignments need to be reviewed every time the business changes — not just every time the standard does.",[6683,6739],{},[11,6741,6743],{"id":6742},"mistake-3-letting-vendor-relationships-create-ownership-gaps","Mistake #3: Letting Vendor Relationships Create Ownership Gaps",[16,6745,6746,6747,6751],{},"PCI DSS Requirement 12.8 is clear: organizations are responsible for managing the compliance of all ",[261,6748,6750],{"href":6749},"\u002Fglossary\u002Fthird-party-risk","third-party service providers"," who have access to cardholder data. In practice, many organizations interpret this requirement as \"get a copy of their AOC and file it.\"",[16,6753,6754],{},"That's not management. That's documentation.",[16,6756,6757],{},"The gap shows up when a vendor has a breach, when a third-party integration introduces a vulnerability, or when an assessor asks how the organization monitors the compliance posture of its vendors — and the answer is \"we check their certificate once a year.\"",[16,6759,6760],{},"Vendor ownership in PCI requires a named internal owner for each critical third-party relationship. Someone who understands what that vendor does, what data they access, what their contractual security obligations are, and what the escalation path looks like if something goes wrong. Without that, vendor risk exists on paper but is managed by nobody.",[6683,6762],{},[11,6764,6766],{"id":6765},"mistake-4-role-assignments-that-dont-survive-personnel-changes","Mistake #4: Role Assignments That Don't Survive Personnel Changes",[16,6768,6769],{},"PCI roles are often documented at the person level — \"Sarah owns firewall management,\" \"Marco is responsible for log review\" — rather than at the function level. When Sarah leaves or Marco moves to a different team, the role doesn't transfer cleanly. Institutional knowledge walks out the door, and the new person inherits a responsibility they weren't briefed on.",[16,6771,6772],{},"This is especially dangerous in small security teams, where one person often carries multiple PCI functions. When that person leaves without a proper transition, entire sections of the compliance program can become effectively unowned — sometimes for months before anyone notices.",[16,6774,6775],{},"Sustainable role assignment means documenting at the position level, not the individual level. It means keeping role documentation alive and connected to onboarding processes, so that new team members understand their compliance obligations from day one. And it means building succession into the program architecture, not treating it as an afterthought.",[6683,6777],{},[11,6779,6781],{"id":6780},"mistake-5-assuming-the-ciso-owns-everything-that-isnt-assigned-elsewhere","Mistake #5: Assuming the CISO Owns Everything That Isn't Assigned Elsewhere",[16,6783,6784],{},"In many organizations, the CISO is the implicit owner of last resort. If a PCI requirement doesn't have a clear owner, it defaults upward — and eventually lands on the security leader's desk.",[16,6786,6787],{},"This is a governance problem masquerading as an efficiency problem. When the CISO is the catch-all for unassigned compliance obligations, two things happen: the CISO is spending time on operational tasks that should be delegated, and the organization's compliance program lacks the distributed ownership structure it needs to function at scale.",[16,6789,6790],{},"The CISO's role in PCI should be strategic: defining the program, setting the accountability structure, owning the relationship with assessors, and reporting to the board on risk posture. The moment the CISO is personally responsible for reviewing firewall rule changes or validating log configurations, something in the ownership model has broken down.",[16,6792,6793],{},"A well-structured PCI program distributes operational ownership to the teams closest to the work — and gives the CISO visibility into all of it without requiring their direct involvement in any of it.",[6683,6795],{},[11,6797,6799],{"id":6798},"what-getting-it-right-actually-looks-like","What Getting It Right Actually Looks Like",[16,6801,6802],{},"The organizations that manage PCI compliance most effectively share a few traits. Their role assignments are documented at the function level and reviewed on a regular cadence. Their business unit owners understand their obligations — not just their technical ones. Their vendor relationships have named internal owners with active oversight responsibilities. And their CISO has clear visibility into the program without being buried in its day-to-day operations.",[16,6804,6805],{},"None of this requires a larger team. It requires a more deliberate structure.",[16,6807,6808],{},"PCI compliance isn't won or lost in the technical controls. It's won or lost in the clarity of who owns them, who monitors them, and who is accountable when they fail.",[6683,6810],{},[16,6812,6813],{},[64,6814,6815],{},"Is your PCI ownership model as clear as you think it is?",[16,6817,6818,6819,6823,6824,6827],{},"At ",[261,6820,6822],{"href":6821},"\u002F","episki",", we help security leaders build compliance programs where accountability is real — not just documented. From role mapping to third-party oversight to board-level reporting, we work alongside your team to make sure your ",[261,6825,6826],{"href":263},"PCI"," program holds up when it matters most.",[16,6829,6830],{},[261,6831,6834],{"href":4024,"rel":6832},[6833],"nofollow","Let's talk →",[6683,6836],{},[16,6838,6839],{},[6840,6841,6842],"em",{},"Compliance on paper isn't compliance. It's paperwork.",{"title":267,"searchDepth":268,"depth":268,"links":6844},[6845,6846,6847,6848,6849,6850],{"id":6701,"depth":268,"text":6702},{"id":6724,"depth":268,"text":6725},{"id":6742,"depth":268,"text":6743},{"id":6765,"depth":268,"text":6766},{"id":6780,"depth":268,"text":6781},{"id":6798,"depth":268,"text":6799},"craft","2026-04-15","Unclear ownership is one of the most common — and costly — failures in PCI compliance. Here's what security leaders get wrong about defining roles, and how to fix it.",{"src":6855},"\u002Fimages\u002Fblog\u002FPCI.jpg",{"slug":6857},"defined-roles-pci-compliance-mistakes","\u002Fnow\u002Fdefined-roles-pci-compliance-mistakes",{"title":6667,"description":6853},"3.now\u002Fdefined-roles-pci-compliance-mistakes","0u0CncSJsrHMYJZWMH_BzWgau-vuQTBQ7NdBBVQMz7Q",{"id":6863,"title":6864,"advantages":6865,"body":6887,"checklist":6894,"cta":6903,"description":6891,"extension":279,"faq":1844,"hero":6906,"meta":6914,"name":6915,"navigation":297,"path":6916,"resources":6917,"seo":6930,"slug":6933,"stats":6934,"stem":6944,"__hash__":6945},"industries\u002F6. industry\u002F1.healthcare.md","Healthcare",[6866,6873,6880],{"title":6867,"description":6868,"bullets":6869},"PHI-aware control mapping","Map administrative, technical, and physical safeguards to your stack without rebuilding every audit.",[6870,6871,6872],"Track EHR, identity, and cloud evidence with structured ownership","Track segmentation, backups, and log retention against HIPAA safeguards","Map once for HIPAA and reuse for HITRUST or regional requirements",{"title":6874,"description":6875,"bullets":6876},"Clinician-friendly workflows","Keep nurses, clinicians, and ops aligned without burying them in tickets.",[6877,6878,6879],"Role-aware tasks routed to the right owner with due dates","Playbooks show “what good looks like” for PHI handling","Attestations and approvals captured inline for auditors",{"title":6881,"description":6882,"bullets":6883},"Auditor and partner collaboration","Give regulators, payers, and partners scoped access instead of email threads.",[6884,6885,6886],"Auditor portal with threaded Q&A per safeguard","Secure uploads with expirations and access controls","Exports for SOC 2, PCI, or privacy questionnaires",{"type":8,"value":6888,"toc":6892},[6889],[16,6890,6891],{},"Healthcare buyers move fast when they trust your safeguards. episki keeps PHI protections documented, monitored, and shareable without slowing product or patient care.",{"title":267,"searchDepth":268,"depth":268,"links":6893},[],{"title":6895,"description":6896,"items":6897},"Healthtech compliance checklist","Use this inside your trial to assign owners, attach evidence, and track renewals.",[6898,6899,6900,6901,6902],"HIPAA safeguard library mapped to your systems","BAA tracker with renewal reminders and risk scoring","Incident response runbooks with timelines and owners","Access, logging, and backup verification tasks","Third-party risk reviews tied to PHI data flows",{"title":6904,"description":6905},"Launch a healthtech-ready workspace","Connect your stack, invite stakeholders, and show PHI protections the same day.",{"headline":6907,"title":6908,"description":6909,"links":6910},"HIPAA-grade governance without slowing clinicians","Keep PHI protections provable across cloud apps, clinics, and vendors","episki maps safeguards, automates evidence, and gives auditors scoped access so healthtech teams can keep shipping.",[6911,6913],{"label":6912,"icon":4017,"to":4018},"Start healthtech trial",{"label":4020,"icon":6529,"color":4022,"variant":4023,"to":4024,"target":4025},{},"healthcare and healthtech","\u002Findustry\u002Fhealthcare",{"headline":6918,"title":6918,"description":6919,"items":6920},"Healthcare enablement kit","Keep leadership, clinicians, and auditors aligned on the same story.",[6921,6924,6927],{"title":6922,"description":6923},"PHI data flow deck","Share sanitized diagrams plus segmentation notes for customers and partners.",{"title":6925,"description":6926},"Board + payer brief","Summarize control health, incidents, and remediation in plain language.",{"title":6928,"description":6929},"Auditor-ready workspace","Prebuilt template for requests, evidence, and walkthrough scheduling.",{"title":6931,"description":6932},"Healthcare Compliance Software","HIPAA-ready GRC for healthtech teams. Map safeguards, track PHI evidence, and collaborate with auditors in one secure workspace. Start your free trial.","healthcare",[6935,6938,6941],{"value":6936,"description":6937},"30-day rollout","Move from baseline controls to monitored safeguards in under a month.",{"value":6939,"description":6940},"PHI-safe sharing","Role-based portals keep BAAs, policies, and diagrams organized and protected.",{"value":6942,"description":6943},"Continuous watch","Drift detection across access, logging, vendors, and incidents.","6. industry\u002F1.healthcare","831E5Bdk5x1SUBhE8YrTZtQjqMJj9Q3vjQivX_AG0IQ",1776395341932]