Which should a payment team pursue first, and can CIS Controls replace PCI DSS?
CIS Controls cannot replace PCI DSS validation, so PCI DSS v4.0.1 is pursued regardless of what else the team adopts. A team with a cardholder data environment (CDE) must still produce a Report on Compliance or a Self-Assessment Questionnaire with an Attestation of Compliance, because PCI SSC states that certificates are not recognized as validation. The payment brands decide who must validate, so the first task is to confirm with the acquirer or brand which validation level and document type applies. CIS Implementation Groups are useful for structuring the wider program around that obligation: IG1 covers the essential hygiene that every enterprise should have, and IG2 adds safeguards for organizations with more complex operations and sensitive data. Neither group changes what the QSA or the SAQ requires.
Doing CIS first makes sense in a narrower set of conditions. If the organization has no formal security program, no current asset inventory and little documented control ownership, starting with IG1 builds the habits that PCI DSS later tests, such as knowing where card data flows and who owns each control. The CIS mapping in the Navigator links several IG1-era safeguards to PCI DSS v4.0 requirements. For example, Safeguard 1.2 maps to PCI DSS v4.0 requirement 11.2.1, and Safeguard 2.1 maps to requirements 1.2.5 and 6.3.2. Treat those links as a starting point for your own mapping, not as proof that a safeguard satisfies a requirement. Confirm each mapping against the PCI DSS text with your QSA.
When the team already operates a defined CDE, PCI scope should set the priority order, not the CIS sequence. Segmentation, the list of in-scope systems and the quarterly ASV scans that Visa requires at merchant and service provider levels have fixed deadlines and cannot be replaced by a compensating control if they are missed. Ask your QSA or acquirer which periodic activities are on the calendar, then assign CIS safeguards to fill the gaps around them. The annual penetration test and the evidence it produces also need their own scoping decision, so they should not depend on a CIS safeguard being marked complete. Confirm the current assessment window and document type with your assessor before setting the plan.
How PCI DSS and CIS Controls differ on scope, obligation and proof
This table compares who owns each source, who must comply, how each is structured, what it costs to use and what evidence it produces. Read it as a split between a payment standard enforced through brand rules and a free prioritized safeguard set that does not replace any compliance scheme.
| Dimension | PCI DSS v4.0.1 | CIS Controls v8.1 |
|---|---|---|
| Owner and maintainer | PCI Security Standards Council, which does not enforce compliance itself | Center for Internet Security, a US 501(c)(3) nonprofit |
| Who must comply | Entities that store, process or transmit cardholder data, or could affect the cardholder data environment, as decided by the individual payment brands | No one is required to adopt the Controls; they are free for any organization to use to improve its own cybersecurity |
| Structure | 12 principal requirements grouped under six goals | 18 Controls containing 153 Safeguards, each tagged with an asset class, a security function and Implementation Groups |
| Prioritization | Applies to every in-scope system; no tiering by organization size | IG1 (56 Safeguards) is baseline hygiene, IG2 adds 74 for more complex enterprises, IG3 adds the remaining 23 for regulated, sensitive environments |
| Cost of use | Standard is published free, but validation requires a QSA for a ROC or a self-assessment with an AOC, and ASV scans | Free to use internally; commercial use under CC BY-NC-ND 4.0 requires CIS's prior approval, and CIS also offers paid services |
| Proof produced | Report on Compliance or Self-Assessment Questionnaire, each with an Attestation of Compliance; certificates are not accepted | No certificate or attestation; organizations produce their own evidence, and CIS says the Controls do not replace any compliance scheme |
| Quarterly ASV scans | Required for in-scope entities, and missed periodic activities cannot be fixed by compensating controls | Not a CIS requirement, though some Safeguards cover vulnerability management that can feed PCI evidence |
Can CIS Implementation Groups serve as the security baseline around a cardholder data environment?
IG1 can give a cardholder data environment (CDE) a sound hygiene baseline, but it cannot stand in for the PCI DSS requirements that apply to it. IG1 holds 56 Safeguards and CIS defines it as essential cyber hygiene and a minimum standard for every enterprise. IG2 adds 74 Safeguards for enterprises with more operational complexity that often hold sensitive information, bringing the total to 130. IG3 adds the remaining 23, aimed at regulated, sensitive assets facing sophisticated attacks. For a payment environment, IG2 is the more realistic starting point for most merchants and service providers with multiple departments and sensitive data, because it reaches the asset inventory, access and logging work that a CDE depends on. Confirm with your QSA which requirements in PCI DSS v4.0.1 your environment must meet directly, since no IG level substitutes for them.
The mapping in the CIS Controls Navigator for v8.1 shows where the two sets overlap. For example, Safeguard 2.1 links to PCI DSS v4.0 requirements 1.2.5 and 6.3.2, and Safeguard 1.2 links to requirement 11.2.1. These links tell you where a CIS safeguard supports evidence you will need anyway, not that the safeguard satisfies the requirement. Requirements such as the scope and segmentation controls, the quarterly ASV scans, the annual penetration tests and the ROC or SAQ with its AOC still need their own specific controls, testing and signed documentation. CIS states that the Controls do not replace any regulatory or compliance scheme, so treat IG implementation as the hygiene layer beneath those obligations.
The Controls Assessment Specification is the piece that makes an IG program measurable, but it has limits. For each Safeguard, the CAS defines the inputs, operations, measures and metrics used to verify implementation. CIS says it covers what to measure, not how, so your team must write the procedure, the tooling and the evidence format. Ask any implementation partner to show, for each CDE-relevant Safeguard, the measure, the data source, the owner and the retained artifact, and to state which of those artifacts the QSA has agreed to accept.
Where CIS Safeguards map to PCI DSS v4.0 requirements
CIS publishes mappings in the CIS Controls Navigator that link individual Safeguards to PCI DSS v4.0 requirements and to other frameworks. The cards below show the mappings that matter most for a cardholder data environment, along with the check every mapping needs before it goes into a PCI evidence file.
Safeguard 1.2 and requirement 11.2.1
CIS Safeguard 1.2 sits under the asset inventory controls in v8.1, and the Navigator links it to PCI DSS v4.0 requirement 11.2.1, which concerns internal vulnerability scanning. The link is useful for explaining how an inventory of devices feeds a scanning schedule, but it does not replace the scan itself. Confirm with your QSA which systems in scope must appear in the scan population and how the scan results are retained as evidence.
Safeguard 2.1 and requirements 1.2.5 and 6.3.2
CIS Safeguard 2.1 concerns software inventory, and the Navigator maps it to PCI DSS v4.0 requirements 1.2.5 and 6.3.2. Requirement 1.2.5 covers the services, protocols and ports allowed in the network, while 6.3.2 covers the inventory of bespoke and third-party software components. A single software inventory can support both, but the PCI evidence must show the inventory is complete for the cardholder data environment.
Safeguard 2.1 links to ISO and SOC 2
The same Safeguard 2.1 mapping also links to ISO/IEC 27001:2022 Annex A 5.9 and to SOC 2 CC3.2 and CC6.1. Teams that hold an ISO or SOC 2 report can reuse one software inventory across frameworks, but each framework still tests it on its own terms. Ask your QSA whether SOC 2 evidence can be reviewed and reused for PCI DSS, since a QSA cannot rely on SOC 2 reports directly.
Mappings are not equivalence statements
NIST and CIS mappings show where two texts address a similar topic, not that meeting one satisfies the other. CIS maintains its mappings, but the reader must confirm each link against the current PCI DSS v4.0.1 wording before relying on it. Record the mapping version, the requirement number and the reviewer's decision in the assessment file so that a QSA can trace every claim.
Periodic tests still need PCI evidence
A CIS Safeguard that mentions scanning or testing does not remove the PCI requirement for quarterly ASV scans or annual penetration tests. Visa requires quarterly scans by an Approved Scanning Vendor, and a missed scan cannot be fixed by compensating controls. Plan the scan calendar as a PCI item, then use CIS only to explain the process behind it.
Which PCI requirements still need their own evidence
Mapping CIS Controls to PCI DSS does not produce PCI evidence. Some PCI DSS activities have fixed cadences and must be performed and documented by specific parties, and a CIS-based program cannot substitute for them. The first of these is external vulnerability scanning. Visa requires quarterly network scans by an Approved Scanning Vendor at every merchant and service provider level, with Level 4 merchants scanning where applicable. According to PCI SSC FAQ 1572, a missed periodic activity cannot be repaired with a compensating control. A missed quarterly ASV scan leaves a gap in evidence that you must address through corrective action, and that gap can delay your compliance. Put the ASV scan dates on the same calendar as your CIS vulnerability management work, and confirm with your acquirer or Visa which scan obligations apply to your merchant or service provider level.
Penetration testing is the second item that CIS safeguards only support. Confirm the current annual and after-change testing cadences directly in PCI DSS v4.0.1 and in the reporting templates your assessor will use, because the standard is the authority here and this page does not restate those intervals. Your reporting path then depends on your validation type. A Report on Compliance is completed by a Qualified Security Assessor, and a Self-Assessment Questionnaire is completed by the entity itself. Each produces an Attestation of Compliance on the official PCI SSC template. PCI SSC FAQ 1220 is explicit that certificates are not recognized as validation, so a CIS Controls certificate or a CIS-branded assessment cannot stand in for the AOC.
SOC 2 reports deserve careful handling. A QSA cannot rely on a SOC 2 or SOC 3 report for a PCI DSS assessment, but the QSA may reuse evidence from those audits after reviewing it independently, as described in PCI SSC FAQ 1567. For a team that already runs a SOC 2 examination, this means organizing evidence so the QSA can trace each PCI requirement to a dated, reviewed artifact. Ask your QSA early which SOC 2 evidence they will accept, and keep CIS Controls outputs such as configuration baselines and asset inventories in a form that can be sampled and independently checked.
Who assesses each framework and what it issues
This table compares who checks PCI DSS and CIS Controls, what document each produces and how often the work repeats. Read it to see which proof a payment brand or acquirer may ask for and which parts of the CIS Controls you can run and evidence yourself.
| Aspect | PCI DSS v4.0.1 | CIS Controls v8.1 |
|---|---|---|
| Who assesses | A Qualified Security Assessor completes a Report on Compliance, or the entity completes a Self-Assessment Questionnaire, depending on its validation level and the payment brand's rules | No assessor program. Teams self-assess, or an accredited CIS SecureSuite member may help under CIS Controls Accreditation, run with CREST |
| Output document | Report on Compliance or SAQ, each with an Attestation of Compliance. A certificate is not recognized as validation | No attestation or certificate is issued under the Controls themselves. Evidence is internal and per Safeguard |
| Accreditation fees to note | Not applicable to the standard itself. Assessor fees are set by each QSA and the scope agreed with them | CIS lists an application fee of $1,500 for CREST members and $2,500 for non-members for CIS Controls Accreditation |
| Who decides what is required | The payment brands decide which entities must validate and run enforcement. The PCI SSC does not enforce compliance or impose penalties | CIS does not enforce anything. It states the Controls do not replace any regulatory or compliance scheme |
| Scanning and testing | Quarterly external scans by an Approved Scanning Vendor, and the annual validation cycle. Missed scans cannot be fixed with compensating controls | No mandated scan frequency. Teams set their own cadence for each Safeguard |
| Assessment cycle | Annual validation plus quarterly scans | No mandated cycle |
| Self-assessment tool | The SAQ and PCI SSC templates, with a QSA-led ROC where required | CIS-Hosted CSAT lets teams delegate questions, set deadlines, upload evidence and export results, with cross-mappings to PCI DSS |
Sequencing CIS Controls work around a PCI DSS program
This sequence sets the cardholder data environment boundary first, then uses CIS Safeguards to build the security baseline around it, so the ROC or SAQ evidence reflects one consistent scope. The QSA or your assessor confirms the final scope before the evidence is assembled.
Define the cardholder data environment and segmentation
Map every system, network path, person and process that stores, processes or transmits cardholder data, or could affect the security of that environment. Document the segmentation controls that separate the CDE from the rest of the estate. The QSA sets the final scope, so bring this inventory to the scoping discussion early. The step closes when the scope statement and data flow diagrams are approved by the assessor.
Map current controls to PCI DSS requirements
Inventory existing controls and link each one to the PCI DSS v4.0.1 requirements it would need to satisfy, using the CIS Controls Navigator v8.1 mapping to PCI DSS v4.0 as a starting point rather than a finished answer. Record gaps, owners and the evidence each control produces. The mapping is complete when every in-scope requirement has either a control, a documented customized approach or a known gap with an owner.
Close IG1 hygiene gaps outside the CDE
Apply the 56 IG1 Safeguards to systems across the wider enterprise, including endpoints, accounts and asset inventories that support the CDE without sitting inside it. These controls raise the baseline for the whole organization and reduce the chance that an ordinary compromise reaches cardholder data. Confirm closure by checking each Safeguard against its CAS measures and recording the results in your control register.
Apply IG2 Safeguards for enterprise-scale gaps
Where the organization is operating at enterprise scale, with multiple departments, sensitive data and specialized technology, add the IG2 Safeguards that address those conditions. Assign ownership across teams with different risk profiles and set review points in the change process. The step is complete when IG2 Safeguards that map to in-scope PCI requirements, such as those mapped to requirements 1.2.5 and 6.3.2 in the CIS mapping, have implementation evidence and a named owner.
Reuse CAS measures as evidence inputs
Use the measures and metrics in the CIS Controls Assessment Specification for each Safeguard as the inputs for your own evidence, such as configuration exports, log samples and review records. CAS states what to measure but not how, so your team defines the method and the sampling approach. The QSA decides whether the resulting evidence satisfies each PCI requirement, so agree the format with the assessor before collection begins.
Schedule ASV scans and penetration tests
Book quarterly external vulnerability scans with an Approved Scanning Vendor and annual penetration tests against the CDE, as PCI DSS requires. Missed periodic activities cannot be fixed with compensating controls, so put these dates in a calendar with owners and escalation paths. The step closes when the scan and test schedule is confirmed in writing, and each ASV scan result is retained with its remediation record.
Assemble the ROC or SAQ evidence package
Gather the scope statement, control mappings, CAS-based evidence, ASV scan reports and penetration test results into the evidence set for the applicable PCI SSC template. A Report on Compliance is completed by a QSA, while an SAQ is completed by the entity and backed by an Attestation of Compliance. Certificates are not recognized as validation. The sequence is complete when the assessor accepts the package and the AOC is signed on the correct template.
What do buyers ask before hiring help for PCI DSS and CIS Controls?
Can implementing CIS Controls satisfy PCI DSS?
No. CIS Controls do not replace PCI DSS, and implementing them does not produce a PCI DSS validation. PCI DSS is a mandatory standard assessed through a Report on Compliance or a Self-Assessment Questionnaire, each with an Attestation of Compliance. CIS publishes a mapping in the CIS Controls Navigator for v8.1 that links many safeguards to PCI DSS v4.0 requirements, so the Controls can be a useful baseline. Those mappings still need to be checked against the requirement wording by your QSA or assessor, and the PCI-specific evidence still has to be produced.
What drives the effort of a PCI DSS assessment?
Four factors matter most: the size of the cardholder data environment, the number of systems and third parties inside or connected to it, the validation level or SAQ type that already applies, and how mature your evidence collection is. A small scope with centralized logging and current asset inventories is far less work than a sprawling environment where evidence lives in tickets and personal folders. Ask any provider to state which of these factors it assumed in a quote.
Is the CIS Controls framework free to use?
The Controls are free for any organization to use to improve its own cybersecurity. The content is licensed under Creative Commons Attribution-NonCommercial-NoDerivatives 4.0, and commercial use requires CIS's prior approval. Paid items are separate: CIS-Hosted CSAT and CIS Controls Accreditation carry their own terms, and any consulting or implementation work is priced by the firm doing it. Check the license terms with CIS if you plan to reuse the text in a commercial product or service.
How long does a PCI DSS or CIS implementation take?
No duration can be stated responsibly without a defined scope, so do not accept a timeline before one exists. Timing depends on scope, the state of existing controls, how quickly system owners respond, and the assessment calendar your acquirer or payment brand sets. Ask for a written scope with deliverables and milestones, and confirm the assessment timing with your QSA before work starts. Most DeployOpen engagements are fixed-scope, with scope and timelines agreed in writing before work begins.
What does the client team need to provide?
The engagement needs named system owners who can explain what each system does and who can approve changes, a current inventory of devices, software, data stores and network segments, and read access to logs for the systems in scope. Your team also needs to provide network diagrams, data flow information, prior assessment records and access to the people who run vulnerability scans and penetration tests. Missing inventories are one of the most common reasons evidence gathering slows down, so confirm these inputs in the written scope.
Can a team complete PCI DSS on its own?
It can be possible for a scope that qualifies for a Self-Assessment Questionnaire, but eligibility depends on how cardholder data is handled, whether systems can affect the cardholder data environment, and which SAQ type applies. Confirm eligibility with your acquirer or payment brand before you assume you can self-assess. Quarterly external scans must still come from an Approved Scanning Vendor, and periodic activities that are missed cannot be fixed with compensating controls, so plan that calendar from the start.
What does a quote for this work usually include?
A quote should list the scope boundaries, the systems and locations included, the deliverables, the testing and evidence tasks, and what the client must supply. Costs fall into one-time work such as scoping, gap analysis, hardening and documentation, and recurring work such as scans, periodic reviews and retainers for ongoing support. Ask which items are fixed-scope and which are time-based, who pays for the QSA or assessor, and what changes if the scope grows. DeployOpen does not publish a price list, and a quote follows from the written scope.
What to ask for in a quote for combined PCI and CIS work
Ask every bidder to separate one-time work from recurring work before comparing totals. One-time work covers scoping the cardholder data environment, a gap analysis against the PCI DSS v4.0.1 requirements, and remediation. Recurring work covers the quarterly scans that Visa requires from an Approved Scanning Vendor, the annual penetration test, and the annual validation (a ROC or SAQ with its AOC). Treat the CIS side as a separate line: CIS Controls content is free to use, so its cost sits in internal staff time, any tooling such as CIS-Hosted CSAT, and the implementation work itself. Ask whether each figure covers the assessor, the vendor, your staff or the remediation, because the same number can mean very different things.
Each cost component has a different payer and a different driver. A QSA or assessor fee depends on the scope you define, so a smaller cardholder data environment with fewer systems in scope usually costs less to assess. ASV and penetration test vendors price against the systems and networks they must test. Internal staff time rises when evidence is spread across teams, and tooling costs depend on the number of users and whether you host it yourself. Remediation is the least predictable item, so ask the vendor to state the assumptions behind any estimate and what would change them. Note that a missed quarterly ASV scan cannot be fixed with a compensating control and may delay compliance, so the schedule for recurring scans belongs in the quote as a dated commitment, not a footnote.
Require a fixed-scope written agreement whose deliverables are mapped to specific identifiers: the PCI DSS v4.0.1 requirement IDs in scope, such as 1.2.5 or 6.3.2 where they apply, and the CIS Safeguard IDs that support them, such as Safeguard 2.1. A mapping that names both sets lets you check that each PCI requirement has a documented owner and evidence source, and that no Safeguard is claimed twice without explanation. Ask for the mapping as a deliverable with a version date, and confirm with the vendor and your QSA how they will treat the mapping, because CIS's mapping does not replace the assessor's own testing. Ask also which items are excluded, which evidence the client must produce, and how change requests after signature are priced.
How DeployOpen prepares PCI DSS and CIS Controls readiness
DeployOpen is a Chainscore Labs company that plans, implements, hardens and documents self-hosted open-source platforms inside the client's own infrastructure. For PCI DSS and CIS Controls work, we prepare the systems, controls and evidence that a QSA or other assessor will review, without issuing any audit report or attestation ourselves.
How we scope
- Written scope fixes which systems, networks and cardholder data flows sit inside the cardholder data environment.
- Scope documents which CIS Safeguards and Implementation Groups apply, and which PCI DSS v4.0.1 requirements they map to.
- Scope names which evidence sits with your QSA, your ASV or your own team, including ASV scans and penetration tests.
How we build
- We configure self-hosted platforms in your cloud accounts, data centers or air-gapped networks to meet agreed Safeguards.
- We build test procedures against each Safeguard so your team can confirm it is implemented and working as designed.
- We run security testing of applications, APIs and infrastructure in scope, and report findings against the agreed requirements.
How we hand over
- Deliverables include configuration records, control mappings and evidence packs organized for your assessor's review.
- Documentation states which requirements remain with your team, your QSA or your ASV, so responsibilities are explicit.
- Handover sessions walk your staff through running the controls, collecting evidence and repeating the test steps.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work is complete.
- Retainers can cover periodic evidence collection, control reviews and remediation tracking between assessment cycles.
- Before any quote, confirm with us which PCI DSS v4.0.1 and CIS v8.1 items your assessor expects to see in the evidence.
