After we alert you —
what happens, and what we ask of you.
The moment a finding is confirmed real, both sides have work to do. This page states our side and yours: the call you get, the exact steps we walk you through platform by platform, what we check afterward to confirm containment actually took, and the short list of things we will never do to your systems. Published so nobody has to guess mid-incident.
Reviewed by the founder · last updated 17 September 2026. If we ever do less than this page says, that's a bug: security@familysentinel.org reaches a person.
What happens, start to close.
We follow a five-step response model used across the security industry. In plain English, applied to a real finding:
Detect
Our engine reads the signals — sign-ins, admin changes, forwarding rules, rogue app grants — around the clock. Nothing reaches you at this stage; it reaches our Security Architect.
Verify & triage
A person confirms the finding is real and decides how serious. Some findings stop here — verified as noise, logged, never surfaced to you. Real, serious findings move on.
Scope, contain, eradicate, recover
The loop below, worked with you, repeated until nothing new turns up.
Close, with a name attached
Closure happens when the checks are green and you — or whoever you name as the decision maker — sign off on the residual risk in writing.
Debrief
A short report and a lessons-learned call, so the same gap does not reopen next quarter.
The 60-minute business-hours SLA.
When a finding is verified as a real P1 or P2, you get a phone call within 60 minutes of a person verifying it (Mon–Fri, 8am–6pm Central, excluding US federal holidays), on Guardian and above. Outside those hours it is best-effort, except on Guardian Complete, where the 60 minutes applies around the clock. The clock starts at verification, not at the first automated signal, because we would rather call you with something real than fast with something wrong. Essentials gets a same-day email plus this same checklist, in writing, to work from with your IT provider. Every call covers the same three things: what happened, why it matters to your organization specifically, and one clear recommendation to start with.
Two minutes, before you touch anything.
Write down the time, the account, and what you saw. Do not delete a forwarding rule or a connected app until you have noted its exact name and destination — that name is evidence, and once it is gone, it is gone. Then work the steps for your platform as close to simultaneously as you can; doing them one at a time gives an attacker time to notice and react.
Per-platform containment — what you do, what we validate.
The exact steps we walk you through on the call, for whichever platform is affected. The right-hand column is what we check afterward, read-only, to confirm the step actually took — not just that it was attempted.
Google Workspace — compromised user
| # | Step (admin console) | Why | We validate, read-only |
|---|---|---|---|
| 1 | Reset the password (Directory → Users → user → Reset password); do not email it to the same mailbox | Stops the credential | Sign-ins after reset use the new credential |
| 2 | Sign the user out of all sessions (Security → Sign-in cookies → Reset) and reset app passwords | A password reset alone leaves tokens valid | No sessions older than the reset |
| 3 | Remove third-party app access (Security → Connected applications) you do not recognize | OAuth grants survive password resets | No unrecognized grants remain |
| 4 | Remove forwarding and filters that forward, delete or move mail | The attacker's quiet persistence | No external forward; no delete/move rules |
| 5 | Check mailbox delegation and remove unknown delegates | Send As / Full Access persists | No unknown delegates |
| 6 | Re-enroll 2-step verification; remove backup codes and unknown phones/keys | Attacker-registered factors | 2SV enrolled, no unknown factors |
| 7 | If the user is an admin: review admin roles, recent admin audit events, and API clients | Tier-0 persistence | No new admin roles / API clients |
| 8 | Export the login audit for the window and keep it | Evidence | We already hold it; you keep a copy |
Microsoft 365 / Entra ID — compromised user
| # | Step | Why | We validate, read-only |
|---|---|---|---|
| 1 | Reset the password (Entra admin → Users → Reset password) | Stops the credential | — |
| 2 | Revoke sessions (user → Revoke sessions) | This invalidates refresh tokens — a password reset alone does not | Sign-in token version incremented |
| 3 | Review Enterprise applications consent and the user's app grants; remove anything with Mail.Send, Mail.ReadWrite, MailboxSettings.ReadWrite or Files.ReadWrite.All you do not recognize | A common persistence path once a session is compromised | No unrecognized grants |
| 4 | Remove inbox rules that forward externally or move/delete mail, and any recently added transport rules | Quiet persistence | Rules clean |
| 5 | Remove unknown Full Access / Send As permissions | Delegation persists past a password reset | Delegation clean |
| 6 | Re-register MFA; delete unknown authentication methods and devices | — | MFA methods known |
| 7 | If Conditional Access exists: require a compliant device or block the sign-in country until cleared | — | No sign-ins from the flagged geography |
| 8 | Export sign-in and audit logs now — the Entra free tier retains only 7 days | Evidence | We already hold it |
AWS — compromised IAM user or key
| # | Step | Why | We validate, read-only |
|---|---|---|---|
| 1 | Deactivate the access key (IAM → Users → Security credentials → Make inactive); do not delete yet | Stops the key, keeps the record | Key inactive in CloudTrail |
| 2 | Revoke active sessions and reset the console password | Sessions outlive keys | No calls with the old session |
| 3 | Tag affected resources Status=UnderInvestigation, enable termination protection, snapshot EBS volumes | Evidence and safety | Tags present |
| 4 | Apply a quarantine security group (inbound only from your admin IP, no egress); keep the instance running | Preserves memory for later analysis | Security group applied |
| 5 | Check every region for new users, keys, roles, Lambda functions, startup scripts | Attackers park persistence in unused regions | GuardDuty + CloudTrail across regions clean |
| 6 | Turn on S3 Block Public Access account-wide if it is not already | A large share of exposed buckets hold sensitive data | Block Public Access on |
| 7 | Confirm CloudTrail data events are on for buckets holding sensitive data, and that billing alerts exist | You cannot prove what was read otherwise | Findings clear |
After containment on any platform: a same-day persistence hunt across rules, grants, delegation, MFA methods, sign-in geography and new keys — across all accounts, not just the one flagged — and thirty days of heightened watch on the tenant. Closure comes only when nothing new has appeared, the checks above are green, and your named decision maker signs off, with the residual risk written down.
What we never do, on any platform.
We do not hold your passwords, we do not sign in as you, we do not change settings, delete mail, or move money. You keep the keys, always. We give you the list, stay on the phone, and confirm afterward that each step actually took. See also how our checks stay safe.
What comes next.
Once the platform checklist is green, we move into eradication and recovery: the persistence hunt, the 30-day watch, and — on Guardian and above — the debrief report and lessons-learned call. Full pricing for these services, and what stays scoped separately as a fixed quote, is on the scope & boundaries page.
Response model adapted from Dynamic Incident Response by Joshua Wright, © 2026 SANS Institute, licensed CC BY 4.0.