Account Compromise

Account compromise occurs when an unauthorised party gains access to a legitimate user’s credentials or active session, enabling them to operate within organisational systems as that user. This playbook addresses five distinct attack vectors: business email compromise (BEC) fraud, credential leaks from external breaches, password spraying attacks, MFA fatigue exploitation, and SaaS application takeover through malicious OAuth grants. Each vector requires specific detection and containment approaches, though all share common remediation and recovery procedures.

The playbook applies to standard user accounts. Compromised administrator or privileged service accounts require the elevated procedures in Privileged Access Breach due to their broader access scope and persistence implications.

Activation criteria

Invoke this playbook when any of the following indicators appear. Multiple indicators from the same account strengthen confidence that compromise has occurred rather than representing legitimate but unusual user behaviour.

Roles

For organisations without dedicated security staff, the IT Manager or sole IT person assumes both incident commander and technical lead roles. The communications lead role can transfer to a line manager for user notification once technical containment completes.

Response flow

The response proceeds through five phases. The total timeline depends on attack vector and scope, ranging from 2 hours for a single credential leak to 2 days for widespread BEC with financial impact.

+------------------------------------------------------------------+
|                   ACCOUNT COMPROMISE DETECTED                    |
+------------------------------------------------------------------+
                               |
                               v
              +----------------+----------------+
              |         PHASE 1: CONTAIN        |
              |         (0-30 minutes)          |
              +----------------+----------------+
                               |
         +---------------------+---------------------+
         |                     |                     |
         v                     v                     v
+--------+--------+   +--------+--------+   +--------+--------+
| Session         |   | Password        |   | MFA             |
| Revocation      |   | Reset           |   | Reset           |
+-----------------+   +-----------------+   +-----------------+
                               |
                               v
              +----------------+----------------+
              |      PHASE 2: SCOPE             |
              |      (30 min - 4 hours)         |
              +----------------+----------------+
                               |
         +---------------------+---------------------+
         |                     |                     |
         v                     v                     v
+--------+--------+   +--------+--------+   +--------+--------+
| Access          |   | Data            |   | Lateral         |
| Timeline        |   | Access          |   | Movement        |
+-----------------+   +-----------------+   +-----------------+
                               |
                               v
              +----------------+----------------+
              |    PHASE 3: VECTOR-SPECIFIC     |
              |    (1-8 hours)                  |
              +----------------+----------------+
                               |
       +-----------+-----------+-----------+-----------+
       |           |           |           |           |
       v           v           v           v           v
  +----+----+ +----+----+ +----+----+ +----+----+ +----+----+
  | BEC     | |Cred Leak| | Spray   | | MFA     | | SaaS    |
  | Fraud   | |Response | | Resp    | | Fatigue | | Takeover|
  +---------+ +---------+ +---------+ +---------+ +---------+
                               |
                               v
              +----------------+----------------+
              |        PHASE 4: RECOVERY        |
              |        (2-24 hours)             |
              +----------------+----------------+
                               |
                               v
              +----------------+----------------+
              |       PHASE 5: POST-INCIDENT    |
              |       (1-5 days)                |
              +----------------+----------------+

Figure 1: Account compromise response flow showing containment, scoping, vector-specific actions, and recovery

Phase 1: Immediate containment

Objective: Terminate attacker access to the compromised account within 30 minutes of detection.

Timeframe: 0-30 minutes

1. Revoke all active sessions for the compromised account.

   For Microsoft Entra ID (Azure AD):

   # Connect to Microsoft Graph
   Connect-MgGraph -Scopes "User.ReadWrite.All"

   # Revoke all refresh tokens (forces re-authentication)
   Revoke-MgUserSignInSession -UserId "user@example.org"

For Google Workspace:

   # Using GAM (Google Apps Manager)
   gam user user@example.org signout

For Okta:

   # Clear all sessions via API
   curl -X DELETE "https://example.okta.com/api/v1/users/{userId}/sessions" \
     -H "Authorization: SSWS {api_token}"

Session revocation takes effect within 5 minutes for most applications. Some applications with long-lived tokens require additional steps in Phase 3.

2. Reset the account password to a randomly generated 20+ character string.

   Do not communicate this password to anyone. The user will set a new password during re-onboarding. This step prevents the attacker from re-authenticating even if they observed the original password reset.

   # Microsoft Entra ID - generate random password
   $newPassword = -join ((48..57) + (65..90) + (97..122) | Get-Random -Count 24 | ForEach-Object {[char]$_})

   Update-MgUser -UserId "user@example.org" -PasswordProfile @{
     Password = $newPassword
     ForceChangePasswordNextSignIn = $true
   }

3. Reset MFA registration if the attack vector involved MFA (fatigue attack, SIM swap, or authenticator compromise).

   For Microsoft Entra ID:

   # Remove all authentication methods
   $methods = Get-MgUserAuthenticationMethod -UserId "user@example.org"
   foreach ($method in $methods) {
     Remove-MgUserAuthenticationMethod -UserId "user@example.org" -AuthenticationMethodId $method.Id
   }

For attacks not involving MFA (credential leak, password spray with MFA bypass), preserve existing MFA registration to simplify user re-onboarding.

4. Disable the account if attack scope appears extensive or if containment cannot be verified.

   Account disabling is a more aggressive containment measure that prevents all access, including legitimate access by the user. Use this when:

   • The account has elevated permissions
   • Evidence suggests persistent access mechanisms
   • Financial fraud is in progress
   • You cannot verify session revocation succeeded

   # Microsoft Entra ID
   Update-MgUser -UserId "user@example.org" -AccountEnabled:$false

5. Document the containment timestamp and actions taken.

   Record: account identifier, detection time, containment start time, containment completion time, specific actions taken, administrator who performed actions.

Checkpoint: Proceed to Phase 2 when all active sessions are revoked and the password is reset. If you disabled the account, ensure the user’s manager is informed within 1 hour.

Phase 2: Scope determination

Objective: Determine what the attacker accessed, modified, or exfiltrated during the compromise period.

Timeframe: 30 minutes to 4 hours depending on log availability and access breadth

+------------------------------------------------------------------+
|                       SCOPE DETERMINATION                        |
+------------------------------------------------------------------+
|                                                                  |
|  +--------------------+                                          |
|  | Establish Timeline |                                          |
|  | - First suspicious |                                          |
|  |   authentication   |                                          |
|  | - Last legitimate  |                                          |
|  |   activity         |                                          |
|  +---------+----------+                                          |
|            |                                                     |
|            v                                                     |
|  +---------+----------+     +--------------------+               |
|  | Query Sign-in Logs |---->| Identify Anomalous |               |
|  | for compromise     |     | Sessions           |               |
|  | window             |     | - New locations    |               |
|  +--------------------+     | - New devices      |               |
|                             | - New IPs          |               |
|                             +---------+----------+               |
|                                       |                          |
|         +--------------+--------------+---------------+          |
|         |              |              |               |          |
|         v              v              v               v          |
|  +------+-----+ +------+------+ +-----+------+ +------+------+   |
|  | Email      | | File        | | App        | | Admin       |   |
|  | Access     | | Access      | | Access     | | Actions     |   |
|  | - Mailbox  | | - Downloads | | - OAuth    | | - Config    |   |
|  | - Forwards | | - Shares    | | grants     | | - Users     |   |
|  | - Sent     | | - Deletes   | | - API      | | - Groups    |   |
|  +------------+ +-------------+ +------------+ +-------------+   |
|                                                                  |
+------------------------------------------------------------------+

Figure 2: Scope determination workflow showing timeline establishment and access analysis

1. Establish the compromise timeline by identifying the first suspicious authentication and the last known legitimate activity.

   Query sign-in logs for the 30 days preceding detection:

   # Microsoft Entra ID - Get sign-in history
   $startDate = (Get-Date).AddDays(-30).ToString("yyyy-MM-ddTHH:mm:ssZ")
   $signIns = Get-MgAuditLogSignIn -Filter "userPrincipalName eq 'user@example.org' and createdDateTime ge $startDate" -All

   # Export for analysis
   $signIns | Select-Object CreatedDateTime, IpAddress, Location, DeviceDetail, Status, ConditionalAccessStatus |
     Export-Csv -Path "signin_analysis.csv" -NoTypeInformation

Look for: first authentication from attacker infrastructure (unfamiliar IP, new location, new device), authentication successes following failed attempts, authentications outside user’s normal hours.

The compromise window spans from first suspicious authentication to containment completion. All activity within this window requires analysis.

2. Identify all systems and data accessed during the compromise window.

   For Microsoft 365, query the Unified Audit Log:

   # Connect to Exchange Online
   Connect-ExchangeOnline

   # Search audit log for all user activity
   $auditResults = Search-UnifiedAuditLog -StartDate $compromiseStart -EndDate $compromiseEnd `
     -UserIds "user@example.org" -ResultSize 5000

   # Export for analysis
   $auditResults | Select-Object CreationDate, Operations, AuditData |
     Export-Csv -Path "audit_analysis.csv" -NoTypeInformation

Categorise findings by risk:

3. Check for mail forwarding rules that would persist beyond containment.

   Attackers commonly create inbox rules to forward copies of incoming mail to external addresses, maintaining visibility even after password reset.

   # Check inbox rules
   Get-InboxRule -Mailbox "user@example.org" |
     Where-Object {$_.ForwardTo -or $_.ForwardAsAttachmentTo -or $_.RedirectTo} |
     Select-Object Name, ForwardTo, ForwardAsAttachmentTo, RedirectTo, Enabled

   # Check mail forwarding
   Get-Mailbox -Identity "user@example.org" |
     Select-Object ForwardingAddress, ForwardingSmtpAddress, DeliverToMailboxAndForward

Remove any forwarding rules created during the compromise window. Document them first for evidence.

4. Review OAuth application grants and connected applications.

   # Microsoft Graph - List OAuth2 permission grants
   $grants = Get-MgUserOauth2PermissionGrant -UserId "user@example.org" -All

   $grants | ForEach-Object {
     $app = Get-MgServicePrincipal -ServicePrincipalId $_.ClientId
     [PSCustomObject]@{
       Application = $app.DisplayName
       Permissions = $_.Scope
       ConsentType = $_.ConsentType
     }
   }

Revoke any grants created during the compromise window or any grants to unfamiliar applications regardless of timing. Malicious OAuth grants persist through password resets and session revocation.

5. Check for lateral movement indicators.

   Query authentication logs for other accounts from the same attacker infrastructure:

   # Find other accounts accessed from attacker IP
   $attackerIPs = @("192.0.2.50", "192.0.2.51")  # IPs identified in step 1

   $lateralMovement = Get-MgAuditLogSignIn -Filter "createdDateTime ge $compromiseStart" -All |
     Where-Object { $attackerIPs -contains $_.IpAddress -and $_.UserPrincipalName -ne "user@example.org" }

If other accounts show successful authentication from attacker infrastructure, treat them as compromised and execute containment (Phase 1) for each.

Checkpoint: Proceed to Phase 3 when you have established the compromise timeline, catalogued accessed data, removed persistence mechanisms (forwarding rules, OAuth grants), and verified no lateral movement to other accounts.

Phase 3: Vector-specific response

Execute the procedures specific to the attack vector that caused the compromise. If the vector is unclear, proceed with the credential leak response as the most common scenario.

Business email compromise response

BEC attacks aim to redirect payments or extract sensitive information by impersonating trusted parties. Time-critical financial containment differentiates BEC from other account compromises.

1. Notify the Finance liaison immediately if any payment-related messages were sent from the compromised account.

   Query sent items for payment-related keywords:

   # Search for financial keywords in sent mail
   $searchQuery = "kind:email sent:$compromiseStart..$compromiseEnd (wire OR transfer OR payment OR bank OR account OR routing OR IBAN OR SWIFT)"

   # Use Compliance Search in Microsoft 365
   New-ComplianceSearch -Name "BEC Investigation" -ExchangeLocation "user@example.org" -ContentMatchQuery $searchQuery
   Start-ComplianceSearch -Identity "BEC Investigation"

2. Identify all recipients of potentially fraudulent messages and notify them directly by phone (not email) that the instructions may be fraudulent.

   Do not rely on email notification as the attacker may still have visibility into the recipient’s email if they have compromised multiple accounts.

3. Coordinate payment recall with Finance.

   Payment recall success rates by time elapsed:

   Time since payment	Domestic wire	International wire	ACH
   Under 4 hours	85%	60%	95%
   4-24 hours	50%	25%	80%
   24-72 hours	20%	10%	40%
   Over 72 hours	5%	2%	10%

   Initiate recall through the originating bank immediately. Provide the bank with: transaction reference, amount, beneficiary account details, fraud declaration.

4. Review all payment instruction changes in the 30 days preceding detection.

   The attacker may have been monitoring the account for weeks before executing the fraud. Check for: vendor bank detail changes, new payee additions, payment approvals outside normal workflow.

5. Preserve evidence for law enforcement and insurance.

   BEC losses exceeding £10,000 warrant law enforcement notification. Preserve: original phishing email (if applicable), sent fraudulent messages with full headers, sign-in logs showing attacker access, financial transaction records.

Credential leak response

Credential leaks occur when the user’s password appears in a third-party breach database, enabling attackers to attempt authentication across services where the user may have reused the password.

1. Identify the breach source if possible.

   Check breach notification services for the user’s email address:

   • Have I Been Pwned API: https://haveibeenpwned.com/api/v3/breachedaccount/{email}
   • Internal breach monitoring alerts

   Knowing the breach source helps determine what other credentials may be affected and whether the leaked credential was the current organisational password or a personal account password that was reused.

2. Query authentication logs for successful authentications from unusual locations following the breach date.

   If the breach database publication date is known, focus on authentications after that date from locations outside the user’s normal pattern.

3. Check whether the user reused the leaked password for any other organisational accounts.

   This requires user interview during re-onboarding (Phase 4). If the user confirms reuse, those accounts require password reset.

4. Review the user’s password history for complexity and recency.

   Weak passwords or passwords unchanged for over 180 days increase likelihood of compromise from credential stuffing. This informs user education during re-onboarding.

Password spraying response

Password spraying attacks attempt common passwords against many accounts simultaneously, avoiding lockout thresholds by distributing attempts across users.

1. Identify all accounts targeted in the spray campaign.

   Query authentication logs for failed attempts from the spray source:

   # Find accounts targeted by spray source IP
   $spraySourceIP = "192.0.2.100"  # Identified spray source

   $targetedAccounts = Get-MgAuditLogSignIn -Filter "ipAddress eq '$spraySourceIP' and status/errorCode ne 0" -All |
     Group-Object UserPrincipalName |
     Select-Object Name, Count |
     Sort-Object Count -Descending

2. Reset passwords for all accounts that had successful authentication from spray infrastructure.

   Even if only one account showed suspicious activity, any successful authentication from spray infrastructure indicates the password was guessed correctly.

3. Analyse password patterns across compromised accounts.

   If multiple accounts were compromised, their passwords may share common patterns (season+year, organisation name variations). This informs password policy review.

4. Block the spray source at the network perimeter.

   Add spray source IPs to firewall block lists and identity provider block lists:

   # Microsoft Entra ID - Create named location for blocked IPs
   New-MgIdentityConditionalAccessNamedLocation -DisplayName "Blocked - Password Spray" `
     -IpRanges @(@{CidrAddress = "192.0.2.100/32"}) -IsTrusted $false

5. Implement or verify smart lockout configuration.

   Smart lockout distinguishes between legitimate users mistyping passwords and attackers attempting to guess passwords. Configure:

   • Lockout threshold: 10 failed attempts
   • Lockout duration: 60 seconds (increases automatically for repeated lockouts)
   • Enable extranet lockout for federated authentication

MFA fatigue response

MFA fatigue attacks exploit push-based MFA by repeatedly triggering authentication prompts until the user approves one to stop the notifications, or approves accidentally.

1. Confirm the attack vector through user interview.

   Ask the user:

   • How many unexpected MFA prompts did you receive?
   • Did you approve any prompts you did not initiate?
   • What time did the prompts occur?
   • Were you attempting to authenticate when you approved?

   Document responses for the incident record.

2. Review MFA logs to quantify the attack.

   # Microsoft Entra ID - MFA events
   $mfaEvents = Get-MgAuditLogSignIn -Filter "userPrincipalName eq 'user@example.org'" -All |
     Where-Object { $_.AuthenticationDetails.AuthenticationMethod -eq "Mobile app notification" }

   $mfaEvents | Group-Object @{Expression={$_.CreatedDateTime.ToString("yyyy-MM-dd HH:00")}} |
     Select-Object Name, Count

MFA fatigue attacks typically show 10-50 prompts in a short window (30 minutes to 2 hours).

3. Reset MFA to a phishing-resistant method.

   Replace push notification MFA with FIDO2 security keys or number matching:

   # Enable number matching (Microsoft Authenticator)
   # This requires admin portal configuration or Graph API

   # For FIDO2, register new security key during re-onboarding

Number matching requires the user to enter a number displayed on the sign-in screen into the authenticator app, preventing blind approval of attacker-initiated prompts.

4. Determine how the attacker obtained the password.

   MFA fatigue requires the attacker to know the password and be able to initiate authentication. Investigate: recent phishing, credential leak, password spray against this specific account, shoulder surfing, or insider threat.

   Address the underlying credential compromise using the appropriate response above.

SaaS takeover response

SaaS takeover occurs when an attacker gains persistent access through malicious OAuth application grants, often via phishing that tricks the user into authorising a malicious application.

1. Inventory all OAuth grants for the compromised account.

   # Microsoft Graph - Full OAuth inventory
   $grants = Get-MgUserOauth2PermissionGrant -UserId "user@example.org" -All

   foreach ($grant in $grants) {
     $app = Get-MgServicePrincipal -ServicePrincipalId $grant.ClientId -ErrorAction SilentlyContinue
     [PSCustomObject]@{
       ApplicationName = $app.DisplayName
       ApplicationId = $app.AppId
       Publisher = $app.PublisherName
       Permissions = $grant.Scope
       ConsentType = $grant.ConsentType
       GrantedOn = $grant.StartTime
     }
   } | Export-Csv "oauth_grants.csv" -NoTypeInformation

2. Identify and revoke malicious grants.

   Indicators of malicious applications:

   • Publisher name is blank or generic
   • Permissions include Mail.Read, Mail.Send, Files.ReadWrite.All, or User.ReadWrite
   • Application name mimics legitimate services with slight variations
   • Grant date falls within compromise window
   • Application ID does not appear in organisational approved application list

   # Revoke specific grant
   Remove-MgOauth2PermissionGrant -OAuth2PermissionGrantId $grant.Id

   # Or revoke via service principal
   Remove-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $app.Id -AppRoleAssignmentId $assignment.Id

3. Check for token theft and API access from the malicious application.

   Query application access logs for the malicious application’s client ID:

   # Microsoft Graph API access logs
   $apiAccess = Get-MgAuditLogSignIn -Filter "appId eq '{malicious-app-id}'" -All

Determine what data the application accessed. This informs the scope assessment and whether data breach procedures apply.

4. Block the malicious application tenant-wide.

   Prevent other users from granting consent to the same malicious application:

   # Block application tenant-wide
   $app = Get-MgServicePrincipal -Filter "appId eq '{malicious-app-id}'"
   Update-MgServicePrincipal -ServicePrincipalId $app.Id -AccountEnabled $false

5. Search for other users who may have granted consent to the same application.

   # Find all users with grants to this application
   $allGrants = Get-MgOauth2PermissionGrant -Filter "clientId eq '$($app.Id)'" -All
   $allGrants | Select-Object PrincipalId | Get-MgUser

Treat all users with grants to the malicious application as potentially compromised and execute containment.

Checkpoint: Proceed to Phase 4 when vector-specific containment is complete and all persistence mechanisms are removed.

Phase 4: Recovery and user re-onboarding

Objective: Restore secure access for the legitimate user and verify account integrity.

Timeframe: 2-24 hours depending on user availability

1. Contact the user to schedule re-onboarding.

   Use an out-of-band channel (phone call to verified number) rather than email, as the attacker may have set up forwarding to an external account. Verify user identity through questions only the legitimate user could answer or through manager confirmation.

2. Guide the user through password creation.

   The user should create their new password directly through the self-service password reset portal. Requirements:

   • Minimum 14 characters
   • Not based on personal information
   • Not previously used
   • Consider passphrase format (4+ random words)

   Do not communicate the temporary password set during containment. The user creates a new password, never knowing the containment password.

3. Re-establish MFA registration.

   If MFA was reset during containment:

   For push notification MFA with number matching:

   1. User installs authenticator application
   2. User registers through security info portal
   3. Verify number matching is enabled

   For FIDO2 security key:

   1. Issue security key to user
   2. User registers through security info portal
   3. Test authentication with key

   For phishing-resistant authentication after MFA fatigue or credential phishing, strongly encourage FIDO2 security keys.

4. Review account configuration with user.

   Walk through with the user:

   • Connected applications (should they recognise all of them?)
   • Inbox rules (are any unfamiliar?)
   • Email delegates (expected?)
   • Mobile devices registered (expected?)
   • Recent file sharing (expected?)

   Remove anything the user does not recognise.

5. Verify account recovery contact information.

   Confirm the password reset email and phone number belong to the user. Attackers sometimes modify recovery information to maintain access after remediation.

   Get-MgUser -UserId "user@example.org" -Property SecurityIdentifier,
     OtherMails, MobilePhone, BusinessPhones, UserPrincipalName

6. Provide user education specific to the attack vector.

   Attack vector	Key education points
   BEC	Verify payment changes by phone, question urgency, check email addresses carefully
   Credential leak	Use unique passwords, enable breach monitoring, consider password manager
   Password spray	Use passphrase format, report lockout notifications
   MFA fatigue	Never approve unexpected prompts, report prompt storms immediately
   SaaS takeover	Review OAuth consent carefully, only approve known applications

   Document that education was provided.

7. Re-enable the account if it was disabled during containment.

   Update-MgUser -UserId "user@example.org" -AccountEnabled:$true

8. Monitor the account for 30 days following recovery.

   Set up alerting for:

   • Authentication from new locations
   • New OAuth grants
   • New inbox rules
   • Password changes

   Review alerts daily for the first week, then weekly for the remainder of the monitoring period.

Checkpoint: Phase 4 is complete when the user has secure access, MFA is operational, account configuration is verified clean, and monitoring is in place.

Phase 5: Post-incident

Objective: Document the incident, identify improvements, and complete regulatory notifications if applicable.

Timeframe: 1-5 days following recovery

1. Complete the incident report.

   Document:

   • Detection method and time
   • Attack vector and indicators
   • Compromise timeline (first attacker access to containment)
   • Systems and data accessed
   • Containment actions and timing
   • Recovery actions
   • User impact
   • Financial impact (if any)
   • Recommendations

   Use the incident report template in Evidence Collection.

2. Determine data breach notification requirements.

   If personal data was accessed or exfiltrated, assess notification requirements:

   Jurisdiction	Notification threshold	Timeline
   GDPR (EU/UK)	Risk to data subjects	72 hours to supervisory authority
   US state laws	Varies by state	Varies, typically 30-60 days
   Donor requirements	Per agreement	Per agreement

   Consult Data Breach Response for full notification procedures if personal data exposure is confirmed.

3. Conduct post-incident review.

   Within 5 business days, convene incident participants to discuss:

   • What worked well?
   • What could be improved?
   • Were playbook procedures adequate?
   • Are policy changes needed?
   • Is additional user training needed?
   • Are technical controls adequate?

   Document recommendations and assign owners.

4. Implement quick-win improvements.

   Actions that can complete within 2 weeks:

   • Update playbook based on lessons learned
   • Adjust monitoring alerts based on detection gaps
   • Deliver targeted user awareness communication
   • Reconfigure authentication policies if gaps identified

5. Plan longer-term improvements.

   Actions requiring project effort:

   • Deploy phishing-resistant MFA organisation-wide
   • Implement privileged access management
   • Enhance detection capabilities
   • Review and tighten OAuth consent policies

   Add to security improvement backlog with appropriate prioritisation.

Communications

Stakeholder notification matrix

Communication templates

User notification (initial)

Subject: Your account has been secured - action required

[User name],

Our security team detected suspicious activity on your organisational account.
We have secured your account by resetting your password and signing out all
active sessions.

What this means:
- You cannot currently access your email or other organisational systems
- This is a precautionary measure to protect your account and our systems
- Your account has not been deleted

What happens next:
- [Technical lead name] will contact you at [verified phone number] within
  [timeframe] to verify your identity and restore your access
- This call will come from [phone number]
- Please do not attempt to reset your password yourself before this call

If you have questions, contact [IT support contact].

[Signature]

User notification (BEC with potential financial fraud)

Subject: URGENT - Account security incident - please call immediately

[User name],

We have detected suspicious activity on your email account that may involve
fraudulent financial communications. We have secured your account and need
to speak with you immediately.

Please call [incident commander name] at [phone number] as soon as you
receive this message, regardless of time.

If you sent any emails regarding payments, wire transfers, or bank account
changes in the past [timeframe], please have those details available.

Do not forward this message or discuss with others until we have spoken.

[Signature]

Manager notification

Subject: Account security incident - [employee name]

[Manager name],

We detected and responded to a security incident involving [employee name]'s
account today. Their account has been secured and we are working to restore
access.

No action is required from you at this time. [Employee name] will have limited
access to email and organisational systems until approximately [timeframe].

This notification is for your awareness only. Please direct any questions
to [IT contact].

[Signature]

Evidence preservation

Preserve the following evidence before it expires or is overwritten:

For evidence collection procedures and chain of custody requirements, refer to Evidence Collection.

See also

• Privileged Access Breach -when administrative accounts are compromised
• Phishing Campaign Response -when compromise results from phishing campaign
• Data Breach Response -when personal data is exposed
• Evidence Collection -for evidence preservation procedures
• Identity and Access Management -for IAM architecture and concepts
• Access Reviews and Recertification -for post-incident access review
• Incident Triage Matrix -for incident classification