What PCI DSS is, for a Madhya Pradesh business
- Who publishes itPCI Security Standards Council, founded 2006
- Who enforces itYour acquirer, under the merchant agreement
- Version in forcev4.0.1, sole active version since 1 Jan 2025
- What you produceAn Attestation of Compliance, renewed annually
Because the obligation is contractual, there is no regulator in Madhya Pradesh to appeal to, no statutory grace period, and no partial credit. A requirement either applies to you and is met, or it applies and is not. What there is instead is a counterparty, your acquiring bank or payment aggregator, which decides your level, sets your deadline and receives your attestation.
That is also why the cost of a programme varies so widely between businesses of the same size in Madhya Pradesh. The standard scales with the CDE, the cardholder data environment, and that environment follows architecture rather than revenue. A company that never lets a card number reach its own servers answers a short questionnaire; one that stores PAN data answers the whole standard, every year, for as long as it keeps doing so.
Assessment ready What a readiness programme produces
These are the artefacts an assessor asks for and an acquirer expects to see, and they are the same artefacts that answer an enterprise customer's security questionnaire months before any attestation is signed.
- Card data discovery results across databases, logs, backups and endpoints
- Data flow diagrams and a network diagram showing the CDE boundary
- Scope reduction plan: redirection, tokenisation, retirement, segmentation
- Gap assessment against v4.0.1 with owners in your Madhya Pradesh team
- Policy set, plus a targeted risk analysis for every self-set frequency
- Evidence pipeline, control calendar and the scanning and testing schedule
Who can sign your validation, and who cannot
Where your acquirer requires a Report on Compliance, only a Qualified Security Assessor company listed by the PCI Security Standards Council can perform the assessment and sign it, and it has to be independent of the entity being assessed. It does not have to be located in Madhya Pradesh or even in India. Where a self-assessment applies, your own executive officer signs the Attestation of Compliance and carries responsibility for the answers. IncorpX does the scoping, remediation, documentation and evidence work behind either route, and briefs the assessor where one is engaged.
How the obligation reaches a business in Madhya Pradesh
No Indian statute names PCI DSS, yet almost every business in Madhya Pradesh taking card payments now has to hold an attestation. The obligation arrives through the payment chain, and since September 2025 the Reserve Bank of India has written it into the rules governing that chain.
| Source | What it requires | Who it lands on |
|---|---|---|
| Merchant agreement with your acquirer | Validation at the level the acquirer assigns, by the route and deadline it sets, with the attestation filed to it | Every merchant in Madhya Pradesh taking card payments, whatever its size |
| RBI (Regulation of Payment Aggregators) Directions, 2025 | A payment aggregator shall ensure that the infrastructure of its merchants is compliant with security standards like PCI DSS and PCI SSF, as applicable | Payment aggregators, and through onboarding, their merchants |
| The same Directions, Annexure 1 | Customer card credentials shall not be stored within the database or the server accessed by the merchant | Merchants onboarded by any Indian payment aggregator |
| The same Directions, reporting schedule | Submission of the Attestation of Compliance and the Report on Compliance, alongside vulnerability assessment and penetration test reports | Authorised payment aggregators, to the Reserve Bank of India |
| The same Directions, system audit clause | An annual system audit including a cyber security audit, conducted by CERT-In empanelled auditors | Authorised payment aggregators |
| Card-on-file tokenisation framework | Card credentials replaced by network tokens for saved-card use cases, keeping the card number with issuers and networks | Merchants and aggregators offering a saved-card experience |
The practical effect for a business in Madhya Pradesh is that the question is no longer whether to hold an attestation, but which one and by when. Aggregators now collect attestations at onboarding and at renewal because their own filings to the Reserve Bank depend on it, and an onboarding that stalls for want of a signed attestation stalls the revenue behind it.
The second effect is more useful than it looks. Because Indian rules keep card credentials out of merchant systems, the architecture most merchants in Madhya Pradesh already run is the architecture that produces the smallest assessment. The work is usually not building new controls but proving that card data really does stay where the design says it stays, which is where discovery earns its place.
Tokenisation shrinks the scope; it does not close the file
A network token is not account data, so a system holding only tokens is out of scope for the requirements that protect stored card numbers. What remains in scope is the path the real card number takes on its way to the provider: the payment page and everything that assembles it, the redirect or iframe, the scripts loaded into the customer's browser, and any support process in Madhya Pradesh where a number can be read aloud or pasted into a ticket. Those are exactly the areas the newest requirements target, so a tokenised merchant still validates, just against a much shorter list.
Scope, the cardholder data environment and how to shrink it
Scope is the cheapest thing to get right and the most expensive thing to fix late. It sets your assessment effort, your control spend and your evidence load for every year the architecture stays as it is.
Systems that hold the data
Anything that stores, processes or transmits account data sits inside the environment by definition, including the queue that carries an authorisation message and the log line that captured one by accident.
Systems merely connected to them
A jump host, a directory service, a monitoring agent, a build pipeline or a backup server can be in scope without ever seeing a card number, because it can reach the environment or affect its security.
Your Madhya Pradesh locations
Offices, support desks and workstations from which in-scope systems are reached come inside the boundary, and Requirement 9 expects physical access controls, media handling and device inspection at each of them.
Third parties and their attestations
Providers that handle card data on your behalf carry their own obligations, and you are expected to hold their attestations, know which requirements they cover for you and record where each responsibility sits.
The whole programme in three moves
Step 1. Find every place card data lands in the Madhya Pradesh operation, including the places nobody designed for it, because discovery decides where the boundary can honestly be drawn. Step 2. Remove or isolate everything the business can operate without, since scope removed is scope you never defend again. Step 3. Apply the controls to what is left, and keep producing the evidence that proves they ran, because the attestation is annual but the obligations are continuous.
What may you store, and what can you never keep?
The standard splits payment card data into two families, and the line between them is absolute. One family may be retained under protection. The other may be used to authorise a transaction and must then be gone, encrypted or not.
| Data element | Family | May it be stored after authorisation? |
|---|---|---|
| Primary Account Number, the card number | Cardholder data | Yes, only when rendered unreadable wherever it is stored |
| Cardholder name | Cardholder data | Yes, protected in line with the rest of the environment |
| Expiry date | Cardholder data | Yes, protected in line with the rest of the environment |
| Service code | Cardholder data | Yes, protected in line with the rest of the environment |
| Full track data from stripe, chip or equivalent | Sensitive authentication data | Never, in any form, including encrypted |
| Card verification value printed on the card | Sensitive authentication data | Never, in any form, including encrypted |
| PIN or PIN block | Sensitive authentication data | Never, in any form, including encrypted |
Where the card number is displayed rather than stored, masking applies: the maximum a screen may show is the bank identification number and the last four digits, and anyone needing more than that has to have a documented business justification. Where it is stored, rendering it unreadable means strong cryptography, keyed hashing across the whole number, truncation, or tokens backed by properly protected mappings.
The prohibition on sensitive authentication data is the requirement most often broken by accident rather than by design. It is broken by a debug flag that logs the full authorisation request, by a support agent in Madhya Pradesh pasting a verification value into a ticket, and by a call recording that captures a number read aloud. Each of those is a storage event, and each is found by discovery rather than by reading the architecture diagram.
A card number in a log file is a card number in scope
The most common finding in a first assessment is account data sitting in application logs, ticket attachments, call recordings, database exports or a backup taken years ago and never reviewed. Every one of those pulls the system holding it into the cardholder data environment, along with everything connected to it. This is why discovery runs before the boundary is drawn rather than after, and why it is repeated periodically instead of being treated as a one-off exercise at the start of the programme.
Which self-assessment questionnaire applies to you?
Eight questionnaires exist, and eligibility is decided by architecture rather than by preference. The shortest carries a handful of requirements; the longest is the entire standard. Getting this wrong is the most expensive administrative error in the programme.
| Questionnaire | Who it is for | The condition that decides eligibility |
|---|---|---|
| SAQ A | E-commerce or mail and telephone order merchants who have outsourced all account data functions | No account data touches your systems, and every payment page element comes only and directly from a compliant provider |
| SAQ A-EP | E-commerce merchants whose own site controls how the payment page is delivered | You never receive account data, but your server influences the page or the script that collects it |
| SAQ B | Merchants using imprint machines or standalone dial-out terminals | No internet connection carrying account data and no electronic storage of it |
| SAQ B-IP | Merchants using standalone approved terminals with an IP connection | Terminals are validated, isolated, and no account data is stored electronically |
| SAQ C-VT | Merchants keying transactions into a hosted virtual terminal | One isolated device, a provider-hosted terminal, and no electronic storage |
| SAQ C | Merchants running a payment application connected to the internet | The payment application is on a system with internet access, with no electronic storage of account data |
| SAQ P2PE | Merchants using only terminals in a validated point-to-point encryption solution | The solution is listed as validated, and no account data is stored electronically |
| SAQ D | Every other merchant, and every service provider eligible to self-assess | Anything that does not fit above, including any electronic storage of account data |
The line between SAQ A and SAQ A-EP is where most e-commerce merchants in Madhya Pradesh spend their scoping time, and it is a technical question rather than a commercial one. If the customer is redirected to the provider, or the payment fields sit inside an iframe served entirely by the provider, SAQ A is available. If your own page renders the fields, or your own script posts the data onward, the answer is SAQ A-EP and roughly ten times the requirement set.
What changed for SAQ A, and what changed again in 2026
From 31 March 2025, the Council removed Requirements 6.4.3 and 11.6.1 from SAQ A itself and replaced them with two eligibility criteria: every element of the payment page delivered to the browser must originate only and directly from a compliant provider, and the merchant must confirm its site is not susceptible to script attacks that could affect its e-commerce systems. On 4 August 2026 the Council revised FAQ 1331, so treating those requirements as not applicable in a Report on Compliance now requires confirmation from the acquirer or payment brand, rather than agreement with an assessor alone.
Merchant and service provider levels
Your level decides whether you may self-assess at all. It is assigned by the card brands and confirmed by your acquirer, which means the number you calculate yourself is a prediction rather than a decision.
| Level | Annual transaction volume | How validation is performed |
|---|---|---|
| Level 1 | More than 6 million transactions a year, or any merchant a brand designates | Report on Compliance by a Qualified Security Assessor or an Internal Security Assessor, plus quarterly scans by an Approved Scanning Vendor |
| Level 2 | 1 million to 6 million transactions a year | Annual self-assessment questionnaire plus quarterly scans by an Approved Scanning Vendor |
| Level 3 | 20,000 to 1 million e-commerce transactions a year | Annual self-assessment questionnaire plus quarterly scans by an Approved Scanning Vendor |
| Level 4 | Below 20,000 e-commerce transactions, or up to 1 million across all channels | Annual self-assessment questionnaire, with scanning and reporting as the acquirer requires |
| Service provider Level 1 | More than 300,000 transactions a year stored, processed or transmitted | Annual Report on Compliance by a Qualified Security Assessor, plus quarterly scans |
| Service provider Level 2 | Up to 300,000 transactions a year | Annual SAQ D for service providers, plus quarterly scans |
A breach can change your level overnight
Volume is the usual route into Level 1, but it is not the only one. A card brand can designate any entity a Level 1 merchant at its discretion, and after a confirmed compromise it routinely does, moving a business that was self-assessing to assessor-led validation with a forensic investigation running alongside. Planning a programme in Madhya Pradesh on the assumption that this year's volume fixes next year's obligations is how a company ends up commissioning a Report on Compliance with no evidence pipeline behind it.
The 12 requirements, under six control objectives
The structure has been stable across versions, which is why a control programme built once keeps its shape. What changes between versions is the depth of each requirement and the evidence expected behind it.
| Control objective | Requirement | What it covers in practice |
|---|---|---|
| Build and maintain a secure network and systems | 1. Network security controls | Firewall and equivalent controls between the environment and everything else, with reviewed rulesets and documented flows |
| Build and maintain a secure network and systems | 2. Secure configurations | Vendor defaults removed, hardening standards applied to every system component, and configuration drift managed |
| Protect account data | 3. Protect stored account data | Retention limits, sensitive authentication data never kept, the card number rendered unreadable, and key management that stands up to testing |
| Protect account data | 4. Protect data in transmission | Strong cryptography for account data crossing open public networks, with an inventory of the certificates and protocols in use |
| Maintain a vulnerability management programme | 5. Protect against malicious software | Anti-malware coverage, periodic evaluation for systems deemed not at risk, and anti-phishing controls for users |
| Maintain a vulnerability management programme | 6. Secure systems and software | Patching to defined timelines, secure development practices, code review, and management of the scripts on a payment page |
| Implement strong access control measures | 7. Restrict access by business need | Least privilege by role, access granted by a defined approval path, and reviews that produce a signed record |
| Implement strong access control measures | 8. Identify users and authenticate access | Unique identity for every user, no shared accounts, multi-factor authentication into the environment, and current password thresholds |
| Implement strong access control measures | 9. Restrict physical access | Controls over your Madhya Pradesh facilities, media, devices and their disposal, including periodic inspection of point-of-interaction terminals |
| Regularly monitor and test networks | 10. Log and monitor all access | Audit trails for every access to the environment, time synchronisation, protected logs, and reviews that are actually performed |
| Regularly monitor and test networks | 11. Test security regularly | Internal and external vulnerability scanning, annual penetration testing, segmentation testing, and detection of unauthorised change |
| Maintain an information security policy | 12. Policies and programmes | The policy set, risk analyses, awareness training, third-party management, and an incident response plan that has been tested |
What v4.0.1 changed, and what is now mandatory
Version 4 added 64 new requirements. Thirteen applied at once and 51 were future-dated to 31 March 2025, which has now passed. Every one of them is testable today, and these are the ones that reshape an existing programme.
| Requirement | What it asks for | Why it catches teams out |
|---|---|---|
| 6.4.3 Payment page scripts | Every script loaded into the payment page is inventoried, authorised, and its integrity assured | Nobody owns the tag manager, and analytics scripts arrive on the payment page through marketing rather than engineering |
| 11.6.1 Tamper detection | A mechanism that alerts on unauthorised change to the payment page content and its HTTP headers | It is a new capability rather than a policy, so it needs tooling and an owner before the assessment, not during it |
| 8.4.2 Multi-factor authentication | Multi-factor authentication for all non-console access into the cardholder data environment, for every role | One legacy path, a break-glass account or a vendor jump host is usually still single factor |
| 8.3.6 Password strength | A minimum of 12 characters, or 8 where the system genuinely cannot support 12, with complexity applied | Legacy systems and service accounts inherit an old standard nobody has revisited |
| 12.3.1 Targeted risk analysis | A documented analysis justifying every frequency the entity sets for itself | Policies say quarterly with no reasoning recorded, which is now a finding rather than a preference |
| 5.4.1 Anti-phishing | Mechanisms that protect users from phishing attacks, technical rather than only educational | Awareness training exists, but the technical control behind it is assumed rather than evidenced |
| 11.3.1.1 Lower-severity findings | Vulnerabilities not ranked high or critical are managed rather than ignored | The backlog of medium findings has never had an owner or a treatment decision |
| 12.10.7 Card data found outside scope | Incident response is triggered when account data is discovered where it should not be | Discovery finds card numbers and the finding goes to a backlog instead of an incident process |
Alongside the new requirements, v4 introduced the customized approach: instead of meeting a requirement exactly as written, an entity may design its own control, document how it meets the stated objective, support it with a targeted risk analysis, and have the assessor test it against that objective. It suits unusual architectures and it is heavy on documentation, so it rewards teams that already run a mature control programme rather than teams reaching for it to avoid one.
Version 4.0.1, published in June 2024, is a limited revision. It adds and removes nothing, clarifying wording and guidance instead, and it has been the only active version since v4.0 retired on 31 December 2024. In June 2026 the Council opened a request for comments on v4.0.1 to begin shaping the next release, so a programme built now in Madhya Pradesh should assume the current requirement set is stable for the assessment ahead of it.
How a Madhya Pradesh business gets PCI DSS ready
Ten steps in dependency order. The first four decide the size of everything that follows, which is why discovery and scoping happen before a single control is designed or bought.
Ask the acquirer which level and route apply
Your acquiring bank or payment aggregator assigns your level and states whether it expects a self-assessment questionnaire or a Report on Compliance, and by when. Those two answers fix the shape of the programme, so they are worth obtaining in writing before anything else starts.
Find the card data before you design anything
Run discovery across databases, file shares, application logs, backups, ticketing systems, call recordings and the endpoints your Madhya Pradesh team uses. Account data almost always turns up somewhere nobody designed for it, and a boundary drawn before discovery fails under testing.
Map the flows and draw the boundary
Document every path account data takes into, through and out of the business, then define the cardholder data environment: what stores, processes or transmits the data, plus everything connected to it, including the Madhya Pradesh offices from which it is reached.
Cut the scope before you spend on controls
Redirect the payment page to a compliant provider, adopt network tokens in place of stored card numbers, retire systems holding account data for no current reason, and segment the network. Every system removed is a set of requirements you never evidence again.
Run the gap assessment against v4.0.1
Test the current state against the requirements that apply to your validation route, including the 51 formerly future-dated requirements that became mandatory on 31 March 2025. The output is a prioritised gap list with named owners and target dates, not a percentage score.
Remediate access and the payment page first
Multi-factor authentication on every path into the environment, unique credentials with no shared administrator accounts, an inventory of the scripts on the payment page with integrity checks, tamper detection on page content and headers, and logs a reviewer can search.
Write the policies and the targeted risk analyses
Produce the information security policy set the standard expects, then document a targeted risk analysis for every requirement whose frequency you choose yourself, recording the asset, the threat, how a failure would be detected and when the decision is reviewed.
Set up scanning, testing and the evidence pipeline
Schedule quarterly external scans with an Approved Scanning Vendor and internal scans on the same cadence, book annual penetration testing and the segmentation testing that protects your scope reduction, and decide where every piece of evidence lands and who owns it.
Complete the questionnaire or the assessor fieldwork
For a self-assessment, work through the applicable questionnaire, confirm the eligibility criteria genuinely hold, collect the evidence and sign the attestation. For the assessor-led route, brief the Qualified Security Assessor with scope, diagrams and control matrix, then support sampling.
Keep validation alive through the year
File the attestation with the acquirer, keep the external scans passing every quarter, re-test after significant change, review access on schedule, and re-run discovery periodically so card data does not quietly reappear outside the boundary before the next annual validation.
Find out how much of your Madhya Pradesh stack is in scope
A scoping review traces every card data flow, tells you which questionnaire you are genuinely eligible for, and gives you the gap list with owners before any assessor is engaged or any tooling is bought.
Timeline, validity and the annual cadence
An attestation is dated, not open-ended, and the obligations behind it run continuously. These are the intervals that decide when your validation stops answering the question your acquirer is asking.
| Stage | Typical duration | What is happening |
|---|---|---|
| Phase 1. Discovery and scoping | 3 to 5 weeks | Card data discovery across the Madhya Pradesh operation, data flow mapping, boundary definition and the scope reduction plan |
| Phase 2. Gap assessment | 2 to 4 weeks | Testing the current state against v4.0.1, producing the gap list with owners and target dates |
| Phase 3. Remediation | 6 weeks to 2 quarters | Access, segmentation, payment page controls, logging, policies and the targeted risk analyses |
| Scanning and testing | Runs alongside remediation | First passing external scan by an Approved Scanning Vendor, internal scans, penetration testing |
| Self-assessment route | 2 to 4 weeks | Completing the questionnaire, assembling evidence and signing the Attestation of Compliance |
| Assessor-led route | 6 to 10 weeks | Qualified Security Assessor fieldwork, sampling, findings, remediation and the Report on Compliance |
| Attestation validity | Annual | Revalidation each year, with the attestation filed to the acquirer or payment aggregator |
| External scan cadence | Every 90 days | A passing Approved Scanning Vendor scan each quarter, plus re-scans after significant change |
| Penetration testing | At least annually | External and internal testing, and after any significant infrastructure or application change |
| Segmentation testing | 12 months, or 6 for service providers | Confirming the segmentation controls that keep systems out of scope still work as described |
Plan backwards from the acquirer deadline
A merchant in Madhya Pradesh told in October to produce an attestation by March has roughly five months, and remediation is the only variable in that equation. Discovery and scoping take weeks; a payment page rebuild, a segmentation project or replacing a system that stores card numbers takes a quarter or more. The teams that finish comfortably start the scoping review the week the request arrives, because scope reduction decided in week two removes work that would otherwise consume months four and five.
What produces a clean validation, and what produces findings
Almost every finding in a first assessment traces back to one of these, and almost every one of them is cheaper to fix during scoping than during fieldwork with an assessor waiting.
Produces a clean validation
- Discovery run before the boundary is drawn, and repeated on a schedule afterwards
- A payment page delivered so the merchant genuinely qualifies for the questionnaire it uses
- Segmentation designed deliberately, documented, and tested on its required cadence
- Multi-factor authentication on every path into the environment, including vendor and break-glass access
- An inventory of the scripts on the payment page, with an owner and integrity checking
- A targeted risk analysis recorded for every frequency the business sets for itself
- External scans booked as a standing quarterly commitment rather than remembered late
Produces findings
- Card numbers sitting in application logs, ticket attachments, call recordings or an old backup
- A flat network where every system is connected to the environment and therefore in scope
- Shared administrator accounts, or one legacy access path still on a single factor
- Analytics and marketing tags added to the payment page by people outside engineering
- A questionnaire chosen for its length rather than for the architecture it describes
- Policies that state frequencies with no risk analysis recorded behind them
- Scans run once at the start of the year and never repeated until the next attestation is due
PCI DSS vs SOC 2, ISO 27001 and the privacy laws
They answer different people asking different questions, and a growing number of companies in Madhya Pradesh are asked for all four. One control programme can feed every one of them when it is designed that way from the start.
| Dimension | PCI DSS | SOC 2 | ISO 27001 | DPDP and GDPR |
|---|---|---|---|---|
| What it is | A contractual security standard for card data | An auditor report on controls | A certifiable management system standard | Statutory obligations |
| Who asks for it | Your acquirer and payment aggregator | Enterprise buyers in procurement | Enterprise buyers, often European | Regulators, and any customer whose data you hold |
| Who signs off | You, or a Qualified Security Assessor | A licensed audit firm | An accredited certification body | Nobody: you evidence compliance yourself |
| Output | An Attestation of Compliance | A restricted-use report shared under NDA | A certificate valid three years with surveillance | An evidence pack produced on demand |
| Scope defined by | Where card data flows and what connects to it | Your system description and chosen criteria | Your management system scope statement | The personal data you actually process |
| Result type | Pass or fail against each requirement | An opinion, with exceptions disclosed | Certified, with major and minor findings | Continuous, tested only when challenged |
| Recurs | Annually, with quarterly scanning throughout | Annually, by observation window | Surveillance yearly, recertification every three years | Continuously, reviewed on change |
The overlap is genuine but partial. One access review process, one change workflow, one logging pipeline and one evidence store can serve PCI DSS, SOC 2 and ISO 27001 at once. What none of them gives you is a lawful basis, a privacy notice or a consent record, which is why companies in Madhya Pradesh handling personal data run a privacy programme alongside the security work rather than in place of it.
PCI DSS terms, defined
The vocabulary acquirers, assessors and payment aggregators use, in the sense the standard gives it rather than the sense the words carry elsewhere.
- Account data
- The umbrella term covering both cardholder data and sensitive authentication data. Anything that stores, processes or transmits it is inside the cardholder data environment by definition.
- Primary Account Number
- The payment card number, abbreviated PAN throughout the standard. It is unrelated to the Permanent Account Number issued by the Income Tax Department, and it may be stored only when rendered unreadable.
- Sensitive authentication data
- Full track data, the card verification value and the PIN or PIN block. It may be used to authorise a transaction and must never be retained afterwards, in any form, including encrypted.
- Cardholder data environment
- The people, processes and technologies that store, process or transmit account data, together with every system component connected to them or able to affect their security.
- Qualified Security Assessor
- A company qualified by the PCI Security Standards Council to perform onsite assessments and issue a Report on Compliance. It must be independent of the entity assessed, and need not be based in Madhya Pradesh.
- Approved Scanning Vendor
- A vendor approved by the Council to run external vulnerability scans against internet-facing systems. A passing scan is required at least every 90 days.
- Attestation of Compliance
- The signed declaration of validation status that accompanies a questionnaire or a Report on Compliance. It is the document an acquirer, aggregator or enterprise customer actually asks to see.
- Compliance Accepting Entity
- The acquirer or payment brand that receives and accepts your validation. Since the August 2026 revision to FAQ 1331, it is the party that confirms how certain requirements may be reported.
- Network token
- A network-issued substitute for the card number used in saved-card and recurring flows. It is not account data, which is why tokenisation removes systems from scope rather than merely protecting them.
PCI DSS guides and resources
Deeper reading on how card data scope is set, the security stack Indian startups build for enterprise sales, the CERT-In reporting duties that sit alongside a card breach, and the privacy frameworks that run in parallel with PCI DSS.
FAQs about PCI DSS compliance in Madhya Pradesh
35 questions taken from real search queries, acquirer onboarding checklists, PCI Security Standards Council guidance and the way assessments actually run in India.
Cut the scope first, then meet the standard
Our security compliance experts map every card data flow in your Madhya Pradesh operation, define the cardholder data environment, remove what does not need to be in it, close the gaps against v4.0.1 and prepare the attestation your acquirer is waiting for.
Nebin Binoy 
