AI-FIRST CYBERSECURITY · Always Wise. Always Ahead. +91-95851-60363 info@semperwise.com DOVER, DE, USA

Retail cybersecurity · India

Your biggest week of sales is theirs too.

Festive sales bring the year’s highest traffic, the most rushed changes to the site, the most marketing scripts on the checkout — and the most attackers. This page gives you a ten-week countdown to the sale, a self-check for the payment-page script rules that have applied under PCI DSS since March 2025, and the ways retailers have actually been hurt.

Book a sale-readiness call Read the retail brief

Reviewed 24 September 2026 · 10 sources cited

The short answer

Retail cybersecurity centres on the checkout. Since 31 March 2025, PCI DSS 6.4.3 has required every script on a payment page to be authorised, integrity-checked and inventoried with a justification, and 11.6.1 a tamper-detection mechanism checked at least weekly. Before a festive sale, freeze and inventory what runs at checkout, test promotions and login for abuse, watch for lookalike sites, and rehearse the six-hour CERT-In report.

Why retail

The checkout runs code you did not write.

A modern checkout page loads analytics, tag managers, chat widgets, A/B testing, fraud tools, the payment gateway’s scripts and whatever the marketing agency added last week. Every one of them runs in the shopper’s browser with the same power as your own code — including the power to read what is typed into a card field. That is why PCI DSS v4 added two requirements aimed squarely at the browser. Requirement 6.4.3 says every script on a payment page must be authorised, have its integrity assured, and appear in an inventory with a written justification. Requirement 11.6.1 says a change- and tamper-detection mechanism must alert you to unauthorised changes to those scripts and to security-impacting HTTP headers, checked at least weekly. Both have applied since 31 March 2025.

The risk is not hypothetical. In June 2024 researchers at Sansec found that polyfill.io — a script library embedded by more than 100,000 websites — had been bought by a new owner and was injecting malicious code into sites that loaded it, redirecting mobile visitors and hiding itself from administrators. Nobody at those sites changed a line of their own code. The script they trusted had changed hands.

Retail’s wider numbers point the same way. In Verizon’s 2026 breach data, retail breaches nearly doubled year on year; 68% involved a third party, and exploited vulnerabilities were the leading way in, at 42%. When attacks go further than the checkout, the cost is counted in weeks: Marks & Spencer suspended online orders in April 2025 and forecast a £300 million hit to operating profit, with online disruption expected into July.

In India the calendar adds its own pressure. The festive-sale season concentrates traffic, discounting and hurried site changes into a few weeks — and CERT-In has warned of campaigns impersonating brands with fake festive offers. From May 2027, the DPDP Act adds duties of its own: an e-commerce platform with two crore or more registered users in India must erase a customer’s data three years after they were last active, with 48 hours’ notice first.

Ten weeks to the sale

A countdown to the festive sale

Work back from the first day of your biggest sale — festive season, end-of-season or a brand day. The dates move; the order does not.

  1. 10 weeks out

    Inventory what is live Coming

    List every payment page, every script that runs on it and why it is there, every third-party widget and every campaign microsite. This is the 6.4.3 inventory, and it is also the list an attacker would start from.

  2. 8 weeks out

    Test checkout, promotions and login Coming

    Test the checkout, coupon and gift-card logic, loyalty points, cart pricing and the APIs behind the app — the places discounts can be abused — and customer login for credential stuffing. Leave time for fixes.

  3. 6 weeks out

    Fix and retest Coming

    Fix what the tests found and have it retested. A finding is not closed until someone has checked the fix against the live site.

  4. 4 weeks out

    Freeze the payment pages Coming

    From here, only authorised scripts reach checkout. Tamper detection is switched on and alerting, and a named person responds to it. Tag-manager access to checkout pages is locked.

  5. 2 weeks out

    Watch for lookalikes Coming

    Search for domains, apps and social accounts impersonating your brand and your sale. CERT-In has warned of festive-offer campaigns built on exactly this. Tell customers where your real offers appear.

  6. 1 week out

    Rehearse the bad day Coming

    Walk through a checkout compromise or an outage: who pauses what, who calls the payment provider, who reports to CERT-In within six hours, and who writes to customers.

  7. Sale week

    Watch the page, not only the servers In force now

    Check payment-page scripts and headers more often than the weekly minimum while traffic peaks, and keep the change freeze.

  8. 2 weeks after

    Take down what the sale added Coming

    Remove temporary scripts, campaign microsites, agency logins and plugin accounts added for the sale, and update the script inventory.

A general sequence, not a compliance programme. Your acquirer, payment provider or assessor may set requirements of their own.

14-question self-check

Payment-page script readiness

Built on PCI DSS 6.4.3 and 11.6.1 and the practices that make them work. Tick only what you could show an assessor today. Nothing you tick leaves this page.

Evidence

What the data says about retail

Global breach patterns from Verizon’s retail analysis, the script supply-chain case, and one retailer’s own estimate of the cost. Each is linked in the sources.

806 Confirmed retail breaches in Verizon’s 2026 data — nearly double the year before [1]
68% Of retail breaches involved a third party [1]
42% Of retail breaches with a known way in began with an exploited vulnerability [1]
19% Of retail breaches with a known motive were espionage, up from 9% [1]
100K+ Websites that embedded the polyfill.io script before its new owner used it to inject malware [3]
£300M Operating-profit hit Marks & Spencer forecast after its 2025 cyber attack — 30.5% of annual operating profit [4]

Verizon’s figures describe retail breaches in its global dataset, not Indian ones specifically.

Where retailers get hurt

Four ways retailers have been hurt

Three from reported cases. The fourth is the one that turns a discount into a loss.

01

The script that changed hands

  1. Way inA popular script library, loaded from its own domain by thousands of sites, bought by a new owner.
  2. ThenMalicious code served to visitors of every site that loaded it — only on some devices, at some hours, and never to administrators.
  3. CostMore than 100,000 sites exposed through code none of them had changed — the polyfill.io case of 2024.

What we test: An inventory of every third-party script, where each loads from, and whether it is pinned to a version you reviewed.

02

The day the online store stopped

  1. Way inAn intrusion that spread through the systems behind payments, click-and-collect and the website — the retailer’s chief executive later put its cause down to “human error”.
  2. ThenContactless payments and click-and-collect suspended first, then all online orders.
  3. CostA forecast £300 million hit to operating profit and online disruption lasting into July — Marks & Spencer, 2025.

What we test: The accounts, help-desk processes and internal paths that let one mistake become a company-wide outage.

03

The festive offer that was not yours

  1. Way inMessages on WhatsApp, Telegram and Instagram promising festive gifts from a well-known brand.
  2. ThenShoppers land on a lookalike site and hand over logins, card details or one-time passwords.
  3. CostCustomers defrauded in your name and a brand that takes the blame — the pattern CERT-In warned of before Diwali.

What we test: Where your real offers and apps live, how customers can check them, and what you publish under your own domains.

04

The coupon that stacked

  1. Way inA promotions API that trusts the basket total, the coupon count or the loyalty balance sent by the app.
  2. ThenDiscounts combined, reused or applied to items they were never meant for, at sale-day volume.
  3. CostLosses that look like sales until the reconciliation — and bots that find the flaw faster than your team.

What we test: Business-logic testing of checkout, coupons, gift cards and loyalty before the sale starts.

Next step

Ten weeks is enough. Four is tight.

A 30-minute call with a practitioner who tests checkouts for a living. No charge, and no obligation.

  • What to test before your next sale, in the time you have
  • Whether your payment pages meet PCI DSS 6.4.3 and 11.6.1
  • Which SAQ you should be using, and why
  • A fixed price, with a retest of every fix included
Book the call We reply within 24 business hours.

Where SemperWise fits

What we do for retailers and online stores

Services are people doing the work; SemperWise One is the platform that keeps the evidence current between engagements. Each row says which.

“Test our checkout and promotions.”

Service

Authenticated testing of checkout, coupons, gift cards, loyalty and account takeover — the business logic scanners miss.

Web application testing

“Our shopping app and its APIs.”

Service

API testing for price and quantity tampering, one customer reading another’s orders, and weak session handling.

API security testing

“Are we ready for PCI DSS?”

Service

Readiness against PCI DSS v4.0.1 — including 6.4.3 and 11.6.1 and your SAQ eligibility — and fix verification before your assessment.

PCI DSS readiness

“Our store runs on WordPress.”

Service

Plugin, theme and hosting review for WooCommerce and other WordPress stores, where most small-store compromises begin.

WordPress security

“What do we have online?”

SemperWise One™

Continuous discovery of every site, campaign microsite and exposed system under your domains.

Attack surface management

“Evidence for the assessor.”

SemperWise One™

In SemperWise One, PCI DSS controls with dated evidence, findings and retests, so the assessment is not a scramble.

Compliance automation

“Our store staff and help desk.”

Service

Awareness sessions for the people attackers call first — store staff, customer service and the help desk.

Security training

Terms

Retail security terms, defined

PCI DSS v4.0.1
The card industry’s data security standard in its current version; its payment-page requirements took effect on 31 March 2025.
Requirement 6.4.3
Every script on a payment page is authorised, has its integrity assured, and is inventoried with a written justification.
Requirement 11.6.1
A change- and tamper-detection mechanism alerts you to unauthorised changes to payment-page scripts and security-impacting HTTP headers, at least weekly.
SAQ A
The shortest PCI self-assessment, for merchants that fully outsource payment pages; since 2025 it requires confirming the site is not susceptible to script attacks.
SAQ A-EP
The self-assessment for e-commerce merchants whose website can affect the security of the payment page, with many more requirements than SAQ A.
Web skimming
Malicious code on a checkout page that copies card details as they are typed — often called Magecart after the groups that popularised it.
Script supply chain
The third-party code your pages load from other domains, any of which can change without you changing anything.
Content security policy
An HTTP header that tells the browser which sources a page may load scripts from.
Credential stuffing
Trying usernames and passwords leaked from other sites against your login, at scale.
Business-logic abuse
Using a feature as built but not as intended — stacking coupons, replaying gift cards, changing a price in a request.
Targeted risk analysis
The PCI DSS analysis that can justify a frequency other than the default — for example, for 11.6.1 checks.

Questions

Retail security — answered.

What buyers in this sector ask us before they commit to anything.

What are PCI DSS requirements 6.4.3 and 11.6.1?

Two requirements added in PCI DSS v4 to protect payment pages in the shopper’s browser. 6.4.3 requires that every script loaded and executed on a payment page is authorised, has its integrity assured, and is recorded in an inventory with a written business or technical justification. 11.6.1 requires a change- and tamper-detection mechanism that alerts staff to unauthorised changes to payment-page scripts and security-impacting HTTP headers as the browser receives them, evaluated at least weekly or as a targeted risk analysis sets.

When did 6.4.3 and 11.6.1 become mandatory?

On 31 March 2025, when the future-dated requirements of PCI DSS v4.0.1 took effect. Merchants and service providers assessed after that date are expected to meet them, unless they are eligible for SAQ A and meet its script-related eligibility criterion instead. Before then they were best practice; an assessment today will look for the script inventory, the authorisation and integrity methods, and evidence that tamper alerts were reviewed.

Do they apply if we use a payment gateway’s hosted page?

If you validate with SAQ A, you no longer answer 6.4.3 and 11.6.1 directly; since the January 2025 revision you must instead confirm that your site is not susceptible to attacks from scripts that could affect your e-commerce systems. The PCI Council says this does not remove or diminish the underlying requirements. If you cannot make that confirmation, SAQ A-EP applies, with far more requirements. Ask your acquirer or assessor which applies to you.

How should an online store prepare for a festive sale?

Start about ten weeks out. Inventory every payment page and script, test checkout, promotions and login for abuse, fix and retest, then freeze the payment pages about four weeks before the sale with tamper detection switched on. Watch for lookalike sites and fake offers in the final two weeks, rehearse an incident in the last week, and remove anything added for the sale afterwards. The countdown on this page sets it out step by step.

What does the DPDP Act mean for large e-commerce platforms?

From about 13 May 2027, all online retailers become subject to the DPDP Act’s duties on notice, consent, security safeguards and breach reporting. An e-commerce platform with two crore or more registered users in India also has to erase a user’s personal data three years after they last used the service or exercised their rights — with exceptions for account access and stored tokens such as wallet balances — and must tell the user at least 48 hours before erasure. See our DPDP readiness assessment.

Must a retailer report a breach to CERT-In?

Yes. Under CERT-In’s April 2022 Directions, listed incidents — including data breaches, website compromise and defacement, and attacks on applications — must be reported within six hours of noticing them, and logs kept for 180 days in India. Your payment provider and card brands have notification requirements of their own, and from May 2027 the DPDP Act adds notice to the Data Protection Board and affected customers.

Are you a PCI QSA or ASV?

No. SemperWise is not a PCI Qualified Security Assessor or Approved Scanning Vendor, and cannot sign a Report on Compliance or issue ASV scan reports. We prepare you for the assessment, test the checkout and promotions, verify fixes and keep the evidence — and your QSA or ASV does the formal validation. We say so up front.

How do we protect customers from fake sites using our brand?

Publish, in one place under your own domain, where your real offers, apps and customer-service numbers are; enforce email authentication so nobody can send mail as your domain; and search regularly for lookalike domains, apps and social accounts, especially before a sale. Report impersonating sites to the registrar, the platform and CERT-In. The less your customers have to guess, the less a fake offer works.

Sources

Checked by our research desk on 24 September 2026. Regulations and figures move; where a number here matters to a decision, follow it to the source.

  1. 2026 Data Breach Investigations Report (retail) — Verizon, 2026
  2. Important updates announced for merchants validating to Self-Assessment Questionnaire A — PCI Security Standards Council, January 2025
  3. Polyfill supply chain attack hits 100K+ sites — Sansec, June 2024
  4. M&S cyberattack to wipe out nearly one-third of annual profits — CNBC, 21 May 2025
  5. M&S suspends all online sales as cyber attack worsens — Computer Weekly, April 2025
  6. PCI DSS guidance for requirements 6.4.3 and 11.6.1 — CampusGuard
  7. Big changes for SAQ A: 2025 updates for 6.4.3 and 11.6.1 — SecurityMetrics, 2025
  8. CERT-In cautions of fake festival gift messages — Deccan Herald, 21 October 2022
  9. Digital Personal Data Protection Rules, 2025 (Rule 8 and Third Schedule) — MeitY, 13 November 2025
  10. Directions under sub-section (6) of section 70B of the IT Act, 2000 — CERT-In, 28 April 2022

Where retail clients usually start

Governance, Risk & Compliance PCI DSS Scope reduction, testing and SAQ or RoC readiness Read more → Application Security Web Application Testing OWASP Top 10, ASVS and business logic Read more → Application Security API Security Testing REST, GraphQL and service-to-service Read more → Technology Security WordPress Security Hardening and testing for WordPress sites, plugins and themes Read more →

All 17 industries we serve

Next step

Test the checkout before the traffic arrives.

A 30-minute call, no charge. You leave knowing what to test before your next sale, whether your payment pages meet 6.4.3 and 11.6.1, and what can still be fixed and retested in the time left — with a written scope and fixed price if testing makes sense.

Book a sale-readiness call See our coverage