Running Incident Response When You Are the Entire Security Team

Relationship 1: IR retainer or on-demand IR firm. An incident response retainer is a contract with a security firm that guarantees response capacity within a defined SLA (4 hours, 8 hours, or next business day, depending on the retainer level). The retainer means that when the incident happens, you call a named account team who knows your environment, your tooling, and your contacts -- rather than spending the first hour of an incident explaining your stack to a firm that has never seen it. The cost of an IR retainer is significantly lower than the cost of an unretained emergency response engagement, which typically carries a premium for the same capabilities.

For organizations that cannot justify a formal retainer: establish a relationship with a smaller boutique IR firm or an independent consultant who can work on an hourly basis with a pre-established statement of work. The goal is to have a phone number you can call at 2am and a person on the other end who will pick up and start helping within the hour.

Relationship 2: Legal counsel with data breach experience. General corporate counsel is not the right resource for a data breach. Data breach-experienced legal counsel knows the notification timeline requirements (GDPR's 72 hours, HIPAA's 60 days, SEC's 4 business days for material incidents), can provide attorney-client privilege protection over the investigation when required, and can coordinate with state attorneys general and regulators if notification is required. Identify this counsel before the incident -- searching for specialized legal counsel during a breach introduces delay in the notification timeline.

Relationship 3: Communications or PR contact. For incidents that may require external communication (customer notification, regulatory disclosure, press inquiries), a PR professional or communications consultant who has handled data breach communications should be identified in advance. They can turn around customer notification letter drafts in hours and manage press inquiries in a way that limits reputational damage. This is particularly important for companies with consumer-facing products.

The first hour of an incident is when the decisions made under the most stress have the most lasting impact. A runbook with the first 30 actions pre-defined means you are executing a plan rather than improvising one.

The runbook structure for the most common incident type (credential compromise / unauthorized access):

Actions 1-5: Establish incident scope (first 15 minutes)

1. Preserve the triggering alert or report exactly as received (screenshot, export, or copy). Do not dismiss or close any original alerts.
2. Open the incident documentation log (a dated document in your notes, not just a mental model). Every action taken, who took it, and when.
3. Identify the affected account, system, or endpoint from the alert details.
4. Query authentication logs (Okta, Azure AD, Google Workspace, AWS CloudTrail) for all activity by the affected account in the last 24 hours.
5. Identify whether any lateral movement indicators are present: logins from new IPs, access to systems the account does not normally reach, new OAuth application grants.

Actions 6-10: Initial notification (first 20 minutes) 6. Notify your manager or the highest-available leadership contact (CEO, CTO, or designated incident escalation contact) with one sentence: "We have a potential security incident involving [what]. I am investigating. I will update you in 30 minutes." 7. Open your IR retainer or on-demand contact line. Provide them the same one-sentence summary and your ETA for a detailed briefing. They begin preparing. 8. Do not notify the potentially compromised user or any suspected insider threat at this stage. 9. Start a timer for your 30-minute leadership update. 10. If the incident involves a cloud account: confirm you still have administrative access to your cloud console. Attackers who compromise cloud credentials sometimes modify the compromised account's access to lock out the legitimate owner.

Actions 11-20: Evidence collection (first 40 minutes) 11. Export the authentication log for the affected account (last 7 days). Download to a local storage location -- do not rely on the log remaining available in the cloud console. 12. Check for new rules, delegations, or role assignments created by the affected account. 13. Check for any data exports, downloads, or email forwarding rules created by the affected account. 14. Capture the current session state for the affected account (active sessions, OAuth tokens, active API keys). 15. [And so on through the remaining 15 actions tailored to your specific environment and tooling.]

The runbook should have scenario-specific variants: credential compromise, ransomware, insider threat, cloud misconfiguration. The first 10 actions are largely the same across scenarios; actions 11 through 30 diverge based on the incident type.

Solo security responders regularly face a containment dilemma: isolating a compromised system is the correct security action, but it may interrupt business operations, and you are not empowered to make that business continuity trade-off unilaterally.

The solution is pre-authorized containment decisions -- a document, agreed upon before any incident occurs, that specifies which containment actions you can take immediately without seeking approval and which require authorization from a named executive.

Pre-authorized actions (you can take these immediately):

• Disabling a single user account or OAuth token
• Blocking a specific IP address in the firewall or cloud security group
• Revoking a specific API key
• Enabling MFA enforcement for an individual account
• Suspending a cloud account or service account (with immediate notification to the affected team)

Actions requiring executive authorization (call the named contact before acting):

• Isolating an endpoint or server that is actively processing transactions or running critical services
• Revoking credentials for a service account used by production systems
• Taking down a public-facing service for security remediation
• Initiating external notification (customer notification, regulatory notification)
• Engaging law enforcement

Having this document agreed upon and signed before an incident means you are not spending 20 minutes during the first hour of a breach seeking approval for the authority to disable a compromised account. You already have it. You are calling the executive to inform, not to request.

The single biggest leverage available to a solo security responder is delegation. Many incident response tasks do not require security expertise -- they require organizational access, communication skills, or administrative coordination that other team members can provide.

Four categories of delegatable tasks:

Evidence collection from known locations. If you need IT to collect specific log files from servers you cannot directly access, or to export specific reports from a SaaS system, you can brief a trusted IT administrator in 5 minutes and they can execute that task independently. Provide them with exact instructions: "Log into the Okta admin console, go to Reports > System Log, filter by user email X, date range Y to Z, and export the CSV. Send it to me encrypted via [method]." This frees you to run parallel investigations.

Communication with affected teams. If a specific business unit needs to be notified that a system they use is under investigation, a business unit liaison or operations manager can deliver that notification and collect information about their system use. You brief the liaison on what to say and what to ask; they handle the communication.

Vendor and partner notification. If the incident requires notifying vendors (your payment processor, your cloud provider's abuse team, a software vendor whose product is involved), a capable IT or operations team member can make those calls following your provided script. This is particularly valuable when the notification calls are routine (notifying a vendor that you are investigating their integration) rather than sensitive (asking a vendor to preserve logs related to your incident).

Regulatory notification document drafting. Your legal counsel or a general counsel paralegal can draft the initial regulatory notification document from a template you provide, requiring your review and approval rather than you drafting from scratch. This is a 2-hour paralegal task that would otherwise consume 2 hours of your investigation time.

Leadership communication during an incident is a genuine requirement -- executives making business continuity decisions need security information. But unmanaged stakeholder communication becomes a context-switching tax that destroys investigation effectiveness.

The 15-minute cadence: commit to a specific update interval (every 30 minutes in the first 2 hours, every 60 minutes thereafter). At each interval: send a structured 5-sentence update. Do not take questions -- invite questions via a separate call at a defined time (at the top of the next hour). Use a pre-drafted template.

Template for the 30-minute update: "Security Incident Update -- [Time]

Current status: [One sentence on what we believe is happening.]

What we know: [Two sentences on confirmed facts -- what systems are affected, what data may be involved.]

What we are doing: [One sentence on current investigation focus.]

What we need from leadership: [Specific ask or 'No action required at this time.']

Next update: [Time of next planned communication.]"

Send this as an email or Slack message to a defined distribution list (CEO, CTO, General Counsel, Head of Operations). No calls unless a decision is required. The structured format allows leadership to extract what they need without requiring you to be on a call explaining it.

If leadership demands more frequent calls: designate a non-security proxy (often the COO or CTO) who absorbs the ad-hoc questions from other executives and consolidates them for your scheduled updates. This one-to-one interface protects your investigation time while ensuring leadership receives answers.

Solo incident response produces an additional risk: if the incident leads to litigation, regulatory investigation, or a post-incident review, the incident timeline and actions taken exist only in the solo responder's memory and notes. Documentation discipline during the incident is not optional -- it is the evidence trail that demonstrates competent, timely response.

The incident log must include: every action taken (what, who, when, why), every query run (specific query text, time range, data source), every communication sent or received (with timestamps), every containment action and the authorization basis, and every decision point where alternatives were considered and the reasoning for the chosen action.

Post-incident review structure for a solo team: Conduct the review within 5 business days of incident closure while memory is fresh. The review document covers: incident timeline (start to containment to full resolution), root cause analysis (what specific control failure or attacker action enabled the incident), what detection occurred versus what was missed (and why), what the response did well, what the response would improve with a second incident of the same type, and what specific control or process changes will prevent recurrence.

Share the post-incident review with leadership and legal counsel. For regulated data incidents: the review document may be requested by regulators as evidence of your incident response capability. A thorough review that documents what was done and what will be improved is better received by regulators than a cursory summary.

Pre-populate the next incident's runbook. After each incident, update the runbook with the specific queries, tool steps, and decision points that were most useful. The runbook after 3 incidents is significantly more useful than the runbook written from theory before the first one.