164.308(a)(6) Security incident procedures guide

What 164.308(a)(6) security incident procedures require in practice

In short, 164.308(a)(6) requires you to have written policies and procedures for security incidents, and to show that you identify and respond to suspected or known incidents, reduce their harmful effects where practical, and document each incident and its outcome. The standard has a single implementation specification, response and reporting, which is required rather than addressable. If a compliance lead is preparing for an assessment, the question is rarely whether a policy exists. It is whether the organization can produce a record for an actual event that shows what was detected, who acted, what was contained and what was learned.

The definition is broader than most teams expect. Under 164.304, a security incident includes attempted unauthorized access, use, disclosure, modification or destruction of information, as well as interference with system operations. That means blocked brute-force attempts, rejected malicious requests and failed intrusion attempts fall inside the standard, not only successful breaches. Because the rule is short, examiners test it through incident records instead: the log of alerts triaged, the tickets opened, the containment steps taken and the closure notes. Teams often find three gaps when they try to produce those records. The organization has no defined boundary for what counts as an incident, so triage decisions are inconsistent. Logs from firewalls, endpoints and identity systems cannot be tied to a single case. And the response plan has never been run as a drill, so its steps are untested when a real event arrives.

A practical first step is to decide, in writing, the threshold for opening an incident record and to confirm that every alert source feeds into one case-tracking place with a timestamp and an owner. Then run a tabletop exercise against the plan and keep its outputs as evidence. Confirm with your counsel and your business associates how incident reporting obligations under 164.314(a)(2) flow into your contracts, since those duties interact with breach notification. The 2025 proposed revision would make written response plans reviewed and tested every 12 months, but it has not been finalized, so treat that cadence as a planning assumption, not a current requirement. The NIST SP 800-66 Rev. 2 resource guide offers sample questions to test whether your procedures are complete.

Which systems, events and parties fall inside security incident procedures

Security incident procedures under 164.308(a)(6) reach further than the servers that hold ePHI. The scoping choices below decide which systems, which events and which outside parties your response and reporting procedures must cover, and each one changes the work your team takes on.

ePHI systems and their security tooling

Scope starts with every system that creates, receives, maintains or transmits electronic protected health information, including databases, file shares, interfaces and backups. Scope also has to include the security tooling and identity systems that record activity on them, such as log collectors, EDR agents, directory services and firewalls. An intrusion that reaches an identity provider can expose ePHI without touching the database itself, so omitting these components leaves a gap in detection and in your documented incident history. Ask which systems your risk analysis lists as holding ePHI and confirm each one has a named owner.

Attempted events, not only successful ones

Under 164.304, a security incident includes attempted unauthorized access, use, disclosure, modification or destruction, and interference with system operations, not just the successful ones. That means repeated failed log-ins, blocked port scans and malware quarantined at the gateway can all fall inside your procedures. Decide which attempted events you will triage, which you will only count, and how each is documented. A procedure that records only confirmed compromises will not show the identification and response activity the standard asks you to document.

Identification sources that feed triage

Identifying a suspected incident depends on what you collect. Log sources from hosts, network devices, cloud services and endpoints determine whether an event can be seen at all. Decide which sources feed your detection and which alerts create a case for review. Confirm that each source is retained long enough for an investigation to reconstruct what happened, and that the same events appear in the record you will later use for the documentation required under this standard.

Business associates and subcontractors

Under 164.314(a)(2)(i)(C), business associate contracts must require the vendor to report security incidents it becomes aware of to the covered entity, including breaches of unsecured PHI under 164.410. Your procedures therefore cover incidents that happen inside a hosting provider, billing company or managed IT firm. Check that each contract sets a reporting obligation, that subcontractors flow the duty down, and that your intake process can accept a vendor report and open a case without delay.

Clearinghouse functions inside a larger organization

If a health care clearinghouse operates inside a broader organization, its ePHI and the security events that touch it need to be visible to the same incident process. Decide whether the clearinghouse has its own log sources, its own responders and its own reporting path, or whether it shares them with the parent. Either model can work, but the documented procedures must say which one applies so that an incident in one unit is not handled as if it belonged to another.

Who decides an event is an incident

The scope also includes the people and roles that classify events. Name the person or team who decides whether an alert is a security incident, who decides mitigation steps, and who records the outcome. Their authority should reach vendor-hosted systems and shared identity services as well as internal ones. Without a named decision point, incidents at the edge of your scope tend to be closed as routine alerts and never reach the documentation the standard requires.

How an assessor tests incident procedures and what passes

This table walks through each step an assessor takes to test 164.308(a)(6), from the written policy to the incident records and contracts behind it. Read each row as a test with the evidence requested, the result that passes and the gaps assessors most often write up. NIST SP 800-66 Rev. 2 is informational guidance, not a legal requirement, so it supports the approach rather than setting the bar.

Assessor step	Evidence requested and what passes	Common findings
Review the written policy and procedures	Written incident response policy and procedures that define a security incident as in 164.304, assign roles and describe how staff identify, respond and report. Passes when the document is current, approved and matches how the organization actually responds.	Policy copied from a template and never adopted; definition of security incident omits attempted events; no named owner.
Interview the security official and on-call staff	Consistent answers on who triages alerts, who decides escalation, and how a suspected incident reaches the response team after hours. Passes when people describe the same steps the written procedure states.	On-call staff unaware the procedure exists; security official cannot name the reporting path; escalation depends on one person.
Sample incident records	A sample of tickets, case files or log extracts covering both high and low severity events. For each record, the assessor checks evidence of detection, response actions, mitigation of known harm and the documented outcome. Passes when every sampled record shows all four elements.	Records show detection but no outcome; mitigation steps missing; incidents closed with no root cause or affected-system note.
Check the incident log for completeness	Full incident register covering attempted and successful events, not only those escalated. Passes when the log shows how minor events were triaged and why they were closed.	Low-severity incidents handled in chat and never recorded; gaps in dates or case numbers; attempted intrusions dismissed without a record.
Review tabletop and post-incident records	Exercise reports, after-action notes and changes made to the plan after real events. Passes when lessons from exercises or incidents appear as dated updates to the procedure, consistent with the post-incident analysis NIST SP 800-66 Rev. 2 describes.	Policy never tested; tabletop held once with no follow-up actions; post-incident reviews not linked to plan updates.
Check business associate contracts	Business associate agreements that require the vendor to report security incidents it becomes aware of, including breaches of unsecured PHI, as 164.314(a)(2)(i)(C) requires. Passes when the clause is present in each contract and the vendor's contact path is known.	Older agreements missing incident reporting language; no defined timeframe or contact; vendors not included in tabletop exercises.
Confirm evidence of retention and access	Proof that incident documentation is kept and can be retrieved for review. Confirm the retention period and storage location with your own compliance counsel, since the rule's six-year documentation retention applies to policies and required documentation under 164.316.	Incident records stored in personal mailboxes or chat channels; no retention rule; records cannot be produced on request.
Confirm the tools that produce the evidence	Ask which detection, case management and logging tools generate the records above, and confirm that the audit trail and exports are available before the assessment begins. Passes when the organization can show the tool output used to build each sampled record.	Alerts exist in a tool that cannot export history; case notes edited without an audit trail; no evidence that the tool was running during the review period.

How to build incident procedures that an assessor can follow

This sequence turns the single required specification of 164.308(a)(6) into a working set of goals, roles, procedures, records and reviews, so an assessor can trace each suspected incident from detection to documented outcome. Each step ends with a named artifact the organization can produce on request.

Set the goals of incident response
Start by writing down what the incident procedures must achieve for your environment: detecting suspected and known security incidents, responding to them, limiting harm to ePHI where that is practicable, and keeping a record of each incident and its outcome. Tie these goals to the systems that hold or can reach ePHI, using the risk analysis as the input. The output is a short, signed statement of goals that the security official and senior leadership approve, which becomes the opening section of the incident response policy.
Define what counts as a security incident
Adopt the regulatory definition in 45 CFR 164.304 as the baseline, then describe how your staff will recognize attempted and successful unauthorized access, use, disclosure, modification or destruction of information, and interference with system operations. Include examples drawn from your own systems, such as repeated failed log-ins, unexpected data exports or ransomware encryption. The output is a written incident definition with a triage matrix that rates events by impact and urgency, so that the same event is classified the same way by different responders.
Name the response team and its roles
Assign a named incident lead, technical responders, a privacy or compliance contact, legal counsel, communications, and the people who can authorize containment on production systems. Where you use a managed provider or retained responders, document who they are, what they may do without further approval, and how they reach your lead. Publish the escalation path with contact methods and backups for each role. The output is a roster and escalation chart that an assessor can check against the people who actually answered the last alert.
Write procedures for each response phase
Write one procedure for each phase: identification, containment, mitigation of harmful effects, eradication, reporting, and documentation. Each procedure should name the trigger, the responsible role, the actions in order, the approval needed, and the record created. Reporting procedures must route to the business associate contract terms and to breach assessment steps where ePHI is involved. The output is an approved runbook set, with a checklist per incident type such as phishing, lost device or ransomware.
Connect logs and alerts to a case record
Configure detection sources so that alerts from endpoint, network, identity and cloud logs reach a single case record. Open-source platforms such as DFIR-IRIS can hold assets, indicators, tasks, evidence and a timeline in one case with an audit trail, while detection engines such as Wazuh or OpenSearch Security Analytics can generate the alerts that open those cases. Confirm each integration in your own environment, and test that a sample alert produces a case with the required fields. The output is a working alert-to-case flow and a documented list of log sources, each tied to the systems in your risk analysis.
Preserve evidence and document outcomes
Require that evidence collected during an incident is hashed, logged and held under chain of custody, so that the record can support later findings, legal review or breach analysis. Record the decisions made, the times they were made, and the final outcome, including whether ePHI was involved and what mitigation was applied. Ask your tooling vendor to confirm how evidence hashing and audit trails are implemented before relying on them in a dispute. The output is a closed case file template that an assessor can read without interviewing the responder.
Run the post-incident review
After each significant incident and after each test, hold a review that asks what happened, why detection or response was slow or incomplete, and what must change in policy, tooling, training or contracts. Record the review and the specific updates made to the incident procedures, risk analysis or business associate agreements. NIST SP 800-66 Rev. 2 describes post-incident analysis as feeding back into updates. The output is a review record linked to each change, with an owner and a completion date for each action.
Test the plan and keep the evidence
Run tabletop exercises and technical drills against realistic scenarios involving ePHI systems, and confirm that the roster, escalation path and case flow work as written. Keep the test plans, participant lists, results and remediation items. The January 2025 proposal would require written incident response plans to be reviewed and tested at least every 12 months, but that change is not final, so set your own test cadence in the policy and confirm it against the rule once finalized. The output is a dated test record that shows the procedures were exercised, not only written.

Evidence that satisfies incident procedures and how to keep it current

Under 164.308(a)(6), the evidence an assessor or OCR investigator asks for is a set of connected records: the policy, the people, the case log, the containment work, the lessons learned and the tests. Each artifact below needs a routine owner and a dated trail so it stays accurate between audits.

Written incident response policy and procedures

This is the document that sets how your organization identifies, responds to, mitigates and documents security incidents affecting ePHI, and it is the first thing a reviewer reads. Check that it defines a security incident using the definition in 45 CFR 164.304, names the systems in scope, and points to who decides what. Keep a revision history with dates, approvers and the reason for each change. Review it at least once a year and after any material incident or system change, and confirm that staff can find the current version.

Response team roster and escalation contacts

A named roster shows who identifies, triages, contains and reports incidents, and who backs them up when people are unavailable. Include security, IT operations, privacy, legal, communications and the business associate contacts you depend on, with out-of-hours numbers. Record the escalation path from first alert to the security official. Verify contact details on a schedule, for example each quarter, and log each check with the date and the person who made it so an assessor can see the roster was current when incidents occurred.

Incident case log with timestamps

The case log records every suspected or known incident with the time it was detected, the actions taken, the owner of each action and the outcome. Entries for events judged not to be incidents matter as much as confirmed ones, because they show the team screened alerts and made a documented decision. Confirm that timestamps are synchronized across sources, that entries are append-only, and that closed cases carry a disposition. Reconcile the log against alerts from your SIEM or detection tools each quarter to find gaps.

Mitigation and containment records

These records show that known incidents were mitigated to the extent practicable, as the required specification asks. For each incident, capture what was isolated or disabled, which accounts were reset, which evidence was preserved and what harmful effects were confirmed or ruled out. Where evidence is handled, record hashes and chain of custody. Ask whether containment steps were checked against the risk analysis and whether any exposure of PHI triggered the separate breach assessment in 164.410 and the notification steps that follow.

Post-incident reviews and procedure changes

A post-incident review explains what happened, why controls did not stop it, and which procedures, detections or training changed as a result. NIST SP 800-66 Rev. 2 describes incorporating post-incident analysis into updates to the response policy, so link each review to a dated change in the procedure it affected. Track open actions to closure with owners and due dates. Review the list each quarter to confirm that recurring root causes have a documented fix rather than repeated write-ups.

Tabletop and test records

Test records prove the procedures work in practice, not only on paper. Keep the scenario, participants, start and end times, decisions made, gaps found and the follow-up tasks from each tabletop or technical exercise, such as a restore test or a simulated alert triage. Store the results next to the policy version that was tested. Schedule exercises at a defined frequency set by your risk analysis, and confirm that findings flow into the case log and the revision history.

Which open-source tools produce incident evidence

DFIR-IRIS is an open-source incident response case management platform licensed under LGPL-3.0-or-later. It is most useful after an alert or report has been raised, because it holds the working record of an incident in one place. Analysts can open a case, attach affected assets and indicators of compromise, assign tasks, and keep the evidence that supports each decision. For the documentation element of 164.308(a)(6)(ii), the case itself is the evidence trail.

One case record: Assets, IOCs, tasks and evidence sit in a single case, so the file shows what was known and when.
Full audit trail: Changes to the case are logged, which helps show who did what during the response.
Alert triage: Alerts from SIEM, EDR and REST sources can be triaged into cases for review.
Consolidated timeline: The platform builds an investigation timeline from case data, supporting the record of outcomes.
Evidence integrity and reports: Evidence is logged with SHA-256 verification and chain of custody, and reports are generated from case data.

Confirm the LGPL-3.0-or-later terms with your legal team, and check the DFIR-IRIS documentation to verify that the alert sources, evidence handling and report formats match your environment before relying on them.

What meeting incident procedures costs in money and effort

This table compares the cost components of running security incident procedures under 164.308(a)(6), showing who is paid, whether each cost is one-time or recurring, what pushes it up, and what to request in writing. No cost figures are given because none were supplied; use the drivers and quote questions to build a comparable estimate. Open-source tooling removes license fees but not the staff time to operate it.

Cost component	One-time or recurring, and who is paid	What drives it up	What to ask for in a quote
Tooling and licenses	Recurring if commercial. Open-source tools such as Wazuh and DFIR-IRIS carry no license fee but still need hosting, storage and upkeep.	Number of log sources, retention period, indexer storage volume, number of case-management users.	Itemized licenses or subscriptions, hosting assumptions, storage sizing by log source, and who patches and upgrades the platform.
Engineering time to build detection and case workflow	One-time for initial rules, playbooks and case templates, then recurring for tuning. Paid to internal staff or an implementation partner.	Number of systems in scope, custom rules needed for ePHI applications, integration with ticketing and identity systems.	Fixed-scope deliverables listing detection use cases, case workflow steps, integrations and acceptance tests, with a written timeline.
Ongoing log review and triage staffing	Recurring. Paid to internal security operations staff or an outsourced monitoring provider.	Alert volume, hours of coverage, false positive rate after tuning, number of covered entities and business associates feeding logs.	Hours of coverage assumed, alert triage levels and escalation paths, staffing model, and the monthly report format.
Documented incident response plan and procedure writing	One-time to draft, recurring to review. Paid to internal compliance or security staff, or an outside consultant.	Number of business associate reporting paths, number of regulated sites, complexity of the escalation chain.	Named deliverables for the written procedure, the reporting matrix, and the review schedule it will follow.
Tabletop exercise time	Recurring, usually at least annual in practice. Paid through staff hours and facilitator fees if external.	Number of scenarios tested, number of participants including executives, business associates invited to join.	Facilitator qualifications, scenario scope, participant list, and a written after-action report with corrective actions.
External incident response retainer or forensic support	Recurring retainer plus per-engagement charges when an incident occurs. Paid to an outside forensic firm.	Scope of affected systems, volume of evidence to collect, whether legal counsel must be engaged, response hours included.	Retainer terms, included hours, rate card for additional work, response time commitments as written, and conflict-of-interest handling.
Assessor time for sampling	Recurring at each assessment. Paid to the independent assessor or auditor, not to the implementation partner.	Number of incidents in the review period, number of sites and systems sampled, quality of existing documentation.	Sampling approach, documents requested in advance, and whether the assessor will issue a report or only findings.

Who does what: your team, a partner and the auditor

Your organization owns the security incident procedures under 45 CFR 164.308(a)(6). The Security Rule places the duty to identify, respond to, mitigate and document incidents on the covered entity or business associate, and no outside party can take that duty over. The people who hold it are the security official, the leaders who approve the policy, and the staff who run the response when an alert turns into an incident.

Incident response policy: Your leadership approves the written policy and procedures, sets who may declare an incident, and decides how the policy is reviewed.
Security official role: The named security official under 164.308(a)(2) answers for how incidents are handled, escalated and documented.
Notification decisions: Your privacy and legal functions decide whether an event is a breach, run the four-factor risk assessment, and make any notice to individuals, media or HHS.
Business associate contract terms: Your contracts must require vendors to report security incidents they become aware of, including breaches of unsecured PHI, as 164.314(a)(2)(i)(C) requires.
Records and outcomes: Your staff keep the incident documentation, including the outcome of each incident.

Confirm internally who holds each of these roles and who can sign off a notification decision before any partner starts work.

Where incident procedures usually fall short and how to close each gap

Most incident procedure failures are not missing documents. They are definitions that exclude attempts, responses that leave no record, and plans that never get tested or updated. Each card below names one gap, what it looks like in practice, and the evidence that closes it under 164.308(a)(6).

No written definition of incidents

Many policies define a security incident as a confirmed breach, which leaves out the attempted access the rule covers. Under 45 CFR 164.304, a security incident includes attempted unauthorized access, use, disclosure, modification or destruction, and interference with system operations. Check that your policy uses this definition, that staff can state it, and that failed log-in bursts and blocked scans are routed into the same intake path as successful events.

Incidents closed in chat

When a suspicious login is handled in a chat thread or a phone call, the response may be sound but no one can later prove what happened. The rule requires documenting incidents and their outcomes, so the record has to exist outside someone's memory. Require a ticket or case for every suspected incident, with timestamps, actions taken, the person who decided to close it and the reason. Sample a month of closed tickets against chat logs to confirm the record is complete.

Procedures never exercised

A response plan that has never been run tends to fail on its first real use, usually at the handoff between IT, legal and the security official. Run tabletop exercises that walk through a ransomware event and a lost laptop with PHI on it, and record who was paged, how long containment took and which step stalled. Feed each finding back into the procedure. The 2025 proposal would require annual testing of written plans, which is still a proposal as of October 2026, so treat it as a planning benchmark rather than a current duty.

Log sources missing from cases

Incident response depends on the telemetry reaching the case. If endpoint, identity, cloud and network logs feed separate consoles, responders reconstruct events by hand and small activity disappears from the record. Map each system that holds or touches ePHI to the log source that covers it, then confirm that alerts from a SIEM or detection platform open cases automatically. Open-source case management tools such as DFIR-IRIS can ingest alerts from SIEM and EDR sources and keep a single timeline with evidence hashes and a chain of custody.

Business associate contracts without reporting terms

A covered entity can lose sight of an incident that happened inside a vendor's environment if the contract never requires reporting. The rule requires business associate contracts to oblige the vendor to report security incidents it becomes aware of, including breaches of unsecured PHI. Review every BAA for a defined reporting window, a named contact, the content of the report and cooperation duties. Ask each vendor for its own incident procedure and how it notifies customers, and record the answers in your vendor file.

Post-incident reviews that change nothing

Post-incident analysis is only useful when its findings flow back into the policy, detection rules and training. NIST SP 800-66 Rev. 2 treats lessons learned as an input to updates, yet many organizations write a closing memo and never revise anything. For each incident, record the root cause, the control that failed, the policy or rule changed as a result, and the date it took effect. Review the last several incidents to confirm that at least one tangible change traces back to each.

How much work does 164.308(a)(6) take, and what should we do ourselves?

Does a HIPAA certification prove we comply with 164.308(a)(6)?

No. HHS states that no Security Rule standard requires an entity to certify compliance, that HHS does not endorse or recognize private certifications, and that a certification does not stop HHS from later finding a violation. For 164.308(a)(6), what counts is whether your written incident procedures exist, are followed, and leave a documented record of each incident and its outcome. Any outside assessment, including one labeled a HIPAA certification, is a point-in-time opinion about that evidence, not a finding of compliance. Ask any provider which independent assessment they performed, who issued it, and what it covered.

How long does it take to build incident response procedures under the Security Rule?

No fixed duration applies to this standard, so the honest answer depends on the starting point. The work is driven by how many systems hold ePHI, how much logging already exists, whether a security incident response team is already defined, how many business associates and subcontractors need reporting terms, and how many approval rounds your legal and privacy functions require. An organization with centralized logs and an existing incident process typically has less to write and test than one that starts with neither. Ask any partner for a written schedule that lists each deliverable and the review gates before work begins.

What does the incident response work require from our own staff?

Several roles need named owners before any outside party starts. You need an accountable security official, a response lead who can declare an incident, an owner for legal and privacy review, and someone who controls log access for the systems holding ePHI. Responders need read access to authentication, endpoint and network logs, plus a way to preserve evidence. Plan calendar time for tabletop exercises with the people who will actually respond, and for a post-incident review after each real event. Expect these commitments to recur every year, not only during the first build.

Can our team write and run the incident procedures in-house?

Often yes, if you have staff who understand both the Security Rule and your technical environment, and if leadership will give them time. The Security Rule asks for documented procedures, not a specific format, and NIST SP 800-66 Rev. 2 provides informational key activities and sample questions that many teams use as a checklist. In-house work usually struggles in three places: mapping ePHI systems completely, testing the plan under realistic conditions, and keeping the documentation current after staff and systems change. Decide early which of these you will do yourselves and which you will buy as a fixed-scope piece.

What should we ask a partner to include in a fixed-scope quote?

A usable quote lists each deliverable, the systems in scope, and what you must supply. Ask for the following in writing:

The list of ePHI systems and log sources covered, and which are excluded
The procedure documents, response roles and escalation paths to be produced
How tabletop exercises are run, how many, and who must attend
What evidence is handed over, such as incident logs, exercise reports and revision history
Which steps your staff must perform, and the dates by which they must do so
Which items are one-time work and which are recurring support

DeployOpen plans, implements and documents these systems inside your environment under a fixed scope agreed in writing before work starts. It does not issue audit reports or certifications, so any assessment remains with an independent auditor you select.

Does the 2025 proposed rule change the incident response work?

It could. HHS proposed a major Security Rule revision on January 6, 2025 (90 FR 898), and that proposal would require written security incident response plans that are reviewed and tested at least once every 12 months. As of October 2026, that proposal is not a final rule, and the latest Unified Agenda lists final action as projected for July 2027. Today's obligation remains the existing standard. Build your procedures so that an annual review and test cycle can be added without rewriting them, and track the rulemaking through the Federal Register and your counsel.

What does a breach notification assessment add beyond this standard?

Standard 164.308(a)(6) covers identifying, responding to, mitigating and documenting security incidents. A breach notification assessment asks a separate legal question: whether an incident is a breach of unsecured PHI that triggers notification duties to individuals, the media and HHS, and how fast those steps must happen. That analysis uses a four-factor risk assessment and the rules in the breach notification provisions, which are distinct from the incident procedures. Your incident records are the main input to it, so the two should share one case record. Confirm the notification analysis with qualified counsel rather than assuming the incident team can make it alone.

How DeployOpen prepares incident procedures and evidence

DeployOpen helps organizations prepare the incident procedures and records that 164.308(a)(6) Security incident procedures calls for, inside the client's own infrastructure. The organization keeps ownership of its policies, response decisions and reporting, while DeployOpen plans, implements and documents the supporting systems and evidence.

How we scope

Engagements are fixed-scope, with the systems, log sources and response workflows agreed in writing before work starts.
The written scope names which incident types, tools and business associate reporting paths are covered for 164.308(a)(6).
Scope also states what the client owns, including the response team, reporting decisions and any outside counsel or forensic firm.

How we build

Detection content is configured on self-hosted platforms such as Wazuh and OpenSearch Security Analytics, tuned to the client's log sources.
Case management is set up in DFIR-IRIS so each incident keeps assets, indicators, tasks and evidence in one audit trail.
Test scenarios are run against the configured workflow so the client can show that detection and escalation work as documented.

How we hand over

Deliverables include written incident response procedures, case templates and a record of what was configured and tested.
Each incident record format is documented so reviewers can trace detection, response, mitigation and outcome for each event.
Handover covers how to export case reports and where records are retained, so the client can present them to an independent assessor.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Procedures can be reviewed and retested on a schedule the client sets, as part of the post-incident analysis the rule expects.
Confirm with DeployOpen during scoping which support terms and testing cadence apply to your environment.