Peak Trading Readiness: A Cyber Resilience Plan for Black Friday and Seasonal Surges

The weeks around Black Friday, Cyber Monday and the Christmas run-up are when a retailer can least afford an outage, and they are also when bots, fraudsters and extortion groups are most active. Traffic multiplies, temporary staff and suppliers join in large numbers, changes are frozen and the security team is stretched across long trading hours. This guide is a readiness plan for that window: what to prepare in the twelve weeks before peak, how to run a change freeze that does not freeze security, how to protect capacity, checkout and customer accounts, how to staff the peak war room, and what to measure. It is written for heads of security, IT operations, ecommerce and digital leads, fraud teams and incident managers in retail, hospitality, ticketing and any business with a seasonal surge. What to do once an incident is under way is covered in the Retail Incident Response Guide; this page is about getting ready.

Source note: threat, standard and guidance references are from OWASP, the PCI Security Standards Council, the NCSC and NIST, as listed under Standards and references; the timeline, change freeze table and sizing guidance are NHI Mgmt Group recommendations. Confirm against the official text before relying on it.

Key takeaways

• Start twelve weeks out. Load tests, DDoS and bot defence tuning, supplier contacts and exercises all need time to fix what they find before the change freeze.
• Freeze features, not security. The peak change freeze should explicitly allow emergency patching, credential rotation, bot and WAF rule changes and blocking actions.
• Automated abuse looks like demand. Scalping, credential stuffing, carding and denial of inventory hide inside genuine peak traffic, so baselines must be set before the surge.
• Peak swells your identity estate. Seasonal staff, agency workers, outsourced help desks and supplier access all expand at once and must be time-bound and verified.
• Decide the hard calls in advance. Who can take the site offline, pause a promotion, or disconnect a supplier at 2am on Black Friday must be agreed and written down before the day.

Why peak changes the risk

Peak does not create new attack types, it changes the economics of the familiar ones. An hour of downtime costs many times more than in a normal week, which raises the pressure to pay an extortion demand or to restore systems before they are clean. Limited stock and heavy discounting reward automated buying and account takeover. Fraud volumes and customer contact volumes climb together, so a social engineering attempt on the help desk lands on agents who are already overloaded and often new.

The calendar also matters. Attackers favour weekends and holidays, when fewer staff are watching. The Marks and Spencer cyberattack began over the Easter weekend in April 2025: attackers impersonated a third-party user, deployed ransomware, and online ordering was paused from 25 April until June, at an estimated cost of around £300 million in profit. Peak readiness is about making sure that kind of event, if it happens in November, meets a team that has already rehearsed it.

Threats that peak amplifies

The OWASP Automated Threats to Web Applications project describes these threats as the misuse of valid functionality rather than the exploitation of vulnerabilities, which is why ordinary scanning and patching do not stop them.

See the Top 10 Automated Bot Attacks and the Ticket Scalping and Inventory Hoarding Bots Guide for the bot threats in depth.

The twelve-week readiness timeline

The timeline below is an NHI Mgmt Group recommendation; adjust the weeks to your own trading calendar.

1. Twelve weeks out, scope and owners: name a peak readiness owner and a security lead for peak; list the revenue-critical services (site, app, checkout, payments, stock, order management, fulfilment, customer service, store tills) with their owners, dependencies and suppliers. Agree the change freeze dates.
2. Ten weeks out, capacity and load tests: run load tests at a multiple of last year's peak against production-like environments, including the login, search, basket and checkout journeys and third-party services such as payment gateways and fraud scoring. Fix the bottlenecks found.
3. Eight weeks out, DDoS and bot defences: confirm upstream DDoS protection covers every internet-facing origin, including any origin that can be reached directly and bypass the protection; tune bot rules on last year's traffic; agree escalation contacts and response times with each provider. The NCSC's denial of service guidance frames this as understanding your service, understanding your defences, creating a response plan and testing it.
4. Eight weeks out, checkout integrity: refresh the inventory of every script loaded on payment pages, confirm each is authorised and integrity-checked, and confirm that tamper alerts reach a person who can act out of hours.
5. Six weeks out, identity hygiene: remove leavers and stale supplier accounts, set expiry dates on seasonal and agency accounts at creation, check that MFA covers every remote access path, and rotate shared and service credentials that are due before the freeze.
6. Six weeks out, exercise: run a tabletop of a Black Friday ransomware or DDoS extortion scenario with ecommerce, store operations, logistics, customer service, communications and the outsourced help desk. The NCSC's free Exercise in a Box includes ransomware, phishing and supply chain scenarios.
7. Four weeks out, patch and harden: apply outstanding critical patches, especially on internet-facing systems, before the freeze begins; confirm backups of order, stock and customer systems are complete and that a restore has been tested.
8. Two weeks out, war room set-up: publish the peak rota, the contact sheet (internal, suppliers, DDoS and bot providers, payment acquirer, insurer, incident response retainer), and the pre-approved decision list.
9. Peak, run and watch: daily stand-ups, live dashboards and named on-call cover for security through nights and weekends.
10. Two weeks after, review: hold a post-peak review covering incidents, near misses, false positives that hurt sales and bot or fraud losses, and feed it into next year's plan.

A change freeze that keeps security moving

Many retailers freeze changes to production around peak to reduce outage risk. That is sensible for features and infrastructure, but a freeze written too broadly blocks the very changes that contain an attack. NHI Mgmt Group recommends defining the exceptions in the freeze policy itself, with a fast approval path, as in the table below.

Rollback: every allowed change records how it is reversed. Bot and WAF rules should be deployed first in a monitoring or log-only mode where the tool supports it, and switched to blocking once their effect on genuine customers is understood.

Capacity, DDoS and bot defences

• Protect every path in: a DDoS service in front of the main site does nothing for an API host, an origin IP published in old DNS records, or a store VPN concentrator. List them all and test each one. See the DDoS Readiness Checklist.
• Scale and shed load: confirm auto-scaling limits and quotas, and agree in advance what can be switched off under load (recommendations, reviews, personalisation) to keep checkout alive. A virtual waiting room for launch hour is a valid control for both demand and bots.
• Baseline before peak: record normal login success rates, basket-to-checkout ratios and traffic by source in the weeks before, so that the surge can be separated from abuse.
• Tune bot rules on journeys, not pages: apply the strictest checks where value is extracted: login, account creation, gift card balance, add to basket for limited items and checkout. See the Bot Management Guide.
• Prepare the extortion response: a DDoS ransom note should trigger the rehearsed plan, not a negotiation. See the DDoS Response Playbook.

Checkout and payment integrity

The PCI Security Standards Council describes PCI DSS v4.x requirements 6.4.3 and 11.6.1 as aimed at reducing e-skimming: ensuring that payment page scripts are authorised, checking them for integrity, and monitoring payment pages for tampering, including security-impacting HTTP headers. Peak is when a skimmer does most damage, so treat these controls as peak-critical.

• Script inventory: list every script on payment pages with its owner and business reason; remove marketing tags that do not need to run there.
• Integrity and policy: use subresource integrity hashes for static scripts and a Content Security Policy that limits where scripts and form data can go.
• Tamper alerting at night: a change detection alert at 3am must reach someone with authority to roll back the page.
• Fraud rules tuned for volume: agree with the fraud team and the payment acquirer how card testing will be throttled without blocking genuine shoppers, and who can raise thresholds during a surge.

See the Ecommerce Store Security Checklist and the Loyalty Points and Gift Card Fraud Guide.

Where identity fits

Peak is the time of year when the identity estate grows fastest and is checked least. Seasonal store staff, warehouse agency workers, extra contact centre agents, outsourced help desk capacity and supplier engineers all need accounts quickly.

• Time-bound by default: create seasonal and agency accounts with an end date and least-privilege roles, and disable them automatically after peak.
• Help desk resets under pressure: a busy, partly temporary service desk is the ideal target for impersonation. Require call-backs to known numbers or manager approval for password and MFA resets, especially for privileged and third-party users, and brief the outsourced provider on the same rule.
• Supplier access: list every supplier with remote access to peak-critical systems, confirm their contacts for the period, and make sure their access can be cut quickly.
• Machine credentials: API keys for payment, fraud, delivery and marketing integrations often have broad rights and no expiry. Rotate those due before the freeze and know how to revoke each one in an incident. See the Retail and E-Commerce Identity Security Guide.
• Customer accounts: offer passkeys and check new passwords against breached password lists, so that credential stuffing at peak has less to work with.

Running the peak war room

• Roles: a peak incident commander for each shift, a security on-call, an ecommerce on-call, a payments and fraud contact, a communications lead and a supplier liaison.
• Pre-approved decisions: write down who can take the site or app offline, pause a promotion, switch on a waiting room, block a country, disable an integration, or move to manual store processes, and at what threshold.
• Escalation contacts: DDoS and bot providers, payment acquirer, cloud provider, incident response retainer and cyber insurer, with numbers tested in advance.
• Out-of-band communications: if email and chat are compromised, the war room needs another way to talk; agree it beforehand.
• Customer messaging: drafted holding statements for outage, data breach and fake promotion scams, approved by legal before peak.

Decision guidance by size. A small online retailer on a hosted ecommerce platform should focus on the platform's own bot, DDoS and account security settings, admin account MFA, payment page script control and a one-page incident contact sheet. A mid-size retailer adds load testing, a formal freeze policy with security exceptions and a tabletop exercise. A large multi-channel retailer needs the full timeline, a staffed war room around the clock, supplier exercises and a tested ability to trade with key systems down.

Detection and measurement

• Watch: login failure rate and failures per source; account creation velocity; gift card balance checks; card authorisation decline rate; basket hold volumes for limited stock; payment page script changes; help desk reset volumes for privileged and supplier accounts; DDoS and WAF events; sign-ins to seasonal accounts outside rostered hours.

Metrics that show readiness and performance:

1. Percentage of revenue-critical services load-tested at the target multiple before the freeze.
2. Percentage of internet-facing origins behind DDoS protection, with no directly reachable origin.
3. Seasonal and agency accounts created with an end date (target 100%) and disabled within 48 hours of their end date.
4. Time to triage a payment page tamper alert out of hours.
5. Credential stuffing login attempts blocked, and the false positive rate measured against conversion.
6. Number of open action items from the peak exercise closed before the freeze.

Framework mapping

Common failure patterns

• The freeze blocks the fix: a broad freeze policy delays an emergency patch or a bot rule change while attackers act.
• Load test without third parties: the site scales but the payment gateway, fraud scoring or address lookup service fails at peak volume.
• Unprotected origin: attackers find and flood an origin server or API host that sits outside the DDoS service.
• Seasonal accounts that never expire: agency and temporary accounts stay active into the new year with store or warehouse access.
• Help desk reset on request: overloaded agents reset a "contractor's" MFA without a call-back, as in the Marks and Spencer cyberattack, where impersonation of a third-party user was the way in.
• No one can decide: the war room spends the first hour of an incident finding out who may take the site offline.

Practitioner checklist

• Peak readiness owner, security lead and change freeze dates agreed twelve weeks out.
• Revenue-critical services, dependencies and suppliers listed with named owners.
• Load tests completed at the target multiple, including third-party services.
• Every internet-facing origin behind DDoS protection, with provider escalation contacts tested.
• Bot rules tuned on login, account creation, gift card, basket and checkout journeys.
• Payment page scripts inventoried, authorised and monitored for tampering out of hours.
• Freeze policy explicitly allows patching, credential rotation, blocking and supplier disconnection.
• Seasonal, agency and supplier accounts time-bound, with MFA and a verified help desk reset process.
• Peak ransomware or DDoS extortion tabletop held, with actions closed before the freeze.
• War room rota, contact sheet, pre-approved decisions and holding statements published.

Standards and references

• PCI Security Standards Council: Payment Page Security and Preventing E-Skimming
• OWASP: Automated Threats to Web Applications
• OWASP: OAT-005 Scalping
• NCSC: Denial of service (DoS) guidance
• NCSC: Exercise in a Box
• NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• MITRE ATT&CK: T1110.004 Credential Stuffing

Related NHI Mgmt Group resources: Retail Incident Response Guide · Cybersecurity for Retail and Ecommerce Guide · DDoS Protection Guide · Cyber Resilience Guide · Tabletop Exercise Guide