NIST Special Publication 800-61 Revision 2, titled "Computer Security Incident Handling Guide," was published in August 2012. It can be accessed in the NIST catalog at nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf. This guide, produced within the U.S. Department of Commerce, is the most widely used reference document in the world for enterprise cyber incident response. ENISA's Good Practice Guide for Incident Management, the Microsoft Incident Response Playbook, and the SANS PICERL model belong to the same language family as this resource.

NIST SP 800-61 Revision 2 divides the incident response life cycle into four phases.

  1. Preparation
  2. Detection and Analysis
  3. Containment, Eradication and Recovery
  4. Post-Incident Activity

This guide adapts each of the four phases to the Turkish context with concrete checklists. At the end of each section there are practical notes drawn from the field experience of the DSET team.

Section 1. Phase 1 - Preparation

The preparation phase encompasses all the investment made before an incident occurs. NIST states that this phase has two main goals. The first is establishing the incident response capability. The second is reducing the likelihood of incidents occurring, that is, preventive security.

1.1. Incident response capability checklist

No. Control item Status
1 Incident response policy published with management approval _
2 Incident response team (CSIRT or IRT) defined _
3 Chain of command and backup signing authorities documented in writing _
4 Communication tree (call list) updated within the last 90 days _
5 External support contract (forensic retainer) signed _
6 Incident classification matrix defined _
7 Runbooks written for critical systems _
8 Communication templates ready (internal, external, press, regulator) _
9 Legal process flow (KVKK, USOM, BTK) documented _
10 At least 2 tabletop and 1 live exercise added to the annual exercise calendar _

1.2. Preventive controls checklist

No. Control item Status
1 Asset inventory (CMDB) passed a consistency check within the last 30 days _
2 Patch management running with a 7 day SLA for CVSS 9 and above, and a 30 day SLA for 7 to 9 _
3 EDR / XDR deployment above 95 percent of endpoints _
4 Privileged Access Management (PAM) active for privileged accounts _
5 Multi factor authentication active on 100 percent of administrator accounts _
6 SIEM and log collection above 95 percent of critical sources _
7 Backups compliant with the 3-2-1 rule, at least one of them offline _
8 Network segmentation ensuring the production / management / user / DMZ separation _
9 DMARC, DKIM, and SPF records in enforce mode for email _
10 Annual security awareness training completed with 90 percent attendance _

1.3. DSET field note

The most frequently encountered shortcoming in the preparation phase is documents that exist on paper but are not accessible. Keeping the "who to call" chart on a shared file server turns it into meaningless information the moment that server becomes inaccessible due to ransomware. The call tree must also exist as an offline copy in a printed binder.

Section 2. Phase 2 - Detection and Analysis

NIST SP 800-61 divides incident indicators in the detection stage into two groups.

  • Precursor, a pre incident indicator. There is no incident yet, but there are signs of a future incident. For example, a port scan.
  • Indicator, an incident indicator. An incident has occurred or is occurring. For example, unauthorized account creation.

2.1. Detection checklist

No. Control item Output
1 A SIEM alert or a user report being received Incident ticket
2 Initial confirmation of the incident, elimination of false positives Triage note
3 Assignment of the incident number and severity level Severity label
4 Making the first chain of command call Call record
5 Estimate of affected systems and users Preliminary inventory
6 Initial evidence preservation decision (snapshot, RAM dump, log preservation) Evidence log form
7 Notifying the legal unit (is there a KVKK category) Legal note
8 Sending the first internal communication message Message copy
9 Sharing the incident ticket with all actors included in the scope Access list
10 Starting the time tracking clock (T0 assignment) Timeline

2.2. Impact criteria table

A Turkish adaptation of NIST SP 800-61 Figure 3-2 is below. This table helps to score the impact created by the incident across three dimensions.

Dimension Low Medium High
Functional impact No impact on any critical service Some non critical services disrupted All critical services down
Information impact No access to sensitive data Possible access to sensitive data, not yet confirmed Sensitive data leak confirmed
Recoverability Return within hours using predefined resources Additional resources required, return within days Unclear whether recovery is possible

The severity level of an incident is determined by the highest of the three dimensions.

2.3. RAM dump workflow with Volatility 3

Volatility 3 is a Python based open source memory analysis framework. It is published in the github.com/volatilityfoundation/volatility3 repository. The workflow for collecting volatile evidence from a Windows system is as follows.

  1. A physical RAM image is taken with WinPMem or FTK Imager Lite, run not from the disk but from a write protected USB.
  2. The SHA-256 hash of the image is computed and written into the evidence form.
  3. The image is placed into the evidence store in two copies.
  4. Volatility 3 is run on the analysis copy.
  5. The list of active processes is extracted with the windows.pslist plugin.
  6. The parent-child relationship is visualized with the windows.pstree plugin.
  7. Network connections and listening ports are extracted with the windows.netscan plugin.
  8. The command line arguments of each process are obtained with the windows.cmdline plugin.
  9. Suspicious injection regions are scanned with the windows.malfind plugin.
  10. Loaded DLLs and handles are examined with the windows.dlllist and windows.handles plugins.

For Linux systems, the linux.pslist, linux.pstree, and linux.netstat plugins provide a similar workflow.

2.4. Chain of custody form template

The ISO 27037 standard defines the processes for identifying, collecting, acquiring, and preserving digital evidence. The form below helps to produce a basic chain of custody record compliant with ISO 27037.

Field Description
Evidence ID Unique number, for example DSET-2026-001
Acquisition date and time UTC and local time zone
Acquisition location Geographic location, system, and port
Acquired by First name, last name, title, contact
Acquisition tool Hardware or software, version
Write protection Yes, no, which method
Hash algorithm SHA-256, SHA-1 (reference only)
Hash value Full character string
Storage location Physical safe, logical vault
Access record Date, person, purpose, signature

The form is expanded with a new row at each transfer. A field left blank can lead to the evidence being rejected in court.

Section 3. Phase 3 - Containment, Eradication and Recovery

NIST groups this phase under a single heading because the steps follow one another, yet they contain interwoven decisions.

3.1. Containment trade-off, short term and long term

When making a containment decision, two separate time horizons are considered.

Short term containment: These are the urgent interventions made to stop the spread of the attack within minutes. Isolating the affected endpoint from the network, suspending the suspicious account, and cutting off the external connection with the firewall are typical examples. Short term containment must not destroy evidence, but it should aim for speed.

Long term containment: This is the creation of a temporary solid foundation in place of a permanent solution. It includes steps such as a new isolated VLAN for the affected system, internet access via a temporary proxy, and the full invalidation of old credentials. Long term containment is the preparation phase for recovery.

The typical mistake in this dilemma is that the short term solution quickly becomes "permanent" and the long term hardening is suspended.

3.2. Containment checklist

No. Control item Result
1 Isolation of the affected endpoint from the network (EDR isolation) _
2 Suspension of the suspicious account, invalidation of its sessions _
3 Blocking C2 IP addresses with the firewall and DNS sinkhole _
4 Separating backup servers from the attacker's traffic _
5 Placing Domain Controller logs under additional protection _
6 Moving the affected segment to a temporary VLAN _
7 Closing third party connections (VPN, B2B) _
8 Review of measurement: is the impact still expanding _
9 Revision of the decision between short term and long term _
10 Informing legal stakeholders of the containment decision _

3.3. Eradication checklist

No. Control item Result
1 Listing all IoCs (hash, IP, domain, registry key, file path) _
2 Scanning for IoCs on all affected endpoints _
3 Cleaning up persistence mechanisms (scheduled task, service, registry, startup) _
4 Resetting the passwords of the accounts used and the Kerberos KRBTGT _
5 Rotation of API keys and certificates _
6 Patching privilege escalation vulnerabilities _
7 Deleting the side effects produced by the malware (byproduct files, dumps) _
8 Running the affected backups through a cleanliness check as well _
9 Confirmation of antivirus and EDR signature updates _
10 Verification of cleanup with a repeated scan _

3.4. Recovery checklist

No. Control item Result
1 Backup integrity verification (hash comparison) _
2 Planning the recovery order by business criticality priority _
3 A ban on opening to production before cleanliness is verified on the system _
4 Additional monitoring after restore (increased log level, EDR canary) _
5 Performance and functional acceptance tests _
6 Service restoration announcement to users, notes on expected limitations _
7 An enhanced monitoring period for the first 14 days _
8 Configuration records changed during recovery _
9 Retention of the approval chain for irreversible changes _
10 Timestamped documentation of all stages _

3.5. DSET field note

The most critical mistake in the recovery phase is shortening the enhanced monitoring period out of an "the incident is over" mindset. It has been observed that attackers can wait days or even weeks for a second wave. NIST's recommendation is an enhanced monitoring period of at least 2 weeks after recovery.

Section 4. Phase 4 - Post-Incident Activity

This is the phase in which the impact of the incident is measured, the lessons are drawn, and the organization is strengthened. NIST recommends that the lessons learned meeting be held no later than two weeks after the incident.

4.1. Lessons learned meeting template

Meeting duration: 90 minutes. Participants: the incident response team, legal, a senior management representative, and the relevant business unit owner.

Time Agenda
0-10 min Incident summary and impact table
10-25 min Timeline walkthrough, critical decisions
25-45 min Discussion of what we did well
45-65 min Discussion of what we can improve
65-80 min Action items, owner and date assignment
80-90 min Documentation and communication plan, closing

Every action that comes out of the meeting must be documented with an owner, a date, and a verifiable acceptance criterion. An action without an owner or without a date does not get closed before the next incident.

4.2. KVKK and USOM notification integration

Post-incident activity is intertwined with regulatory processes.

  • KVKK notification to the Authority within 72 hours. For details, the DSET KVKK 72 Hour Notification Template guide can be referenced.
  • USOM, notification within 3 hours in critical infrastructure sectors. The case ticket opened via usom.gov.tr proceeds in coordination with the sector SOME.
  • BTK carries a separate notification obligation in the electronic communications sector.
  • Sector regulators. Additional notifications may be required in areas such as BDDK, SPK, EPDK, and Ministry of Health integration.

4.3. Tabletop exercise scenario

An example tabletop flow is presented below. Duration 120 minutes; participants: the CISO, the IT manager, the legal counsel, the communications director, and a senior management representative.

Scenario: Friday 16:30. The SOC team detects a newly created suspicious account on the domain controller. The account has connected to 12 different servers in the last 2 hours. The source of the connection is an administrator user account, but the administrator in question is on vacation. It is Friday evening, and the weekend shift is about to begin.

Exercise flow:

  1. 0-15 min. The SOC team reports the incident. The chain of command is called. Time tracking begins.
  2. 15-30 min. Communication with the administrator, confirmation of whether the account was actually used. Initial isolation decision.
  3. 30-50 min. The impact criteria table is filled in. Which systems were connected to, which data may have been affected.
  4. 50-70 min. Legal unit's discussion of the KVKK category. Is there sensitive data, an estimate of the number of affected individuals.
  5. 70-90 min. Communication plan. When and what will be told to customers. Timing of the briefing to senior management.
  6. 90-110 min. Weekend shift plan. Will the external support provider be called, and at what cost.
  7. 110-120 min. Closing, preliminary lessons learned notes.

The goal of the exercise is not to produce a perfect answer, but to measure the team's decision making processes, communication chains, and performance under pressure.

Section 5. Combined Master Checklist of the Four Phases

The master table below offers the chance to see all four phases at a glance. Each item is checked off during the annual audit.

Phase Number of items Target completion rate
Preparation, incident response capability 10 100 percent
Preparation, preventive controls 10 at least 90 percent
Detection and analysis 10 100 percent (for each incident)
Containment 10 100 percent (for each incident)
Eradication 10 100 percent (for each incident)
Recovery 10 100 percent (for each incident)
Post-incident 10 100 percent (for each incident)

Section 6. DSET Incident Response Retainer and IR Exercise Service

The DSET team, with over 20 years of cyber incident response and digital forensics experience, is one of the few independent expert teams in Turkey. Our team, based at the Hacettepe University Teknokent Beytepe campus, conducts work in accordance with the ISO 27037 standard.

6.1. Retainer service scope

  1. A 24/7 emergency call line. Field team dispatch via the line at +90 536 662 38 09.
  2. Remote and on site digital forensics support at the time of the incident.
  3. KVKK and USOM notification coordination, form preparation, and defense statement preparation.
  4. Post-incident report and lessons learned coordination.
  5. Monthly threat hunting hours as an optional add on package.

6.2. IR exercise service

DSET prepares your annual exercise calendar within the NIST SP 800-61 Rev. 2 framework.

  • The tabletop exercise lasts 2 to 3 hours and tests team decisions through a tabletop scenario.
  • The purple team exercise lasts 1 to 2 days and measures technical response performance through a controlled attack simulation.
  • The full scale exercise lasts 1 week and tests the entire chain, including crisis communication, with the participation of senior management.

For meeting requests you can write to [email protected] or call the line at +90 536 662 38 09. The first scoping meeting is free and is held under a non disclosure agreement.

Closing Note

NIST SP 800-61 Rev. 2 is the most widely accepted incident response guide in the world, but it does not produce value as a document that is read on paper and left on the shelf. Unless you embed this guide into your internal runbooks, call trees, and exercise plans, NIST's four phases remain merely an elegant picture. The act of putting it into practice is the real recommendation of this playbook.