Post-Breach User Communication: A 48-Hour Playbook

When unauthorized access hits your authentication service, technical fixes are often straightforward. The real challenge is how you communicate with millions of affected users in the first 48 hours. This determines whether they trust you afterward. The recent Capcom breach of CAPCOM ID, affecting 11,774,247 email addresses, offers a case study in the dual-track response your incident response team needs to execute simultaneously.

Why Immediate User Communication Matters

Your breach notification isn't just a legal requirement. It's the first moment affected users decide if you're handling the situation competently or trying to cover it up. Most incident response teams focus on containment and forensics during the first 48 hours, treating user communication as a secondary task. This delay creates a vacuum where speculation, media misreporting, and phishing campaigns can thrive.

The Capcom incident highlights the stakes: 196 users had their passwords changed by attackers, and 43 had additional personal details compromised. Without immediate, specific guidance, you're leaving users exposed to credential stuffing and targeted phishing while your forensics team works.

Preparation Before a Breach

Before unauthorized access occurs, your incident response team needs these components ready:

Pre-approved communication templates

• Breach notification email (generic version)
• High-risk user notification (for users with password changes or elevated exposure)
• FAQ page template
• Internal stakeholder briefing

Notification infrastructure

• Dedicated email sending service with authenticated domains (DKIM, SPF, DMARC configured)
• Incident-specific subdomain (e.g., incident-response.yourcompany.com) already provisioned
• Contact form or helpdesk queue with IR team access
• SMS gateway if your authentication service has phone numbers on file

Legal and regulatory checklist

• Breach Notification Requirement timelines for your jurisdictions (most US states: 30-60 days; GDPR: 72 hours for authorities, "without undue delay" for individuals)
• Pre-identified outside breach coach if your in-house counsel lacks breach experience
• Regulatory contact list (state attorneys general, data protection authorities, sector regulators)

Segmentation criteria

• How you'll categorize affected users by exposure level
• Thresholds for high-risk notification (e.g., any user with password change, any user with financial data exposed)

Step-by-Step Implementation

Hour 0-4: Confirm Scope and Trigger Notifications

1. Lock down the compromised service

   • Revoke active sessions for the affected authentication system.
   • If attackers changed passwords (as they did for 196 Capcom users), force password resets for those accounts immediately.
   • Document the timeline: discovery date, estimated intrusion window, containment actions.

2. Segment your affected population

   • Create three tiers based on what was compromised:
     • Tier 1: Email addresses only
     • Tier 2: Email + account metadata (login dates, IP addresses)
     • Tier 3: Email + personal details (dates of birth, gender, location) or password changes
   • Export lists with unique identifiers but no PII in filenames.

3. Draft tier-specific notifications

   • Tier 1 (majority): Generic breach notice, phishing warning, no immediate action required.
   • Tier 2: Same as Tier 1 plus warning about IP-based targeting.
   • Tier 3: Immediate password reset required, enable MFA, monitor for account takeover.

Hour 4-12: Execute First Wave Communication

4. Send high-risk notifications first

   • Start with Tier 3 users (those 196 password-change accounts in Capcom's case).
   • Include specific actions: "We reset your password on [date]. You must create a new password at [dedicated reset page]."
   • Provide a unique incident reference number per user for helpdesk tracking.

5. Publish your incident page

   • Post a public statement on your main domain with:
     • Discovery date (Capcom disclosed October 19)
     • What data was accessed (be specific: "email addresses and account creation dates" not "user data")
     • What you're doing about it
     • How users can verify legitimate communication from you
   • Include a sample of what your official emails look like (subject line, sender address).

6. Notify regulators where required

   • File First Notice of Loss with your cyber insurer (triggers breach coach and coverage).
   • Submit regulatory notifications within jurisdiction timelines.
   • Document submission timestamps and confirmation receipts.

Hour 12-24: Broad Notification and Phishing Defense

7. Send Tier 1 and Tier 2 notifications

   • Batch send to remaining affected users.
   • Stagger if your email infrastructure can't handle 11+ million simultaneous sends.
   • Monitor bounce rates and spam complaints (>5% suggests delivery issues).

8. Implement phishing countermeasures

   • Register common typosquat domains related to your incident page (e.g., yourcompany-breach.com variations).
   • Set up monitoring for phishing emails impersonating your breach notification (DMARC reports, brand monitoring tools).
   • Publish indicators of legitimate vs. fraudulent communication (Capcom warned users about "unsolicited email messages impersonating the company").

9. Staff your helpdesk

   • Route incident-related contacts to trained IR team members, not general support.
   • Create scripted responses for common questions: "Was my password stolen?" (No, but reset anyway), "Should I freeze my credit?" (depends on what data was exposed).

Hour 24-48: Validation and Iteration

10. Track notification delivery and engagement

    • Monitor: delivery rate, open rate, password reset completion rate.
    • If <30% of Tier 3 users reset passwords in 24 hours, send a second notification with stronger language.

11. Update your incident page with FAQs

    • Add questions you're receiving via helpdesk.
    • Clarify any media misreporting.
    • Post timeline updates as forensics progresses.

Validation - How to Verify It Works

User-facing metrics:

• Password reset completion rate for Tier 3 users should exceed 80% within 72 hours.
• Helpdesk volume should peak in hours 12-36, then decline (sustained high volume suggests unclear communication).
• Phishing report submissions should be <1% of total affected users (higher suggests your notification was confusing).

Technical validation:

• Email authentication passing (check DMARC reports for your incident notifications).
• No unauthorized DNS changes or subdomain hijacking on your incident response domain.
• Session invalidation confirmed for all affected accounts.

Regulatory compliance:

• Documented proof of notification within jurisdiction timelines.
• Breach coach review of all public statements before publication.
• Insurer acknowledgment of First Notice of Loss.

Maintenance and Ongoing Tasks

Week 1-2:

• Send follow-up notification to users who haven't reset passwords (if applicable).
• Publish forensics summary when investigation concludes (what happened, how attackers got in, what you've fixed).
• Monitor dark web and credential-stuffing services for your leaked email list.

Month 1-3:

• Implement technical controls identified during forensics (MFA enforcement, session timeout reduction, anomaly detection).
• Conduct tabletop exercise with your IR team using this incident as the scenario, identify what you'd do differently.
• Review your cyber insurance policy's Breach Notification Requirement coverage; confirm your costs are within sublimits.

Ongoing:

• Update your communication templates based on what worked and what caused confusion.
• Pre-stage incident subdomains and authenticated sending infrastructure for future events.
• Train your helpdesk on breach response protocols quarterly.

Your users will judge your breach response not by whether it happened, but by how clearly and quickly you told them what to do about it. The technical remediation buys you time; the communication determines whether they'll trust you when it's over.