What NIST SP 800-53 IR-3 asks for and why assessors test it
IR-3 requires the organization to test the effectiveness of its incident response capability at a defined frequency, using tests the organization itself defines. If a moderate or high system is in scope, the compliance lead needs a test schedule, a test plan for each exercise and records showing what was tested, what failed and what changed afterward. IR-3 is not in the low baseline, so a low-impact system does not need it, but the privacy control baseline does include it. The NIST discussion names several test types: checklists, walk-through or tabletop exercises, and parallel or full-interrupt simulations. A tabletop walks responders through a scenario in a meeting room, while a full-interrupt simulation disrupts live operations to see how the team really responds. Choosing the mix is a decision the organization owns, and it should match the risk the system carries.
The control is often hard to satisfy for two reasons. The first is tests that never produce findings. A tabletop where everyone agrees the plan works, or a checklist that is ticked off without anyone trying the tooling, gives an assessor little reason to believe the capability functions under pressure. The second is a missing link between results and the plan. Assessors look for after-action reports that record gaps, owners and due dates, and then for evidence that the incident response plan, playbooks or contacts were updated as a result. Before scheduling anything, confirm with your authorizing official or assessor how they expect the frequency to be defined and documented, since the frequency is set by the organization rather than by NIST.
An assessor under SP 800-53A examines the test program, the test material and the results, and interviews the people who run the tests. Practically, prepare a dated test plan, the scenario and injects used, attendance, the after-action report and the tracked remediation items. If you use DFIR-IRIS to hold case records, its case timeline and audit trail can help show how a simulated incident was worked, but the test plan and after-action results still have to be written and approved by your organization. Independent assessors make the final determination, and an implementation partner can help prepare the test program and evidence without issuing any assessment result.
Which systems and teams IR-3 applies to in your environment
IR-3 is not a low baseline control, so the first scoping decision is which impact level your systems carry. Once that is settled, the test scope follows the systems, responder teams and third parties that the incident response capability depends on, and the tests must connect to the related controls that share its evidence.
Systems in moderate, high and privacy scope
IR-3 is allocated to the moderate and high baselines and to the privacy baseline, but not to low. Confirm the impact level recorded for each system in its security categorization, then list which systems carry IR-3 into the test plan. A system at low impact may still hold personal information that falls under the privacy baseline, so check that separately before excluding it.
Enhancement IR-3(2) in scope
In SP 800-53B, the moderate and high baselines add IR-3(2) to the base control. Its coordination of testing with related plans and organizational elements is part of what an assessor expects to see. Test records for moderate and high systems should show that exercises were coordinated with the contingency and other responsible groups, not run in isolation by the security team.
Responder teams and their roles
Every team with an incident role, including the security operations center, system administrators, legal, communications and business owners, should appear in the test scope. A tabletop that involves only the security team will not show whether business owners can make containment decisions. Record which roles each test exercised and which were left out, so the gap is visible during assessment.
Third parties in the test
Outsourced security monitoring, forensic retainers and cloud or managed hosting providers often hold parts of the response process. Confirm in the contract who participates in tests, how they are notified, and what they must provide afterward. A simulation that depends on a provider's action should include that provider's contact path, or the test cannot show whether the handoff works.
Linked controls CP-3, CP-4, IR-2, IR-4, IR-8, PM-14
IR-3 tests must connect to CP-3 and CP-4 (contingency training and testing), IR-2 (role-based training), IR-4 (incident handling), IR-8 (the incident response plan) and PM-14 (testing, training and monitoring at the program level). Use one exercise to produce evidence for several of these, but map each finding back to the control it affects so an assessor can trace it.
Choosing tabletop, walk-through and simulation tests
A tabletop or checklist review gathers the people who would respond to an incident and walks them through a scenario or a checklist, without touching live systems. It is the lowest-disruption test and the easiest to run often. It proves that the documented procedures, roles, contact paths and decision points are understood and internally consistent, and it exposes gaps such as missing owners, unclear escalation thresholds or outdated contact lists. It cannot prove that tools work, that staff can execute steps under time pressure, or that logs and backups actually support the response. Organizations usually choose this type for frequent, low-cost testing of the plan and for first-time testing of a new or revised capability.
- What it proves: shared understanding of the incident response plan, roles and decision authority.
- What it cannot prove: that tooling, access and evidence collection work in the live environment.
- Production disruption: none, because no live systems are changed.
- When to choose it: after plan changes, for new staff, or as a frequent baseline between deeper tests.
- Record to keep: the scenario, attendees, decisions made, and gaps logged with owners.
Confirm with your assessor which test types and frequency they expect for your system categorization, and keep the test plan that defines them.
A walk-through steps responders through each documented procedure in order, checking that every step is accurate, reachable and sufficient. Unlike a tabletop, the reviewer confirms specific actions: whether a named account can log in to the SIEM, whether the forensic evidence store is reachable, whether the isolation procedure refers to the right network segment. It proves that individual procedures are accurate and that the people and access they depend on exist. It does not prove that the whole capability works together under an actual incident, because the steps are performed one at a time and usually without a live adversary or real alert volume. Organizations often choose walk-throughs after procedures change, or when a particular playbook, such as containment for a specific system, has never been exercised.
- What it proves: each procedure is accurate, complete and executable by the named role.
- What it cannot prove: timing, coordination across teams and behavior during a real incident.
- Production disruption: low, since steps are checked on test or read-only paths where possible.
- When to choose it: after a playbook change, a tool migration or a staffing change.
- Record to keep: the procedure version tested, the steps verified, and corrections raised.
Ask your team which procedures have never been performed by the person assigned to them, since those are the ones a walk-through should cover first.
NIST's discussion names parallel and full-interrupt simulations as the most operational test types. A parallel simulation runs the response in parallel with normal operations, so the team works through the scenario while production continues, and the test checks coordination, tooling and communication. A full-interrupt simulation goes further and disrupts normal operations as an actual incident would, which means the team responds as if the event were live. These tests prove that people can execute the capability with the tools and access they will really use, and they surface timing, escalation and evidence-handling problems that discussions cannot. They cannot fully prove readiness for every threat, because the scenario is finite, and they carry real operational risk if controls, rollback and communication are not agreed in advance. Organizations usually choose these for high-impact systems, after major architecture changes, or where a regulator or customer expects demonstrated operational capability.
- What it proves: execution under realistic conditions, including tooling, access, timing and cross-team coordination.
- What it cannot prove: coverage of threats outside the chosen scenario.
- Production disruption: parallel runs are moderate; full-interrupt runs can be significant and need written approval.
- When to choose it: for high-impact systems, after major changes, or where demonstrated capability is required.
- Record to keep: the rules of engagement, injects used, timestamps, and after-action findings with owners.
Before scheduling, confirm the stop conditions, rollback plan and who can halt the exercise, and ask your assessor how they want those agreements documented.
How an assessor tests IR-3 under SP 800-53A
This table walks through how an SP 800-53A assessment of IR-3 is structured, from the single determination statement to the examine and interview methods, the assessment objects an assessor requests and the findings that commonly appear. Read it as a preparation checklist: each row names what the assessor will look for and where organizations usually fall short.
| Assessment element | What the assessor does | Evidence or finding to watch |
|---|---|---|
| Determination statement | Checks one statement: the organization tests the effectiveness of the incident response capability at the defined frequency, using defined tests. | Both the frequency and the test types must be defined somewhere the assessor can read, not only implied by practice. |
| Examine method | Reviews documents and records named as assessment objects for IR-3 and related contingency testing. | Documents must exist, be approved and match what staff say they do. |
| Incident response testing material | Reads the test plans, scenarios, scripts and checklists, and checks whether they cover the organization's real response capability. | Generic scenarios unconnected to the organization's systems or current threats are a common weakness. |
| Incident response test results | Compares recorded results against the test plan and the stated objectives. | Results that record attendance only, with no outcome, gap or pass or fail judgment, weaken the test. |
| Procedures for IR testing | Confirms written procedures describe how tests are scheduled, run, observed and documented. | Procedures that stop at the test day and omit reporting and follow-up are incomplete. |
| Procedures for contingency plan testing | Checks whether IR testing is coordinated with contingency plan testing where the two overlap, such as recovery and communications. | Separate test calendars for IR and contingency work can leave overlapping scenarios untested. |
| Contingency planning policy | Confirms the policy addresses testing of the contingency capability that IR-3 relates to. | A policy that names no testing expectation gives the assessor nothing to trace the tests back to. |
| Interview with test personnel | Asks the people who design and run tests how they choose scenarios, invite participants and record outcomes. | Interviewees who cannot describe the last test or name the owner of follow-up actions signal weak governance. |
| Common finding: undocumented frequency | Looks for the defined test frequency in policy, procedures or the plan. | No written frequency, or a frequency that differs between documents, is a frequent finding. |
| Common finding: no corrective actions | Traces each identified gap from the results to a tracked corrective action with an owner and status. | Results with no corrective actions, or actions never closed, suggest the test does not improve the capability. |
| Common finding: responder teams skipped | Checks whether the people who actually respond, including technical and communications staff, took part. | Tests run only by the security team, with no engineering, legal or management participation, are often judged incomplete. |
How to set up an IR-3 testing program step by step
This sequence turns IR-3 from a line in the incident response plan into a repeatable cycle: scoped tests, documented results, tracked fixes and updated plans that an assessor can trace from start to finish.
Set test frequency and scope in the IR plan
The organization defines how often it tests the incident response capability and what that testing covers, including which systems, teams and scenarios are in scope. IR-3 leaves the frequency to the organization, so the value has to be written down and approved by the owner of the incident response plan. The output is a testing section in the IR plan, produced under IR-8, that names the frequency, the scope and the accountable role. Confirm the parameter value with your own authorizing official or governance body, and check the moderate and high baselines, which add IR-3(2), before fixing the scope.
Select test types for each scenario
Choose the test type that matches each objective. NIST's discussion names checklists, walk-through or tabletop exercises, and parallel or full-interrupt simulations as options. Tabletop exercises suit decision-making and communication, while simulations test whether the technical response works in practice. A typical program mixes types across the year so that each part of the capability is exercised. The output is a test schedule that lists each planned exercise, its type and the scenario it uses, approved by the IR lead and the system owners whose systems will be involved.
Write test plans with objectives and success criteria
For each exercise, write a test plan that states the objective, the participants, the injects or scenario steps, the systems and data involved, the safety rules that keep a simulation from causing real outage, and the measures that show success. Success criteria should be observable, such as whether the team detected the event, followed the escalation path in the plan, reached the right external contacts and restored the service. Route the plan to the IR lead and to any system owner whose environment is touched. The output is an approved test plan for each exercise, stored with the testing material an assessor will examine.
Run the test and capture what happened
Run the exercise as planned, with a facilitator who keeps time, records decisions and notes deviations from the script. For simulations, keep the event logs, ticket records and communication timestamps generated during the run, because these are the raw evidence of the response. Record who was interviewed or who took part, since assessors also ask personnel with testing responsibilities about how tests are designed and run. The output is a set of session notes and collected artifacts tied to the approved test plan, ready for the after-action review.
Record after-action results and sign them off
Within the period the organization sets in its own procedures, hold an after-action review that compares actual performance with the success criteria in the test plan. Document each gap as a finding with an owner, a description and a severity the organization defines. The report should separate what worked from what did not and link each finding to evidence from the run. The output is a signed after-action report, approved by the IR lead, that serves as the test result an assessor reviews under the determination statement for IR-3.
Track corrective actions to closure
Enter every finding into the organization's tracking system, assign an owner and a due date, and review progress at a set cadence until each item is closed or formally accepted as a risk. Closure should require evidence, such as a revised runbook, a configured alert, a corrected contact list or a completed retest. Open items that cannot be closed belong in the plan of action and milestones maintained under the CA family. The output is a tracker showing each finding, its status and the evidence of closure, which lets an assessor trace a test result to a fix.
Feed results into IR-8 and IR-4 updates
Use the after-action findings to update the incident response plan under IR-8 and the handling procedures and playbooks under IR-4. Changes to roles, escalation paths, tooling or contact details should be reflected in the plan and reissued to the people who use it. Confirm that updated documents are approved, versioned and distributed, and that the changes are traceable to specific findings. The output is a revised IR plan and handling procedures, with a change log that links each revision to the test that prompted it, and the start of the next testing cycle.
Evidence that passes an IR-3 review and how to keep it current
An assessor testing IR-3 reads the test program as a chain: a plan, a scenario, proof that the right people took part, results, and fixes that reached the plan. Each card below is one link in that chain, and the set only passes if the links point to the same version of the plan and the same test.
Test plan with stated objectives
The test plan is the first document a reviewer asks for. It should name the test type (checklist, walk-through, tabletop, or parallel or full-interrupt simulation), the systems and incident scenarios in scope, the objectives each test measures, and the roles that run it. Check that the plan cites the test frequency the organization defined under IR-3, because a plan that contradicts the frequency in the IR policy is an immediate finding. Confirm the plan is approved and dated before the exercise runs.
Scenario scripts and injects
A scenario script records the sequence of events the exercise team introduces, the time or trigger for each inject, and the expected response from each role. Keep the scripts with the exercise they were used for, not in a shared folder that gets overwritten. Illustrative example: a script for a ransomware tabletop might list a suspicious privileged login, a containment decision and a request to the legal team, with the expected handoff to the IR-4 playbook for each step.
Attendance and participant records
Reviewers check that the people who hold incident response roles took part, and that the exercise covered the roles the plan assigns. Record names, roles, organizational units, and whether each participant attended in full or in part. Attendance records also feed IR-2 training records, so a gap in one usually shows in the other. Ask a reviewer's question before the exercise: which roles in the plan have never been tested?
Test results and observed gaps
Results show what happened during the test, measured against the objectives in the plan. Record actual response times, decisions that differed from the plan, tools that were unavailable, and communications that failed. A results record that reports only success is weaker evidence than one that shows where the response broke down. Capture the raw timeline from the exercise platform or incident case, so the summary can be checked against the source.
After-action report and corrective actions
The after-action report summarizes results, assigns each gap an owner and a due date, and links every finding to a corrective action ticket. Assessors look for the chain from finding to ticket to closure. Tickets should record what changed, who verified it, and the date it was closed. A report with open items and no tickets is a common reason for a weak IR-3 result.
Evidence that fixes reached the IR plan
Reviewers test whether lessons from the exercise changed the incident response plan that IR-8 requires. Keep the revised plan, its version number and approval record, and a change log that maps each corrective action to the section it changed. Where a fix changed a playbook or tooling configuration, keep that artifact too, with the same version reference. Without this link, the test results show a problem and nothing shows it was addressed.
Version control and retention between audits
Store each test package in a versioned repository or document system with a fixed folder per exercise, and never edit a closed package. Record who approved each document and when. Confirm the retention period with the auditor and with the organization's records policy, because the period is not set by SP 800-53. Plan a review of the set before each assessment so the latest test, its findings and their closure are easy to pull. Open-source case management tools such as DFIR-IRIS can hold case records and evidence trails, but confirm that the platform's audit trail and export meet the organization's retention needs.
What meeting IR-3 costs in money and effort
This table breaks the cost of IR-3 testing into its components, showing who is paid for each, whether it is one-time or recurring, and what moves it up or down. NIST does not estimate compliance costs, so use the rows to build the questions you put to any quote.
| Cost component | Who carries it | One-time or recurring, and what drives it |
|---|---|---|
| Test design and test plan | Internal IR lead, with optional outside facilitator | One-time for the first plan, then recurring at each test cycle. Driven by how many scenarios, systems and teams are in scope. |
| Staff time to run exercises | Incident responders, IT, legal, communications, business owners | Recurring. Driven by test type, participant count and how many hours each person must release from normal duties. |
| External facilitation or red team support | Outside facilitator or testing provider under a written scope | Recurring if used at each cycle, otherwise one-time for a first exercise. Driven by simulation depth and whether independent observers are required. |
| Tooling and test environments | Organization, or implementation partner for setup | One-time for setup such as a case management platform or sandbox, recurring for hosting, licensing and upkeep. Driven by whether tests use production-like systems. |
| After-action reporting and remediation tracking | Internal IR and control owners | Recurring. Driven by the number of findings and how they are tracked into plans of action and milestones. |
| Evidence upkeep for the assessor | Compliance lead and control owners | Recurring. Driven by how many test records, results and sign-offs must be retained and retrievable for sampling. |
| Assessor sampling and review | Independent assessor (fee set by the assessor) | Recurring at each assessment. Driven by the assessment scope, the number of test cycles in the review period and the depth of sampling. |
Who runs IR-3 tests and who outsources them
IR-3 is an obligation of the organization operating the system. The organization decides which tests to run, how often to run them and what counts as a passing result. The test program belongs to the people accountable for the incident response capability, and their decisions are what an assessor evaluates. Outsourcing work does not transfer that accountability. The organization must be able to show that it defined the tests, approved the test plans and acted on the findings.
- Defining the test frequency: The organization sets the frequency in its own documents. The assessor checks that the frequency was defined and then followed.
- Choosing test types: Checklist reviews, walk-throughs, tabletop exercises and simulations are the organization's choice, matched to the systems and risks in scope.
- Approving plans and objectives: Someone with authority signs off on each test plan, scope and success criteria before testing begins.
- Acting on results: Gaps found in after-action reviews are tracked to closure in the organization's own corrective action records.
- Keeping the record: Test materials, attendance, results and follow-up stay under the organization's control.
Before engaging anyone, confirm internally who owns the test calendar and who signs the after-action reports.
An implementation partner can help the organization build the test program and produce the evidence that goes with it. DeployOpen prepares systems, controls and evidence for compliance assessments, and its work on IR-3 can include designing test plans, facilitating exercises and assembling the test records. The partner works for the organization and does not decide whether the control is met.
- Test plan design: Scoping, scenarios, injects, roles and success criteria can be drafted for the organization's review and approval.
- Facilitated exercises: A partner can facilitate tabletop or simulation sessions, record decisions and capture timing data.
- Evidence preparation: Test materials, attendance records, results and after-action reports can be organized so that an assessor can find them quickly.
- Technical support during simulations: Where a test uses lab or cyber range infrastructure, the partner can prepare and operate that environment.
- Remediation tracking: Findings can be logged into the organization's ticketing or case system so that follow-up is visible.
Confirm in writing which deliverables the partner produces, which the organization approves and which the organization retains, since the scope of the engagement defines who signs each document.
The independent assessor examines the test program and its results against the assessment procedure for IR-3 in SP 800-53A. For IR-3, the procedure uses examine and interview methods. The assessor reviews the documented test program and test results, and interviews personnel with testing responsibilities. The assessor's conclusion is independent of the organization and of any partner that helped prepare the evidence.
- Examining the documents: The assessor reviews contingency and incident response policy, test procedures, test materials and test results.
- Interviewing responsible staff: The assessor asks the people who run tests how the program works in practice.
- Judging the evidence: The assessor decides whether the evidence supports a finding of the control as implemented.
- Reporting independently: Only the assessor, and not DeployOpen, issues assessment reports or certifications.
- Protecting independence: A partner that designed and ran the exercise should not also be the one judging its adequacy.
Ask the assessor early which artifacts they expect and whether they accept partner-prepared materials, since this affects how the engagement is scoped.
Gaps that cause IR-3 findings and how to close them
Most IR-3 findings are not about whether an exercise happened. They come from tests that were never scheduled, never scoped, or never fed back into the plan. The cards below cover the gaps assessors meet most often, and each ends with a closing action you can check before the assessment.
No defined test frequency
IR-3 requires testing at a frequency the organization itself defines, so an unstated or informal cadence is a finding in its own right. Write the frequency into the incident response policy or the test plan, name the owner, and keep a calendar that shows each planned exercise. Close it by recording the interval and the next scheduled date in one controlled document that an assessor can read without asking you.
Tests without written objectives
A tabletop or simulation with no stated objective cannot show whether the capability worked, so the assessor has nothing to measure the results against. Each test should state what it sets out to prove, such as detection time for a scenario or whether escalation reaches the right people. Close it by writing a one-page objective and success criteria for every test before it runs.
Results not tied to corrective actions
Teams often hold a debrief and then lose the findings, so the same gap appears in the next exercise. The after-action report should list each finding with an owner, a due date and a status, and the tracker should be the same one used for other incidents. Close it by linking every finding to a tracked action item and checking its status before the next test is scheduled.
Responders absent from exercises
A test run only by the security team misses the people who act in a real incident, such as system owners, legal, communications and senior decision makers. Assessors interview personnel with testing responsibilities, so gaps in attendance are visible. Close it by keeping an attendance record for every exercise and recording which roles were absent and how they will be covered in the next test.
No record that the plan changed
When a test exposes a weak step, the incident response plan and related procedures should change, and the change should be traceable. Without a version history and a link to the test that prompted it, the organization cannot show that testing led to improvement. Close it by citing the test identifier in the revision note of each plan update and recording the approval date.
Questions buyers ask about IR-3 testing cost, effort and outsourcing
Does IR-3 incident response testing apply to low impact systems?
No. SP 800-53B allocates IR-3 to the moderate and high control baselines and to the privacy control baseline, so it is not part of the low baseline. A low impact system can still benefit from a simple annual tabletop, but an assessor will not test IR-3 against it unless the system's categorization or a contract requires the control. Confirm the baseline selection in the system security plan, because tailoring can add controls to a system. The moderate and high baselines also add IR-3(2), which asks for testing that coordinates with related plans and organizational elements, so check that enhancement separately.
How often must we test our incident response capability under IR-3?
The control requires you to set the frequency yourself and test at that frequency. NIST does not prescribe a single interval in the control text, so the defined frequency is what the assessor checks against. Document the interval in the incident response plan or test plan, state the reason it fits the system's risk, and then keep to it. Many organizations link the frequency to changes, such as a new platform release, a major staffing change or a significant incident, and add scheduled tests on top. Missing your own stated interval is a common finding, so pick a frequency your team can sustain.
Do tabletop exercises alone satisfy the IR-3 control?
A tabletop exercise can satisfy IR-3 if it is part of a defined testing program and produces the evidence an assessor needs. The NIST discussion names checklists, walk-through or tabletop exercises and parallel or full-interrupt simulations as types of testing, so the test type is your choice. Many programs combine a tabletop for decision-making with a technical simulation for the tooling and handoffs. A tabletop with no written scenario, no recorded results and no follow-up actions will be hard to defend. Ask your assessor early whether a tabletop alone is enough for your system's categorization and risk.
How much effort does IR-3 testing take, and what drives it?
The effort depends on test type, system scope, number of teams involved and how much evidence you must produce. NIST does not publish hours or costs for this control, and NIST states it does not estimate compliance costs, so treat any figure you see from a vendor as their estimate. The main drivers are the number of systems and interfaces in the scenario, whether third parties such as cloud providers or managed security services take part, how many roles must attend, and whether you run a simulation that touches production-like tooling. Effort recurs with each test cycle, plus the time to write the after-action report and track corrective actions.
Can our own security team run IR-3 tests without an outside partner?
Yes, the organization owns the control and can design, run and document its own tests. Internal teams usually handle this well when they have a documented test plan, a neutral facilitator who did not design the scenario, and a process for recording results. Outside help tends to add value in three places: designing realistic scenarios, running technical simulations against a self-hosted lab, and preparing the evidence package before an assessment. An implementation partner prepares systems and records, but the organization must still perform and own the testing. An independent assessor, not the partner, reviews the results.
What should we ask an implementation partner to include in a written IR-3 scope?
Ask for a scope that names each deliverable, system and test type before work starts. A useful written scope usually covers:
- The systems, interfaces and business processes in the test boundary, and which baseline applies
- The test types planned (for example tabletop, walk-through or simulation), with the defined frequency and how it was set
- Written test plans, scenarios, roles and success criteria for each exercise
- After-action reports, corrective action tracking and the update process for the incident response plan
- Which evidence will be delivered, where it is stored, and who signs off on it
- Which parts are excluded, such as the independent assessment, staff time or third-party participation
Confirm that the partner prepares evidence but does not issue assessment reports.
Who pays for IR-3 testing, and what recurs after the first test?
The organization pays for its own staff time, any third-party facilitators or assessors it hires, and any tooling or lab infrastructure it commissions. An implementation partner's work is priced from a written scope, and DeployOpen does not publish a price list, so ask for a quote tied to specific deliverables. One-time costs include designing the test program, building scenarios and setting up a lab. Recurring costs include each test cycle, updating scenarios after system changes, writing after-action reports and running the corrective actions they produce. Ask the partner which costs are one-time and which recur, so you can budget for the cycle, not just the first test.
How DeployOpen scopes and prepares IR-3 testing evidence
DeployOpen plans, implements and documents the systems and evidence an organization uses to test its incident response capability for IR-3. The organization owns its controls and test decisions, and an independent assessor reviews the results.
How we scope
- Written scope names the systems, teams and incident types that each IR-3 test will cover.
- We confirm which baseline applies, since IR-3 sits in the moderate and high baselines and the privacy baseline.
- Scope records the test types chosen, such as tabletop exercises, walk-throughs or simulations, and who approves them.
How we build
- We prepare test plans with objectives, injects, roles, success criteria and a defined test frequency.
- We configure the case management tooling so exercise records, timelines and tasks are captured in one place.
- We prepare evidence templates for test materials, attendance and results so assessors can trace each exercise.
How we hand over
- Deliverables include test plans, exercise materials, after-action reports and open findings tracked to closure.
- We map each artifact to the IR-3 assessment objects so the organization can show what an assessor will examine.
- Handover includes documented procedures that your staff can run again without DeployOpen present.
How we support
- Ongoing support is available as a retainer for running recurring tests and updating test plans after changes.
- Retainers can cover follow-up on after-action findings and preparation for each scheduled exercise.
- Independent auditors and assessors decide whether the evidence meets IR-3, and DeployOpen does not issue reports or certifications.
