Loyalty Account Breach Response: The First 72 Hours

The short version: When loyalty accounts are taken over, freeze redemptions first, size the damage from your points ledger, and notify members and regulators on the clocks that apply to you — then restore every affected balance from the ledger, not from memory. Notification alone is not the response.

Key takeaways

• Freeze first, investigate second. Disable redemption and point-earning within the first hours; every transaction that happens while you investigate is damage you will have to unwind later.
• The ledger is your source of truth. Restore affected balances to each account's last clean state from the transaction log — never with a blanket points reset or a pre-incident backup.
• Two clocks, different triggers. UK GDPR requires notifying the ICO within 72 hours where the breach poses a risk to people's rights and freedoms; US state breach-notification laws vary by state in both trigger and scope. Confirm which apply with counsel.
• Document everything as you go. Timestamps, account lists, queries run, and decisions made — the record you build in the first 72 hours is the one you will rely on in every conversation afterwards.

This article is an operator checklist, not legal advice. Breach-notification duties depend on your jurisdiction, the data involved, and your contracts — confirm your obligations with a lawyer before you notify anyone.

Hour 0–4: Freeze redemptions and contain the incident

The first move in a loyalty account breach response is containment, not investigation. Disable redemption and point-earning across the program — a flag in your loyalty app, a feature toggle, or pausing the integration — so attackers cannot drain more balances while you work out what happened. Then force password resets for affected accounts and preserve your access and transaction logs before they rotate out of retention.

Preserving logs matters more than it looks. If you delete or overwrite the evidence of what the attacker did, you cannot later distinguish a stolen redemption from a legitimate one, and your restoration will be guesswork. Export logs to a separate file the moment you can.

The classic failure: the shop finds one suspicious redemption, refunds that one member, and moves on — while the attacker works through forty more accounts over the weekend. If one account was taken over, assume the perimeter is broken and check the whole program before you unfreeze anything.

How you got here is a separate problem, and it has its own checklist: Loyalty Program Fraud Prevention: Six Minimum Controls covers the controls that stop account takeover before it starts. Read that after the fire is out.

Hour 4–24: Size the incident from the ledger

The points ledger — the transaction-level record of every earn, redeem, and adjustment — is the only reliable way to size a loyalty breach. Query it for abnormal activity: redemptions outside a member's normal pattern, multiple redemptions in minutes, redemptions followed by password changes, or gift-card and discount-code issuance from accounts that never redeem. Pull the customer_id list for every flagged transaction.

Then compute your exposed liability so you know what you are actually on the hook for. The arithmetic is simple: count the affected accounts and multiply by their average point balance, converted to your redemption value.

For example — these are illustrative numbers, replace them with your own: say 40 accounts show abnormal redemptions, and your average member balance is 2,500 points worth $0.01 each. That is 40 × 2,500 × $0.01 = $1,000 of points liability, before you count goodwill gestures or support time. If the attacker redeemed rather than merely accessed, the liability is already spent and your question becomes restoration, not prevention.

While you are in the ledger, note which accounts show access but no redemption. The two groups get different messages later: drained balances versus accessed-but-untouched. Members can tell the difference, and so can a regulator.

Hour 24–72: Notify members and the regulator

Notification obligations differ by jurisdiction, and the two clocks most English-speaking shops care about work differently. Under UK GDPR, you must report a personal data breach to the ICO within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to people's rights and freedoms — a loyalty account holding names, emails, and purchase history will often clear that bar. US state breach-notification laws, by contrast, are triggered by specific categories of personal information and set their own deadlines and thresholds, which vary state by state. Which laws apply to you depends on where your members are and what data was exposed — that determination is a job for counsel, not for this checklist.

Your member notification should say, in plain language: what happened, when you detected it, what data and points were or were not affected, what you have already done (the freeze), and what the member should do now (reset their password, check linked accounts). Send it before members discover the problem themselves — a drained balance found by the member reads as cover-up, the same facts disclosed by you read as competence.

After 72 hours: Restore balances and close the incident

Restoration is where the incident is actually resolved, and the ledger gives you a better option than a blanket reset. Reconcile each affected account to its last clean state: the balance after its last legitimate earn and before the attacker's first illegitimate redemption. Members who had 3,400 points at 2pm on Tuesday get 3,400 points back — not an average, not a round number, and not zero.

Blanket resets — "we've reset everyone's points to zero for security" — punish your innocent members alongside the defrauded ones and destroy the exact goodwill you are trying to protect. The mechanics of rebuilding balances account by account are the same ones you would use in a platform switch; Loyalty Program Migration Without Losing Member Balances walks through the reconciliation approach in detail.

Communicate what was and was not touched. Members whose accounts show access but no theft should hear that their balance is intact and verified — that message costs you nothing and earns disproportionate trust. Once the incident is closed, upgrade the controls that let it happen: rate limits on redemptions, alerts on velocity spikes, and the access and data-handling rules in Loyalty Program Data Privacy: Six Operating Controls.

The classic failure: treating notification as the whole job

The most expensive version of this incident is the one where the shop sends a well-written breach email and then never reconciles the ledger. Members are told, passwords are reset, the freeze is lifted — and three weeks later someone tries to redeem and finds their balance drained anyway, because the restoration step was skipped or done from a stale export. A member told the matter is resolved, then finds a drained balance later, has been lied to twice — the second discovery lands harder than the first, and it costs you the member, not just the points.

Put the reconciliation on the calendar before you lift the freeze. The freeze stays on until every affected account is restored and spot-checked, and the member email promises a date for restored balances that your ledger can actually meet.

One note on the hour bands in this playbook: they are a working rhythm, not a deadline schedule. A small incident may compress the first two phases into a single afternoon; a sprawling one may stretch sizing past 24 hours. The sequence holds even when the clock does not — freeze, size, notify, restore, in that order, with the 72-hour regulator clock running underneath from the moment you become aware.

Frequently asked questions

Do I have to report a points-only breach to the ICO?

It depends on what data was involved. If the attacker accessed only point balances in a system that holds no personal data, there may be no reportable personal data breach; if the account exposed names, emails, addresses, or purchase history, UK GDPR's 72-hour reporting rule likely applies where there is a risk to those people — and a loyalty account minimally stores an email address tied to purchase history, so check whether yours does before assuming the exemption. The determination turns on your specific data and facts, so get a view from counsel rather than deciding alone.

Can I restore points from backups instead of the ledger?

Usually not, and this is the trap. A backup taken after the attacker started redeeming contains the attacker's redemptions as if they were legitimate transactions — restoring from it reinstates the theft. The ledger lets you identify and reverse specific illegitimate transactions; a backup cannot tell them apart from real ones. If you use a backup at all, use it only to cross-check balances, and derive the restoration from the transaction history.

What do I tell members whose points were stolen?

Tell them exactly what happened, the balance they will be restored to, and the date it will be done — then do it on that date. Offer a direct contact for questions, and skip the blame-shifting language ("members should use stronger passwords") entirely; it reads as the company deflecting. Members judge the incident less by the theft than by whether the restoration matched what you promised.