The PCI Security Standards Council develops standards and guidance that help protect payment card data. If your business accepts card payments, understanding the PCI Security Standards Council is a useful first step—but the Council does not certify every business or replace instructions from your payment provider. Your responsibilities depend on how you accept payments and how card data moves through your systems.
Talk with IGTech365 about this article
Send a note and we will reply from this page.
Discuss your payment security needs
What does the PCI Security Standards Council do?
The PCI Security Standards Council (PCI SSC) is an industry organization that develops and maintains payment security standards. Its best-known standard is the Payment Card Industry Data Security Standard (PCI DSS). The standard sets technical and operational requirements for entities that store, process, or transmit payment account data, as well as systems that can affect the security of that data.
The Council publishes standards, supporting documents, and training resources. It also manages qualification programs for assessors and other professionals. Its role is different from that of payment brands, acquiring banks, and processors. Those parties communicate validation requirements to merchants and service providers. The PCI SSC provides the framework; it generally does not decide the specific validation process your business must follow.
For the Council’s own information about its standards and programs, visit the PCI Security Standards Council website. For a business-focused overview of common obligations, IGTech365 also has a guide to PCI compliance requirements.
Does PCI DSS apply to your business?
If you accept payment cards, assume you need to understand the PCI DSS obligations that apply to your payment environment. The details can vary with payment channels, the way card data is handled, and requirements set by your acquiring bank or payment brand. Do not select a validation form or decide that you are exempt based on a generic checklist. Ask your processor or acquiring bank which validation method, documentation, and deadline apply to your business.
For example, a small retailer using a hosted payment page may have a different card-data environment from a company running payment applications on its own network. But the word “hosted” does not answer every scope question. Website access, integrations, staff practices, devices, and administrative accounts may still matter. A business that never deliberately saves card numbers could also have processes that expose data through written notes, call recordings, exports, or email.
Start with actual processes rather than assumptions. Include routine transactions and exceptions such as refunds, telephone orders, recurring billing, keyed transactions, and end-of-day reporting. If staff can take an unusual path when the normal system is unavailable, record that path too.
How can you map your payment environment?
Trace a payment from the moment a customer presents a card through authorization, settlement, reporting, and any later storage or deletion. Do this for each way customers pay, not only the main checkout flow. The aim is a useful working picture of systems, connections, people, and service providers—not a claim that the map alone proves compliance.
- List every payment channel. Record in-person terminals, website checkout, mobile transactions, phone orders, recurring payments, and manual entry. Note the business locations and teams involved.
- Draw the data flow. Show where payment data enters, which applications or devices handle it, where it is sent, and whether it is retained. Include reports that staff download, print, or forward.
- Identify connected systems. Inventory payment devices, networks, workstations, administrative accounts, and services that could affect payment security—even if they do not directly store card data.
- Document service providers. List the processor, gateway, point-of-sale provider, website host, and other vendors involved. Request written descriptions of each provider’s role and your remaining responsibilities.
- Mark open questions. If nobody knows whether a system receives data or can affect a payment component, record the uncertainty and assign someone to investigate it. Do not label an unclear system out of scope by default.
| Payment setup | What to map | Useful question to ask |
|---|---|---|
| Hosted online checkout | Website links and redirects, integrations, scripts, administrative access, and reports | Which components does the provider host, and what remains under our control? |
| In-person terminal | Terminal connections, network segment, staff access, and settlement reports | How is the terminal connected, and who can change its settings? |
| Phone or manual entry | Call handling, written notes, recordings, entry devices, and deletion practices | Could card data be captured or retained outside the payment application? |
| Business-managed application | Servers, endpoints, accounts, updates, logs, backups, and support access | Who maintains each system and checks security changes? |
After mapping, compare the diagram with what staff actually do. A useful test is to walk through one ordinary transaction and one exception with the people who handle them. If the diagram says a customer enters data directly into a provider-hosted page but staff describe copying details into a separate system, resolve that difference before making scope decisions.
Which security controls should you review first?
PCI DSS is a detailed standard, and the requirements that apply depend on your environment and validation path. A first review can still focus on exposure, access, ownership, and readiness. Use these questions to identify issues to discuss with your provider or qualified assessor; do not treat this list as a substitute for the full standard or formal validation.
- Can you avoid retaining payment data? Remove unnecessary storage and confirm approved retention and deletion practices with your payment provider. Check paper notes, exports, backups, and recordings, not just the main payment application.
- Who can access payment-related systems? Review employee and vendor accounts. Grant only the access needed for each role, protect administrative accounts, and promptly remove access when work or responsibilities change.
- Are payment systems separated where appropriate? Ask a qualified professional whether network design can reduce unnecessary connections between payment components and general business devices. Keep a record of the intended boundaries and who can approve changes.
- Who maintains devices and software? Identify owners for supported software, updates, secure configurations, and alerts. Make sure responsibilities are understood when a vendor manages part of the environment.
- Can staff recognize and report a problem? Explain how to handle payment information, respond to suspicious requests, and report a lost, altered, or unexpected payment device. Give staff a clear contact path.
- Is there an incident process? Decide who contacts the processor or acquiring bank, who preserves relevant information, and who coordinates technical and business decisions. Follow provider instructions when an incident is suspected.
Keep evidence of decisions and recurring checks. A practical record can include a system inventory, named owners, provider documents, review dates, unresolved questions, and follow-up actions. If your business is reviewing wider access practices, the guide to IAM and privileged access management offers related context. For broader security planning, see IGTech365’s resources on network security and common cybersecurity gaps.
For businesses that need help coordinating day-to-day IT responsibilities, managed IT services can be part of the broader support conversation. A service provider can help document systems and assign operational owners, but it cannot choose your official validation path in place of your acquiring bank or payment brand.
How should you work with providers and assessors?
Ask your acquiring bank or processor to confirm the validation method that applies, whether a self-assessment questionnaire is appropriate, and whether an attestation or scan is required. Ask for the current form or instructions in writing. If the answer depends on details about your setup, provide a concise payment-flow diagram and a list of channels rather than describing the business only as “small” or “online.”
For each provider that handles payment functions, request current documentation about its service scope and the division of responsibilities. Clarify which components it operates, which configurations you control, what information it needs from you, and what evidence you should retain. A vendor statement about its own service does not establish that every part of your business environment is covered.
When an assessment is needed, confirm that the assessor is qualified for the task and that the scope is clear before work begins. Ask what locations, systems, and processes are included; what evidence is expected; how findings will be documented; and who will verify corrective actions. Name an internal owner to coordinate questions and keep the final materials together.
Changes can alter the picture. Before adding a payment channel, new location, integration, or provider, review the data flow and ask whether the change affects responsibilities or validation. After a change, update the diagram and inventory so the records do not describe an old arrangement.
Explore managed IT support for your business
How can you reduce scope without creating blind spots?
Reducing the number of systems that handle or can affect payment data may make responsibilities easier to manage. Options to discuss with your provider may include a validated hosted checkout or provider-managed terminal, removing unnecessary storage, limiting access, and restricting network paths. Whether a specific change reduces formal PCI scope must be confirmed against the applicable standard and your provider’s requirements.
Do not treat a vendor’s claim that a solution is “PCI compliant” as proof that your whole business is compliant. Ask what service components the claim covers, what responsibilities remain with you, and whether your particular integration or configuration changes the arrangement. For instance, a hosted checkout may reduce direct handling of card data, while staff procedures, website controls, or administrative access still require attention.
Scope reduction can fail when exceptions are ignored. A worker might write down card details during an outage, export a report to a shared workstation, or use a new device that has not been included in the original diagram. Make the approved process easy to follow, explain what staff should do when it is unavailable, and check whether records or temporary workarounds leave data behind.
When network changes are involved, record the intended design, test that payment functions still work, and review access and monitoring afterward. Keep an inventory of terminals, locations, and applications. Assign an owner to review additions and changes, because an untracked system can quietly reintroduce connections that scope-reduction work was meant to remove.
What should you do if payment data may have been exposed?
Use your incident process and contact your payment processor or acquiring bank promptly for instructions. Preserve relevant information, limit further exposure where it is safe to do so, and involve appropriate security and legal professionals. Avoid deleting logs or resetting equipment before you understand what evidence needs to be retained. Record who was notified, when instructions were received, and which actions were taken.
Use the event to review the process that failed or was unclear. Was a device missing from inventory? Did staff lack a reporting path? Was a vendor contact out of date? Correcting those operational gaps and documenting the lessons can make future response more consistent. For additional planning context, you can review the guide to detecting a cyberattack early.
Call IGTech365 at (866) 365-7798
Frequently asked questions
Is the PCI Security Standards Council a government agency?
No. The PCI SSC is an industry organization that develops and maintains payment security standards. Payment brands, acquiring banks, and processors communicate the validation requirements that apply to merchants and service providers.
Does using a payment processor make my business automatically compliant?
No. A processor may handle important payment functions, but your business may still have responsibilities for devices, access, staff practices, websites, networks, and records. Ask the provider to explain the division of responsibility for your exact setup and confirm validation requirements with your acquiring bank.
Can I choose my own PCI DSS questionnaire?
Do not choose one based on an assumption about business size or payment method. Ask your acquiring bank or payment brand which validation method applies to your circumstances and follow its current instructions.
Does a hosted payment page remove every PCI responsibility?
Not necessarily. Hosting may change how card data reaches your business, but you still need to understand the website, access, staff practices, integrations, and validation conditions that apply to your configuration. Confirm the details with the provider and acquiring bank.
What should you do next?
Begin by mapping each payment channel, the systems involved, and the providers responsible for each step. Use that map to ask your processor or acquiring bank for the correct validation instructions, then assign owners to clarify open questions and track follow-up. A current, accurate picture of payment flows is a practical foundation for protecting customers and managing your next steps.