Incident First Response & SOC Collaboration: A Practical Runbook from Detection to Containment

The magnitude of damage from a security incident is often determined by the time from detection to initial response and the quality of that response, rather than the sophistication of the attack itself. Even if EDR (Endpoint Detection and Response) or SIEM (Security Information and Event Management) detects suspicious behavior, if decisions such as "Is this real?", "How far has it spread?", "Can we isolate the terminal?", or "Who should we report this to?" stall, attackers will continue lateral movement and data exfiltration. The challenge for many organizations is not detection itself, but rather who makes the decisions and who takes action during the "first golden hour" after detection.

This challenge is most evident with ransomware. In the IPA's "Top 10 Information Security Threats 2026," "damage from ransomware attacks" was selected for the 11th consecutive year, ranking first among organizational threats in the 2026 edition (IPA, 2026). According to a report published by the National Police Agency in March 2026, the number of reported ransomware incidents in 2025 remained high at 226 cases. Over 50% of the affected organizations spent 10 million yen or more on recovery, and just over 50% were able to recover within a month (National Police Agency, 2026). A delay in the initial response directly impacts recovery time and costs.

This article clarifies the division of roles between SOC and CSIRT, reviews the concepts of NIST SP 800-61 Rev.3 (revised in April 2025), and presents an initial response runbook spanning from detection accuracy determination to containment, evidence preservation, reporting, recovery, and post-incident review. It also explains practices specific to Japanese enterprises—such as reporting to the Personal Information Protection Commission and consulting with the police—ransomware response precautions, and how initial response changes when an AI agent handles the SOC's primary investigation.

SOC vs. CSIRT Roles: "Detect and Verify" vs. "Decide, Act, and Communicate"

SOC (Security Operations Center) is the organization that monitors logs and alerts to detect and analyze suspicious events. Incident detection is the core phase of a SOC. Upon receiving EDR or SIEM alerts, the SOC determines whether they are true or false positives, estimates the initial scope of impact, and hands over cases requiring action to the next team. Many organizations outsource 24/7 monitoring to MSSPs, meaning the physical SOC is often external.

On the other hand, a CSIRT (Computer Security Incident Response Team), as defined by JPCERT/CC, is "an incident response team that specializes in handling information security issues within an organization" (JPCERT/CC). JPCERT/CC publishes the "CSIRT Material" to assist in building internal CSIRTs across three phases: concept, construction, and operation. In practice, the CSIRT's role is to declare incidents, direct the overall response, approve containment measures, coordinate with executive management, legal, PR, and business units, and serve as the point of contact for external entities like authorities, police, business partners, and JPCERT/CC. Simply put, while the SOC is the team that "detects and verifies," the CSIRT is the team that "decides, acts, and communicates."

The critical issue is what happens at the boundary between these two. In many Japanese companies, the CSIRT is a virtual organization staffed by employees with concurrent duties in IT, general affairs, or legal, while the SOC is outsourced. In this setup, the handoff from the SOC to the CSIRT is the most common point of delay. A typical scenario involves the outsourced SOC emailing, "We have detected suspicious communication. Please check," and the internal contact reading it the next morning, taking half a day to verify it internally. To accelerate this handoff, you must predefine which severity level triggers what communication channel, within what timeframe, and using what information format. The SOC should generally provide the CSIRT with the following five details:

• Detection details, time, and confidence: What was detected and the likelihood of it being a true positive, accompanied by the reasoning.

• Initial scope estimate: Terminals, accounts, and servers confirmed to be involved, alongside what has not yet been verified.

• Completed containment: Actions already taken within the SOC's authority, such as isolated terminals or disabled accounts.

• Recommended next steps: Actions requiring CSIRT approval and the rationale.

• Evidence location: Where logs and alerts used for the determination are stored and how to access them.

With these five points ready, the CSIRT can start making decisions immediately. If they receive only the bare fact that "an alert was triggered," they must redo the primary investigation, doubling the delay in initial response.

NIST SP 800-61 Rev.3: Incident Response is Now Part of Risk Management

NIST SP 800-61 has long been referenced as the standard for incident response. Rev.2, released in August 2012, outlined a lifecycle consisting of four phases: "Preparation," "Detection and Analysis," "Containment, Eradication, and Recovery," and "Post-Incident Activity." This has served as the backbone for procedural manuals in many organizations. In April 2025, NIST updated this with Rev.3, titled "Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile," replacing Rev.2 (NIST, 2025).

The most significant change in Rev.3 is the realignment of incident response with the six functions of the Cybersecurity Framework (CSF 2.0): Govern, Identify, Protect, Detect, Respond, and Recover. NIST explains that given the frequency and scale of modern incidents, incident response is a critical component of cybersecurity risk management and must be integrated into overall organizational operations (NIST, 2025). The mapping to the old model is also provided: "Preparation" maps to Govern, Identify, and Protect; "Detection and Analysis" maps to Detect and Identify (Improvement); "Containment, Eradication, and Recovery" maps to Respond, Recover, and Identify (Improvement); and "Post-Incident Activity" maps to Identify (Improvement) (NIST, 2025).

This has two practical implications. First, "Post-Incident Activity" is no longer just the final phase. While the old model placed lessons-learned activities exclusively at the end, Rev.3 structures them as a continuous feedback loop from detection, response, and recovery into improvement. Second, the Respond function is organized into four categories: "Incident Management (RS.MA)," "Incident Analysis (RS.AN)," "Reporting and Communication (RS.CO)," and "Mitigation (RS.MI)," while Recover is structured under "Recovery Plan Execution (RC.RP)." For instance, RS.MA-01 recommends that detection technologies automatically report incidents, and RS.MA-04 requires escalations as necessary (NIST, 2025). The runbook in the next section is built along these categories.

Initial Response Runbook: 7 Steps from Detection to Post-Incident Review

A runbook is an execution manual defining "who does what, in what order, and with what authority" for each incident type. Below is a common framework of seven steps. While target times for each step depend on an organization's risk tolerance, systems are typically designed to complete containment within minutes to a few hours.

Step 1: Detection Confidence Determination (SOC)

Upon receiving an alert, the SOC first determines whether it is a true positive or a false positive. This phase, which involves deduplication and enrichment with asset info, user attributes, and threat intelligence, is detailed in Alert Triage Automation. From an initial response perspective, the key is predefining "incident declaration" criteria. Setting rules like "Declare and activate the CSIRT if a true positive involves a critical asset or privileged account, or shows signs of lateral movement" eliminates hesitation. A delay in declaration delays all subsequent steps.

Step 2: Scope Identification

In parallel with the declaration, teams trace the scope of impact from terminals to users, servers, and data. Analysts query EDR and SIEM to check if the same hash value or C2 communication destination exists on other hosts, if the account signed in from another location at the same time, or if access to shared servers or cloud environments surged from the terminal. NIST SP 800-61 Rev.3 (RS.AN-08) requires organizations to estimate and validate the incident scope, advising against underestimation (NIST, 2025). The scope at this stage can be tentative, documented with the assumption that it will be updated as containment proceeds.

Step 3: Containment: Terminal Isolation, Account Disabling, and Network Block

There are three basic containment actions. First is terminal isolation, restricting the terminal's communication to only the EDR management server using the EDR's network isolation feature. This stops lateral movement while keeping the connection active for investigation, making it the most common initial response. Second is account disabling, which involves disabling compromised accounts, resetting passwords, revoking active sessions/tokens, and requiring MFA re-registration. This is top priority if privileged accounts are involved. Third is network blocking, which includes segment-level isolation, blocking known C2 destinations, or temporarily suspending VPN devices suspected of being the entry point.

NIST SP 800-61 Rev.3 (RS.MI-01) requires containing incidents. When selecting containment strategies, organizations should consider the incident type and risk assessment factors, as well as the duration of the measure—whether it is an emergency workaround, a temporary bypass, or a permanent solution (NIST, 2025). In practice, containment is always a trade-off between operational disruption and further damage. To avoid making this decision from scratch every time, establish an authority matrix beforehand, such as: "SOC can immediately isolate a single workstation," "CSIRT leader approval is required to isolate multiple terminals/servers or disable privileged accounts," and "Approval from the IT and business unit heads is required to shut down core networks." Specifying how many minutes to wait before escalating to an alternate approver if the primary contact is unreachable is key to keeping weekend and night responses moving.

Step 4: Evidence Preservation

Simultaneously with containment, preserve evidence to support subsequent investigation and reporting. The National Police Agency advises against shutting down computers or network devices during ransomware infections, noting that device and network logs are vital clues, and recommends routinely collecting various logs (National Police Agency). Since turning off devices wipes volatile memory, the runbook should explicitly state that isolation means "disconnecting from the network," not "powering down." From there, extract memory or disk images as needed and preserve EDR, SIEM, IAM, VPN, and proxy logs before they are overwritten or hit retention limits.

NIST SP 800-61 Rev.3 requires logging actions taken during investigations to maintain record integrity and provenance (RS.AN-06), and collecting incident data/metadata according to evidence preservation procedures (RS.AN-07). While formal evidence collection or chain-of-custody procedures may not occur for every incident, collected data should still be treated as evidence (NIST, 2025). Your ability to show "who did what and when" during police consultations or regulatory reporting depends on the records kept at this step.

Step 5: Escalation and Reporting

In parallel with containment, initiate internal and external reporting. NIST SP 800-61 Rev.3 requires notifying internal and external stakeholders following established procedures (RS.CO-02) and sharing information with designated external parties, including industry ISACs (RS.CO-03) (NIST, 2025). Internal recipients include executives, legal, PR, HR, affected business units, and sales teams managing impacted clients. Reports should be templated, containing detection time, event summary, confidence level, scope (confirmed vs. unconfirmed), completed actions, pending items, and the next decision deadline. Being transparent about "what is still unknown" in the initial report is critical for maintaining trust.

Step 6: Eradication and Recovery

Once containment is complete and the entry path and attack vector are understood, proceed to eradication and recovery. NIST SP 800-61 Rev.3 (RS.MI-02) requires eradication, which involves removing persistence mechanisms or patching exploited vulnerabilities. For recovery, it lists verifying backup integrity before restoring assets (RC.RP-03), validating restored asset integrity for normal operation (RC.RP-05), and declaring recovery complete to finalize documentation, including post-incident reports (RC.RP-06) (NIST, 2025). Since attackers often attempt to re-enter post-recovery, it is standard practice to temporarily enhance monitoring for the same vectors immediately after restoration.

Step 7: Post-Incident Review

NIST SP 800-61 Rev.3 notes that improvements are often identified during follow-up reporting or lessons-learned meetings near the end of recovery, which is particularly vital for major incidents (NIST, 2025). The review should break down where delays occurred—detection, initiation, decision-making, or execution—and apply fixes to detection rules, runbooks, automation, or authority design. To prevent reviews from becoming mere formalities, track the completion rate of action items. Metrics for this are discussed in What are MTTR and MTTD? SOC KPI Design and Improvement.

Japan-Specific Business Practices: Regulatory Reports, Police Consultation, Partners, and After-Hours

Reporting Personal Information Leaks and Notifying Individuals

The Act on the Protection of Personal Information (APPI) requires reporting to the Personal Information Protection Commission (PPC) and notifying affected individuals when specific data leaks occur. The PPC website lists reportable events, including leaks of sensitive personal information, leaks that could cause financial damage through unauthorized use, leaks suspected of being committed with malicious intent, and leaks exceeding 1,000 individuals, all of which include "(or risk thereof)" (PPC). This means the reporting clock starts ticking when there is a risk of a leak, even if not yet fully confirmed. Incidents involving unauthorized access or ransomware generally fall under "suspected malicious intent" and can be reportable regardless of the number of individuals involved.

The reporting deadline is two-tiered. The PPC website guides organizations to submit a preliminary report within 3 to 5 days of discovery, followed by a definitive report within 30 days (60 days if malicious intent is suspected). Reports are typically made directly to the PPC, though business operators in fields where authority is delegated to supervising ministers report to those ministries (PPC). For industries like financial institutions where separate reporting to regulators is required, those specific procedures must also be verified (see Security Operations Required for Financial Institutions). For individual notifications, the PPC Q&A outlines options for verbal notifications or alternative measures if notification is difficult, such as setting up inquiry desks, publicizing contact details so individuals can check if their data was affected, or issuing public announcements (PPC Q&A).

To integrate this into your runbook, add a check to Step 2 asking, "Are systems or file servers handling personal data in scope?" If yes, build a workflow to immediately notify legal and privacy teams during Step 5. Because the 3-to-5-day preliminary reporting window is too short to wait for a full technical investigation, it is practical to prepare templates in advance to "report what is known, then supplement with the definitive report."

Reporting and Consulting with the Police

The National Police Agency provides an online portal for reporting cyber incidents, allowing organizations to submit reports, seek advice, or share information with prefectural police (National Police Agency). Regarding ransomware, the agency's report emphasizes that organizations should report incidents early, noting that police can provide initial response advice or decryption tools depending on the situation (National Police Agency, 2026). Knowing the contact point and defining who reaches out in the runbook ensures this remains a viable option during the initial response.

Contacting JPCERT/CC and Business Partners

JPCERT/CC accepts incident reports, contacts sites potentially involved in incidents (such as external network administrators of attack sources or defaced sites), and coordinates with foreign National CSIRTs, handling about 10,000 cases annually (JPCERT/CC). It is valuable to know this contact point beforehand as a communication channel if the attack source or stepping stone lies outside your organization.

Notifying partners carries as much weight for Japanese companies as regulatory reporting. In the IPA's "Top 10 Information Security Threats 2026," "attacks targeting supply chains and subcontractors" ranked second for organizational threats, marking its 8th consecutive year in the top tier (IPA, 2026). You must assume that your incident could serve as an entry path to your partners. Map out contractual notification obligations, deadlines, contacts, and the scope of information to share beforehand, and include partner notification as a decision point in Step 5. Since a subcontractor leak can call the contractor's oversight into question, confirming bidirectional notification paths with suppliers is also recommended.

After-Hours and Weekend Escalation

Even with perfect procedures, the initial response stalls if approvers are unreachable after hours or on weekends. Build contact trees with timeouts, not just sequences. If the primary contact does not respond in 10 minutes, move to the secondary contact. If the CSIRT leader is unreachable for 30 minutes, delegate containment approval to an alternate. Expanding the scope of "pre-approved containment actions" in your authority matrix accelerates after-hours response. The structural reasons why after-hours systems fail are discussed in detail in "Why Weekend and Night Security Operations Fail."

Key Considerations for Ransomware Initial Response

The National Police Agency report outlines the reality of ransomware damage in 2025 as follows: reported incidents remained high at 226 cases, with mid-sized and small businesses making up about 60% of victims, and manufacturing accounting for about 40%. Surveys of affected organizations showed that VPN devices accounted for over 60% of entry routes, and only about 18% of organizations had established business continuity plans (BCPs). Double extortion, where data is stolen and threat actors demand payment to prevent its release, made up the majority of cases, alongside attacks that exfiltrated data and threatened exposure without encrypting files (National Police Agency, 2026). These facts demand that ransomware initial response runbooks incorporate the following precautions:

• Prioritize isolation and keep devices powered on: The National Police Agency advises isolating infected terminals from the network by unplugging LAN cables or turning off Wi-Fi, without powering them down (National Police Agency). This halts encryption and lateral movement while preserving evidence in volatile memory.

• Include entry-point blocking in containment: With VPN devices accounting for over 60% of entry points, isolating endpoints is not enough. Build VPN device suspension, credential revocation, and emergency patching into initial containment.

• Assume double extortion and check for exfiltration: Do not just focus on stopping encryption. Monitor proxy or firewall logs for large data transfers. If personal data might have been stolen, initiate leak assessment workflows simultaneously.

• Verify backup integrity before restoring: As required by NIST SP 800-61 Rev.3 (RC.RP-03), ensure backups themselves are not encrypted, deleted, or altered before starting restoration (NIST, 2025).

• Predefine the ransom payment policy: The National Police Agency warns that ransom payments fund criminal groups, and notes that the "No More Ransom" project provides decryption tools for certain strains (National Police Agency). Decisions on payment should not be made by responders in the heat of the moment; management and legal should establish policies during peacetime.

• Determine recovery priorities beforehand: The fact that only 18% of organizations had BCPs indicates that most teams debate recovery priorities after the damage is done. Defining core business priorities and alternative workarounds beforehand dictates recovery speed.

How AI Agents Transform SOC Primary Investigations and Initial Response

Of the seven steps, Step 1 (confidence determination), Step 2 (scope identification), and Step 4 (evidence collection) consist of the primary investigation typically handled by the SOC. The CSIRT cannot make decisions, contain threats, or issue reports until this primary investigation is complete. In human-operated SOCs, alert queues and after-hours staffing shortages are structural factors that delay this phase.

Deploying an AI SOC where AI agents handle the primary investigation directly addresses this bottleneck. Yagura AI SOC is an in-house developed service where AI agents replicating the investigative workflows of elite analysts monitor, investigate, and respond to EDR and SIEM alerts 24/7. It integrates with over 100 security products, including Microsoft Sentinel, EDRs, SIEMs, and identity providers, learning local environments via context memory to enhance investigation accuracy. For initial response, the AI investigates and structures alert data, helping the CSIRT quickly verify confidence, scope, evidence, and recommended actions. The depth of the five handoff points provided depends on integration points and available data. Measure investigation times and human verification overhead in your environment to see how this reduces initial response burdens. Running cross-log queries for indicators of compromise (IOCs) is also critical for tracking lateral movement.

However, speed only has value when backed by governance. What is delegated to AI agents versus what requires human approval must be clearly documented based on the following concepts:

• Separation of Read and Write Actions: Let agents autonomously handle read-only investigations like log queries and evidence gathering, but restrict write operations like terminal isolation, account disabling, and network blocks to your authority matrix. A common approach permits automated isolation for low-impact, reversible actions (like isolating a single workstation) under pre-approval, while requiring human approval for server, privileged account, or segment-level network shutdowns. NIST SP 800-61 Rev.3 also touches on automated containment options, noting that the scope should be decided based on organizational risk assessments (NIST, 2025).

• Approvers and Approval SLAs: Define who responds to agent approval requests and within how many minutes, specifying what happens if no response is received, including during nights and weekends.

• Audit Trails: Log every query the agent runs, the results obtained, the rationale behind its decisions, actions taken, and the associated approvers. This applies the logging requirements of RS.AN-06 to machine actions.

• Rollback Procedures: Document who can reverse actions and how if the agent mistakenly isolates an asset or disables an account.

• Accountability: Declaring incidents, making final containment decisions, reporting to regulators/police/partners, and deciding on ransom payments remain the sole responsibility of the CSIRT and executives. AI agents accelerate the response; they do not assume accountability.

With this design, AI agents eliminate "waiting for analysts to log on" delays, giving the CSIRT more time to make critical decisions. When evaluating these tools, start by adding the agent's operational boundaries into your runbook's authority matrix to frame the technical discussion around organizational workflow.

Summary

The success of incident response depends heavily on whether you have defined who evaluates alert confidence, who approves containment, and who handles reporting within the first hour of detection. Clarify the division of labor—SOC for "detecting and verifying" and CSIRT for "deciding, acting, and communicating"—and define the five data points required at their handoff point as a starting step. NIST SP 800-61 Rev.3 integrates incident response with the six functions of CSF 2.0 and structures it to feed lessons learned back into improvements. The seven steps in this article align with this framework to organize response from detection to post-incident review.

For Japanese organizations, preliminary reports to the PPC (within 3 to 5 days), police consultation, partner coordination, and after-hours escalation structures dictate response speed just as much as technical steps. For ransomware, ensure your runbooks reflect key rules: isolate but keep devices powered on, include entry-point blocking in containment, and check for exfiltration under double-extortion assumptions. Letting AI agents handle primary SOC investigations changes the CSIRT handoff from raw alerts to structured findings, bringing response times down to minutes. However, its value is unlocked only with governance: separation of read/write, SLAs, audit trails, rollbacks, and accountability. Start by mapping out your containment authority matrix and after-hours escalation paths in your runbook today.

Related Service: Learn more about Yagura AI SOC, our service where AI agents autonomously investigate and handle EDR and SIEM alerts 24/7, covering primary investigations—including confidence determination, scope identification, and evidence collection—described in this article.

References and Sources

• NIST, "SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile" (April 2025): https://csrc.nist.gov/pubs/sp/800/61/r3/final

• NIST, "SP 800-61 Rev. 3" PDF Document (April 2025): https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r3.pdf

• Personal Information Protection Commission, "Handling and Resources for Data Leaks" (Accessed September 2026): https://www.ppc.go.jp/personalinfo/legal/leakAction/

• Personal Information Protection Commission, "Q&A on Guidelines for the Act on the Protection of Personal Information" (Accessed September 2026): https://www.ppc.go.jp/personalinfo/faq/APPI_QA/

• National Police Agency, "Threat Situation in Cyberspace for 2025" (March 2026): https://www.npa.go.jp/publications/statistics/cybersecurity/data/R7/R07_cyber_jousei.pdf

• National Police Agency, "Ransomware Prevention Measures" (Accessed September 2026): https://www.npa.go.jp/bureau/cyber/countermeasures/ransom.html

• National Police Agency, "Consultation Desk for Cyber Incidents" (Accessed September 2026): https://www.npa.go.jp/bureau/cyber/soudan.html

• IPA, "Top 10 Information Security Threats 2026" (Published January 29, 2026): https://www.ipa.go.jp/security/10threats/10threats2026.html

• JPCERT/CC, "CSIRT Material" (Accessed September 2026): https://www.jpcert.or.jp/csirt_material/

• JPCERT/CC, "What is Incident Response" (Accessed September 2026): https://www.jpcert.or.jp/ir/