BRB vs Standard Incident Response

Owner: Anchor MSP Operations Lead Last reviewed: 2026-05-24

Purpose

Define when to activate the BRB (Big Red Button) Protocol versus following standard incident response procedures. This document provides a clear decision framework so operators can make the correct call under pressure.

Scope

All security and availability incidents affecting systems under Anchor managed production where BRB agents are deployed.

Decision Tree

The following flowchart guides the decision to activate BRB Protocol or follow standard incident response.

flowchart TD
    A[Incident Detected] --> B{Is the threat active?}
    B -->|No| C{Is the system compromised?}
    B -->|Yes| D{What type of active threat?}

    C -->|No| E[Standard Incident Response]
    C -->|Suspected but unconfirmed| F[Standard IR with elevated monitoring]

    D --> G{Confirmed ransomware?}
    D --> H{Active data exfiltration?}
    D --> I{Compromised credentials with active exploitation?}
    D --> J{Unauthorized root access with active threat?}

    G -->|Yes| K[Activate BRB Protocol]
    H -->|Yes| K
    I -->|Yes| K
    J -->|Yes| K

    G -->|No| H
    H -->|No| I
    I -->|No| J
    J -->|No| E

    K --> L[Execute BRB Lockdown]
    L --> M[Forensic Collection]
    M --> N[Staged Recovery per BRB Procedures]

    E --> O[Follow 6-Phase IR Procedure]
    F --> O

BRB Protocol Triggers

Activate BRB Protocol immediately when any of the following are confirmed:

1. Confirmed ransomware — Encryption activity detected on managed host. File integrity monitoring shows mass file modifications. Ransom note discovered.
2. Active data exfiltration — Unusual outbound data transfer detected. Sensitive data observed leaving the network to unauthorized destinations.
3. Compromised credentials with active exploitation — Credentials confirmed stolen AND actively being used to access systems. Login activity from unauthorized locations/IPs.
4. Unauthorized root access with active threat — An attacker has gained root or admin access AND is actively executing commands, installing software, or modifying system state.

The key distinction: BRB is for active, confirmed threats where every second of delay increases damage.

Standard Incident Response Triggers

Use the standard Incident Response Procedure for:

1. Performance degradation — System is slow but functional. No evidence of malicious activity.
2. Partial outage — Some services down but no security component. Caused by configuration error, resource exhaustion, or software bug.
3. Suspected but unconfirmed compromise — Security alerts fired but investigation has not confirmed a breach. Proceed with standard IR with elevated monitoring while investigating.
4. Configuration issues — Misconfiguration causing service impact. No adversary involved.
5. Monitoring gaps — Monitoring coverage failure detected. No active incident but operational visibility is reduced.
6. Backup failures — Backup jobs failing. Data integrity risk but no active threat.

Comparison

Aspect	Standard Incident Response	BRB Protocol
Trigger	Any incident per severity classification	Active, confirmed security threat only
Speed	Methodical 6-phase approach	Immediate automated lockdown
System impact	Minimal -- system stays running during investigation	Maximum -- system is fully isolated and locked
Network	Remains connected	Isolated (all traffic blocked except emergency SSH)
Services	Continue running	All stopped
User accounts	Remain active	All locked except emergency account
Forensics	Manual collection during investigation	Automated collection during lockdown
Recovery	Restore based on root cause fix	Staged recovery with dual-approval
Approval	IC decides recovery steps	Two different operators must approve recovery
Use case	Outages, degradation, suspected issues	Ransomware, data breach, active attacker

Escalation from Standard IR to BRB

During standard incident response, the Incident Commander may escalate to BRB Protocol if the investigation reveals an active threat. The escalation criteria are:

1. Evidence emerges during Phase 3 (Containment) or Phase 4 (Eradication) that the threat is active and ongoing.
2. The IC determines that standard containment is insufficient to stop the damage.
3. The IC activates BRB Protocol and documents the escalation in the incident thread.

Escalation does not require additional approval. The IC has authority to activate BRB when conditions warrant it.

De-escalation from BRB to Standard IR

After BRB lockdown and forensic collection, if the investigation determines the threat was less severe than initially assessed:

1. Complete the BRB staged recovery process (do not skip recovery stages).
2. Once the system is recovered, transition to standard IR Phase 6 (Post-Incident) for the postmortem.
3. Document the initial BRB activation and de-escalation rationale in the postmortem.

De-escalation does not bypass the dual-approval recovery requirement. All BRB recoveries require two different operators regardless of final severity assessment.

Exceptions

None. The decision framework above applies to all incidents on BRB-enabled systems. If unsure whether to activate BRB, contact the Operations Lead. When in doubt and the Operations Lead is unreachable, err on the side of activation -- a false BRB activation is recoverable; an uncontained breach is not.