Client Support Retainer: Security Incident / Suspected Compromise Pack (With AI)

When a support retainer client forwards a “we think we were hacked” email, a login from a new country, or a password that showed up in a breach feed, you are not in a generic urgent P1 outage (site down) or a calm planned maintenance window. You are in a security incident: contain first, communicate with care, rotate credentials with a paper trail, and preserve evidence without turning the ticket into panic theater.

This pack gives freelancers and small agencies a repeatable workflow with ChatGPT (FACT vs ASSUMPTION triage), a one-page Google Doc Security Incident Brief, and sequenced Gmail updates—so billable retainer hours stay focused and the client gets written clarity.

What this pack is (and is not)

It is: a suspected credential compromise, phishing click, rogue admin session, or leaked password playbook while the retainer is active.

It is not: a full post-incident RCA after a major outage (use that pack once service is stable), a vendor escalation when the SaaS vendor owns the fix, or primary contact change paperwork. You can link to those guides if the incident grows.

Before you start (5-minute setup)

1. Confirm retainer scope covers security response (or note if you will bill a one-off incident block).
2. Identify systems in scope: identity (Google/Microsoft), hosting, CRM, payment, shared inboxes, API keys.
3. Open a dated folder: ClientName-Security-Incident-YYYY-MM-DD with read-only exports only—no secrets in email bodies.

Step 1 — Triage with FACT vs ASSUMPTION

Paste the client’s message, alert screenshot text, or sign-in log export into ChatGPT with this prompt:

You are an IT incident triage assistant for a small business. Split the input into FACT (observed data) and ASSUMPTION (interpretation). List immediate containment actions that are safe without destroying evidence. Flag anything that needs legal or insurance review. Output bullets only; no drama.

Review the ASSUMPTION list yourself. Clients often merge “someone clicked a link” with “we lost everything.” Your job is to name what is verified.

Step 2 — Contain without guessing

Use this minimum containment checklist (adapt to their stack):

• Force sign-out of all sessions for affected accounts.
• Disable or reset passwords for compromised identities; use a password manager for new secrets.
• Revoke and re-issue API keys, OAuth apps, and webhook secrets that touched the account.
• Turn on or verify MFA on admin accounts.
• Preserve logs: export sign-in, audit, and mail filter rules before cleanup.
• If email forwarding rules appeared, remove them and document the rule text in the brief.

Do not wipe devices or delete mailboxes until scope is documented—retainer clients often need that evidence for insurers.

Step 3 — Security Incident Brief (Google Doc)

Create a one-page doc titled Security Incident Brief — [Client] — [Date]. Sections:

1. Summary — one paragraph, FACT-only.
2. Timeline — UTC and client local time.
3. Scope — accounts, apps, data classes touched (mark unknowns explicitly).
4. Containment actions taken — who did what, when.
5. Rotation list — passwords, keys, tokens pending vs done.
6. Client actions required — e.g., notify payroll if bank details were in a mailbox.
7. Open questions — vendor tickets, legal, cyber insurance claim number.
8. Communication log — link Gmail threads.

Share view-only with the client primary contact; keep edit access on your side until closed.

End-to-end flow

Step 4 — Gmail sequence (copy-ready)

Email 1 — Notice (within 2 hours of confirmed signal)

Subject: [Action] Security incident — containment in progress — [Client]

Body skeleton: what we know (FACT), what we are doing now, what we need from them (e.g., confirm last legitimate login), link to the Google Doc, single point of contact.

Email 2 — Action required (same day)

List rotations they must perform (bank portal, personal email if reused, social accounts). Set a deadline. Offer a 15-minute call slot.

Email 3 — All-clear (after verification)

Subject: Security incident closed — verification complete — [Client]

Summarize rotations completed, monitoring for 7 days, and one lesson (e.g., MFA on admin). Point to the monthly retainer review row.

Step 5 — Verify “clean enough to close”

Checklist before all-clear:

• No unknown admin users or mail rules remain.
• MFA enabled on privileged accounts.
• Passwords and API keys on the rotation list are marked done with dates.
• Client acknowledged the brief in writing (reply OK).

If verification fails, loop back to containment—do not send all-clear to “stop the emails.”

Step 6 — Retainer hygiene

Add one row to your monthly retainer review log: incident date, root cause category (phishing, credential reuse, vendor breach), hours burned, preventive action (training, MFA policy). If the incident caused downtime, cross-link your post-incident retrospective guide for a blameless follow-up.

Practical tips

• Bill transparently: security work is retainer-worthy; note incident hours separately in the brief footer.
• Avoid naming attackers in client comms; stick to observable facts.
• Escalate early if payment data or health data may be involved—your doc should say “legal notified” not diagnose compliance outcomes.

You now have a written, client-visible path from suspicion to verified recovery—without conflating security response with a generic outage ticket.