GOVERN 4.3 NIST AI RMF: AI testing and incident sharing

What NIST AI RMF GOVERN 4.3 asks your organization to enable

A customer questionnaire, a contract clause or an internal review asks whether your AI systems can be tested, whether failures get identified, and whether known limitations are shared with the people who rely on them. GOVERN 4.3 is the NIST AI RMF outcome that answers those questions at the organizational level. It describes practices that make three things possible: AI testing, identification of incidents, and information sharing. NIST AI RMF is voluntary and has no certification, so no body will issue a GOVERN 4.3 badge. What your organization can do is show a working set of policies, roles, records and evidence that an independent assessor or customer can inspect.

The risk is that AI failures stay invisible. Testing is often the first casualty of delivery pressure: evaluation staff are thin, test sets are not kept current, and nobody owns the decision to hold a release until limitations are understood. Incidents are then discovered late, by users or customers, or they are fixed quietly and never written down. Without a minimum incident record, the same failure recurs across teams and no one can see the pattern. Limitations also drift out of the documentation that operators read, so the people deploying the system do not know where it is unreliable.

Start by asking three questions of your current program. Does a written policy require evaluation before release and name who signs off? Is there a single intake for AI incidents, with a minimum set of fields such as system identifier, reporter, date, description, impacts and affected stakeholders? Is there a documented route for sharing known limitations with deployers and, where your obligations require it, for public disclosure? The Playbook suggestions for GOVERN 4.3 cover these points, and the Generative AI Profile adds specific suggested actions for generative systems. Confirm current Playbook content and any planned revision with NIST directly, since the AI RMF is under revision. Your internal evidence set, not a third party, is what makes these practices verifiable.

Which AI systems, teams and third parties fall under GOVERN 4.3

GOVERN 4.3 is only as wide as the scope you draw around it. The decisions below set which AI systems need testing and incident handling, which teams own those activities, and how vendors and customers feed limitations and incidents back into your program. Settle each one in writing before estimating effort, because each choice moves the workload more than the tooling does.

Generative AI systems in scope

Decide whether general-purpose and generative systems are inside the testing and incident program or handled as a separate track. NIST AI 600-1 ties its GOVERN 4.3 suggested actions to Data Privacy, Information Integrity and Information Security risks, so a chatbot or content generator brings those risk areas into scope from day one. Check whether prompts, outputs and retrieved content are logged, because testing and incident reconstruction both depend on those records.

Third-party models and vendor systems

Decide whether vendor-hosted models and pre-trained components count as your AI systems. If they do, you need contractual access to test results, limitation disclosures and incident notices, and you must define who reports to whom. If you treat them as out of scope, your incident and limitation records will have gaps exactly where a vendor change is most likely to cause harm. Ask each vendor what it will disclose and how fast.

Testing and operations roles

Assign who performs testing, who monitors production behavior and who holds governance oversight, using the actor categories the AI RMF Playbook tags to GOVERN 4.3: TEVV, Operation and Monitoring, and Governance and Oversight. Separate testers from the teams that approve releases where possible, so findings are not filtered before they reach oversight. The effort rises when one team covers all three roles without documented handoffs.

Customer-facing incident channels

Decide which user reports, complaints and appeals count as potential AI incidents and how they reach the incident queue. A customer who notices harmful output is often the first source of evidence. Define intake channels, triage criteria and the minimum fields each report must carry, such as system ID, date, description, impacts and stakeholders affected. Without this, reports arrive in support tickets and are never classified as incidents.

Limitation sharing with downstream parties

Decide which known system limitations must be shared with deployers, customers and other AI actors, and in what format. The Playbook suggests committing to identify limitations and share them with appropriate actors. Scope this to the system versions you ship and the configurations customers run, since a limitation found in one release may not apply to another. Expect recurring effort each time a model, prompt or data source changes.

Evidence retention and case records

Decide where incident records, test logs and disclosure decisions are kept and for how long. Case management tools can hold assets, evidence and an audit trail in one place, and some support chain of custody, but the retention period is a policy choice that your legal and compliance teams must set. Confirm that the tooling you select can export records for a regulator or auditor, and that access to those records is itself controlled.

How an assessor tests GOVERN 4.3 and what passes

The table walks through each part of the GOVERN 4.3 outcome: testing resources, incident identification and reporting, documentation, and disclosure of limitations. For each part it shows the evidence an independent assessor typically requests, the finding that usually appears when evidence is missing, and what a passing sample looks like. NIST does not validate or endorse any organization's use of the AI RMF, so the assessor's conclusion comes from their own testing.

Outcome part	Evidence requested	Typical finding when missing	What a passing sample looks like
Testing resources and policy	Written AI testing policy, named TEVV owners, test environments and budget or staffing records for testing	Testing happens ad hoc with no policy, so teams cannot show who tested a model before release	Approved policy naming TEVV roles, a dated test plan for a sampled system, and records showing the environment and staff were assigned
Identifying system limitations	Known-limitations register, test results that record failure modes, and sign-off that limitations were reviewed	Limitations exist only in developers' heads or vendor documents, with no record of review	A limitations entry for a sampled system tied to a test result, with an owner and a review date
Incident identification	Monitoring configuration, alert rules or user feedback channels for AI system behavior, and the trigger definitions for an AI incident	No defined trigger, so model errors or harmful outputs are handled as routine bugs and never logged as incidents	Documented incident criteria, a sampled monitoring alert or user report traced to a logged incident record
Incident reporting and documentation	Incident report template with minimum fields such as system ID, title, reporter, date, description, impacts and affected stakeholders	Reports are free text, missing dates, affected parties or impact details, and cannot be compared across incidents	Completed reports for sampled incidents containing every required field, with a closure record and lessons learned
Procedures for handling and disclosure	Escalation procedure, disclosure decision record and communication log for internal and external AI actors	No documented decision on whether to disclose, or disclosure decisions made without a record	Disclosure decision for a sampled incident showing who decided, the rationale and who was notified
Information sharing with AI actors	Records of limitations and incident findings shared with operators, deployers, risk owners or oversight functions	Findings stay within the build team, so operators and governance owners learn of issues late or not at all	Dated distribution records or meeting minutes showing a sampled limitation reached the relevant AI actor
Independence of the assessment	Assessor's engagement letter, scope and sample selection record	Internal reviewers present their own work as the assessment, without an independent view	An independent auditor or assessor selects the samples and issues the report, since NIST does not certify or validate use of the framework

How to build the testing and incident practice step by step

This sequence turns GOVERN 4.3 from a statement of intent into working practice: named roles, a testing policy, incident procedures, a limitations-sharing rule and a first test cycle that shows the practice works. Each step ends with a record that an assessor or internal reviewer can inspect.

Assign roles to the Playbook's AI actor categories
Start by naming the people who hold each of the three AI actor categories the Playbook tags to GOVERN 4.3: TEVV, Operation and Monitoring, and Governance and Oversight. The AI RMF Playbook points to AI 100-1 Appendix A for what each category does, so use that appendix to write a short duty statement for each role. Assign a named owner for each system, not just a team, and record who covers the testing, who watches production and who can accept or stop a release. The step is done when a roster exists, each named person has signed off on their duties, and the same names appear in the system inventory. Ask any vendor or partner to show how its own staff map to these categories.
Set the testing policy for AI systems
Write a policy that requires testing before deployment and at defined points afterward, and that gives the testing team the access, datasets, environments and authority to run tests that could fail a release. The Playbook's suggested action for this subcategory is to set policies that equip AI system testing, so the policy should state what must be tested, who signs off on results and what happens when a test fails. Link the policy to the risk tolerances set under GOVERN 1 so testers know which harms matter most. The step is complete when the policy is approved by a governance owner, published to the teams that build and run AI systems, and referenced in the release checklist.
Define incident reporting and documentation procedures
Create a written procedure that explains how anyone in the organization reports a suspected AI incident, how the report is logged, who triages it and how the record is kept. NIST AI 600-1 suggests identifying the minimum fields for generative AI incident reports, including system ID, title, reporter, date of incident, description, impacts and stakeholders affected, and those fields are a practical starting template for any AI system. Choose the case-management tool in advance and decide whether reports go into a ticketing system or a dedicated incident platform. The Playbook also asks for procedures covering handling and public disclosure, so include who decides on external communication. The step is done when a sample report can be filed, triaged and closed in the chosen tool with every required field populated.
Set rules for identifying and sharing system limitations
Define how the team records known limitations of each AI system, such as failure modes, out-of-scope uses and conditions where accuracy drops, and to whom those limitations must be sent. The Playbook suggests committing to identify system limitations and share them with appropriate AI actors, so the rule should name the recipients for each system, for example operators, deployers, customers and the monitoring team. Decide the format, the update trigger and the review cadence, and confirm the rule with your legal and communications leads before it is needed in a live event. The step is complete when each system in the inventory has a limitations record, a named recipient list and a dated owner.
Run a first test cycle and review the records
Run one complete cycle on a single in-scope system: plan the tests from the policy, execute them, log any findings, open an incident record for each failure that meets the procedure, and share the resulting limitations with the named recipients. Open-source tools can produce parts of the evidence. For example, garak writes a JSONL report of every probe attempt and a hit log of attempts that found a vulnerability in language models, and Langfuse traces capture inputs, outputs and tool calls for production review. Compare the records against the policy and the procedure, then close gaps in roles, templates or handoffs. The step is done when a reviewer can trace one finding from test result to incident record to shared limitation without asking the author for missing details.

Evidence that satisfies GOVERN 4.3 and how to keep it current

GOVERN 4.3 asks whether your organization's practices make AI testing, incident identification and information sharing possible. The artifacts below are the records an assessor or customer is likely to ask for, and each one needs an owner and a review rhythm between audits. Several of them also feed the generative AI suggested actions in NIST AI 600-1, which are optional for any organization.

Testing policy for AI systems

A written policy that sets when AI systems must be tested, who signs off on test scope, and which testing, evaluation, verification and validation (TEVV) activities are required before deployment and after significant change. It is the document that gives testers authority and resources, so it should name the roles that run tests and the roles that can stop a release. Check that the policy references the current Playbook suggestions for GOVERN 4.3 and that its review date and approver are recorded. Ask the owner to show who last used it to block or delay a deployment.

Test plans and results

For each AI system, a test plan that states the scenarios tested, the metrics used, the data sources and the pass criteria, together with the results from each run. Results should be kept with the system version they were produced against, so an assessor can see whether testing covered the model currently in production. Keep records of adversarial and misuse testing as well as functional testing. Stale results for an older model version are a common gap, so confirm that every production change links to a current test record.

Incident register with minimum fields

A single register of AI incidents in which each entry records the system ID, title, reporter, date of incident, description, impacts and stakeholders affected. NIST AI 600-1 lists these fields as a suggested action for generative AI (GV-4.3-002), and they are a sensible baseline for any AI system. Entries should be linked to triage, root cause and corrective action records, so the register shows what happened after the report. Confirm that reporters outside the AI team can reach the register and that the fields are required rather than optional.

Limitation notices shared with AI actors

Written notices that describe known limitations of an AI system and go to the AI actors who operate, monitor or depend on it, such as product owners, support staff and downstream integrators. Each notice should state the limitation, the conditions under which it appears, the date it was issued and the people it was sent to. Acknowledgments are useful evidence that the commitment to share limitations was carried out. Review notices whenever testing finds a new limitation or the system changes, and retire notices that no longer apply.

Disclosure procedure for incidents

A documented procedure that sets who decides whether an AI incident is disclosed, to whom (internal leadership, affected users, customers or regulators), how fast, and through which channel. The Playbook suggests procedures for publicly disclosing AI incidents, so the procedure should state the criteria that trigger disclosure and the review step that approves wording. Keep past disclosure decisions, including decisions not to disclose, with their reasoning. Test the procedure against a tabletop scenario at least once between audits and file the outcome.

Generative AI actions as a cross-check

NIST AI 600-1 lists three suggested actions for GOVERN 4.3 (GV-4.3-001 to GV-4.3-003), tagged to the generative AI risks of data privacy, information integrity and information security. These actions can be checked against the five artifacts above, so you can see which records already cover them and where a gap remains. The profile is voluntary, and an organization running generative AI is not required to adopt its actions. Use the mapping to prioritize work, and record in your own documentation which actions you adopted and which you chose not to apply.

What meeting GOVERN 4.3 costs in money and effort

This table lists the cost components of putting GOVERN 4.3 testing, incident identification and information sharing into practice, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to build your own cost model and to check that a quote covers each line. No dollar figures appear because none are supplied for this topic, so ask vendors and providers for line-item estimates against your own scope.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it up or down
Testing tooling or licenses	Tool vendor for commercial products; no license fee for self-hosted open-source tools such as garak (Apache-2.0)	Recurring for commercial licenses; none for open source	Commercial seat or usage terms, number of AI systems under test. Open source removes license spend but not staff or hosting
Engineering time for test design and evaluation	Internal AI, security or TEVV staff, or an implementation partner under a written scope	One-time to build test suites, recurring as systems change	Number of AI systems, generative AI use, frequency of model or prompt changes. Reusing probe sets across systems reduces effort
Hosting for test and logging infrastructure	Your cloud account or data center, or the hosting provider you already use	Recurring	Volume of test runs and traces, retention period. Self-hosted tools such as Langfuse (MIT) keep data in your environment but require you to size storage
Incident process setup	Internal incident response and governance teams; an implementation partner if you deploy a case tool	One-time for procedures and tooling setup, recurring for maintenance	Number of reporting channels, existing SIEM or ticketing integration, whether incident reports must include the minimum fields in NIST AI 600-1
Incident case tooling	Internal operations staff; open-source tools such as DFIR-IRIS (LGPL-3.0-or-later) carry no license fee	One-time setup, recurring operation	Alert sources to integrate (SIEM, EDR, REST), number of cases, chain of custody requirements for evidence
Evidence upkeep and documentation	Internal governance, compliance and product owners	Recurring	Number of documented limitations, disclosure commitments, review cycles and how often AI systems change
External testing or review	Independent testers or red team providers under a fixed scope; DeployOpen provides testing services within its own scope	Often one-time per engagement, sometimes recurring as a retainer	Depth of testing, number of systems, whether generative or agentic AI is included. Ask for scope, deliverables and timing in writing
Assessor or auditor time	Independent auditor or certification body, if a customer or regulator asks for an assessment	Recurring per assessment cycle	Scope of the assessment and sample size. NIST AI RMF has no certification, so confirm what the requesting party will accept as evidence

Open-source tools that produce testing and incident evidence

GOVERN 4.3 asks for organizational practices that make AI testing, incident identification and information sharing possible. The three tools below each produce one kind of record an assessor can read: probe results for models, traces for runtime behavior, and case files for incidents. Confirm each tool's license terms and fit with your environment before you rely on its output.

Model probing with garak

garak is an Apache-2.0 scanner that probes language models for hallucination, data leakage, prompt injection, misinformation, toxicity generation and jailbreaks. Each run writes a JSONL report of every attempt and evaluation, plus a hit log of attempts that found a vulnerability. That pairing gives a testing team a complete record of what was tried, not only what failed. Check which probes cover your use case, and confirm that your testing policy defines who reviews the hit log and how findings reach the system owner.

Runtime traces with Langfuse

Langfuse is an MIT-licensed observability platform for LLM applications. Each trace records every operation in a request, including LLM calls, retrieval steps, tool executions and custom logic, with timing, inputs, outputs, token usage and metadata. Traces show how a deployed system behaved, which supports the monitoring and limitation records GOVERN 4.3 expects. Confirm that your retention and data handling rules allow storing prompts and outputs, since traces often contain personal data.

Case management with DFIR-IRIS

DFIR-IRIS is an LGPL-3.0-or-later incident response platform that keeps each case as one record of assets, indicators of compromise, tasks and evidence, with a full audit trail. It triages alerts from SIEM, EDR and REST sources into cases and builds a consolidated investigation timeline. Its reports draw on case data, which helps document incidents for internal and external disclosure. Review the LGPL terms with counsel if you plan to modify the software, and confirm that alert sources in your stack are supported.

Evidence integrity in DFIR-IRIS

DFIR-IRIS logs evidence with SHA-256 verification and chain of custody. For AI incidents, this matters when a model output, log extract or prompt sample becomes the basis for a disclosure or a regulator inquiry. Hash records show that an artifact has not changed since it was logged. Ask your legal and security leads which evidence must be preserved and for how long, and confirm that the platform's custody records meet those rules before you treat them as sufficient.

Who owns GOVERN 4.3 and what a partner can take on

The organization owns GOVERN 4.3 in full. Its leadership decides what its AI systems are allowed to do, which limitations must be disclosed, how incidents are classified and which ones are reported outside the company. No partner can make those calls on its behalf, because the risk decisions and the accountability for them stay inside the organization. Policies that equip AI testing, commitments to identify and share system limitations, and procedures for reporting and publicly disclosing AI incidents are internal documents that the organization approves and enforces.

Policy ownership: approving the policy that requires testing before deployment and sets who can sign off a release.
Limitation disclosure: deciding which known limitations go to deployers, users or affected parties, and in what form.
Incident accountability: naming an incident owner, setting severity thresholds and deciding on external disclosure.
Testing resources: funding testers, test environments and time for red teaming, and protecting testers who report uncomfortable findings.
Reporting records: keeping the incident register and reviewing it at a set cadence.

Check that each of these duties has a named role in your organization, not only a team name, and that the people holding them have the authority to stop a release.

Where organizations usually fall short on GOVERN 4.3

GOVERN 4.3 asks whether the organization's practices make AI testing, incident identification and information sharing possible. The gaps below tend to appear in the same place: testing and incident handling that happen informally, with no policy, record or disclosure path behind them. Each card names one gap and the step that closes it.

Testing without a governing policy

Teams run evaluations when someone remembers to, with methods chosen case by case. GOVERN 4.3 expects policies that equip testing of AI systems, so testing has a defined scope, owner and cadence. Check whether your policy names which systems require pre-deployment and ongoing testing, who signs off on results, and what happens when a test fails. Closing step: write a testing policy that ties each high-impact system to a named test owner and a minimum test set, and review it against your AI inventory.

Incidents handled in chat

A model produces harmful output, a user reports a wrong answer, or a red-team finding surfaces in a direct message, and the fix ships without a record. The Playbook suggests procedures for reporting, documenting and handling AI incidents, and a chat thread cannot show what happened, who acted or when. Closing step: route every AI incident through one intake channel that opens a ticket or case with a unique identifier, so the discussion stays linked to a record.

Incident reports missing minimum fields

Incident reports often record what broke but omit the fields needed to compare incidents later. NIST AI 600-1 lists minimum fields for generative AI incident reports, including system ID, title, reporter, date of incident, description, impacts and stakeholders affected. Check whether every report template captures those fields and whether reports are reviewed before closure. Closing step: adopt a standard report template with the minimum fields as required inputs and reject submissions that leave them blank.

Limitations kept inside engineering

Engineers often know where a model fails, such as weak performance on certain inputs or unsupported languages, but deployers and users never see it. GOVERN 4.3 calls for a commitment to identify system limitations and share them with appropriate AI actors. Ask whether known limitations appear in release notes, deployer documentation and user guidance, and who owns updating them. Closing step: keep a limitations register per system and assign each entry to a named owner responsible for sharing it with deployers and users.

Generative AI incidents outside security processes

Prompt injection, data leakage and jailbreaks are often treated as product bugs and never reach the security incident process, which is where forensic handling and evidence control already exist. NIST AI 600-1 ties GOVERN 4.3 suggested actions to data privacy, information integrity and information security risks, so these incidents need the same triage as other security events. Check whether your security team receives generative AI findings and whether the two processes share severity levels. Closing step: map generative AI incident categories into the existing security incident workflow and agree on who declares severity.

Questions buyers ask about GOVERN 4.3 cost, time and effort

Can an organization get certified against GOVERN 4.3 or the NIST AI RMF?

No. The NIST AI RMF is a voluntary framework, and NIST does not run a certification, accreditation or conformity assessment program for it. NIST also states that it does not validate or endorse any individual organization's use of the framework. What an organization can do is show, through its own documents and evidence, how its practices for AI testing, incident identification and information sharing work. An independent auditor may review that evidence against a customer or contract requirement, but that review is an assessment of the organization's claims, not an AI RMF certificate. Any vendor offering an AI RMF certificate should be questioned closely before a contract is signed.

How long does GOVERN 4.3 work take and what sets the pace?

The pace depends on scope rather than on a fixed period. The main drivers are the number of AI systems in use, whether they are built in-house or bought, how many teams handle testing and incidents, and how far current testing and reporting practices already reach. Organizations with a clear inventory and existing incident tickets usually need less time to document the practices than organizations starting from informal habits. The work is fixed-scope when agreed with DeployOpen, so the timeline is set in the written scope before work begins. Ask any provider to tie its timeline to named systems, named deliverables and named reviewers.

Can our own team implement GOVERN 4.3 without an outside partner?

Often yes, at least for the policy and process layer. The GOVERN 4.3 outcome asks for organizational practices, such as policies that support AI system testing, a commitment to disclose system limitations to relevant AI actors, and procedures for reporting, documenting, handling and publicly disclosing AI incidents. Those are governance decisions the organization owns. Where an outside partner adds value is in preparing the technical side: test environments, logging of AI interactions, and incident case tracking. Whichever route is chosen, the organization owns its controls and decides who signs off on the policies.

What does the work require from our staff?

The NIST AI RMF Playbook tags GOVERN 4.3 to three AI actor groups: testing, evaluation, verification and validation (TEVV), operation and monitoring, and governance and oversight. Your organization should expect to name people from each group, including a policy owner, the people who run tests, and the people who handle incident reports. Staff need time to write procedures, review test results, and take part in incident drills. The actor tasks are described in AI 100-1 Appendix A, which is a useful starting point for role assignment.

What should a quote for GOVERN 4.3 work include?

A quote should follow from a written scope and list each deliverable separately. Ask for the systems in scope, the policies and procedures to be drafted or reviewed, the test environments or tooling to be set up, the incident record fields to be defined, and the handover and training included. Also ask which items are one-time work, such as drafting policies and configuring tools, and which recur, such as retesting after a model change, updating incident records or supporting reviews. Confirm who is responsible for each deliverable, what the organization must provide, and what happens if the scope changes. DeployOpen does not publish a price list, so a quote is produced from the written scope.

How does the pending NIST AI RMF revision affect GOVERN 4.3?

NIST says AI RMF 1.0 is being revised as part of the White House AI Action Plan and has not yet published a revised version. The July 2025 AI Action Plan recommends removing references to misinformation, diversity, equity and inclusion, and climate change. The GOVERN 4.3 outcome concerns testing, incident identification and information sharing, so its core practices are likely to remain relevant, but wording may change. NIST also says the Playbook will be updated after the framework is revised. Build your documentation so that each practice is tied to the outcome rather than to specific Playbook text, and review it when NIST publishes the revision.

What evidence would an auditor expect to see for GOVERN 4.3?

An auditor would look for evidence that the practices exist and are followed. Typical evidence includes a written testing policy, records of tests run against AI systems, a list of known system limitations and who they were shared with, and an incident procedure with completed incident records. The Generative AI Profile suggests minimum fields for generative AI incident reports, including system ID, title, reporter, date of incident, description, impacts and stakeholders affected. Keep records that show the procedure was used in practice, not only written. Ask the auditor early which evidence they will accept and in what format.

How DeployOpen prepares GOVERN 4.3 testing and incident evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so the testing, incident records and disclosure practices behind GOVERN 4.3 run in systems you control. We prepare the systems and evidence; your organization owns its policies and decisions, and any assessment report comes from an independent auditor.

How we scope

Engagements are fixed-scope, with the testing workflows, incident categories and reporting paths agreed in writing before work starts.
The written scope names which AI systems, teams and environments fall under GOVERN 4.3 testing and incident records.
We confirm with you which policy owners approve testing rules, limitation disclosures and public incident statements.

How we build

We deploy evaluation tooling such as garak, which writes JSONL reports of every probe attempt and a hit log of findings.
We configure tracing with Langfuse so requests, retrieval steps and tool calls leave timestamped records for incident review.
We set up DFIR-IRIS cases with an audit trail, timeline, evidence hashing and chain of custody for AI incident handling.

How we hand over

We document incident report fields, such as system ID, reporter, date, description, impacts and stakeholders affected, in templates your teams can reuse.
We deliver runbooks showing how testing results, limitation notices and incident reports are stored, reviewed and escalated.
We hand over evidence packages mapped to GOVERN 4.3 subcategories, ready for your internal review or an independent auditor.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
Retainers can keep test suites, tracing configuration and incident templates current as your AI systems change.
Ask us to confirm in writing which parts of the evidence remain your responsibility after handover.