Retail and E-commerce
Protecting shoppers, payments and omnichannel platforms
INDUSTRY FACT FILE · RETAIL & E-COMMERCE
Cybersecurity FAQs for Retail and E-commerce
Forty frequently asked questions and answers in five categories, written for Boards, CTOs and CISOs, engineering and product teams, payments and fraud teams, marketing and operations leaders.
|
In this document 1. Category 1: Cyber risk, governance and strategy 2. Category 2: Regulation, standards and partner requirements 3. Category 3: Storefronts, APIs, payments and checkout 4. Category 4: SOC, incidents, fraud and resilience 5. Category 5: Customers, data, partners and brand |
Category 1: Cyber risk, governance and strategy
Audience: Boards, CEOs, CFOs, CTOs and CISOs
Q1. Why are retailers and e-commerce platforms attacked so often?
Because they hold the three things attackers monetise fastest—cards at the checkout, stored value in accounts and loyalty programmes, and large customer databases—and because their storefronts, APIs and partner integrations are open by design. Imperva measured bad bots at 59% of retail web traffic in 2025.
Q2. What are the biggest risks for an Indian retailer or platform?
Payment page skimming, account takeover and bots, customer database leaks, festive-season DDoS and outages, compromise through a script, plugin, partner or franchisee, ransomware across stores and dark stores, and slow detection that misses CERT-In's six-hour reporting window.
Q3. Which incidents should the Board know about?
Marks & Spencer's 2025 ransomware attack with an estimated £300 million profit impact; British Airways' 2018 Magecart skimming and £20 million fine; Target's 2013 vendor-led breach of about 40 million cards; and the Indian leaks at BigBasket, Juspay, Domino's India and boAt involving millions of customer records.
Q4. Is this an engineering problem or a business problem?
Both. Most retail incidents exploit business logic, third-party trust or customer behaviour rather than a single bug, and their cost lands on revenue, fraud losses and brand. Security must be owned jointly by engineering, payments, fraud, marketing and operations, with the Board accountable.
Q5. What should the Board review each quarter?
Festive-readiness status, results of application and API testing, payment page and PCI DSS posture, fraud and account takeover trends, customer data inventory and DPDP progress, partner access, incidents and near misses, audit findings and SOC coverage.
Q6. Who should own retail cybersecurity?
A CISO or security head reporting to the CTO or CEO, working with payments, fraud and privacy leads, with clear ownership of each platform, store estate and partner relationship and a single inventory of applications, APIs and data stores.
Q7. How should we prioritise investment?
Secure the checkout and payment integrations, harden identity and the APIs behind the app, map and protect customer data, control partner and script access, test for the peak and build monitoring that includes fraud signals—in that order.
Q8. How can Codec Networks help?
Codec Networks provides web, mobile and API VAPT, payment integration and PCI DSS v4.0.1 reviews, DPDP privacy programmes, brand and fraud protection, bot, DDoS and festive-readiness testing, 24x7 retail SOC, forensics and crisis exercises.
Category 2: Regulation, standards and partner requirements
Audience: Compliance, legal, company secretarial, payments and CISO offices
Q9. Do CERT-In Directions apply to retailers and platforms?
Yes. They apply to bodies corporate generally. Cyber incidents, including data breaches and unauthorised access, must be reported within six hours of noticing them and ICT logs retained for 180 days in India.
Q10. What do CERT-In's 2025 audit guidelines expect?
Risk-based, independent cyber audits covering applications, APIs, cloud and infrastructure, with closure of findings—so storefronts, payment integrations and cloud platforms belong in the audit scope.
Q11. Can we store our customers' card numbers?
No. Under RBI's payment aggregator framework, merchants may not store customer card credentials, and since 1 October 2022 saved cards must be card-on-file tokens issued by networks or issuers. Your systems should only hold tokens and limited data for transaction tracking.
Q12. Does PCI DSS apply to us if a payment aggregator handles payments?
Usually yes, in a reduced scope. Acquirers and aggregators carry PCI DSS obligations into merchant contracts, and since March 2025 the v4.0.1 requirements on payment page script inventory and tamper detection apply even to sites using hosted or embedded payment pages, subject to your validation route.
Q13. What do the E-Commerce Rules and dark-pattern guidelines require?
The Consumer Protection (E-Commerce) Rules, 2020 require a grievance officer, a nodal contact, seller and charge disclosures and fair practices; the CCPA's 2023 guidelines prohibit thirteen dark patterns such as false urgency, basket sneaking and subscription traps. Applicability depends on whether you are a marketplace or inventory seller.
Q14. What must listed retailers disclose?
Under SEBI's LODR Regulations, listed entities disclose cyber security incidents, breaches and loss of data in the quarterly corporate governance report, and material events as required.
Q15. How does the DPDP Act affect a retailer?
You process personal data of customers, loyalty members, sellers, riders and employees. The DPDP Act and Rules require notice, consent, safeguards, retention limits and breach intimation, with most obligations taking effect in May 2027—so data mapping and consent design should start now.
Q16. Can Codec Networks audit us?
Yes. Codec Networks is CERT-In empanelled and performs application, API and cloud audits, PCI DSS v4.0.1 gap assessments, ISO 27001 assessments and DPDP readiness reviews.
Category 3: Storefronts, APIs, payments and checkout
Audience: Engineering, product, payments and DevOps teams
Q17. How often should we test our website, apps and APIs?
At least annually in full, after every major release or new payment method, and with a focused retest before each festive season. Continuous testing suits platforms that release daily.
Q18. What is business-logic testing and why does retail need it?
It tests how the application behaves rather than only its code—can a coupon be reused, a price altered in the cart, a refund issued twice or stock reserved by a bot? Most retail fraud exploits logic, not injection flaws.
Q19. How do we protect the payment page from skimming?
Keep an inventory of every script on the page, authorise and integrity-check each one, isolate card entry in hosted or tokenised fields, deploy tamper detection, and assess the vendors behind third-party scripts.
Q20. How should we secure our payment gateway and UPI integrations?
Validate signatures and webhooks, never trust client-side amounts, handle tokens and callbacks securely, segregate payment keys, log every payment event and test the integration end to end after each change.
Q21. How do we stop credential stuffing and account takeover?
Rate-limit and monitor login and OTP flows, use risk-based MFA and device binding, detect leaked-credential replay, require step-up authentication for saved cards, points and address changes, and test these controls regularly.
Q22. How should we prepare for a festive or flash sale?
Load-test at projected peaks, test APIs and DDoS resilience, tune bot management and rate limits, freeze risky changes, rehearse runbooks with the SOC and CDN or WAF providers and staff a war room on sale day.
Q23. Are hosted commerce platforms and plugins safe by default?
The platform may be, but your configuration, plugins, themes, API keys and agencies are your responsibility. Review plugin permissions, remove unused ones, manage secrets and test the storefront as you would custom code.
Q24. Should mobile apps be tested separately from the web?
Yes. Apps expose their own APIs, store data on devices and can be reverse-engineered; test them against OWASP MASVS alongside API testing and web testing.
Category 4: SOC, incidents, fraud and resilience
Audience: SOC, fraud, risk, infrastructure and incident response teams
Q25. Do retailers need a 24x7 SOC?
Yes, if online revenue matters. Attacks peak at night and on sale days; a SOC that correlates platform, cloud, store and endpoint telemetry with fraud and bot signals catches account takeover and data exfiltration before customers do.
Q26. What should a retail SOC monitor?
Login and OTP anomalies, API abuse, payment page script changes, cloud storage and key usage, admin and support-agent activity, partner and franchisee access, POS and store networks, and gift card and refund velocities.
Q27. How should fraud and security teams work together?
Share signals and cases: credential stuffing is both a security event and a fraud precursor. Joint dashboards, shared playbooks and common identifiers for accounts and devices stop the same attack being handled twice or not at all.
Q28. What should an incident playbook include?
Containment that keeps the checkout and deliveries running where safe, card-data incident steps with the aggregator and acquirer, CERT-In reporting within six hours, customer and partner communication, SEBI disclosure if listed, and DPDP breach intimation once in force.
Q29. How should backups be designed?
Immutable or offline backups of OMS, WMS, POS back-ends, ERP, databases and configurations, with regular restore tests and documented restart sequences for the platform and the store estate.
Q30. Should we run exercises?
Yes—a festive-season war game with engineering, SOC and CDN or WAF partners, a ransomware tabletop with leadership and operations, and a breach-notification exercise with legal and communications, at least annually.
Q31. How quickly can a retailer recover from ransomware?
With segmented core systems, tested backups and manual store and delivery procedures, days; without them, weeks—as public cases show, with online orders halted for extended periods.
Q32. When should forensics be engaged?
As soon as compromise or card-data exposure is suspected, with investigators who understand e-commerce platforms, to preserve evidence, establish root cause and support CERT-In, partner, PCI and insurance processes.
Category 5: Customers, data, partners and brand
Audience: Marketing, CRM, privacy, procurement, operations and trust & safety teams
Q33. How do we protect our customer database?
Know every copy—CRM, CDP, warehouses, cloud exports, agencies—minimise and encrypt it, restrict access by role, monitor bulk access and downloads, and remove data you no longer need.
Q34. How should consent and personalisation work under DPDP?
Collect only what the purpose needs, give clear notices, record consent, honour withdrawal and retention limits, and design interfaces without dark patterns. Personalisation and retail media must rest on lawful, documented processing.
Q35. How do we deal with fake apps, sites and festive offers using our brand?
Monitor app stores, domains and social channels, issue takedowns quickly, warn customers through official channels and report large campaigns to CERT-In and law enforcement.
Q36. How do we manage risk from couriers, 3PLs, franchisees and agencies?
Tier partners by the access and data they hold, assess the critical ones, give them least-privilege, MFA-protected access through brokered channels, put security and notification clauses in contracts and review access regularly.
Q37. How should seller and partner portals be secured?
Test them like customer-facing apps, enforce strong authentication, separate seller data strictly, monitor for scraping and abuse, and review API keys and permissions issued to sellers and integrators.
Q38. How do we reduce loyalty, coupon and refund fraud?
Test redemption and refund logic, require step-up authentication for high-value redemptions, apply velocity limits, restrict support-agent overrides, and monitor patterns across accounts and devices.
Q39. What about AI chatbots and recommendation systems?
Treat them as applications: test for prompt injection and data leakage, limit what they can access and do, log interactions and review how customer data trains or feeds them.
Q40. How can we start with Codec Networks?
Begin with a scoping call on your platforms, payment stack, partners and sales calendar; Codec Networks will propose a peak-aware assessment and assurance plan.
Talk to Codec Networks
|
Contact Codec Networks Pvt. Ltd. New Delhi: 507, 5th Floor, New Delhi House, Barakhamba Road, Connaught Place, New Delhi – 110001 Gurugram: 707, 7th Floor, Silverton Tower, Golf Course Extension Road, Sector 50, Gurugram – 122018, Haryana Landline: 011 430 496 96 | 011 437 522 99 Mobile: +91 99716 76124 | +91 88007 88220 | +91 88003 31124 Email: mktg@codecnetworks.com Web: www.codecnetworks.com |
Note: These FAQs provide general guidance as of October 2026 and do not constitute legal or regulatory advice. Confirm obligations against the official instruments and your payment partner and platform contracts.