PaysecVisit Website →
← Back to blog

PCI Scope Reduction: Payment Teams Must Prove What’s Out

October 17, 2026
PCI Scope Reduction: Payment Teams Must Prove What’s Out

You can shrink your PCI scope when cardholder data is removed or isolated and the isolation is provably effective. The main levers are eliminating stored card numbers, tokenization and third-party vaults, point-to-point encryption (P2PE), network segmentation, and outsourcing to PCI-validated processors. Every reduction needs documented verification, such as segmentation tests and a scope confirmation you repeat on a schedule.

TL;DR:

  • Delete unnecessary card numbers and search databases, logs, tickets, backups, and replicas; customer service should use secure payment links instead of free text.
  • Tokenization can remove systems from scope when only nonreversible tokens reach them; encrypted PAN remains reversible and generally keeps storing systems in scope.
  • For card present payments, deploy a PCI validated P2PE solution only within its approved configuration, and maintain terminal inventories, tamper checks, and chain of custody.
  • A validated processor reduces scope only if PAN never reaches your systems; retain its current compliance attestation and responsibility matrix, and review integration changes.
  • Keep systems in scope until tests prove isolation; document results, and reconfirm scope every 12 months and after significant changes.
Paysec
Make Payment Costs More Transparent
PaySec offers flexible payment options, detailed transaction reporting, and payment compliance for businesses seeking clearer processing costs.
Visit PaySec

Table of Contents

What PCI DSS scope means and why you assume in-scope first

PCI DSS scope is the set of people, processes and technologies that store, process or transmit cardholder data, plus anything that can affect the security of those systems. Getting this definition right is the foundation of every tactic in this article.

Three terms matter most:

  • Cardholder data environment (CDE): the systems that store, process or transmit the primary account number (PAN) or sensitive authentication data, and the people and processes around them.
  • Connected-to systems: components that are not in the CDE but can communicate with it, such as a shared database server, a monitoring host or a jump box.
  • Security-impacting systems: components that do not touch card data but can affect how the CDE is secured, such as identity providers, patch servers, logging platforms and admin workstations.

The PCI Security Standards Council recommends a "default to in-scope" approach: treat a system as in scope until you verify otherwise. That posture protects you from the most common scoping error, which is declaring a system out of scope because it is inconvenient to secure.

Applicability follows the same logic. The Council's guidance says a requirement can be marked not applicable only with documented evidence that the system cannot access cardholder data or cryptographic keys.

PCI DSS v4.x also added a rule that you document and confirm your scope at least every 12 months and upon significant change to the in-scope environment. Service providers face a more frequent cadence. Scoping is no longer a one-time exercise before an assessment. It is a recurring control with an owner and an evidence trail.

Why reducing PCI scope pays off

Fewer in-scope systems means fewer systems to assess, patch, log, monitor and document. Costs fall in three places: the assessment itself, the remediation work that follows, and the daily control effort that never ends once a system is in the CDE.

  • Lower assessment and remediation effort. Each in-scope server, subnet and account adds evidence to collect and controls to test.
  • A smaller attack surface. A tight CDE is easier to monitor, easier to place under change control, and gives attackers fewer paths to card data.
  • Simpler operations. Logging, access reviews and vulnerability scans cover a short, well-understood list of assets instead of a sprawling one.

These benefits appear only under one condition: the controls behind the reduction have to be real and provable. PCI SSC practitioner guidance frames scope reduction as a risk-management strategy, not a way to skip controls, and expects documented, verified evidence (often penetration testing) that out-of-scope systems cannot affect the CDE.

QSA Jacob Ansari makes the same point in the Council's assessor Q&A. He warns that organizations often confuse an "inconvenience assessment" with a "risk assessment" and notes that the teams that succeed isolate card data by design instead of bolting segmentation on later.

Design for isolation first: the cheapest scope reduction is the one built into the architecture, as the Council's assessor guidance on scoping and segmentation describes, because retrofitting segmentation means proving it after the fact.

The core strategies at a glance

Think of scope reduction as a toolbox. Most teams combine several tools, because each one removes a different kind of exposure.

  • Eliminate storage: stop keeping PAN you do not need. Scoping impact: high, because removed data cannot put a system in scope.
  • Tokenization and vaulting: replace PAN with tokens issued by a vault. Scoping impact: high for systems that only ever see tokens.
  • P2PE: encrypt at the card reader and decrypt only in a validated environment. Scoping impact: high for card-present channels.
  • Network segmentation and microsegmentation: isolate the CDE from everything else. Scoping impact: medium to high, depending on how well you verify it.
  • Cloud isolation: dedicated projects, accounts and private networks for the CDE. Scoping impact: medium to high.
  • Outsourcing to validated providers: let a PCI-validated processor handle PAN. Scoping impact: high when PAN never touches your systems.

Combining tactics is the norm. Tokenization removes PAN from your application, segmentation contains what remains, and outsourcing handles the part you would rather not own.

Eliminate unnecessary cardholder data storage

The simplest scope reduction is to stop storing card numbers you have no business reason to keep. Data that does not exist cannot be breached, and systems that never hold it do not belong in your CDE.

Work through it in this order:

  1. Map your data flows. Trace every path a card number takes, from capture to settlement, including support tools and exports.
  2. Run automated discovery. Scan databases, file shares, tickets, spreadsheets, email archives, application logs and backups for PAN patterns. Manual interviews miss the forgotten copies.
  3. Set retention rules. Keep card data only as long as a documented business or legal need requires, then delete it on a schedule.
  4. Automate deletion. Scheduled purges beat reminders. Apply them to production data, test data and replicas.
  5. Mask or encrypt what must stay. Where a team needs to see part of a number, show only the digits they require. Use field-level encryption for any stored value that remains.
  6. Sanitize logs and backups. Fix the application that wrote PAN to a log, then purge the historical entries and any backup copies.
  7. Confirm secure deletion. Verify that deleted data is unrecoverable from the storage tier it lived on.

Pro Tip: Search your backups and log archives before you search production. Teams routinely clean the live database and then discover years of card numbers sitting in a nightly dump.

Customer service is a frequent leak. Agents who take card details over chat or email create PAN in ticketing systems, and every one of those systems joins the CDE. Replace free-text capture with a secure payment link or a hosted entry form so the number never lands in your tools.

Tokenization and vaulting

Tokenization replaces the PAN with a surrogate value, a token, that has no exploitable meaning outside the vault that issued it. Your applications store and pass tokens. The vault, operated by a validated provider or inside a tightly controlled enclave, holds the real number.

Vault maps card data to reusable payment tokens

This differs from encryption. Encrypted PAN can be reversed by anyone holding the key, so systems that store it generally stay in scope. A token cannot be mathematically reversed. It is only a reference, and only the vault can map it back.

The usual pattern is a vault API. The customer's card details go straight from the browser or device to the vault, bypassing your servers. Your application receives only a token and uses it for charges, refunds and recurring billing. Because PAN never enters your infrastructure, your web servers, application tier and databases can fall out of the connected-to set.

Design decisions that determine whether the reduction holds:

  • Vault placement: run the vault in a separate, isolated environment, or use a PCI-validated third-party vault.
  • Redemption rules: limit which services can exchange a token for a real number, and require strong authentication for each one.
  • Audit logging: record every detokenization request and review the log.
  • Network isolation: keep the vault on a restricted network path, reachable only by the systems that need it.
  • Token design: use tokens with no mathematical relationship to the PAN.

Assessors look for proof that the reduction is real. Expect to show that no PAN appears in merchant logs, databases or backups, that token redemption is tightly controlled, and that your documentation matches what the systems do.

Pro Tip: Test your own pipeline by submitting a known test card number and searching every log, queue and data store for it afterward. If it turns up anywhere in your environment, that system is still in scope.

If you want a payment gateway without building your own, our payment gateway gives developers an API.

Point-to-point encryption (P2PE)

P2PE protects card data from the moment of capture. The payment terminal encrypts the card number at entry, the data stays encrypted through your network, and decryption happens only inside a validated environment operated by the P2PE provider. Your systems carry ciphertext they cannot read.

When you use a PCI-validated P2PE solution and deploy it as validated, your point-of-sale network, store systems and the networks between them can see far less PAN, and in many cases none. That can shrink both the number of systems in scope and the number of requirements that apply to them.

P2PE does not make everything disappear. You still own terminal handling, tamper inspection, the physical security of devices, and the integrity of the way you deployed the solution. A solution deployed outside its validated conditions loses its scoping benefit.

What assessors typically check:

  • Validation: the solution is listed as validated and you are using it in the way it was validated.
  • Device inventory: you maintain a current list of terminals, their locations and their serial numbers.
  • Tamper controls: staff inspect devices on a schedule and know how to report a swapped or modified terminal.
  • Chain of custody: devices are tracked from shipping through installation, repair and decommissioning.
  • Network behavior: no clear-text card data appears anywhere between the terminal and the provider.
  • Provider documentation: you hold the provider's instructions and your own records showing you followed them.

Keep P2PE's benefit by treating every change as a possible scope event. A new terminal model, a reseller change or a rerouted network path can quietly move you out of the validated configuration. If you accept card-present payments, our terminal program offers free placement of devices, and our team can help you line up the deployment with your scoping goals.

Network segmentation, microsegmentation and zero trust

Segmentation separates the CDE from everything else so that out-of-scope systems cannot reach it. Segmentation is not required by PCI DSS, but it is the most common way to keep the CDE small. Done well, it limits which systems count as connected-to the CDE.

Options range from coarse to fine:

  • Perimeter segmentation: a firewall between the CDE and the rest of the network.
  • Internal firewalls and VLANs: separate zones inside a data center, with explicit rules between them.
  • Dedicated CDE VPCs or virtual networks: a cloud network created only for card-handling workloads.
  • Software-defined microsegmentation: policy enforced at the workload level, so even two servers on the same subnet cannot talk unless a rule allows it.

The Council's information supplement on scoping and segmentation for modern network architectures covers zero trust, microsegmentation, multi-cloud, asset inventory, the risks introduced by modern configurations, and how to verify segmentation controls. It supplements the standard and does not replace it.

Zero trust fits scoping well because it removes the idea of a trusted internal network. Every request is authenticated and authorized by identity, and access is granted at the smallest practical scope. Applied to PCI, that means a system's position on a network never earns it access to the CDE. A narrow, identity-based rule does.

Practical guidance:

  • Default deny. Block all traffic into and out of the CDE, then open only documented flows.
  • Tie rules to identities and workloads, not IP ranges that change.
  • Control management paths. Admin access, monitoring agents and backup jobs are the connections teams forget.
  • Document every allowed flow with a business reason and an owner.
  • Review rules on a schedule and remove any flow no one can justify.

The official guidance on PCI DSS scoping and network segmentation gives examples of segmentation methods such as firewalls, router configurations and logical or physical controls. It also states that segmentation must be verified before systems can be considered out of scope.

Segmentation counts only once it is verified: the Council's scoping and segmentation guidance treats testing as the step that moves a system out of scope, not the diagram on the wall.

For teams working on the application and analytics layer, privacy-safe approaches to ecommerce segmentation show how audience data can be separated from sensitive records, which supports the same principle of keeping data where it belongs.

Cloud-specific measures

Cloud platforms make segmentation faster to build and faster to break. A single permissive rule or an inherited permission can pull a whole project into scope, so cloud scoping works best when you design the boundaries first.

Google Cloud's architecture guidance on limiting PCI scope describes isolation through the resource hierarchy, dedicated VPCs with service controls, and organization policy constraints that support continuous compliance. AWS takes a parallel route in its whitepaper on architecting for PCI DSS segmentation and scoping, which recommends defining segmentation boundaries with cloud services and selecting security-impacting services carefully.

Apply these patterns:

  • Use a dedicated CDE project, folder or account. Keep card-handling workloads in their own container so policies and permissions do not leak in from neighboring environments.
  • Enforce organization-level constraints. Block public IP assignment, restrict regions, and require approved services in the CDE container.
  • Build a dedicated VPC. Use private subnets and no default routes to the internet or to other VPCs.
  • Use service perimeters and private endpoints. Keep traffic to managed services on the provider's private network so data cannot be copied to an unapproved destination.
  • Apply network policies in container platforms so pods communicate only with the services they need.
  • Tag everything. Resource tags tied to scope status let you query, alert on and report the CDE accurately.

Ephemeral services are the hard part. Containers, functions and autoscaled instances can appear and vanish quickly, and scope can drift between reviews. Automate inventory by pulling resource lists from the provider's APIs, flag any untagged resource in the CDE container, and have a pipeline remove or quarantine anything that does not match policy.

Identity and access management

Weak access control quietly widens scope. Any account, workstation or tool that can reach the CDE becomes a security-impacting system, so tightening identity is one of the most direct ways to keep the boundary small.

  • Require multi-factor authentication (MFA) for all administrative and remote access into the CDE.
  • Enforce least privilege with role-based access. Grant the narrowest rights needed and review them regularly.
  • Isolate admin workstations from general corporate networks, email and web browsing, so a phished laptop cannot become a path into card systems.
  • Separate management tools such as jump hosts, configuration managers and patch servers, and treat them as in scope if they touch the CDE.
  • Use short-lived credentials for service accounts and automation, issued on demand and revoked automatically.
  • Log identity events such as logins, privilege changes and secret retrievals, and send them to a protected store.

Teams often forget that identity providers and directory services are security-impacting. If your CDE trusts a corporate directory, that directory and the accounts in it belong in your scoping analysis. A dedicated identity boundary for the CDE can keep that dependency small.

Pro Tip: List every human and machine account that can reach the CDE, then ask who approved each one and when. Accounts nobody can explain are the first ones to remove.

Outsourcing to PCI-validated providers

When a PCI-validated third party captures, processes and stores card data, your own systems can drop out of scope, provided PAN never touches them. A hosted payment page or a processor-managed vault are the usual examples. You do not eliminate your responsibility. You change its shape.

What shifts to the provider: the secure handling of card data inside its environment, and the controls that protect it there. What stays with you: choosing a compliant provider, integrating it correctly, protecting the pages and code that redirect or embed it, and managing the relationship over time.

Collect and keep these items from every provider:

  • Attestation of Compliance (AOC) that is current and covers the services you use.
  • A responsibility matrix showing which requirements the provider covers and which you cover.
  • Validation evidence for the specific products you rely on, such as a validated P2PE listing.
  • Contractual assurances that the provider will maintain compliance and notify you of changes.
  • SAQ eligibility statements so you know which self-assessment questionnaire applies to your integration.

Monitor the boundary after signing. Check AOC expiry dates, track provider incidents, and re-review the integration whenever either side changes it. A redirect that becomes an embedded form, for example, can change your eligibility.

Our merchant services cover in-store, eCommerce and mobile acceptance, and our PCI compliance assistance can support your compliance efforts. For the self-assessment side, our guide to PCI SAQ types and v4.0.1 eligibility walks through the choices.

Verify segmentation and scoping decisions

An out-of-scope claim is only as strong as the evidence behind it. Assessors do not take a network diagram on faith. They want to see that your controls work as intended.

Build your evidence in this order:

  1. Gather the architecture. Current network diagrams, data-flow maps and system inventories that agree with each other.
  2. Export the rules. Firewall rulesets, security group configurations, routing tables and cloud policy definitions.
  3. Run segmentation tests. Attempt connections from out-of-scope networks into the CDE on all relevant ports and protocols, and record the results.
  4. Commission penetration testing of the segmentation controls, covering internal and external paths.
  5. Review configurations against your documented standards and note any drift.
  6. Log and file everything with dates, testers, scope and findings.
  7. Repeat after significant change, such as a new network, a migration or a major release, and at least once a year.

The assessor Q&A is blunt about the stakes: reducing scope must be paired with segmentation and documented verification, and the Council's materials describe penetration testing as the usual method of proving that segmented systems cannot affect the CDE.

Evidence outlasts memory: the 12-month confirmation cycle in the PCI DSS v4.x summary of changes rewards teams that file test results as they go instead of reconstructing them before an audit.

Asset inventory and continuous governance

Scope is accurate only while your inventory is. In dynamic environments, an inventory built once for an audit goes stale within weeks, and every missing asset is a hole in your boundary.

The Cloud Security Alliance notes that, with cloud, microservices, serverless and zero trust, scoping becomes a continuous activity that demands an up-to-date asset inventory to capture ephemeral services.

Build the governance process like this:

  1. Create one authoritative inventory covering data centers, cloud accounts, containers, serverless functions, service accounts, SaaS tools and logging endpoints.
  2. Record scope status for each asset: in scope, connected-to, security-impacting, or out of scope with the evidence reference.
  3. Name an owner for every asset and every segment, with a deputy.
  4. Define change triggers that force a scope review: new network connections, new vendors, new data flows, mergers, migrations and major releases.
  5. Hook the process into change management so a change ticket cannot close without a scope check.
  6. Schedule the annual confirmation and start it early enough to fix findings before your assessment.
  7. Set an escalation path so that when a new in-scope item surfaces, someone is accountable for bringing it into compliance or removing it.

Pull inventory data from live sources such as cloud APIs, configuration management databases, endpoint tools and network scanners, and reconcile them against each other. Differences between sources are where unknown assets hide.

Implementation checklist

Use this order of operations. It puts the highest-impact, lowest-risk changes first so each step reduces work for the next.

  1. Discover and map. Document every data flow and every location where PAN is stored, processed or transmitted.
  2. Remove what you can. Delete stored PAN you do not need and stop new collection paths.
  3. Replace PAN with tokens. Move to a vault or a gateway that returns tokens, and update applications to use them.
  4. Adopt validated channels. Use P2PE for card-present payments and a validated hosted checkout for online ones.
  5. Outsource where it makes sense. Collect AOCs and responsibility matrices from every provider.
  6. Segment the remainder. Isolate the CDE with firewalls, dedicated cloud networks and microsegmentation, with default-deny rules.
  7. Tighten identity. Enforce MFA, least privilege and isolated admin paths into whatever stays in scope.
  8. Verify. Run segmentation tests and penetration tests, and file the evidence.
  9. Operationalize. Link scope checks to change control, automate inventory, monitor continuously and schedule the annual confirmation.
  10. Review and repeat. Revisit the plan after every significant change and at least once a year.

Pro Tip: Assign each checklist step a named owner and a due date in your project tracker. Scope reduction stalls when everyone agrees on the plan and nobody owns step four.

For a broader view of the controls that surround scope, our PCI compliance checklist for small businesses pairs well with this list.

Common pitfalls and scope creep

The same mistakes show up again and again. Each one has a short remedy.

  • Relying on segmentation nobody has tested. A diagram is not a control. Test after every meaningful change and keep the results.
  • Forgetting backups, logs and admin tools. These copy or reach card data without anyone planning it. Add them to the inventory, sanitize logs, and isolate management paths.
  • Overlooking connected-to systems. The Council's scoping guidance flags that admin workstations and IT management systems can be in scope even when they never touch cardholder data directly. Trace dependencies, not just data.
  • Poor cloud visibility. Ephemeral workloads escape quarterly reviews. Automate detection and tagging so new resources are classified the moment they exist.
  • Treating scope reduction as a way to dodge controls. The goal is less exposure, not fewer questions from your assessor.
  • Letting scope drift after go-live. Temporary firewall exceptions and test data copies tend to become permanent. Expire exceptions automatically.

Detailed steps to conduct a PCI scope assessment

A scope assessment is a structured exercise that ends with a documented list of in-scope assets and the reasoning behind every exclusion. Run it the same way each year so results are comparable.

  1. Set the objective and the team. Include security, network, application, cloud, payments and a business owner. Agree on the assessment date and the systems under review.
  2. Identify every payment channel. List card-present, online, mobile, phone, mail order and any recurring or marketplace flows.
  3. Trace data flows. Follow card data from the point of capture through authorization, settlement, reporting, customer service and archiving.
  4. Discover stored data. Use automated PAN discovery across databases, files, logs, tickets, endpoints, backups and cloud storage.
  5. Build the system list. For each component in a flow, record function, owner, location and the data it handles.
  6. Classify each asset as CDE, connected-to, security-impacting or out of scope, assuming in scope until you can prove otherwise.
  7. Document the evidence for each out-of-scope decision: the segmentation test, the configuration or the provider attestation.
  8. Include people and process. Staff with access to card data, third parties and outsourced functions all belong in the picture.
  9. Review with an assessor or internal audit before finalizing, and resolve disagreements in writing.
  10. Sign off and store the record so next year's confirmation starts from a known baseline.

Useful discovery methods include network scans for card-data patterns, review of firewall and security group rules, analysis of flow logs, interviews with process owners, and reviewing third-party contracts for undocumented data sharing.

Best practices for continuous monitoring and maintenance

Scope reduction controls decay. Rules accumulate exceptions, new services appear, and people change roles. Monitoring catches the decay while it is still cheap to fix.

  • Watch the boundary. Alert on any new connection into the CDE, any firewall or security group change, and any resource created in the CDE container without approval.
  • Scan for PAN continuously. Run discovery on a schedule and on every release, and treat a hit outside the CDE as an incident.
  • Review access regularly. Recertify accounts, roles and service credentials, and remove what is unused.
  • Test on a cycle. Re-run segmentation tests after significant change and at least annually, and keep each result.
  • Centralize logs. Send CDE logs to a protected platform with alerting and retention that match your policy.
  • Track provider status. Monitor AOC expiry and provider notices so a lapsed validation does not silently put you back in scope.
  • Measure drift. Report the number of in-scope assets, open exceptions and aging findings to leadership each quarter.
  • Rehearse failure. Practice the response for finding PAN where it should not be, including who contains it and who tells the assessor.

Treat these tasks as operations work with owners and calendars. Controls that depend on someone remembering will not survive staff turnover.

Impact of emerging technologies on PCI scope

Containers, serverless functions and service meshes change how scope behaves. They do not change what counts as cardholder data, but they change how quickly your boundary can move.

Containers and orchestration. Containers on shared hosts share a kernel, so a container that handles card data can pull the host, the orchestrator and neighboring workloads into scope. Dedicated clusters or node pools for card-handling workloads, strict network policies between pods, and signed, scanned images keep the footprint predictable.

Serverless. Functions have no servers for you to patch, but they still process data and call other services. Any function that sees PAN is in scope, along with the triggers, queues, logs and storage it touches. Keep PAN out of event payloads, and make sure function logs do not capture request bodies.

Microservices and service meshes. Many small services mean many connections. Mutual TLS and identity-based policies in a mesh give you the fine-grained control that supports microsegmentation, but only if you document and test the policies.

Multi-cloud. Boundaries that span providers need consistent policy, identity and logging on both sides. The Council's podcast on scoping and segmentation highlights zero trust, multi-cloud boundaries, asset inventory for ephemeral services and verification of segmentation as the key areas for modern guidance.

The common thread is automation. Declare your boundary in code, enforce it in your pipeline, and inventory from live APIs so scope tracks the environment instead of lagging behind it.

Integrate scope reduction with broader compliance frameworks and audits

A smaller CDE helps more than your PCI assessment. Many of the controls you build for scope reduction map directly onto other frameworks, so the work pays back across your compliance program.

  • Access control and MFA satisfy PCI requirements and also line up with SOC 2 common criteria and ISO 27001 access controls.
  • Network segmentation and logging support the same infrastructure and monitoring expectations across those frameworks.
  • Asset inventory and change management are foundational in nearly every standard, so one well-run process serves several audits.
  • Vendor management evidence such as AOCs, contracts and monitoring supports both PCI third-party requirements and general supplier risk programs.

Practical steps: maintain a single control library that maps each control to every framework it satisfies, collect evidence once and reuse it, and schedule assessments so findings from one audit feed the next. Align your annual PCI scope confirmation with your wider risk assessment so the two documents agree.

Be careful about one thing. Meeting another framework does not prove PCI scope reduction, and the reverse is also true. Keep PCI-specific evidence, such as segmentation test results and scope documentation, in a form your assessor can find without hunting. If you are preparing for a full assessment, our walkthrough of PCI DSS Level 1 readiness shows how scope decisions flow into the audit, and our PCI compliance guide for small businesses covers the basics for teams earlier in the process.

How we help merchants simplify PCI effort

Our editorial view is simple: the best PCI program is the one with the least card data in it. The same order of operations guides our approach. Remove what you do not need, tokenize what you do, use validated channels for capture, and segment the small remainder with evidence you can show.

That is also how we build for merchants. Our gateway integrations, terminals and merchant services support payment acceptance, and our PCI compliance assistance supports your compliance efforts. Onboarding is straightforward, with no long-term contracts, so merchants can focus on running their business while we handle the heavy lifting around payments security.

If you want tailored guidance on shrinking your own scope, talk to our team. We will look at your payment flows, point out where card data can be removed or replaced, and map a practical path to a smaller, easier-to-defend environment.

— PaySec Marketing Team

FAQ

Do I have to pay a PCI compliance fee?

PCI DSS compliance itself is a requirement set by the card brands, but any fee for it comes from your acquirer or processor, and the amount and terms vary by provider. Ask yours exactly what is charged, what it covers and what happens when you complete your validation. With PaySec, our PCI compliance assistance is designed to make the process simple; current pricing details are on our pricing page.

Can I do PCI compliance myself?

Many smaller merchants validate compliance on their own using a Self-Assessment Questionnaire, and the right one depends on how you accept payments. Larger merchants and service providers generally need a Qualified Security Assessor or internal security assessor. Reducing scope first, through tokenization, P2PE or a hosted checkout, makes the self-assessment shorter and easier to complete.

What are the 12 requirements for PCI compliance?

The twelve principal requirements of PCI DSS cover building and maintaining secure networks and systems, protecting account data, maintaining a vulnerability management program, implementing strong access control, regularly monitoring and testing networks, and maintaining an information security policy. The full text is published by the PCI Security Standards Council. Version 4.x keeps the structure and adds requirements such as documenting scope at least every 12 months.

Sources