IR-4 Incident handling: requirements and evidence

What IR-4 incident handling requires and why auditors test it

When an assessment is coming, IR-4 Incident handling asks for a working incident handling capability, not a document that describes one. The control requires the organization to implement that capability, consistent with its incident response plan, covering preparation, detection and analysis, containment, eradication and recovery. It also requires incident handling to be coordinated with contingency planning, lessons learned to feed back into procedures, training and testing, and handling to be rigorous, scoped and comparable enough that two teams responding to similar events reach similar results. Assessors read the wording as a test of operations: they expect to see the capability run, not only described in the plan.

NIST SP 800-53B allocates IR-4 to the low, moderate and high baselines and to the privacy control baseline. The moderate baseline adds enhancement IR-4(1), and the high baseline adds IR-4(1), IR-4(4) and IR-4(11), so the enhancement load grows with impact level. Under the privacy baseline, the handling capability must also cover incidents involving personally identifiable information. Confirm with your authorizing official or contract which baseline applies to each system in scope, because that choice decides which enhancements an assessor will test. The SP 800-53A procedures ask assessors to examine the incident response policy, the incident response plan and the contingency plan, to interview people with handling and contingency responsibilities, and to test the handling capability itself.

Two things usually make IR-4 hard. The first is evidence scattered across tools and tickets: alerts sit in a SIEM, triage notes in chat, forensic artifacts on a laptop and the closure decision in a service desk queue, so no one can reconstruct a single incident end to end. The second is inconsistent handling between teams, where the security operations group, infrastructure and application owners each close incidents differently and record different fields. A practical first step is to pick a sample of recent incidents and trace each one from detection to lessons learned. If the trace requires manual reconstruction, the handling capability is not yet demonstrable, whatever the plan says.

Which systems, teams and third parties IR-4 covers

IR-4 applies to whatever the organization defines as its incident handling capability, so the first work is deciding which systems, people and providers sit inside that scope. Each decision below changes who responds, what evidence exists and how much of the enhancement set an assessor will test.

Systems inside the authorization boundary

Incident handling must reach every component that stores, processes or transmits the authorized data, including identity services, logging pipelines, backups and administrative consoles. Assessors compare the handling procedures against the boundary in the system security and privacy plan. Check whether logs from components outside the boundary still reach the responders, because an incident often starts in a shared service that the boundary does not name.

Security operations center responsibilities

The security operations center usually performs detection, triage and first analysis, so it must have documented authority to contain an affected host or account. Write down the handoff from alert triage to formal incident handling, and record who can declare an incident. An assessor will ask staff with incident handling responsibilities to describe that handoff, so the description must match the playbooks.

Platform and infrastructure engineering roles

Eradication and recovery usually depend on platform teams who can rebuild images, rotate credentials, restore from backup and change network rules. Name these teams in the handling procedures and state which containment actions they must execute on request. Contingency planning coordination depends on the same people, so their assignments should match the contingency plan rather than existing only in the incident plan.

Legal, privacy and communications involvement

Decisions about breach notification, evidence preservation and public statements need legal, privacy and communications staff to join the handling process at defined points. Set the trigger conditions in writing, for example a confirmed exposure of personal data, and record when each group was engaged. Missing triggers are a common finding because the handling record then shows decisions made without the required input.

Cloud and SaaS provider duties

Cloud and SaaS providers often detect and contain incidents on their own infrastructure, but the organization still owns its response to its data and accounts. Document which provider notifications the organization receives, how it obtains provider logs, and which actions it can take in the provider console. Confirm these terms in each provider agreement and shared responsibility document, because the contract, not the marketing material, defines what the provider must supply.

Baseline selection changes the enhancements

The low baseline carries IR-4 without enhancements, the moderate baseline adds IR-4(1), and the high baseline adds IR-4(1), IR-4(4) and IR-4(11). The privacy baseline also includes IR-4. Confirm the selected baseline in the security plan before scoping evidence, because the enhancement set is what an assessor tests beyond the base control. Ask the authorizing official or contract owner to confirm any tailoring that adds or removes items.

How the handling capability fits together across phases and related controls

IR-4 asks for one incident handling capability that runs through preparation, detection and analysis, containment, eradication and recovery. Assessors read these phases as a sequence of linked activities, not as separate projects. Each phase should have a named owner, documented inputs and outputs, and evidence that the phase happened for real incidents and for exercises.

Preparation: Tools, contacts, access and playbooks are in place before an event, and the incident response plan describes how they are used.
Detection and analysis: Alerts from monitoring are triaged, scoped and recorded so the team can decide whether an event is an incident.
Containment, eradication and recovery: Actions are logged with timestamps, approvals and the systems affected, so the record shows what was changed and when.
Lessons learned: Findings feed back into procedures, training and testing rather than ending in a closed ticket.
Consistency: Handling rigor, scope and results should be comparable across teams, which means one set of playbooks and one severity scale.

Confirm with your own assessor which phase evidence they expect in your environment, and whether they sample closed incidents or only exercises.

How an assessor tests IR-4 under SP 800-53A

This table compares the three SP 800-53A assessment methods used for IR-4 Incident handling, what the assessor asks for under each, the evidence that passes and the findings that come up most often. The SP 800-53A procedure for IR-4 has 13 determination statements, so the assessor will usually review documents, speak with responders and planners, and observe the handling capability itself. Read each row as a question the organization should be able to answer with dated records before the assessment starts.

Test method	What the assessor asks for	Evidence that passes	Common finding
Examine: incident response policy and contingency planning policy	Whether the policies establish incident handling and link it to contingency planning, and whether they were approved and disseminated	Signed policy versions with owner, approval date and distribution record, showing both policies reference the handling capability	Policies mention incident handling only in general terms and do not name who coordinates with contingency planning
Examine: procedures addressing incident handling	Step-by-step procedures covering preparation, detection and analysis, containment, eradication and recovery	Runbooks or playbooks for each phase with version history, owners and references to the tools used for each step	Procedures exist but skip eradication or recovery, or were last reviewed before the current environment was deployed
Examine: incident response plan and contingency plan	That the IR plan and contingency plan describe how handling hands off to recovery and how each plan is kept consistent with the other	Cross-referenced plans showing shared roles, escalation paths and recovery objectives, with a dated review record	The two plans name different owners for the same recovery decision
Interview: personnel with incident handling responsibilities	How responders detect, triage, contain and document an incident, and who decides when to escalate or stop an action	Responders describe the same steps as the written procedures and can point to the case records they produced	Responders describe steps that differ from the documented procedure or rely on one person who is not named in the plan
Interview: personnel with contingency planning responsibilities	How contingency planners learn of an incident, when they activate recovery and how lessons from handling reach the contingency plan	Planners name the trigger, the handoff record and the update they made after the last incident or exercise	Contingency planners were not involved in the last significant incident and learned of the outcome afterward
Test: incident handling capability for the organization	Whether the capability can run end to end on a realistic scenario, with alerts converted to cases, containment actions recorded and recovery confirmed	Test results or a recent live incident record showing timestamps, actions taken, evidence logged and a completed lessons-learned entry	The capability is documented but has never been exercised, so the assessor has no observed result to examine
Test: consistency of handling across the organization	Whether handling rigor and results are comparable across business units, sites or hosting environments	Case records from more than one unit following the same categories, severity scale and closure criteria	Each unit uses its own ticket fields or severity labels, so results cannot be compared
Test: evidence of lessons learned feeding procedures	How lessons from handling change procedures, training and later testing	Lessons-learned entries linked to procedure revisions and to changes in training or test scenarios	Lessons are recorded but no procedure, training module or test plan shows a corresponding change

Implementing an IR-4 handling capability in order

This sequence turns IR-4 from a policy statement into a working handling capability, with each step producing an artifact an assessor can examine, interview against or test. Work proceeds from the incident response plan outward to playbooks, tooling, records, contingency coordination and lessons learned.

Define handling phases and roles against the IR plan
Start from the incident response plan (IR-8) and map the handling phases IR-4 names (preparation, detection and analysis, containment, eradication and recovery) to named roles, decision authorities and escalation paths. The owning organization makes these assignments, and personnel with handling responsibilities must be identifiable because assessors interview them. The output is a roles and phases matrix signed off by the accountable owner. You know it is done when every phase has a named owner and the matrix is referenced from the plan.
Build playbooks for each incident type
Write a playbook for each incident type the plan treats as reportable, such as account compromise, malware on an endpoint, data exfiltration and denial of service. Each playbook sets triage criteria, containment options, eradication steps, recovery checks and the points where contingency planning is invoked. Engineers and the incident lead review each playbook against a recent system architecture. The output is a versioned playbook set with owners and review dates. You know it is done when each playbook can be followed by someone who did not write it.
Set up detection and case tooling
Deploy the detection and case components the playbooks depend on. Open-source options include Wazuh for log decoding and alerting against its ruleset, OpenSearch Security Analytics for Sigma-based detectors and correlation, osquery for fleet-wide host queries, and DFIR-IRIS as the case management layer. Confirm each product's capabilities and licenses against its current documentation before selecting it. The output is a tested data path from log sources to the case system. You know it is done when a known test event produces an alert that opens a case.
Define case record fields and evidence rules
Design the case schema so every incident record holds the same fields: identifier, classification, timeline, affected assets, indicators of compromise, tasks, decisions, and evidence items. Set evidence handling rules covering hashing, chain of custody and access logging. The organization owns these rules, and the schema should match what IR-5 monitoring and IR-6 reporting need. The output is a case schema and an evidence handling procedure. You know it is done when a sample case can be completed and every field is populated or marked not applicable with a reason.
Coordinate handling with contingency planning
Document the hand-off points where an incident affecting availability or recoverability triggers contingency plan activation, and name the people who make that decision. Confirm that recovery steps in the playbooks reference the backup and alternate recovery procedures the contingency plan defines, so the two plans do not conflict. The output is a coordination annex or cross-reference table shared by both plan owners. You know it is done when each contingency activation trigger appears in at least one playbook.
Run a handling test and record the results
Exercise the capability with a scenario that moves through every phase, using a simulated event or a supervised tabletop. Record the start and end times, decisions, tool outputs, gaps and who performed each task. Compare the results against the playbooks and the case schema. The output is a test record with findings and assigned corrective actions. You know it is done when the test record shows each phase was exercised and each gap has an owner.
Capture lessons learned into procedures
After each real incident and each test, hold a structured review and feed the findings into playbooks, detection rules, training content and the incident response plan. IR-4 expects lessons learned to change procedures, training and testing, so each finding should map to a specific document change. The output is a lessons learned log linked to revised artifacts with version numbers. You know it is done when a reviewer can trace at least one finding from the log to an updated playbook or rule.

Which evidence shows IR-4 is working

What incident handling procedures do assessors expect to see for IR-4?

Assessors expect written handling procedures that follow the incident response plan and describe how the team moves through preparation, detection and analysis, containment, eradication and recovery. The procedures should name the roles that act at each stage, the decision points for escalation, and how incident handling is coordinated with contingency planning. Keep a version history with owner, approval date and the last review. Review the procedures after every significant incident, after major system changes and on the schedule set in the organization's own policy. Confirm with your assessor which version history format they will accept, since IR-1 and IR-8 also depend on these documents being current.

Why do case records with timelines and audit trails matter for IR-4?

Case records prove that handling actually happened and that results are comparable from one incident to the next. DFIR-IRIS keeps each case as one record that holds assets, indicators of compromise, tasks and evidence, with a full audit trail and a consolidated investigation timeline. An assessor can sample closed cases and check that the timeline, owner actions and decisions match the procedures. To keep this current, require every case to be opened, updated and closed inside the platform, and run a periodic sample review of closed cases against the handling procedures. Ask the assessor which case sample size and period they expect before the review begins.

How do evidence logs and chain of custody support an incident handling assessment?

Evidence logs show that artifacts collected during an incident were handled in a controlled and verifiable way. DFIR-IRIS logs evidence with SHA-256 verification and chain of custody, so the hash recorded at collection can be checked later against the stored file. Assessors typically sample a few evidence items and ask whether the hash still matches and who accessed the item. Keep the hashing and custody steps part of the collection checklist, and verify a sample of stored evidence on a regular schedule. Confirm with your legal and forensic advisers how long evidence must be retained, since retention rules come from your own obligations, not from SP 800-53.

What playbooks should an organization keep for IR-4 evidence?

Playbooks are step-by-step response procedures for common incident types, such as account compromise, malware on an endpoint, data exposure or a denial of service event. Each playbook should list the trigger, the owner, the containment and eradication steps, the evidence to collect, the recovery checks and the criteria for closing the case. Assessors use playbooks to compare what the procedure says with what responders did in recent cases. Maintain each playbook under version control, tie it to a named owner, and update it after tabletop exercises under IR-3 and after real incidents. Ask your assessor whether they want a playbook for every incident category in your risk assessment or only the high-impact ones.

Which detection rule and alert records prove detection and analysis is working?

Detection rule and alert records show that the organization can detect incidents and that analysts triage what the detection tools produce. Wazuh compares collected events against a ruleset of over 3,000 built-in rules and decoders plus custom rules, writes matches to alerts.log and alerts.json, and maps alerts to MITRE ATT&CK. OpenSearch Security Analytics runs detectors against Sigma rules and records findings with rule, log type and severity. Keep rule change history, the list of active detectors, and samples of alerts that were triaged into cases. Review rule coverage against your incident categories at a set interval, and document any detector you disabled and why.

What do lessons learned reports show, and how should follow-up be tracked?

Lessons learned reports show that incident handling feeds back into procedures, training and testing, which is what IR-4 requires. A useful report records what happened, what the response got right, what failed, the root cause and a list of corrective actions with owners and due dates. Assessors check that accepted actions were carried out, so track each action in your plan of action and milestones or ticketing system until it closes. Hold a short review after each significant incident and a periodic review of trends across cases. Confirm with the assessor how far back they will look and which incidents must be covered.

Can an organization collect IR-4 evidence without an outside partner?

Yes, an organization can collect IR-4 evidence with its own staff, provided it owns the controls and keeps the records assessors test. An implementation partner such as DeployOpen can plan and deploy the self-hosted tooling, configure case, detection and query components inside your own infrastructure, document the procedures and prepare evidence for an assessment. DeployOpen does not issue assessment reports or certifications; an independent assessor does. Most engagements are fixed-scope, so ask any partner to state in writing which artifacts they will deliver, who maintains them afterward and what recurring work remains with your team.

What meeting IR-4 costs in money and effort

This table lists the cost components of an IR-4 incident handling capability, who is paid for each, whether it is one-time or recurring, and what drives it up. No supplied figures exist for these costs, so use the drivers and quote items to compare written proposals. The main takeaway is that open-source tooling removes license spend but not hosting, staffing or evidence upkeep.

Cost component	One-time or recurring	Who is paid or who carries it	What drives the cost
Tooling and licenses	Mostly recurring for commercial tools	Vendor, or no license fee for self-hosted open-source platforms such as DFIR-IRIS, OpenSearch and Wazuh	Chosen platforms, number of users and seats, and whether the organization self-hosts
Hosting and log storage	Recurring	Organization's cloud account, data center or air-gapped network	Log volume, retention periods, number of monitored hosts and index sizing
Engineering time for playbooks and detection	One-time build, then recurring tuning	Internal staff or an implementation partner under a written scope	Baseline selection, number of incident types, detection rules and integrations with SIEM, EDR and ticketing
Deployment and integration	One-time	Implementation partner or internal platform team	Number of log sources, connectors to existing tools and how many environments are covered
Staff availability for incident response	Recurring	Organization, through internal responders, on-call rotations or retained support	Team size, after-hours coverage requirements and skills available in house
Evidence upkeep	Recurring	Organization owns the records; partner may prepare exports and reports	Frequency of incidents, number of case records, lessons learned updates and playbook reviews
External testing or tabletop support	Recurring, usually per exercise	Independent testing or training provider, under a written scope	Exercise scope, number of scenarios, whether IR-3 testing is in the baseline and how often tests run
Auditor sampling and assessment	Recurring per assessment cycle	Independent assessor or auditor, not the implementation partner	Number of incident samples the assessor selects, evidence quality and the assessment scope

Open-source tools that produce IR-4 evidence

IR-4 evidence is mostly records: case histories, detection outputs, containment actions and lessons learned that an assessor can trace from alert to recovery. The four tools below each produce part of that chain, and none of them replaces the incident handling capability, the playbooks or the people who run it.

Case records with DFIR-IRIS

DFIR-IRIS keeps each case as one record holding assets, indicators of compromise, tasks and evidence, with a full audit trail. It triages alerts from SIEM, EDR and REST sources into cases and builds a consolidated investigation timeline. For IR-4, the case record is the main artifact an assessor samples to see handling performed consistently. Confirm that the audit trail, timeline export and report templates meet your documentation standard before relying on them.

Chain of custody in DFIR-IRIS

DFIR-IRIS logs evidence with SHA-256 verification and chain of custody, so each collected item carries a hash and a recorded handling history. This supports the analysis and recovery steps an assessor will ask you to show were carried out with preserved evidence. Check with your legal and forensics leads whether SHA-256 hashing and the recorded custody steps satisfy the evidence rules that apply to your sector.

Sigma detectors in OpenSearch

OpenSearch Security Analytics runs detectors against ingested logs from hosts, network devices and cloud services, using prepackaged or custom Sigma rules. Each match is recorded as a finding with its rule, log type and severity, and alerts go to channels such as Slack or email. Detection and analysis evidence depends on which log sources you actually onboard, so confirm coverage of your critical systems before presenting the detector set as complete.

Correlation across log types

The OpenSearch correlation engine links findings across log types in a correlation graph, which helps analysts see one intrusion across endpoint, network and cloud sources. This matters for IR-4 because scoping an incident and judging its extent depends on connecting related events. Test the correlation rules against a known scenario in your environment, since the quality of links depends on consistent fields and time stamps across sources.

Alerts and ATT&CK mapping in Wazuh

Wazuh decodes collected logs, compares events against a ruleset of over 3,000 built-in rules and decoders plus custom rules, and writes matches to alerts.log and alerts.json. It maps alerts to MITRE ATT&CK and forwards them to the Wazuh indexer for review. These outputs give assessors a traceable link from detection to triage. Review the built-in ruleset against your own systems and document any custom rules and tuning decisions.

Fleet queries with osquery

osquery exposes running processes, loaded kernel modules, open network connections and file hashes as SQL tables, and osqueryd schedules those queries across a fleet. During containment and eradication, this lets responders confirm which hosts still show an indicator and record the results. Keep query packs and result logs under change control, and confirm that your endpoint coverage and retention meet the evidence needs of your incident playbooks.

Who owns IR-4 and what partners and auditors can do

The organization owns IR-4. It must run an incident handling capability that fits its incident response plan, covers preparation, detection and analysis, containment, eradication and recovery, and feeds lessons learned back into procedures, training and testing. No outside party can accept that accountability on the organization's behalf. Internal teams decide severity thresholds, approve playbooks, make containment decisions on live systems and answer to regulators and customers for the outcome.

Accountable decisions: Declaring an incident, choosing containment actions and deciding when to close a case stay with named internal roles.
Playbook approval: Leadership or the incident response lead approves the playbooks that define how handling is done, even when a partner drafts them.
Staffing and on-call: The organization staffs its responders and sets how handling coordinates with contingency planning and business continuity teams.
Lessons learned: Post-incident reviews must change procedures, training and test plans, and that follow-through is an internal responsibility.
Evidence ownership: Case records, timelines and tool logs must exist in the organization's own systems, where it can produce them on request.

Before engaging anyone, confirm with your internal assessor which named roles, approval records and case records they will ask to see for IR-4.

Where IR-4 programs usually fall short

IR-4 is assessed as a capability, not a document, so the gaps that cause findings tend to share a root: the handling process exists on paper but is not exercised, connected to adjacent plans, or recorded consistently. The cards below cover the gaps assessors most often find and what to check before the assessment begins.

Playbooks that were never exercised

A playbook that has never been run against a realistic alert is a hypothesis. Assessors look for evidence that handling steps were followed in practice, so a binder of untested procedures often fails the test objective for the handling capability. Check that each playbook has a named owner, a last-run date, and at least one record of a case worked through it. Where no live case exists, ask whether the playbook was walked through in a tabletop, and keep the notes.

Case records missing timelines

IR-4 depends on handling that can be reconstructed afterward. When case records lack timestamps for detection, triage, containment and recovery, the organization cannot show the sequence of actions or judge whether response was timely. Check that each case captures who acted, when, and on which assets, and that evidence handling is logged with integrity checks. Case management tools that keep an audit trail of changes make this easier to verify.

No link to contingency planning

IR-4 expects incident handling to be coordinated with contingency planning, because containment decisions can take systems offline and recovery depends on backups and alternate sites. Programs often keep the two plans in separate binders, so responders do not know when to invoke recovery procedures or who approves restoration. Check that the incident response plan and the contingency plan name the same roles, reference each other's activation criteria, and that a joint exercise has been recorded.

Lessons learned not fed back

Assessors expect handling experience to change procedures, training and testing. A post-incident review that produces a report but no changes to playbooks, detection rules or training content shows the feedback loop is broken. Check that each lessons-learned item has an owner, a target document or rule that it updates, and a closure date. Keep the before and after versions so the change can be traced to the incident that caused it.

Inconsistent handling across teams

IR-4 requires that handling rigor, scope and results are comparable and predictable across the organization. Business units often triage severity differently, escalate on different thresholds, and record outcomes in different formats, which makes it impossible to compare results or show a single capability. Check that severity criteria, escalation paths and minimum record fields are defined once and applied to every team, and that a sample of cases from each team is reviewed against the same checklist.

Detection that does not feed handling

Handling begins when a detection reaches a responder, so gaps between monitoring and case creation weaken IR-4 in practice. Alerts that sit in one console while cases are opened by hand in another can lose context or go unhandled. Check that alerts from the SIEM and endpoint tools create or update cases automatically, that the mapping of alert fields to case fields is documented, and that sampled alerts can be traced to a case record.

Questions buyers ask about IR-4 cost, effort and scope

How much effort does IR-4 incident handling take to implement?

Effort depends on how much of an incident handling capability already exists. IR-4 asks for a capability that is consistent with the incident response plan and covers preparation, detection and analysis, containment, eradication and recovery, and lessons learned. Most of the work is documenting and testing that capability, wiring it to detection tools, and producing case records that show it runs. Organizations starting from nothing need more effort than those with a working SOC and a tested plan. Ask a partner to size the work from a written list of systems, log sources and existing playbooks, because the baseline (low, moderate or high) and the number of enhancements also change the workload. The SP 800-53B moderate baseline adds IR-4(1), and the high baseline adds IR-4(1), IR-4(4) and IR-4(11).

Can we handle IR-4 compliance readiness in-house?

Yes, if your team has the skills to write playbooks, run an incident case from detection to recovery, and produce evidence an outside assessor can read. IR-4 is not a single product purchase. It is a capability with people, procedures and tools, and assessors interview the personnel who handle incidents and contingency planning. Teams that lack recent incident experience or time to run the tests often bring in an implementation partner to prepare the playbooks, case tooling and evidence set, while they keep ownership of the controls. Whatever you choose, the organization still owns the control, and only an independent assessor issues the assessment result.

What does an implementation partner need from our team?

A partner needs named owners and access to work in your environment. Expect to provide the current incident response plan and contingency plan, the list of in-scope systems, the log sources feeding your SIEM or detection tools, access to existing case records and tickets, and the people who handle incidents and recovery. A partner also needs decisions from you: which severity levels trigger escalation, who can approve containment actions that affect production, and where evidence must be stored. Agree these inputs in the written scope before work starts, so that the schedule and deliverables follow from what your team can provide.

How long does IR-4 readiness take, and who sets the timeline?

NIST does not set a timeline for implementing IR-4 or any other SP 800-53 control. NIST leaves federal implementation timelines to OMB Circular A-130, and the duration for your organization depends on your baseline, system count, existing maturity and how many tests you need to run before an assessment. Ask for a timeline in the written scope, and confirm the milestones for playbook drafting, tooling configuration, test runs and evidence collection. Fixed-scope engagements usually set these dates in advance, so you can check progress against agreed deliverables.

Do the tools for IR-4 have to be open source?

No. IR-4 is technology neutral and does not require open-source tooling. You can meet it with commercial case management, SIEM and endpoint products if they produce the records an assessor needs. Open-source options are one choice. For example, DFIR-IRIS (LGPL-3.0-or-later) can keep each case as one record of assets, indicators, tasks and evidence with an audit trail, and OpenSearch Security Analytics (Apache-2.0) and Wazuh (GPL-2.0-only) can produce alerts that feed those cases. Choose tools based on your licensing, support and data residency requirements, and confirm that the features you rely on exist in the version you deploy.

What will the auditor sample when assessing IR-4?

Assessors follow the SP 800-53A procedure for IR-4, which asks them to examine the incident response policy, the contingency planning policy, procedures for incident handling, the incident response plan and the contingency plan. They also interview personnel with incident handling and contingency planning responsibilities, and they test the incident handling capability. In practice, expect requests for a sample of incident case records showing detection, analysis, containment, eradication, recovery and lessons learned, along with timestamps, evidence logs and the playbooks used. Prepare these records before the assessment, and confirm the sample size and selection method with your assessor, since those are set by the assessor and the organization's assessment agreement.

How DeployOpen prepares IR-4 handling and evidence

DeployOpen plans, implements and documents a self-hosted incident handling capability inside your own infrastructure, so the handling process, case records and tooling evidence exist before an assessor asks for them. Your organization owns the control and its results, and an independent assessor tests them.

How we scope

Engagements are fixed-scope, with the IR-4 boundaries, systems and baseline level agreed in writing before work starts.
The written scope names which preparation, detection, containment, eradication and recovery steps are covered for IR-4 Incident handling.
Scope also records how contingency planning coordination and lessons learned feed into procedures, training and testing.

How we build

We deploy self-hosted case management, SIEM and endpoint query tooling in your cloud accounts, data centers or air-gapped networks.
We write handling playbooks aligned with your incident response plan and the phases IR-4 requires.
We configure case templates, evidence logging and audit trails so each incident produces a consistent, reviewable record.

How we hand over

Deliverables include configuration documentation, playbooks, case record samples and a mapping of tooling output to IR-4 evidence.
We document the handling capability test results so your team can repeat them and show comparable results over time.
Your staff receive walkthroughs on running cases, so ownership of the capability stays with your organization after handover.

How we support

Ongoing support, upgrades and continuous testing of the handling capability are available as retainers.
Retainers can cover tool updates, playbook revisions after exercises and lessons learned, and evidence refreshes for assessment cycles.
Ask your assessor which artifacts they expect for IR-4 before scoping, and confirm those requirements in the written scope.