What RS.AN-06 asks for when investigators act during an incident
If an assessor or customer asks how you know investigation work was recorded reliably, RS.AN-06 is the Subcategory they are testing. In plain words, its outcome is that the actions taken during an investigation are written down and that the integrity and provenance of those records are preserved, so that someone reviewing the case later can tell what was done, by whom and in what order. The Subcategory sits in the Incident Analysis Category of the RESPOND Function in the CSF 2.0 Core. NIST publishes two Implementation Examples for it: one asks that each responder and administrator who performs response tasks record their actions in a way that cannot be altered, and the other asks that the incident lead document the incident in detail and keep its sources intact. According to NIST's CSF 1.1 to 2.0 transition spreadsheet, RS.AN-06 absorbs part or all of CSF 1.1 RS.AN-3, so organizations moving from 1.1 should check that their existing forensic logging practices still cover what the new Subcategory describes.
Records get lost or altered under pressure for predictable reasons. Responders work in shared consoles, paste commands into chat channels, run tools with administrator rights and close tickets from memory after the fact. Timestamps drift between systems, notes live on personal laptops, and a well-meant cleanup can overwrite the only copy of a log. Under time pressure, the incident lead is often the person least able to write a complete account. The practical response is to decide in advance where each class of action is recorded (case management, privileged access logs, change records), who is accountable for the incident narrative, and how that narrative is kept consistent with the underlying logs. Confirm with your own incident response plan which roles carry each duty, because CSF 2.0 leaves the assignment to the organization.
Open-source tooling can produce much of this evidence, but none of it satisfies the Subcategory by itself. DFIR-IRIS (LGPL-3.0-or-later) keeps each case as one record with a full audit trail, and it logs evidence with SHA-256 verification and chain of custody, which speaks directly to provenance. For privileged actions, OpenBao (MPL-2.0) audit devices keep a detailed JSON log of API requests and responses, with most sensitive values hashed using HMAC-SHA256, and Nextcloud's admin_audit app writes extra event detail to audit.log. Before relying on any of these for an assessment, check that the log destination is write-protected, that retention meets your policy, and that someone can show an auditor a complete chain from an alert to the responder's recorded action. Whether these settings meet your organization's requirements is a question for your own assessor, not a claim this page can make.
Which responders, systems and records fall under RS.AN-06
RS.AN-06 applies wherever response work produces records, so scoping starts with people, then the tools that hold their actions, then the third parties acting on the organization's behalf. Each card below is a decision your team must make and document before an assessor asks where the investigation trail lives.
Responders and administrators doing response work
Start with a named list of every person who runs containment, eradication, log queries, account changes or system restores during an incident, including administrators with elevated rights. NIST's Implementation Examples expect each of these people to record their actions immutably, so an on-call engineer who isolates a host at night falls in scope just as the incident lead does. Check that shared or break-glass accounts are mapped to a real individual, because an assessor will not accept an anonymous action in the record.
Case management and investigation timelines
The case system is where the incident lead's detailed record normally lives, so it is the first tool to scope. Confirm that it keeps tasks, evidence references and a timeline with an audit trail, and that task entries cannot be silently edited or deleted. DFIR-IRIS, an open-source option under LGPL-3.0-or-later, keeps each case as one record with a full audit trail, which is the kind of property to verify in your own deployment rather than assume.
Audit logs on file platforms
Collaboration and file platforms hold evidence copies, export records and sharing changes that responders create during an investigation. Decide which applications log these actions, where the log files are written, and who can read them. For example, Nextcloud's admin_audit app writes additional event information to audit.log in the data directory unless a different path is set with logfile_audit, so the log location is a configuration decision to document and protect.
Secrets stores and privileged access logs
Anything that issues or reads credentials during response belongs in scope, because an attacker or a careless responder can use those actions to hide tracks. Secrets stores such as OpenBao keep a detailed JSON log of every API request and response when an audit device is enabled, and most sensitive values are hashed with HMAC-SHA256. Confirm that audit devices are enabled before the incident, that the logs ship to storage the responders cannot alter, and that emergency access is covered by the same logging.
Third parties acting for the organization
An MSSP, incident response retainer or managed service provider that performs containment or log analysis creates investigation actions that your records must still capture. Write the requirement into the contract: the provider records each action immutably, shares its case notes in your system, and retains the records for the period your own policy sets. Ask for evidence of this during onboarding, since the organization owns the record even when the provider performs the work.
Systems that change during response
Firewalls, endpoint tools, identity providers and cloud consoles all change state during containment, and each change is an investigation action. List the systems where response changes are possible, confirm each writes its own audit trail, and test that the trail survives a responder's own account being disabled. A short illustrative exercise, where one tabletop action is traced across three systems, often reveals gaps in this list faster than a document review.
How an assessor tests investigation records
This table compares each test step an assessor is likely to run against RS.AN-06 with the evidence requested and the findings that most often appear. Read each row as a test the organization should rehearse before an assessment, not as a pass or fail rule. The main takeaway is that assessors test the records themselves, so logs must exist, be attributable and be provably unaltered before anyone asks for them.
| Test area | What the assessor checks | Evidence requested and common findings |
|---|---|---|
| Sampling incidents | Selects a sample of recent incidents and confirms each has investigation records covering the actions taken | Incident tickets, case timelines and sign-off dates. Finding: incidents closed without any recorded investigation actions |
| Responder attribution | Confirms each action is logged by the person or account who performed it, not a shared or generic login | Case audit trail, shared account inventory, responder roster. Finding: actions logged under a shared admin account |
| Completeness of responder logs | Compares actions described in the incident narrative with entries in the logs for the same period | Log extracts matched to timeline entries. Finding: gaps where commands, queries or containment steps were run but not recorded |
| Immutability of responder logs | Checks that logs cannot be edited or deleted by responders and that tampering would be detectable | Log storage configuration, write-once or forwarding settings, hash or signature evidence. Finding: logs stored only on the responder workstation |
| Access controls on logs | Reviews who can read, write or purge investigation logs and whether that access is itself logged | Role assignments, access reviews, admin audit records. Finding: administrators able to clear logs without any record |
| Incident lead record | Confirms the incident lead maintains a detailed, dated record of decisions and actions and that it links to its sources | Incident lead record, links to source logs and evidence references. Finding: summaries with no source references |
| Integrity of the record | Checks that edits are versioned or traceable and that the record matches preserved source data | Version history, change log, hash comparisons. Finding: undocumented edits after case closure |
How to implement investigation action recording step by step
This sequence turns the RS.AN-06 outcome into working records: defined actions, central logs that responders cannot quietly edit, a detailed incident lead record, and rules for keeping and accessing it. Each step ends with an output you can show an assessor.
Define which investigation actions must be recorded
The incident lead and the security operations manager agree a short list of action types that must be logged, such as queries run against SIEM data, host isolation, account disablement, evidence collection, containment changes and communications with outside parties. Write the list into the incident response plan and name the roles that must log each action type. The output is a signed-off action catalog that every responder can point to. You know it is done when a reviewer can pick any response task and find the matching entry in the catalog.
Centralize responder activity logging
Platform and security engineers route the logs from responder tools, administrative consoles and ticketing or case systems into one logging store that the responders do not administer. For self-hosted tools this usually means sending the audit output of each system to a central collector in your own infrastructure. The output is a log source inventory showing each responder-facing system, where its audit events land and who can read them. You know it is done when a test action in each tool appears in the central store with a timestamp and user identity.
Make responder logs append-only or tamper-evident
Platform engineers configure write-once or append-only storage for the central logs, or add hash chaining or signed batches so that any later change is detectable. Confirm with each vendor exactly which integrity features the product provides before you rely on them, because capabilities differ between tools and versions. The output is a short integrity design note listing each log store, its protection mechanism and the test used to verify it. You know it is done when an attempted edit or deletion by an ordinary administrator fails or leaves a visible trace.
Assign the incident lead's record template
The incident lead keeps a detailed case record that narrates the investigation: the timeline, decisions and their reasons, hypotheses tested, evidence sources, people contacted and open questions. The security team builds this template inside the case management platform, for example DFIR-IRIS, so that tasks, assets, indicators and evidence link to one case. The output is a template with mandatory fields and a rule that the record is updated as events happen, not reconstructed later. You know it is done when a sample case shows every action linked to a timeline entry and an evidence source.
Set retention, access and review rules
The security governance owner, with legal and privacy input, writes how long response logs and case records are kept, who may read or export them, and how access is granted and reviewed. Access to the investigation record should be limited to people who need it, and every export should itself be logged. The output is a retention and access standard that names the owner of each log store. You know it is done when the standard's periods match your legal and contractual obligations as confirmed by counsel, and the access list can be produced on request.
Test the recording process with a tabletop exercise
The incident response team runs a tabletop exercise based on a realistic but invented scenario, and each participant performs the logged actions the plan requires. Afterwards, a reviewer checks whether every action appears in the central store, whether the incident lead's record matches the actual sequence, and whether any integrity control was bypassed. The output is an exercise report with gaps, owners and corrective actions recorded in the improvement process. You know it is done when the gaps are closed and a repeat check passes for the same scenario.
Why immutable and attributable logs matter more than log volume
An assessor testing RS.AN-06 is rarely impressed by how much was logged. The question is whether the record can be trusted: who took each action, when it happened, and whether anyone changed it afterward. A gigabyte of responder notes that can be edited without trace is weaker evidence than a short, complete trail that shows its own integrity. For planning purposes, the organization owns this control. An implementation partner can configure the logging stack and document how it works, but only the organization can demonstrate, during an assessment, that its responders actually used it.
Integrity and provenance are separate properties and both need design. Integrity means the record was not altered after it was written, which usually requires append-only storage, restricted write paths and tamper-evident hashing or signing. Provenance means each entry traces back to a named account or device. Shared responder accounts break provenance immediately. Responders should authenticate as themselves, and the incident lead's detailed record should cite the responder logs by reference rather than retyping them. Separation also matters: the people who run the logging platform, such as its administrators, should not be the same people who can delete or rewrite the responder trail. Confirm with your own identity team which roles can alter audit storage, and whether those changes are themselves logged to a destination the administrators cannot edit.
Memory is the weakest source for a timeline, so the responder's own actions should be captured as they happen. Ask which tools produce automatic records for each action: case-management entries, command history on jump hosts, privileged session recordings and API audit devices. For example, an OpenBao audit device writes a JSON entry for each API request and response, with most sensitive values hashed, which gives a responder's secret reads and policy changes a record they did not have to write themselves. Where a step cannot be automated, require the responder to log it at the time of action. Before any incident, test the chain by performing a benign action and checking that it appears, attributed correctly, in the place the incident lead will read it.
Evidence that satisfies RS.AN-06 and how to keep it current
RS.AN-06 is tested by records, not by policy statements. The cards below list the artifacts an assessor is likely to ask for, how each one shows that investigation actions were recorded and kept intact, and the routine checks that keep them usable between audits. Treat each artifact as something produced during normal incident handling, not assembled for the audit.
Responder action log export
This is the per-responder record of actions taken during an investigation, which the first Implementation Example for RS.AN-06 asks each responder and administrator to keep immutably. For each incident, the export should show who acted, when, on which system, and what they did, with timestamps from synchronized clocks. Check that the export can be produced for any closed case without manual reconstruction. Confirm that every responder account writes to the same case record.
Case audit trail extracts
Case management tools that keep a full audit trail for each investigation can produce extracts of who viewed, edited or closed tasks and evidence. In DFIR-IRIS, for example, the case stores assets, IOCs, tasks and evidence as one record with an audit trail, so an extract can be filtered to a single incident. Sample a few closed cases each quarter and confirm the trail is complete, including edits made after closure. Ask the vendor documentation how the trail itself is protected from modification.
Incident lead's written record
The second Implementation Example requires the incident lead to document the incident in detail and preserve its integrity and sources. This written record should narrate decisions, the reasons for them, the evidence relied on, and the handoffs between responders. An assessor will compare it against the action log to see whether the narrative matches what the systems recorded. Keep a template with fixed sections so that every incident produces a comparable document.
Log integrity and retention settings
Evidence is only as credible as the settings that protect it. Record the configuration that enables audit logging, where it writes, and who can change it. For Nextcloud, the admin_audit app writes additional event information to audit.log in the data directory or to a path set with logfile_audit. For OpenBao, audit devices keep a JSON log of API requests and responses with sensitive values hashed using HMAC-SHA256. Export these settings with each review so that a change to logging is itself visible.
Access reviews on log stores
Anyone who can edit or delete investigation records can undermine RS.AN-06, even if the logs are otherwise sound. Review who holds administrative rights to the case platform, the log store and the audit file location at a fixed interval, and remove access that is no longer needed. Record each review with the reviewer, the date and the changes made. Confirm that the responders who write action logs cannot alter entries they have already written.
Sample tickets from recent incidents
Ticket samples show whether the process runs in practice. Pull several recent incidents of different severity and check that each has responder actions, an incident lead record, preserved sources and a closure note. Gaps found in a sample should lead to a documented corrective action and a follow-up sample. Keep the sampling method written down so that an assessor can see how the selection was made and that it was not chosen to flatter the program.
Who owns RS.AN-06 in-house, with a partner and with the auditor
The organization owns RS.AN-06 in full. NIST's Implementation Examples place two duties on the organization's own people: each responder and administrator who performs response tasks records their actions in an immutable way, and the incident lead documents the incident in detail and preserves its integrity and sources. No partner or auditor can take over those duties, because the records must reflect what the organization's staff actually did during the investigation.
- Accountable owner: A named role, usually the head of security operations or the incident response lead, is accountable for the outcome and signs off on the procedure.
- Responder conduct: Staff know which actions must be logged, how, and where, and they follow that routine during live incidents.
- Incident lead record: The lead maintains the detailed incident record, including decisions, timestamps and the sources relied on.
- Retention and access: The organization decides how long records are kept, who can read them, and how access is reviewed.
- Policy and procedure: The incident response plan and evidence handling rules are written, approved and tested by the organization.
Before engaging anyone, confirm that a named owner, a written procedure and a designated incident lead exist for every category of incident your organization handles.
An implementation partner prepares the systems and evidence that let the organization meet RS.AN-06. DeployOpen, for example, plans and configures self-hosted platforms inside the client's own infrastructure. The partner does not decide what the organization's policy says, does not issue an audit report, and does not certify that the controls work. Its role is to make the records possible and to produce them on request.
- Logging architecture: Designing where audit logs are written, how they are protected, and how they reach the case management platform.
- Evidence preparation: Building case workflows, evidence logging with integrity checks, and report templates that draw on case data.
- Tabletop testing support: Running exercises that walk responders through recording actions, so gaps appear before a real incident.
- Documentation: Writing configuration records and runbooks that the organization's staff can operate after the engagement ends.
- Scope limits: Work is agreed in writing before it starts, and the partner's deliverables are systems, configurations and documents, not opinions on conformity.
Ask any partner to show, in writing, which deliverables they will hand over and which decisions remain with your staff.
An independent auditor, assessor or certification body tests whether the organization's controls operate as described and issues any report or certificate. NIST does not offer certifications or endorsements of CSF implementations or services, so no CSF 2.0 certificate exists for RS.AN-06 itself. Any assurance report must come from a qualified independent party chosen by the organization, and that party must be separate from the people who configured the systems.
- Sampling: The auditor selects past incidents and checks that action records exist, are timestamped and can be traced to a responder.
- Integrity testing: The auditor checks whether logs were protected from alteration and whether integrity checks were applied to evidence.
- Walkthroughs: Staff explain the procedure in their own words, and the auditor compares it to what the records show.
- Independence: A partner that designed or operated the logging cannot also test it and issue a conclusion on it.
- Conclusions: Only the auditor states whether the control was effective.
Before the engagement, confirm the auditor's independence from your implementation partner and which assurance standard or framework the report will reference.
Some parts of RS.AN-06 are routinely outsourced because they need specialist skills, while others stay in-house because they reflect the organization's own judgment. The practical question is which tasks a partner can carry out without taking over decisions that belong to the organization or conclusions that belong to the auditor.
- Usually outsourced: Logging architecture, evidence preparation, case tool configuration and tabletop exercise design.
- Often shared: Runbook writing, where the partner drafts and the organization reviews and adopts the text.
- Usually kept in-house: Day-to-day recording of responder actions, incident lead documentation and retention decisions.
- Never outsourced: Accountability for the control, and the decision on whether an incident record is accurate.
- Cost drivers: The number of log sources, the size of the environment and the amount of change to existing tooling shape the effort. Ask for a quote that separates one-time build work from recurring support.
Request a written responsibility matrix from any provider that lists each task, the party doing it and the party approving it.
What meeting RS.AN-06 costs in money and effort
This table breaks down the cost components of recording investigation actions under RS.AN-06, showing who is paid for each, whether it is one-time or recurring, and what moves it up or down. Read it as a checklist for a quote: most spend sits in engineering time and ongoing evidence upkeep, while license spend can be reduced with self-hosted open-source tooling.
| Cost component | Who is paid or who bears it | One-time or recurring | What drives the cost |
|---|---|---|---|
| Logging tooling or licenses | Software vendor or open-source project; in self-hosted models, the organization's own infrastructure team | Licenses recur; open-source components carry no license fee but still need hosting | Number of responders, case volume and whether a commercial case platform is chosen; confirm license terms before selecting |
| Engineering time for immutable responder logs | Internal platform or security engineers, or an implementation partner under a fixed-scope agreement | One-time configuration, with periodic review | Number of systems that record response actions, audit log storage design and integration with existing SIEM or case tools |
| Incident lead template and record design | Incident lead and security management, with optional partner support for template drafting | One-time build, updated after each incident or exercise | Complexity of the incident record, number of incident types and how many review cycles leadership requires |
| Evidence upkeep and log retention | Internal operations team; storage costs paid to the cloud or data center provider | Recurring | Log volume, retention periods set by policy and regulation, and frequency of integrity checks on stored records |
| External testing or review of the logging design | Independent security firm or assessor, engaged by the organization | Usually one-time per review cycle, sometimes recurring | Scope of systems reviewed, whether the review tests tamper resistance, and whether it is combined with other testing |
| Auditor sampling of records | Independent auditor or certification body; the organization pays for the audit engagement | Recurring at each assessment cycle | Number of incidents sampled, quality of the index linking tickets to logs, and how much manual reconstruction is needed |
| Staff time for responder compliance | Internal responders and administrators, through their normal duties | Recurring, distributed across incidents | Tool friction, training quality and whether actions are recorded at the time they happen |
Where organizations fall short on investigation records
Most RS.AN-06 failures are not missing tools. They are gaps in where responders write, who can change the record, and whether the record ever gets tested. The cards below cover the gaps we see most often and a closing check for each.
Responder actions in chat and personal notes
Responders often record what they did in chat threads, personal notebooks or ticket comments that anyone can edit or delete. Under RS.AN-06, each responder and administrator who performs response tasks should record those actions in a way that cannot be quietly altered. Check whether a responder's actions can be reconstructed from a system of record without asking the person who performed them.
Logs editable by monitored administrators
When administrators can edit the audit logs of the systems they manage, the record of their own actions is only as trustworthy as their intent. Logs that the monitored party can alter do not show integrity. Confirm that audit output is written to a destination administrators cannot modify, and that log file permissions and retention settings are changed only under documented approval.
Missing incident lead records
The RS.AN-06 Implementation Examples call for the incident lead to document the incident in detail and preserve its integrity and sources. In many organizations the lead keeps a running summary in memory or in a shared document with no version history. Check that a single case record exists, that decisions and timestamps are entered as they happen, and that the lead's entries are not overwritten later.
Records not linked to evidence sources
An investigation timeline is hard to defend when its entries do not point to the evidence behind them. A statement such as "host isolated at 14:10" should trace to a log line, an EDR action or a ticket. Check whether each investigation action carries a reference to its source and whether evidence items have hashes and a chain of custody, which is the link RS.AN-06 expects between records and sources.
Records never tested in exercises
Teams often write response plans that name who records what, then discover during a real incident that the logging path does not exist or that responders lack access. Tabletop and technical exercises are the cheapest place to find this. Check whether an exercise run includes a review of the investigation record itself: whether it is complete, time-ordered and readable by someone who was not on the response team.
Questions buyers ask about RS.AN-06 cost, effort and evidence
How much work does it take to meet RS.AN-06?
The effort depends on how many people perform response tasks, how many systems hold investigation records, and how well the current incident process is already written down. No researched figure is available for hours or fees, so ask any provider for a line-item estimate tied to your environment. The work splits into one-time setup (defining what each responder records, configuring logging and case tooling, and writing the incident lead's documentation standard) and recurring work (reviewing logs, keeping the case record current during live incidents, and testing that records remain intact). Organizations with many administrators and several log sources usually spend more on setup than those with a small, centralized response team.
Can our own team implement RS.AN-06 without outside help?
Yes, many teams do this internally, especially when they already run a SIEM, ticketing system and a documented incident response plan. The harder parts are usually not technical: agreeing which actions every responder must record, deciding who owns the incident lead's record, and proving that logs cannot be silently altered. Outside help is most useful when the team lacks time to build and test the case workflow, or when no one has audited their own logging configuration. Whatever you choose, the organization keeps ownership of its controls and the independent auditor, if one is engaged, issues any report.
What does the work need from our people and systems?
You need named owners for three things: the responders who must log their own actions, the incident lead who keeps the detailed record, and the administrators who control logging settings. On the technical side, you need a central place for case records, audit logging turned on for the systems responders use, and a way to keep those logs in storage that administrators cannot quietly edit. Ask any implementation partner to list the systems in scope, the log sources they will read, and the access controls they will set. Confirm each item against your own environment before work starts.
How long does it take to implement RS.AN-06?
No researched fact gives a duration for RS.AN-06 work, so treat any number you hear as unverified until the scope is written down. Timing depends on the number of systems in scope, whether case tooling must be installed or only configured, how many teams must agree on recording standards, and how much testing you require before relying on the records. A fixed-scope engagement sets the deliverables and timeline in writing before work starts, which is the right point to ask for a schedule.
Does NIST certify that we comply with RS.AN-06?
No. NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans for a conformity assessment program. RS.AN-06 is a Subcategory of the CSF 2.0 Core, which you use to describe your outcomes and measure gaps. If a customer or regulator asks for evidence, an independent assessor or auditor reviews your records and issues whatever report that engagement allows. Implementation partners can prepare systems and evidence but do not issue reports or certificates.
How does RS.AN-06 relate to ISO/IEC 27001:2022 Annex A control 5.28?
The NIST CSF 2.0 Reference Tool lists Annex A control 5.28 as an informative reference for RS.AN-06, which means the two cover related ground on collecting and preserving evidence during incident handling. The mapping is a reference for planning, not a statement that meeting one satisfies the other. Confirm the mapping yourself in the NIST export, then check the wording of control 5.28 in the standard itself, since an ISO auditor tests against that control on its own terms. Shared evidence, such as incident case records and audit logs, can serve both, provided each assessor accepts it.
Which open-source tools can produce RS.AN-06 evidence?
Several self-hosted tools produce evidence that maps to this outcome. DFIR-IRIS keeps each case as one record with assets, indicators, tasks and evidence, a full audit trail, and a consolidated timeline. Nextcloud's admin_audit app writes extra event detail to audit.log, and OpenBao audit devices keep a detailed JSON log of API requests and responses with most sensitive values hashed. Confirm that each tool meets your retention, access and integrity needs in your own environment, because the tool alone does not make the records admissible or complete.
How DeployOpen prepares investigation records and evidence
DeployOpen's part in RS.AN-06 is a fixed-scope implementation engagement that configures self-hosted tooling inside the client's own cloud accounts, data center or air-gapped network, and prepares the records that the client's responders and incident lead will generate. The scope, deliverables and timeline are agreed in writing before work starts. The client keeps ownership of the incident response process, the decision to record each action, and the people who sign off on investigation notes. DeployOpen does not issue audit reports, attestations or certifications. Only an independent auditor, assessor or certification body can state whether the organization's investigation records meet a framework's requirements.
In practice, the engagement usually covers a case management platform such as DFIR-IRIS, where each case holds assets, indicators, tasks and evidence with a full audit trail, and the chain-of-custody entries for hashed evidence. It may also cover audit logging for supporting systems, such as the admin_audit app's audit.log in Nextcloud, and OpenBao audit devices that record API requests and responses. The work includes setting log locations, retention and access, confirming that log files are written to storage the responders cannot edit, and documenting how each record maps to RS.AN-06. Ask the implementation partner to show a test case with actions traced end to end before the engagement closes.
Before you request a quote, confirm three things with your own team: who the incident lead is and what they must document, which systems must write immutable responder logs, and where those logs will be stored and for how long. Your legal and records teams should set retention periods, since these are organizational decisions rather than platform defaults. Ask the implementation partner to state in the scope which configuration items they will deliver and which the client must maintain. Then engage an independent assessor to test the records against your chosen framework, because that test, not DeployOpen's configuration work, is what produces an assurance outcome.
