15 Incident Management: requirements and evidence

What HITRUST domain 15 incident management asks for and why assessments fail on it

If you are a compliance lead or CISO preparing an e1, i1 or r2, domain 15 asks whether your organization can detect, report, handle and learn from security events that touch the environment in scope. Assessors do not stop at whether an incident response plan exists. They test whether the process runs in practice, from the first alert through to documented lessons learned. The risk behind this is concrete: HITRUST's certification letters state that HITRUST may investigate and revoke a certification if a security event results in unauthorized access to the assessed environment. A certificate you already hold can therefore be put at risk by an incident you handled poorly, which is why this domain deserves attention before the assessment window opens, not during it.

Domain 15 is also where AI security requirement statements land when your assessment includes HITRUST's AI security certification. If your scope includes AI systems or agents, confirm with your assessor which additional statements apply in this domain, and plan for them in the same incident process rather than in a separate track. Scope matters here too: the incident process must cover the systems the assessor has in scope, including any hosting or provider components you inherit from elsewhere.

Domain 15 is hard for a specific reason: evidence must show a working process over time, not only a written plan. Assessors look for records of real or exercised events, triage decisions, timestamps, escalation to the right people, evidence handling and post-incident reviews with corrective actions that were tracked to closure. An organization with a polished plan but no case history, or with tickets that stop at detection, typically struggle to show the process was operating throughout the period under review. Before you commit to an assessment, check your incident records for completeness and ask your assessor how they expect samples to be drawn from them.

Which systems, teams and providers fall under incident management scope

Incident management scope follows the assessed environment, so the first decisions are about what is in that environment and who touches it. The cards below cover the scoping choices that most affect how much incident handling an assessor will test and what evidence you need to produce.

The assessed environment and its tenancy

Scope begins with the systems, applications and cloud tenancy inside the assessment boundary. Every production application, administrative console and tenancy in that boundary needs an incident response plan that names how events are detected, escalated and closed. Check whether any environment is left out of the boundary but still connects to in-scope data, because an incident there can still reach the assessed environment.

Security monitoring sources that generate events

Every log source, endpoint agent, network sensor and cloud audit feed that can raise an alert is a candidate input to incident handling. Map each source to the in-scope environment and record who receives its alerts and how they are triaged. Sources that feed the SIEM or a case tool without a documented owner are a common gap in this domain.

Responders and their defined roles

Name the people who declare, coordinate, investigate and communicate an incident, including legal, privacy and executive contacts. Assessors look for written roles, reachable contacts and evidence that the team has used the plan, such as tabletop exercises or past case records. Confirm that on-call and backup responders are covered, especially outside business hours.

Third parties that run platform components

A cloud or managed service provider may handle incidents in the platform it runs, while you handle incidents in your applications and tenancy. In HITRUST's OCI inheritance example, incident management is moderately inheritable on this split. Obtain the provider's incident handling evidence, confirm how it notifies you, and document where its responsibilities stop and yours begin.

AI systems that add requirement statements

If AI systems are in scope, HITRUST's AI security assessment places additional AI security requirement statements in this domain. Decide early which models, agents and AI-enabled services fall inside the boundary, since each one can add incident scenarios such as prompt injection or data exposure through model outputs. Confirm with your assessor whether the AI security certification applies to your environment before planning the evidence.

How an assessor tests incident management in an e1, i1 or r2

This table compares how an Authorized HITRUST External Assessor typically tests each phase of incident management, what evidence the assessor asks for and where findings tend to arise. Read it as a preparation checklist: each row shows what your records must prove before fieldwork begins, not only what the policy says.

Phase	Typical test approach	Evidence requested	Common findings
Planning	Assessor reads the incident response plan and checks that it names roles, escalation paths and the systems in scope, then asks how staff learned of it.	Approved plan with version history, role assignments, contact lists and records of review or update.	Plan is generic, does not cover the in-scope environment, or has not been reviewed since the last change to systems or staff.
Reporting	Assessor traces how staff and third parties raise a suspected event and how it reached the response team within the defined timeframe.	Reporting procedure, intake log or ticket records, and notices to internal stakeholders for sampled events.	Reporting channel is unknown to staff, or intake records lack timestamps needed to show timely escalation.
Handling and response	Assessor samples incidents or exercises and follows each from detection through containment, eradication and recovery, checking decisions against the plan.	Case records with triage notes, actions taken, evidence preservation steps, approvals and closure rationale.	Actions are undocumented, evidence is not preserved consistently, or closure happens without verifying the affected system.
Notification decisions	Assessor asks how the organization decides whether a regulator, customer or affected individual must be told, and checks a sample of those decisions.	Decision records, legal or privacy sign-off, and copies of notices where they were issued.	No documented decision criteria, or decisions made informally without a record of who approved them.
Lessons learned	Assessor checks that completed incidents produce review findings and that corrective actions were tracked to completion.	Post-incident review reports, action items with owners and due dates, and evidence that changes were made.	Reviews are not held for minor events, or action items remain open with no follow-up.
Testing and exercises	Assessor asks how the plan is tested, reviews exercise scenarios and results, and checks whether gaps found were fixed.	Exercise plans, scenarios, attendance, results and remediation tickets.	Tabletop exercises are described but not recorded, or results do not feed back into the plan.
Sampling	Assessor selects a sample of incidents or exercises across the assessment period rather than reviewing every event. Sampling rules sit in the assessment preparation guidance.	A complete, accurate incident register that the assessor can use to select samples.	Register is incomplete or events were closed without a record, which weakens the sample.

How to build an incident response process that passes domain 15

This sequence turns incident management from a written plan into a process an assessor can trace from roles and classification through detection, handling, lessons learned and exercises. Each step produces evidence that the process operates for the in-scope environment, not only on paper.

Assign incident roles and named owners
Name the incident commander, the technical responders, the communications lead and the executive decision maker, along with deputies for each role. Cover both the systems you run and the tenancy or applications you own, because HITRUST's inheritance example splits platform incidents from customer-side response. Record the assignments in an approved document with contact details and review dates. The assessor will look for a roster that matches the people who actually handled your most recent events.
Write the response plan for the in-scope environment
Document how the organization prepares for, detects, contains, eradicates and recovers from security events affecting the systems, data and access paths inside the assessed scope. Name the systems, log sources and third-party services the plan covers, and state which parts a provider handles under its own incident process. Approval by management and a reference to the plan from the policy set are what the assessor checks. Ask your assessor early which scope boundaries they expect the plan to mirror.
Define event classification and reporting paths
Create severity levels, examples of events in each level, and a reporting path that says who must be told, through which channel and within what internal timeframe. Include legal, contractual and regulatory notification triggers that apply to your data, and confirm the exact obligations with counsel rather than assuming them. The output is a classification matrix and a notification procedure that staff can follow without the plan in front of them. Keep the matrix consistent with what your ticketing and SIEM tools actually record.
Connect detection and triage intake
Route alerts from monitoring, endpoint and ticketing sources into one intake point where each alert can be accepted, merged, escalated or closed with a reason. Open-source case management such as DFIR-IRIS (LGPL-3.0-or-later) can hold each case as one record of assets, indicators, tasks and evidence with a full audit trail, and it accepts alerts from SIEM, EDR and REST sources. Automation tools such as Shuffle (AGPL-3.0-only) can start workflows from a webhook, schedule or manual run to create tickets and notify responders. The evidence is a sample of triaged alerts showing timestamps, owners and the decision taken.
Run handling with evidence preservation
For each confirmed incident, record actions in the case as they happen, including containment decisions, affected assets and communications. Preserve evidence with hashes and a documented chain of custody, so that logs and images can be shown to be unaltered later. DFIR-IRIS logs evidence with SHA-256 verification and chain of custody, which can support this step when configured. The assessor will check that handling records are complete, time-ordered and tied to the classification decided earlier.
Hold a post-incident review and track lessons learned
After closure, review what happened, why controls did or did not work, and how notification and recovery performed. Convert each finding into a tracked corrective action with an owner and a status, and feed relevant changes back into the response plan, classification matrix and related domain controls. The output is a written review for each material incident and an action log that shows items being closed. Assessors often sample these reviews, so keep them even for events that were contained quickly.
Exercise the plan and keep records
Run tabletop or technical exercises against the plan, using scenarios drawn from your own environment and past events. Record attendance, the scenario, the decisions made, the gaps found and the corrections assigned. Repeat exercises on a schedule you can justify in the plan itself. Confirm with your assessor which exercise evidence they expect, since expectations can differ between e1, i1 and r2 scopes.
Start evidence collection early and let it run
Begin producing evidence well before the validated assessment, because the process has to operate over time, not only exist on the day of fieldwork. Keep roster updates, classification reviews, alert triage records, case files, review minutes and exercise reports in one controlled repository. Ask your readiness partner or assessor to review a sample of records while there is still time to correct gaps. A process with only a few weeks of records is harder to defend than one with a steady history.

Which incident management evidence passes and how to keep it current

Assessors test 15 Incident Management by reading records, not policy statements. The artifacts below show that a plan exists, that people know their roles, that real events were handled and reported, and that lessons led to tracked fixes. Each one goes stale unless someone reviews and dates it between assessments.

Approved incident response plan

The plan is the document an assessor reads first. It should name the scope of systems it covers, the classification of events, the escalation path and the decision owner, and it should carry a version history showing who approved each revision and when. Check that the plan refers to the systems you run today, not the architecture from the last assessment. Schedule a review on a fixed cycle and after any significant change to the environment, and record the review even when no text changes.

Roster and contact paths

An incident team roster lists who responds, their backups, and how to reach them outside business hours, including vendors and any external responders you rely on. Assessors compare names on the roster with people who actually responded to recent records, so a departed engineer listed as primary is a visible gap. Refresh the roster at least when staff or vendor contracts change, and keep a dated copy so you can show what was in force at a given point in time.

Incident records with timelines

Each incident record should capture detection, triage, containment, eradication, recovery and closure, with timestamps and the person who took each action. A strong record shows the sequence of decisions, not only the final outcome. Confirm that records for events in the assessed environment are complete and consistent, and that any event that touched in-scope systems is recorded even when it was a false positive, since assessors look for the triage reasoning. Case management tools such as DFIR-IRIS keep these records as one case with an audit trail.

Internal and external reporting records

Keep records showing who was notified internally, when, and through which channel, along with any notification made to customers, regulators, contractual parties or law enforcement. Each record should identify the legal or contractual trigger that required the notice, so you can show the decision was made against a defined rule. Confirm your notification obligations with counsel and your contracts, because the required timelines and recipients differ by contract and jurisdiction. Store the sent messages, not only the decision to send them.

Post-incident reviews and tracked actions

A post-incident review explains what happened, why controls did or did not work, and what will change. Each corrective action needs an owner, a due date and a closure record that points to evidence of the change, such as a revised detection rule or an updated runbook. Assessors check whether actions from earlier events were closed, so an open action from a prior review is a common finding. Review the open action list on a fixed cadence and record closure with the date it was verified.

Exercise records

Tabletop and technical exercises show that the plan works under pressure. Record the scenario, the participants, the injects and decisions made, the gaps found and the actions raised, and date every exercise. A plan that has never been exercised is harder to defend than one with a dated exercise and follow-up actions. Plan exercises across the review cycle so that the most recent one falls within the assessment period, and keep the scenario script with the outcome.

What meeting incident management costs in money and effort

This table breaks the cost of the 15 Incident Management domain into components, showing who is paid, whether each cost is one-time or recurring, and what drives it. Use it to frame a written quote, since no fixed prices or durations are published here. The main takeaway is that open-source tooling reduces license spend, but staff time for integration, drills and evidence stays with the organization or its partner.

Cost component	One-time or recurring	What drives it and how to reduce it
Tooling and licenses	Recurring	Commercial case management and SOAR licenses scale with users, alerts or integrations. Self-hosted open-source options such as DFIR-IRIS and Shuffle remove most license spend, but hosting, storage and patching of those tools remain costs. Ask the quote to separate license, hosting and support lines.
Engineering time to wire detection into case handling	One-time, with ongoing upkeep	Cost rises with the number of alert sources (SIEM, EDR, REST) and the number of ticketing or firewall integrations. Connecting these sources to case records and automations is usually the largest one-time effort. Scope it as a fixed deliverable with named sources.
Playbook and workflow build	One-time, with periodic review	Each response procedure for a common event type needs a documented workflow and owner. Fewer, well-scoped playbooks for in-scope systems keep build effort down. Confirm who approves playbook changes.
Staff time for drills and tabletop exercises	Recurring	Frequency, number of participants and whether drills include the provider and the customer shape this cost. Staff pulled from operations to attend are an internal cost that rarely appears on an invoice.
Staff time for post-incident reviews and lessons learned	Recurring, event-driven	Cost follows the number and severity of security events in scope. Clear case records with timelines reduce review time. Ask who attends reviews and how corrective actions are tracked to closure.
Evidence upkeep	Recurring	Assessors expect incident records, timelines, chain of custody for evidence and review sign-off. Keeping these current across the assessment period is an ongoing task. Tools that keep audit trails and SHA-256 evidence verification in the case record reduce manual collection.
External testing or review of the response plan	Recurring or per engagement	Independent exercises, red team scenarios or plan reviews are priced by scope and frequency. Agree in writing which scenarios are tested and what report the organization receives.
Assessor fees for the validated assessment	Recurring, per assessment cycle	Only Authorized HITRUST External Assessor organizations may perform validated assessments submitted for certification. Fees depend on scope, number of assessed domains and sampling. Request the assessor's fee breakdown and the fieldwork window, which HITRUST's Assessment Handbook v1.1 sets at most 90 days.
Implementation partner services	One-time, with optional retainer	A partner can configure tools, build integrations and prepare evidence. It does not issue reports or certificates. Most engagements are fixed-scope, so ask for written deliverables, timelines and what the organization must supply.

Which self-hosted open-source tools can support incident evidence

Two self-hosted open-source tools can hold the records an assessor asks for in incident management: case records, alert triage, evidence handling and automated workflows. They support the evidence, but they do not make your incident process compliant. Your team still owns the response plan, its roles and the decisions made during each event.

DFIR-IRIS case management

DFIR-IRIS (LGPL-3.0-or-later) keeps each incident as one case that links assets, indicators of compromise, tasks and evidence, with a full audit trail of who changed what. It triages alerts from SIEM, EDR and REST sources into cases, builds a consolidated investigation timeline, and logs evidence with SHA-256 verification and chain of custody. Before you deploy it, confirm that the audit trail and evidence hashes meet your retention and reporting expectations, and have counsel review the LGPL terms for your use.

Shuffle event-driven workflows

Shuffle (AGPL-3.0-only) runs event-driven workflows that start from a webhook, a schedule or a manual run. Its app nodes can perform actions such as scanning a file or posting to chat, and connect tools such as a SIEM, a ticketing system and a firewall, according to its documentation. Each automated step creates a record that can support your response timeline, but you must document which steps are automated, who approves them and how failures are handled. Have counsel review the AGPL-3.0-only obligations before you offer modified workflows to users outside your organization.

Who owns incident management, who helps and who verifies it

Your organization owns domain 15 in full. HITRUST expects the organization to own its controls, so the incident response plan, the authority to act during an event and the staff time to run it must sit with your people, not with a vendor. Leadership should name who can declare an incident, who can take systems offline and who signs off on external communication before an event happens, not during one.

Plan ownership: A named role maintains the incident response plan, approves changes and records each review date.
Decision authority: Someone with authority declares incidents, sets severity and decides on containment, including taking production systems offline.
External notifications: Legal, privacy and executive roles decide regulator, customer and law enforcement notices. These decisions are not outsourced.
Staff time: Responders, on-call engineers and application owners need protected time for drills, reviews and post-incident work.
Lessons learned: Your team tracks corrective actions from each event to closure.

Check that the people named in the plan are the people who actually hold these duties today, and that they have signed or accepted their roles.

Where incident management assessments usually fall short

Incident management is scored on evidence that the plan works in practice, not only that it exists. The gaps below are the ones that most often leave a domain thin when an assessor samples records. Each card names one gap and one closure step you can complete before fieldwork begins.

Plan never exercised

An incident response plan that has never been run against a realistic scenario gives an assessor nothing to sample. Assessors look for evidence that the plan was used, such as a tabletop exercise with a dated agenda, attendee list and recorded decisions. Run at least one scenario covering the in-scope environment and retain the minutes, injects and action items. Illustrative: a team that walks through a ransomware scenario and records who declares the incident and who contacts the provider will have far stronger evidence than a plan document alone.

No dated post-incident review

Lessons learned only count if the record shows when the review happened, who attended and what was decided. Many teams hold useful discussions but keep no artifact, so the assessor cannot tie the review to a specific incident. For each closed case, store a review record with date, participants, root cause and open actions in the case system. Confirm that the case tool keeps an audit trail that survives editing.

Third-party incidents without a notification path

When a cloud provider, SaaS vendor or managed service has an incident that affects your data, the organization still needs to know who tells whom and how fast. Gaps appear when contracts name no contact, the vendor's status feed is unmonitored, or no internal owner is assigned. Document the notification path in the incident plan, list the vendor contacts and confirm that the contract includes a notification obligation. Review it alongside your third-party assurance records.

Detection sources not connected to cases

Alerts from a SIEM, endpoint tool or firewall that never reach a case record cannot be shown to have been triaged. Assessors often trace a sampled alert forward to a ticket or case and find nothing. Connect each in-scope detection source to the case management platform, and map each alert type to a triage owner and a timeline. Confirm that the case record links back to the original alert identifier.

Lessons learned that change nothing

A review that produces no control change looks like a formality to an assessor. The organization should be able to show at least one case where a finding led to a configuration change, a new detection rule or a training update, with the change record linked to the incident. Track each lessons-learned action as a task with an owner and a closure date, and retain the change request that closed it. Illustrative: a missed phishing report that results in a new mailbox rule and a training module, both linked to the case.

AI security incidents left out of scope

HITRUST's AI security assessment places AI security requirement statements in this domain, so an incident plan that covers only traditional events leaves those requirements unanswered. Extend the plan to cover model misuse, prompt injection, data leakage through AI tools and unsafe agent actions, with defined triggers and responders. Confirm the AI security certification scope with your assessor before writing the extension, since the requirement wording is proprietary and is not reproduced here.

What buyers and practitioners ask about incident management in HITRUST

How much effort does incident management need from our team for a HITRUST assessment?

The effort depends on how mature your incident response process already is and how much of it you can show as operating evidence. Your team owns the incident response plan, the roles, the escalation paths and the records of real or tested events. Most of the work sits in proving that the process runs: tickets, post-incident reviews, lessons learned and evidence that the plan was exercised. Teams that already run a documented process usually spend their effort collecting and organizing records. Teams without one spend more time writing the plan, assigning owners and building a track record before the assessment window opens. Ask any partner to estimate effort by requirement statement in the written scope, not as a single headline figure.

Can we run HITRUST incident management in-house without an outside partner?

Yes, an organization can prepare its incident management domain internally, and many do. Only an Authorized HITRUST External Assessor organization can perform the validated assessment submitted for certification, so outside help is never a substitute for the assessor. Internal teams often handle the plan, the playbooks, the ticketing records and the evidence index. Outside help is most useful when the team has no recent experience with the assessment's evidence and sampling expectations, or when the same staff run live incidents and cannot also build the evidence trail. Decide the split in writing: what your staff own, what a consultant or implementation partner prepares, and what the assessor tests.

How long is the fieldwork window, and how should it shape our schedule?

The assessor's validated assessment fieldwork window is at most 90 days for e1, i1 and r2 assessments. That limit covers the assessor's testing period, not the time you spend preparing. Incident management evidence needs to exist before fieldwork starts, because assessors test records that were created in the past. Plan your preparation so that the plan, roles, tooling and at least a sample of incident records are in place early enough for the assessor to sample them within the window. Agree the fieldwork dates with your assessor in writing, and confirm how evidence requests are handled during that period.

Does a security incident affect our existing HITRUST certification?

It can. HITRUST certification letters state that HITRUST may investigate and revoke a certification if a security event results in unauthorized access to the assessed environment. A security incident does not automatically revoke a certification, but the outcome depends on whether the event affected the in-scope environment and what the investigation finds. Keep your incident records complete and time-stamped, notify your assessor and the parties that rely on your certification according to your contracts and the rules of your program, and confirm with HITRUST what reporting applies to your assessment type. Treat this as a question to confirm for your own certification, since the outcome depends on the facts of the event.

Is incident handling inherited from our cloud provider enough for this domain?

Usually not on its own. In HITRUST's OCI inheritance example, incident management is moderately inheritable: the provider handles incidents on its platform, while the customer runs an incident response plan for its own applications and tenancy. That means you can inherit the provider's platform-side results, but you still need your own plan, your own detection of events in your workloads and your own records of handling them. Map the split in a shared responsibility matrix, and confirm with your assessor which parts you can rely on and which you must evidence yourself.

What should we ask a partner or assessor for in a written scope?

Ask for a scope that names the assessment type, the in-scope systems and the incident management requirement statements that apply, including any AI security requirements added through the AI security certification. The written scope should state what the partner prepares, what your staff own, which evidence will be produced and in what format, and how sampling will work. Request the deliverables, the review points, the assumptions about your environment, and the process for changes in scope. Ask who performs the validated assessment and confirm that any assessor is an Authorized HITRUST External Assessor. DeployOpen plans and prepares systems, controls and evidence for assessments, and does not issue reports or certifications; the scope should make that split explicit.

How DeployOpen scopes and prepares incident management evidence

DeployOpen works on 15 Incident Management as part of a wider HITRUST readiness effort, starting from the systems and tooling already in your environment. The work is limited to what the written scope covers, and the organization keeps ownership of its incident response program and its certification decisions.

How we scope

Confirm which platforms, tenancies and applications in the assessed environment fall under incident management responsibilities.
Record which incident response duties the organization keeps and which a cloud or hosting provider handles under shared responsibility.
Agree in writing the systems, deliverables and timelines for incident intake, triage, investigation and reporting before work starts.

How we build

Deploy self-hosted case management, alert intake and investigation tooling inside your own infrastructure, such as DFIR-IRIS for case records.
Configure automated response workflows, for example with Shuffle, that route alerts from SIEM, EDR and ticketing tools into cases.
Set up evidence handling with hashing, chain of custody and audit trails so that incident records can be shown to an assessor.

How we hand over

Document the incident response plan, reporting paths and lessons learned process in terms your assessor can trace to requirement statements.
Deliver test records from tabletop or simulated incidents that show the plan was exercised and that the evidence was captured as designed.
Walk your team through runbooks, tool administration and the evidence collection routine so the program runs after the engagement ends.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer, where the written agreement defines the services.
Keep incident tooling current and reassess evidence coverage when the CSF version or the assessed scope changes.
Confirm with your independent assessor which evidence they will sample, since DeployOpen prepares evidence but does not issue any HITRUST report or certification.