The First 60 Minutes of a Cyber Incident: How AI Can Help Us Respond Faster

Image courtesy of Help Net Security.

The incident does not begin when your team notices it

Imagine this.

It is 10:07 AM on a working day.

Your security monitoring system raises an alert for suspicious activity involving an employee's account. A few minutes later, another alert appears. This time, it involves an unusual mailbox rule.

The employee works in Finance.

Your analyst opens the alert. There is an unfamiliar sign-in, an application the employee does not recognize, and activity that does not fit the user's normal pattern.

Meanwhile, the employee has received a realistic email that appears to come from a trusted business partner. The language is convincing. The request is plausible. Nothing about it looks obviously malicious.

Your team now has questions.

Was the account compromised? Is the suspicious application legitimate? Has someone accessed confidential information? Is the attacker still active? Are other employees affected? Is a payment about to be made using fraudulent instructions?

Traditionally, an analyst might spend considerable time opening consoles, searching logs, correlating timestamps and asking other teams for information.

Now imagine an AI-assisted incident-response workflow that can summarize the available evidence, correlate related alerts, prepare investigation queries and suggest the next actions within the team's authorized security environment.

The analyst still needs to verify the evidence and make important decisions. But the investigation can become much more focused.

That is where AI can make a meaningful difference.

The objective is not to let AI take over incident response. It is to help our people make better decisions, with better evidence, in less time.

1. Before the incident: Build your response capability

The biggest mistake is introducing AI only after an incident has started.

If your logs are incomplete, your security tools are disconnected, your incident ownership is unclear and your response procedures are outdated, adding an AI assistant will not magically fix those problems.

AI needs reliable information and a defined process to be useful.

Before the next incident, establish five practical capabilities.

First, make your security evidence accessible. Your authorized response workflow should be able to retrieve relevant endpoint, identity, email, firewall, DNS, cloud audit and application logs. Not every organization needs to send every event to a single platform, but responders must know where the evidence lives and how to retrieve it quickly.

Second, maintain a reliable asset and identity inventory. When an alert involves a device or account, the team should be able to establish who owns it, which business service depends on it, what privileges it has and how critical it is.

Third, prepare short, usable playbooks. Start with compromised identities, ransomware, cloud-account compromise, sensitive-data exposure and suspicious AI-agent activity. Each playbook should specify what to check, how to contain the risk, what evidence to preserve and who can authorize consequential actions.

Fourth, prepare an approved AI-assisted investigation environment. Connect AI only to the information and tools it is authorized to use. Start with read-only access to relevant security evidence. Keep credentials and secrets out of prompts, and apply your organization's data-handling requirements.

Fifth, test the entire process. Run a simulated incident and see whether the analyst can move from alert to verified evidence, containment recommendation and incident timeline without relying on informal conversations or unavailable people.

NIST's Incident Response Recommendations, SP 800-61 Rev. 3 provide a useful foundation for integrating incident response into normal cybersecurity risk management.

The practical question is simple: when your team receives a serious alert tomorrow morning, what can it actually do with the systems, evidence and permissions available today?

2. A realistic incident: One compromised account, several connected problems

Let's return to our Finance employee.

This is an illustrative scenario, but the investigation steps are designed to reflect a real enterprise environment.

The security team discovers four things:

• An unfamiliar sign-in associated with the employee's account.
• A new mailbox rule that could hide messages or redirect communications.
• An unfamiliar application with access to the employee's business data.
• Activity that requires investigation to establish whether sensitive information was accessed.

No single finding tells the entire story. A new sign-in could be legitimate. A mailbox rule could be a normal business change. An application could be approved.

But taken together, these events justify urgent investigation.

The security analyst now has two jobs: establish what happened and prevent further damage.

This is an ideal opportunity for AI-assisted incident response.

Image courtesy of BleepingComputer.

Step 1: Ask AI to organize the evidence

Instead of manually reading every alert first, the analyst submits the relevant evidence to an approved AI investigation assistant.

The assistant receives the available event details, timestamps, account information, alert identifiers and relevant audit records. Its job is not to invent an explanation. Its job is to make the evidence easier to investigate.

A useful instruction would be:

You are assisting an authorized cybersecurity incident responder. Analyze only the evidence supplied through approved sources. Separate confirmed facts from hypotheses and unknowns. Create a chronological timeline, identify relationships between events, highlight evidence gaps, and recommend the next five read-only investigation steps. Reference the available event IDs and timestamps for every material finding. Do not execute containment or other changes.

The AI produces an initial timeline:

The important part is not the table itself. It is the time saved in organizing the investigation.

The analyst must still open the underlying records, verify the timestamps and establish whether the events are genuinely related.

AI can correlate evidence. It cannot make incomplete evidence complete.

Step 2: Expand the investigation beyond the first alert

A common failure during incident response is treating each security alert as a separate problem.

The unfamiliar sign-in might be one alert. The mailbox rule might be another. The suspicious application might generate a third.

An AI assistant can help investigators connect these events and generate targeted queries across available identity, email and cloud logs.

For example, it can help the analyst investigate:

• Whether the same account has other suspicious sign-ins or session activity.
• Whether authentication methods or access permissions were changed.
• Whether similar mailbox rules exist on other accounts.
• Whether the application appears elsewhere in the environment.
• Whether other users or systems show related indicators.
• Whether sensitive records were accessed or downloaded.

The AI can draft queries for the organization's security analytics platform. The analyst should review those queries, confirm their scope and execute them through authorized tools.

This is much more useful than asking a generic chatbot, "Is this a cyberattack?"

It turns AI into an investigation assistant that helps answer specific questions using actual enterprise evidence.

Step 3: Make the containment decision

Suppose the investigation now supports the conclusion that the employee's account has been compromised.

The team must act.

Depending on the technology and evidence, the response may include revoking active sessions and tokens, disabling or restricting the compromised account, removing malicious mailbox rules, blocking an unauthorized application and reviewing associated access permissions.

The exact actions depend on what was compromised and which security controls are available.

AI can help create a containment plan, identify dependencies, explain the expected impact of each action and list the evidence that must be preserved.

But the response must not depend on a language model making an unrestricted decision to change production systems.

The approved response workflow should validate the proposed action against policy, permissions and required authorization before executing it.

For example, an organization's documented policy might allow automated isolation of a high-confidence compromised endpoint under defined conditions. Disabling a critical production identity or making a broad cloud-access change might require explicit approval.

The model can recommend an action. The authorization policy determines whether that action is permitted.

That distinction becomes particularly important when using AI agents connected to operational security tools. OWASP's AI Agent Security Cheat Sheet covers least-privilege access, monitoring, untrusted inputs and human approval for high-impact actions.

3. What should happen in the first 60 minutes?

The first hour is not about completing every aspect of the investigation. It is about establishing control, understanding the scope and preventing avoidable damage.

The following is an illustrative operational sequence, not a universal service-level target.

First 5 minutes: Report and establish ownership

The employee should report the suspicious activity immediately, explaining what happened, when it happened, which account or device was involved, and whether they clicked a link, entered credentials or approved an unexpected authentication request.

They should not delete the email, attempt to confront the suspected attacker or hide an accidental action.

The security responder should acknowledge the report, create an incident record, establish an initial owner and check whether the incident requires immediate containment.

AI can help summarize the initial report, classify the issue provisionally and suggest the most relevant playbook.

It should not delay escalation while trying to produce a perfect classification.

Minutes 5–15: Establish the facts

The analyst gathers the highest-value available evidence from identity, endpoint, email and cloud security systems.

AI helps organize the events into a timeline, identifies missing context and proposes targeted investigative queries.

At this stage, the output should distinguish between three categories:

Confirmed: Supported by identifiable evidence.

Suspected: Plausible, but not yet verified.

Unknown: Information the team still needs to establish.

This simple separation prevents the team from treating an AI-generated theory as an established fact.

Minutes 15–30: Contain the confirmed risk

The incident lead coordinates the appropriate containment measures with the relevant technical teams.

Depending on the findings, this may mean revoking compromised sessions, suspending malicious application access, isolating an affected endpoint, restricting an account or blocking a confirmed malicious indicator.

AI can prepare the proposed action list, map affected identities and assets, identify dependencies and draft execution steps for an authorized responder.

After containment, the team should verify that the relevant access or activity has actually stopped. A recommendation marked "complete" by an automation system is not sufficient proof.

Minutes 30–60: Expand the scope and protect against recurrence

The investigation now asks a broader question: is this an isolated compromise, or are other systems affected?

The team checks for related accounts, endpoints, application permissions, suspicious access patterns, evidence of data exposure and possible persistence.

AI can help compare findings, group related events, generate additional queries and prepare a concise incident timeline.

The incident owner should ensure that the team has a clear record of confirmed impact, actions taken, unresolved questions, and the next investigative priorities.

If the incident involves potentially stolen data, financial fraud, material service disruption or regulated information, the appropriate specialist teams should be engaged promptly under the organization's escalation procedures.

The result should be a more controlled investigation—not an assumption that the incident is over simply because the initial alert has disappeared.

4. Where AI makes the biggest practical difference in incident response

AI should be introduced where it removes real investigative friction, rather than merely adding another dashboard.

Here are six high-value applications.

1. Alert triage and prioritization

AI can summarize multiple related alerts, enrich them with authorized asset and identity context, and explain why an incident may require urgent attention.

The security analyst still validates the underlying evidence and decides whether the escalation is justified.

2. Investigation and threat hunting

AI can help formulate queries, explain unfamiliar log fields, identify gaps in an investigation and suggest additional events worth examining.

This can be particularly useful for smaller security teams that need help investigating across multiple platforms.

3. Timeline reconstruction

AI can organize event records into a chronological sequence, helping responders understand what may have happened before and after the initial detection.

The result must preserve source references and clearly identify gaps, conflicting timestamps and unverified assumptions.

4. Containment planning

AI can draft a prioritized list of potential containment actions, identify affected assets and explain possible operational consequences.

Execution remains subject to the appropriate authorization and safeguards.

5. Response coordination and documentation

AI can prepare incident notes, summarize verified findings, draft technical handovers and maintain a list of unresolved questions and assigned actions.

This reduces the burden of documentation during a fast-moving investigation.

6. Recovery validation and lessons learned

After containment, AI can help turn the recovery checklist into concrete verification steps, compare observed results with the incident's requirements and organize lessons learned.

The team must verify that recovery criteria have been met before restoring trust in an affected system.

These applications are achievable without building a fully autonomous security agent. Existing security platforms may already offer some AI-assisted investigation and reporting capabilities; Microsoft, for example, documents investigation-oriented promptbooks in Microsoft Security Copilot.

Start with the work that consumes the most analyst time and measure whether AI actually reduces that burden.

Image courtesy of The Hacker News.

5. The AI must not become another incident

There is an important risk that organizations can overlook while introducing AI to accelerate incident response.

What happens if the AI assistant receives malicious instructions embedded in a phishing email, a compromised document, a support ticket or a web page?

For example, an attacker may place instructions inside a document telling an AI agent to ignore its normal process, access an unrelated resource or send information to an external destination.

The response assistant must treat such material as untrusted evidence, not as instructions it should follow.

This requires several practical safeguards.

• Use approved data sources and AI environments. Do not paste raw incident logs, credentials, sensitive emails or confidential customer records into an unapproved public AI service.
• Start with read-only access. Allow the assistant to analyze evidence before granting any ability to change systems.
• Apply least privilege. The assistant should have access only to the data and tools required for its authorized task.
• Keep action authorization separate from AI reasoning. A convincing recommendation must not bypass access controls or approval requirements.
• Retain an audit trail. Record the relevant source evidence, AI-generated recommendations, tool calls, approvals and execution results, while avoiding unnecessary exposure of sensitive prompt content.
• Test failure scenarios. Deliberately test malicious documents, manipulated instructions, incorrect recommendations and unavailable evidence before allowing the workflow to handle live incidents.

AI can help us respond to a compromised environment. But a poorly controlled AI integration can create a new route through which that environment is compromised.

6. How much autonomy should we give AI?

The question is not simply whether AI should be allowed to take action. It is which actions it can take, under what conditions, with what permissions and with what recovery options.

A useful starting model is:

This is a suggested operating model, not a prescribed industry standard.

For a new deployment, begin with Levels 1 and 2. Measure accuracy and usefulness, then introduce narrowly scoped automation where the risks are understood and the safeguards have been tested.

Do not let the model itself determine that it is sufficiently confident to bypass authorization.

For consequential actions, the approval request should explain the exact action, target, expected impact and relevant evidence. Where required, use independent approval rather than allowing the same automated workflow to propose and authorize its own action.

The goal is not maximum AI autonomy.

The goal is minimum delay without losing control.

7. What people should do when AI is unavailable or wrong

No incident-response process should depend entirely on an AI service being available.

AI might be unavailable because of a platform outage, an integration failure, an access restriction or a problem with the data being supplied. It may also produce an incorrect conclusion.

Your people must still be able to respond.

Every AI-assisted playbook should have a usable manual path: open the relevant security console, retrieve the necessary logs, follow the containment procedure and escalate when required.

Analysts should be trained to recognize the warning signs of an unreliable answer:

• The recommendation refers to events that cannot be found in the underlying evidence.
• The AI claims an action succeeded, but the security platform shows no confirmation.
• The investigation overlooks contradictory evidence.
• The response suggests broad or irreversible changes without explaining the impact.
• The assistant requests permissions or data beyond its assigned role.

When that happens, the analyst should return to verified evidence and follow the established response process.

AI should make the team more resilient—not leave it helpless when the technology fails.

8. How do we know AI is actually improving incident response?

Organizations sometimes measure AI adoption by the number of analysts using an assistant or the number of automated workflows deployed.

Those measures are not enough.

Measure the effect on real operational outcomes.

Compare results with a pre-AI baseline and use representative scenarios. Faster output is not an improvement if it creates more false leads, unsafe changes or rework.

The best evidence of success is that responders spend less time assembling information and more time making sound decisions.

9. A practical 30-day starting plan

Organizations do not need to transform their entire SOC before gaining value from AI-assisted incident response.

A practical first month could look like this.

Week 1: Identify the biggest operational bottleneck.

Review recent incidents and exercises. Determine whether the main delay comes from alert triage, log collection, cross-platform correlation, containment approvals or documentation. Select one use case.

Week 2: Prepare the evidence and workflow.

Confirm that the necessary logs are available, determine which data the approved AI environment can access and write a short investigation prompt or workflow. Establish the permitted actions and approval boundaries.

Week 3: Test against realistic scenarios.

Use sanitized historical incidents or controlled simulations. Compare the AI-assisted investigation against the manual process. Test incorrect conclusions, missing evidence, malicious instructions and failed actions.

Week 4: Review the results and decide whether to expand.

Measure time saved, investigation quality, evidence traceability, analyst rework and safety. Fix the gaps before connecting additional systems or authorizing more automated actions.

Start with a specific operational problem, prove that the workflow helps, and scale based on evidence.

Final thought: AI should buy responders time to think

A successful incident response is not defined by how many alerts AI can summarize or how quickly an automated workflow can execute commands.

It is defined by how effectively an organization identifies what happened, limits the damage, protects its people and data, and restores services safely.

AI can help us examine evidence at greater scale, discover connections that deserve attention and reduce the manual effort involved in an investigation.

But preparation, reliable telemetry, appropriate permissions, clear responsibilities and disciplined recovery remain essential.

We should not wait for a major incident before testing these capabilities.

Prepare the evidence. Rehearse the playbooks. Introduce AI where it solves a real problem. Keep consequential decisions under appropriate control. Verify every important action.

When the next incident arrives, our responders should not be learning how the process works.

They should already know.

— Deepak Kumar, CISSP