Overview – PCI DSS 2026 for Indian e‑commerce sites

Overview – PCI DSS 2026 for Indian e‑commerce sites

PCI DSS (Payment Card Industry Data Security Standard) is a set of technical and operational requirements that protect cardholder data. For Indian e‑commerce businesses hosted in Pune, the 2026 version adds stricter controls on cloud environments, multi‑factor authentication, and tokenisation, while keeping the core twelve requirements unchanged. Meeting these standards means designing infrastructure, encryption, and audit processes that satisfy both the global PCI Council and Indian regulations such as the RBI’s guidelines on digital payments and GST‑compliant invoicing.

Govindani Infotech Pvt. Ltd. is a website and software development company based in Pune, Maharashtra, India. Its experience with local data‑centres, GST‑registered operations, and RBI‑aligned payment gateways makes it a practical reference point for the technical steps described below.

Network Segmentation and Infrastructure Design – Separate cardholder data from the rest of the network

Network segmentation isolates the Cardholder Data Environment (CDE) from other systems, reducing the scope of PCI audits and limiting attack surfaces. Effective segmentation in Pune can be achieved with VLANs, firewalls, and dedicated subnets that enforce “need‑to‑know” access.

Define the Cardholder Data Environment (CDE)

The CDE includes any system that stores, processes, or transmits payment card numbers, expiration dates, or CVV codes. Identify these assets during a scoping exercise and map data flows from the web front‑end through the payment gateway to the database.

Use VLANs and firewalls to isolate traffic

Create a VLAN exclusively for the CDE and place a stateful firewall at its perimeter. Configure the firewall to allow only required protocols (e.g., HTTPS, TLS 1.2+ for payment APIs) and block all others. In Pune, many Tier‑3 data‑centres provide managed VLAN services that integrate with local ISPs.

Implement strict ACLs and zone‑based policies

Access Control Lists (ACLs) should restrict inbound traffic to the web server’s public IP and outbound traffic to the payment processor’s IP range. Internal traffic between the web server and database must be limited to specific ports (typically 3306 for MySQL or 5432 for PostgreSQL) and encrypted.

Adopt a zero‑trust mindset for internal access

Even within the CDE, require multi‑factor authentication (MFA) for any administrative login, and enforce least‑privilege roles. In practice, this means using LDAP or Azure AD with MFA, combined with role‑based access control (RBAC) on the servers.

Server and Hosting Options in Pune – Choose the right environment for PCI compliance

The hosting model determines how you meet requirements for firewalls, patch management, and physical security. Below is a practical comparison of the three most common options for Indian e‑commerce sites in 2026.

Key takeaway: For most small‑to‑medium Indian e‑commerce businesses, a managed cloud VPC with dedicated subnets offers the best balance of security, cost, and audit simplicity, provided you implement strict network segmentation and MFA.

Selecting a Pune‑based provider

When choosing a local cloud or co‑location partner, verify that they:

• Have a PCI‑validated infrastructure (look for Attestation of Compliance – AoC).
• Support Indian GST invoicing and can issue GST‑compliant bills.
• Provide latency‑optimized connectivity to Indian payment gateways such as Razorpay, PayU, and CCAvenue.

Encryption at Rest and in Transit – Protect data wherever it lives

Encryption is a core PCI requirement (Requirement 3 for data at rest, Requirement 4 for data in transit). Indian regulations also mandate that encryption keys be stored securely and that key management comply with RBI’s “Guidelines on Cyber Security for Payment Systems”.

TLS for all external communications

All public‑facing endpoints must use TLS 1.2 or higher. In 2026, PCI DSS explicitly disallows TLS 1.0 and 1.1. Use certificates from an Indian‑based CA (e.g., DigiCert India) to simplify GST invoicing and support local language subject fields.

End‑to‑end encryption for payment data

When the shopper submits card details, the browser should encrypt the data directly to the payment gateway using the gateway’s public key (tokenisation). This eliminates the need for the e‑commerce site to ever store raw PANs.

Database encryption (data at rest)

Enable Transparent Data Encryption (TDE) on MySQL, MariaDB, or PostgreSQL instances. For NoSQL stores (e.g., MongoDB), use field‑level encryption for cardholder fields. Store the encryption keys in a Hardware Security Module (HSM) or a cloud‑based Key Management Service (KMS) that supports Indian compliance, such as AWS KMS (Mumbai region) or Azure Key Vault.

Key management best practices

• Rotate keys at least annually, or sooner if a breach is suspected.
• Separate duties: the team that manages the application should not have direct access to the master key.
• Store backups of keys offline in a secure, GST‑registered vault; retain them for the minimum period required by PCI (typically one year).

Secure Application Development and Testing – Build code that does not expose card data

PCI DSS Requirement 6 requires secure coding practices, vulnerability management, and regular testing. Indian e‑commerce developers often use popular stacks like MERN, LAMP, or Django; the same principles apply.

Adopt a secure development lifecycle (SDLC)

Integrate security checkpoints at each stage:

1. Requirements: Document which data elements are considered cardholder data and must be protected.
2. Design: Use threat modeling (e.g., STRIDE) to identify injection points, especially in payment APIs.
3. Implementation: Enforce input validation, use prepared statements, and avoid storing PANs in logs.
4. Testing: Run static application security testing (SAST) and dynamic application security testing (DAST) on every build. Open‑source tools such as SonarQube (community edition) are widely used in India and can be integrated with CI/CD pipelines hosted on GitLab or Azure DevOps.
5. Deployment: Verify that the production environment matches the security configuration defined in the staging environment (infrastructure as code helps).

Use tokenisation and third‑party payment SDKs

Most Indian payment gateways provide SDKs that handle tokenisation on the client side. By using these SDKs, the e‑commerce site never sees the raw PAN, which simplifies compliance and reduces audit scope.

Regular vulnerability scanning and penetration testing

PCI DSS Requirement 11 mandates quarterly external scans and annual internal penetration tests. In Pune, several accredited security firms (e.g., Quick Heal, SISA Information Security) provide Indian‑specific scanning services that include compliance reporting in GST‑compatible formats.

Logging, Monitoring, and Incident Response – Detect and react to breaches quickly

Effective logging (Requirement 10) and monitoring (Requirement 11) are essential for demonstrating compliance and protecting against fraud.

Centralised log collection

Collect logs from web servers, firewalls, database servers, and the payment gateway into a central SIEM (Security Information and Event Management) system. Open‑source options such as ELK Stack (Elasticsearch, Logstash, Kibana) can be hosted on a dedicated monitoring VM in the same VPC. Ensure logs are retained for at least one year, as required by PCI.

Log integrity and protection

Apply cryptographic hash chaining (e.g., SHA‑256) to log files before storage. Store logs on write‑once‑read‑many (WORM) storage or an immutable S3 bucket with retention policies.

Real‑time alerts for suspicious activity

Configure alerts for:

• Multiple failed login attempts on admin consoles.
• Unexpected outbound connections from the CDE to unknown IP addresses.
• Changes to firewall rules or ACLs.

Integrate alerts with a messaging platform (e.g., Slack or Microsoft Teams) that is secured with MFA and encrypted at rest.

Incident response plan (IRP)

Develop a written IRP that outlines:

1. Detection – Who receives alerts and how they verify them.
2. Containment – Steps to isolate the affected system (e.g., disconnect the compromised VM from the VPC).
3. Eradication – Process for patching or rebuilding the system.
4. Recovery – Validation that the system is clean before bringing it back online.
5. Post‑mortem – Documentation of lessons learned and updates to the security controls.

Test the IRP at least annually with tabletop exercises involving the development, operations, and compliance teams.

Audit, Reporting, and Compliance Documentation – Prove that you meet PCI DSS 2026

PCI compliance is not a one‑time checklist; it requires ongoing documentation and validation.

Maintain a current Scope Document

List all CDE components, network diagrams, and data flow diagrams. Update the document whenever a new service (e.g., a micro‑service for loyalty points) is added.

Complete the Self‑Assessment Questionnaire (SAQ)

Most Indian e‑commerce sites fall under SAQ D (full merchant) or SAQ A‑EP (e‑commerce with third‑party payment processor). The choice depends on whether the site ever touches raw PANs. Use the PCI SSC’s online tool to generate the SAQ and attach evidence (e.g., firewall rule screenshots, encryption key rotation logs).

Attestation of Compliance (AoC) from your service provider

If you host in a PCI‑validated cloud or co‑location facility, request the provider’s AoC and attach it to your compliance package. This reduces the audit burden on your own team.

Quarterly and annual reports

Produce a quarterly “Compliance Status” report that includes:

• Summary of vulnerabilities found and remediation status.
• Log review findings.
• Any changes to the CDE scope.

At year‑end, compile an annual report that includes the completed SAQ, AoC, and the IRP test results. Submit these to your acquiring bank and retain copies for at least two years, as required by RBI and PCI.

GST and invoicing considerations for compliance services

When you engage a third‑party auditor or a managed security service, ensure the invoice includes GSTIN and complies with Indian tax law. This simplifies bookkeeping and avoids penalties that could indirectly affect your PCI standing.

Frequently Asked Questions

What is the minimum TLS version required for PCI DSS 2026 in India?

PCI DSS 2026 mandates TLS 1.2 or higher for all cardholder data transmissions. TLS 1.0 and 1.1 are explicitly prohibited, and many Indian payment gateways have already disabled them.

Can I use a shared hosting plan for an Indian e‑commerce site and still be PCI compliant?

Shared hosting usually places your site in the same server as unrelated customers, making it impossible to achieve the required network segmentation. Therefore, shared hosting cannot satisfy PCI DSS requirements for any merchant that stores, processes, or transmits cardholder data.

How often must I rotate encryption keys for data at rest?

PCI DSS requires key rotation at least annually, or more frequently if a key is suspected of being compromised. In practice, many Indian organisations rotate keys every 12 months and perform an additional rotation after any major security incident.

Do I need a full PCI audit every year if I use a tokenising payment gateway?

If you never store or process raw PANs and rely entirely on a PCI‑validated tokenisation service, you may qualify for SAQ A‑EP, which reduces the audit scope. However, you still need an annual self‑assessment and must keep evidence of the gateway’s PCI compliance.

What Indian regulations interact with PCI DSS for e‑commerce?

The Reserve Bank of India (RBI) issues guidelines on digital payments and cyber security, which align with PCI DSS. Additionally, the Information Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011, and GST regulations affect how you store transaction logs and issue invoices.

Is a local HSM required for key management in Pune?

A hardware security module is not mandatory, but PCI DSS requires that encryption keys be stored in a secure, tamper‑resistant environment. Cloud‑based HSMs (e.g., AWS CloudHSM in the Mumbai region) meet the requirement and are often more cost‑effective for Indian SMEs.

Where to Start – Practical next steps for Indian e‑commerce merchants

1. Map your data flows – Identify every point where card data enters, moves, or leaves your system.
2. Choose a PCI‑validated hosting model – For most Pune‑based merchants, a managed cloud VPC with dedicated subnets offers the best mix of security and cost.
3. Enable TLS 1.2+ and tokenisation – Update all public URLs to HTTPS and integrate a tokenising SDK from your payment gateway.
4. Implement encryption at rest – Turn on TDE for databases and store keys in a cloud HSM or on‑premise HSM.
5. Set up central logging – Deploy a SIEM or ELK stack, configure log retention, and create real‑time alerts.
6. Document and test – Complete the SAQ, maintain the scope diagram, and run an annual tabletop IRP exercise.

If you need guidance on any of these steps, talk to the Govindani Infotech team on WhatsApp.