GOVERN 6.2 Contingency for third-party failures: evidence guide

What GOVERN 6.2 asks for when a third-party AI system fails

GOVERN 6.2 asks the organization to have contingency processes ready for failures or incidents in third-party data or AI systems that it has deemed high-risk. If your team depends on a vendor model, API or dataset that cannot be allowed to stop, this subcategory expects you to decide in advance what happens when that dependency fails, degrades or is withdrawn, and who acts. The AI RMF is voluntary, and NIST does not offer a certificate for it, so there is no external test that confirms you have done this. The only way to show it is through your own documented plans and the evidence that you have exercised them. The difficulty is structural. Vendors rarely expose model weights, training data or internal change schedules, so you may learn about a model update or outage only after your outputs have shifted. A single hosted endpoint can become a single point of failure for a customer-facing process. The NIST AI RMF Playbook suggests planning for third-party system failures, including redundancy for vital third-party AI systems, and checking that incident response plans cover third-party AI. NIST AI 600-1 adds generative AI actions for incident response plans covering third-party generative AI, redundancy of model weights and other artifacts, and testing rollover and fallback options, which may include manual processing.

Start by listing which third-party AI and data services are high-risk in your own assessment, then ask three questions for each: what breaks if it stops, how quickly you would notice, and whether you hold a copy of the artifacts needed to run a substitute. Where the answer to the last question is no, the contingency plan is weak regardless of the document. Confirm with each vendor what artifacts, exports or contractual rights you can rely on, since NIST does not specify these and the terms vary by provider. Then test the fallback. A manual or simpler process that has never been run is an assumption, not a contingency. Record the exercise, the decision owner and the time taken, and feed the results into your incident response plan. Your readiness work should be scoped in writing before an implementation partner or assessor touches it, because that partner can prepare the runbooks, backups and evidence, but the decision to accept residual risk stays with your organization.

Which third-party AI and data systems fall under GOVERN 6.2

GOVERN 6.2 applies only to third-party AI and data systems the organization has deemed high-risk. Scoping starts with deciding which systems qualify, which of them are vital, which teams own the contingency, and which vendors sit inside that boundary. The cards below walk through those decisions using the actor roles the Playbook tags to this subcategory.

Vendor AI in deployment

Start with every third-party AI system the organization puts into production, including models embedded in SaaS tools and APIs called from internal applications. The Playbook tags GOVERN 6.2 to the AI Deployment actor category, so the people who put these systems into service own the first inventory entry. Check that each entry records the vendor, the hosting location, the business process it supports and whether a non-AI alternative exists. Without that record, no contingency can be tied to a system.

Operators who run vendor systems

The Operation and Monitoring actor category covers the staff who run third-party AI day to day and watch its outputs. They know which outputs drive decisions and which failures would surface first. Ask them to name the systems whose outage would stop a customer-facing or regulated process. Those answers help decide which third-party systems count as vital for redundancy planning.

Testing and evaluation owners

The TEVV actor category covers people who test, evaluate, verify and validate AI systems. For GOVERN 6.2, they confirm whether a vendor system can be rolled over to a backup or fallback, including a manual process, and whether that fallback has been tested. A high-risk designation should not rest on a vendor's marketing material alone, so their test results form part of the decision.

Third-party entities in scope

The Third-party entities actor category names the vendors, model providers and data suppliers themselves. Scope them by contract: which suppliers provide model weights, hosted inference, training data or components that the organization cannot replace quickly. Ask each supplier what it commits to on incident notice and on service continuity. Suppliers that only provide low-impact tools may fall outside the high-risk boundary.

Owners of the contingency plan

Decide which internal team owns the contingency for each high-risk third-party system and who can authorize a switch to fallback. Ownership usually sits with the business process owner, supported by platform engineering and security. Record the named owner in the inventory and in the incident response plan. An unowned third-party system has no one to trigger the plan during an outage.

Third-party data feeding AI

Third-party data sources that train, fine-tune or ground an AI system can fail as badly as the model. A feed that stops, changes schema or is withdrawn can degrade outputs without any visible error. Include data suppliers in scope when their feed is hard to replace. Confirm the organization holds a copy or a substitute source, and that the incident response plan covers a data supplier outage.

How an assessor tests contingency for third-party AI failures

This table compares what a reviewer typically samples, asks for and flags when testing GOVERN 6.2, since NIST publishes no assessor program and your internal audit, customer or regulator sets the test. Read each row as a question the reviewer will ask and the evidence that answers it. The main takeaway is that a plan on paper is weak evidence; reviewers look for proof that fallback paths were exercised.

Test area	What the reviewer samples or asks	Evidence that satisfies it	Common finding
High-risk vendor sampling	Which third-party AI or data systems are classified high-risk, and are they the ones tested?	Current AI inventory extract with criticality ratings and a dated risk classification for each vendor dependency	Vendor list exists but no criticality rating links it to contingency work
Failover runbook review	Does a documented procedure say what to do when a vendor model, API or data feed fails?	Versioned runbooks with owners, trigger conditions, switchover steps and manual processing procedures	Runbook names a fallback that no longer exists or has no named owner
Redundancy of vital AI systems	Are alternative models, model weights, prompts or data sources retained and accessible?	Architecture diagrams, artifact inventories and documented restore or redeployment steps for backup components	Single vendor endpoint with no stored artifacts or exit path
Incident response plan coverage	Do incident response plans name third-party AI providers, escalation contacts and notification duties?	Incident response plan sections for vendor incidents, contact matrices and vendor notification clauses in contracts	Internal plan covers outages but ignores vendor-caused model drift or data corruption
Evidence of tested fallback	Has the fallback been exercised, and what happened when it ran?	Dated test records, tabletop or failover exercise reports, timings observed and corrective actions tracked to closure	Only a plan exists; no exercise has been run or results were not recorded
Backup and restore integrity	Can stored data and artifacts be restored and shown to be unmodified?	Backup job logs, restore test records and integrity verification output for the artifacts the fallback depends on	Backups run successfully but restore has never been tested
Change and decommission alignment	Do contingency plans update when a vendor changes a model version or ends service?	Change records linked to vendor notices and revised runbooks dated after each change	Runbooks reference a retired model version

Implementing contingency for vital third-party AI, step by step

This sequence turns GOVERN 6.2 from a policy statement into a working contingency program: it identifies which third-party AI systems matter most, prepares fallbacks for them, brings vendors into incident response, and proves the fallbacks work through testing. Each step produces a record that an assessor or internal reviewer can inspect.

Inventory third-party AI and classify criticality
Start from the AI inventory maintained under GOVERN 1 and list every AI system, model, API or data feed supplied by an outside party. Owners of each business process classify them by the harm a failure would cause, using the risk criteria the organization already set for high-risk AI. The accountable owner approves the classification list. The output is a dated register that marks which third-party systems are deemed high-risk and therefore in scope for redundancy and incident response planning.
Document dependencies and recovery artifacts
For each high-risk system, record what the organization depends on: the vendor's service and its subprocessors, model versions, APIs, training or fine-tuning data, configuration, prompts, integrations and the people who operate it. Note which artifacts the organization can hold itself, such as exported configurations, documentation, evaluation sets and copies of approved outputs, and which exist only at the vendor. Confirm contract terms that govern data return, exit assistance and service notice. The output is a dependency map reviewed by platform and procurement owners.
Define redundancy and fallback options
For each high-risk system, decide the fallback path: a second provider or model, a self-hosted alternative, a degraded mode, or manual processing performed by trained staff using documented procedures. The Generative AI Profile specifically lists redundancy of model weights and other system artifacts as a concern, so confirm that the organization can actually run the fallback on the artifacts it holds. Record the trigger conditions, decision owner and expected operating limits for each option. The output is a signed fallback specification per system.
Extend incident response plans to vendors
Update the incident response plan so that vendor failures, outages, security incidents and unexpected output changes have their own playbooks. Define how the organization learns of a vendor incident, who contacts the vendor, which contractual notice clock applies, when fallbacks are activated, and how affected users and downstream AI actors are informed. Confirm that the plan covers AI-specific failures such as harmful or inaccurate output, not only infrastructure outages. The output is a revised plan that names the third-party AI systems it covers.
Prepare case tracking and evidence handling
Set up the tooling that will record vendor incidents so that they can be reviewed later. Open-source options such as DFIR-IRIS can hold each incident as one case with its assets, tasks, timeline and evidence, with an audit trail. Backup and restore tools such as Bareos or restic can support recovery of organization-held artifacts, and restic's check command can confirm stored data is unmodified. Confirm these tools meet your own retention and integrity requirements before relying on them. The output is a tested case template and a documented backup verification schedule.
Test rollover and fallback operation
Run tabletop exercises and, where feasible, controlled failover tests for each high-risk system. Simulate a vendor outage, a material change in model behavior and a withdrawn API, and measure whether staff can switch to the fallback and operate it within the limits set in step three. Record what failed, who decided, and what manual processing was needed. Tests should be repeated when the vendor, model version or fallback changes. The output is a test report with findings and owners for each gap.
Record outputs and close findings
Compile the outputs of each step into one contingency file per high-risk system: classification, dependency map, fallback specification, plan extract, test results and open findings. Track each finding to closure and feed lessons into the next review of the third-party AI inventory and vendor terms. Senior accountable owners review the file on a schedule the organization sets and sign off changes. The output is a maintained record that shows the contingency process is operating, which is the evidence most reviewers will ask to see.

Redundancy, model artifacts and manual fallback for vital AI

For a vital third-party AI system, redundancy means your organization can keep a critical process running when the vendor's model, API or hosting fails. NIST AI 600-1 frames this under GOVERN 6.2 with three practical questions: whether you have an alternate path, whether you hold copies of what you need to run it, and whether people can do the work by hand. The Generative AI Profile's actions GV-6.2-003, GV-6.2-005 and GV-6.2-006 ask organizations to address redundancy of model weights and other system artifacts, and to test rollover and fallback options, which may include manual processing. Start by listing each third-party AI component that a high-risk process depends on, then record for each one whether an alternate provider, a retained artifact or a manual procedure exists today.

Retained copies of model weights or other artifacts are only an option where the license allows it. Many commercial model terms restrict downloading, storing outside the vendor's environment or using outputs to build a replacement, and some vendors provide no weights at all. Before you assume you can keep a copy, confirm the contract terms with the vendor and with your legal team, including export of configuration, prompts, evaluation datasets and logs, and what happens to access on termination. Where weights are open and licensed for redistribution, your team can hold them in its own repository, but it should still verify that the stored copy matches the version it tested, because an artifact you cannot run or identify is not a contingency.

Rollover testing is where a plan proves itself. Schedule tests that switch a live or realistic workload to the alternate provider, to a retained artifact or to the manual procedure, and record how long the switch takes, which outputs change, which controls still apply and who approves the decision. Keep the manual path staffed with people who have been trained on it, and make sure the incident response plan names the trigger for invoking it. These tests belong in the same evidence set as your incident records, so an assessor can see that the fallback was exercised and not only written down.

Evidence that shows third-party contingency works

GOVERN 6.2 asks whether an organization can keep going, and recover, when a third-party AI or data system fails. The artifacts below show that the plan exists, names the vendors it depends on, and has been exercised. Keep each one dated and owned, and refresh it on a fixed cycle so it still matches the production system when someone asks for it.

Criticality register for third-party AI

A register that lists every third-party model, API, dataset and data feed the organization relies on, with a criticality rating and a named business owner for each. Rate criticality by impact on the AI system's outputs and on the business processes that consume them. Review the register when a vendor changes its model, terms or hosting location, and at least at each planned AI inventory review. Check that every item marked high-risk has a contingency entry that points to a specific runbook.

Dependency and artifact inventory

A map of what each high-risk AI system needs to run: vendor model versions, model weights or copies held in-house, embeddings, prompts, configuration, and the data pipelines feeding them. The inventory shows which artifacts the organization can reproduce without the vendor and which it cannot. Regenerate it whenever a deployment changes, and reconcile it against actual running components so gaps do not hide between reviews.

Contingency and fallback runbooks

Step-by-step procedures for each high-risk third-party failure: switching to a secondary provider or a self-hosted model, reverting to a previous version, or routing work to manual processing. Each runbook should name the trigger, the decision owner, the time to execute and the rollback criteria. Confirm with each vendor which contractual and technical options exist before writing the runbook, since outage terms and export rights differ by contract.

Vendor-inclusive incident response plan

An incident response plan that covers AI and data incidents originating at a third party, not only incidents inside the organization's own environment. It should set vendor notification duties, escalation contacts, evidence preservation steps and communication to affected users. Test that the plan works with each high-risk vendor's support path. Review it after any change to vendor contracts or to the incident tooling that records case data and evidence.

Rollover test records

Dated records of exercises in which the organization switched to a fallback provider, restored a backed-up model artifact, or ran a manual process in place of the AI system. Each record should state the scenario, the time taken, the gaps found and the corrective actions assigned. Retest after material changes to the primary system, and keep the records even when a test fails, since failed tests show the program is working.

Post-incident reviews

Written reviews after each incident or near miss involving a third-party AI or data system, covering root cause, the vendor's role, whether the contingency plan worked, and the changes made to runbooks, contracts or the inventory. Track each action to closure with an owner and date. Reviews are the clearest evidence that the contingency program learns, so retain them with the incident case and link them to the affected inventory entries.

What meeting GOVERN 6.2 costs in money and effort

This table lists the cost components of meeting GOVERN 6.2, who is paid for each, whether it is one-time or recurring, and what drives it up or down. No figures are given, so use the drivers and quote questions in the right-hand columns to request a fixed-scope quote from written scope.

Cost component	Who is paid or who carries the work	One-time or recurring	What drives the cost
Tooling and licenses	Software vendors for commercial incident response, backup or GRC tools; none for self-hosted open-source tools with permissive or copyleft licenses	Licenses recur; deployment is one-time	Number of vital vendors in scope, user counts, and whether tools are commercial or open source. Ask whether the quote includes subscription and support fees.
Engineering time for redundancy	Internal platform engineers or an implementation partner for fallback paths, second model or provider options, and backup of model weights and artifacts	One-time design and build, then recurring maintenance	Number of high-risk third-party AI systems, how many can be swapped or run in fallback mode, and how much manual processing is kept as a fallback. Ask for the design scope in writing.
Incident response plan updates	Internal security and AI owners, with optional outside facilitation	One-time drafting, recurring review	Number of vendors whose incidents must be covered, and how often playbooks change after vendor or model updates.
Rollover and fallback testing	Internal operations teams, testers or an implementation partner who runs the exercises and records results	Recurring	Frequency of tests, number of vendors and systems tested per cycle, and whether manual fallback is exercised end to end. Ask how many test cycles are included in the quote.
Evidence upkeep	Internal compliance or GRC staff, sometimes supported by tooling that stores test results, restore logs and incident records	Recurring	Evidence volume, how often vendor documents change, and how much case data is collected per incident. Ask how evidence is stored and retained.
External review	Independent reviewers or consultants who check the design and test records before an assessment	Usually one-time per cycle, sometimes recurring	Scope of the review and the number of systems covered. This review is advisory and does not produce an audit report or certificate.
Auditor sampling	The organization pays the independent auditor or assessor, who samples evidence for the scope they test	Recurring with each assessment cycle	Number of vital vendors in the audit scope, sample sizes the auditor selects, and how well evidence is organized. Ask the auditor for its sampling approach in advance.

Who owns GOVERN 6.2 and what a partner can take on

Your organization owns the outcome that GOVERN 6.2 describes: contingency processes for failures or incidents in third-party data or AI systems that are deemed high-risk. That ownership cannot be handed to a vendor or consultant, because the decisions about which dependencies are vital, what downtime is tolerable and which residual risks to accept belong to accountable staff. Your team also decides whether a manual or degraded process is acceptable when a third-party model or data feed fails.

Criticality decisions: Decide which third-party AI systems and data sources are high-risk and therefore in scope for redundancy and fallback planning.
Risk acceptance: Record who accepts residual risk for each dependency that has no practical alternative, and under what conditions.
Fallback choices: Choose between redundancy, rollback, manual processing or suspension for each vital system, and approve the cost of that choice.
Vendor terms: Set the notification, cooperation and exit expectations that you will hold each provider to during an incident.
Plan approval: Approve the incident response plan and confirm that it names third-party AI systems explicitly.

Before relying on any plan, confirm with your legal, procurement and risk owners who signs each decision and where those approvals are stored.

Where third-party contingency plans usually fall short

Most organizations have a business continuity plan and an incident response procedure, but few connect them to the AI vendors, models and data sources they depend on. The gaps below show where a contingency process for high-risk third-party AI tends to break down under GOVERN 6.2, and what to check first.

Plans that never name the vendor

A contingency plan that says "the AI provider" without naming the service, the contract owner, the region and the failover contact cannot be executed at 2 a.m. For GOVERN 6.2, start with an inventory of every high-risk third-party AI system and the vendor behind each one. Check that each entry lists who can switch traffic, who signs off on a suspension, and how the vendor can be reached during an outage. Illustrative: a credit scoring model hosted by one vendor with no named backup path.

Fallback paths that were never tested

A fallback that exists only on paper is not redundancy. The Generative AI Profile suggests testing rollover and fallback options, which may include manual processing. Ask whether the team has run the fallback under realistic load, how long a switch takes, and whether staff can perform the manual steps without the AI system. Record each test result as evidence that the contingency works.

No inventory of model artifacts

Redundancy for a third-party model depends on knowing what exists: model weights, configuration, prompts, fine-tuning data, embeddings and evaluation sets. Many organizations cannot say where a copy of these artifacts lives or whether it is current. Confirm that each vital artifact has a recorded owner, a storage location and a version, and that the copy sits outside the vendor's control.

Redundancy without verified backups

Keeping a copy of model weights or pipeline state only helps if it can be restored intact. Verify that backup jobs cover the artifacts listed in the inventory and that restore tests run on a schedule. Open-source tools such as restic can read pack files back to confirm stored data is unmodified, which gives the team evidence that the redundant copy is usable rather than assumed.

Incident response that stops at the boundary

Incident response plans often cover internal systems and skip the steps needed when a vendor is the source of the failure. The Playbook suggests verifying that incident response plans address third-party AI systems. Check that the plan defines who contacts the vendor, what evidence the vendor must provide, how the organization records the timeline and who decides whether to suspend the system.

Vendor incidents with no case record

When a vendor incident affects several systems, responders need one record of affected assets, indicators, tasks and evidence. Tools such as DFIR-IRIS keep each case as a single record with an audit trail and a consolidated timeline. Confirm that vendor-caused incidents open a case in the same system as internal ones, so the post-incident review can show what failed, when it was detected and how it was contained.

How much effort does GOVERN 6.2 take, and can we do it ourselves?

Is there a fixed price for doing GOVERN 6.2 in our organization?

No published price exists, and DeployOpen does not publish one. GOVERN 6.2 is an outcome that your organization must reach, so the cost depends on how many third-party AI or data systems you consider high-risk, how many of those are vital to operations, and how much redundancy, incident response and testing work each one needs. Costs fall into three groups: internal staff time for risk decisions and ownership, technical work to build or verify fallback paths and backups, and any outside help you buy for planning, implementation or evidence preparation. Ask for a quote built from a written scope that lists the systems in scope and the deliverables.

How long does it take to put GOVERN 6.2 contingency processes in place?

The duration depends on how many high-risk third-party AI and data systems are in scope, how mature your current incident response plan and backup practice are, and how many vendors must agree to cooperate on failover details. No timeline figure is supplied for this work, so confirm one against your own environment before committing. A useful sequence is to identify the high-risk systems first, then document failure scenarios, then build and test fallback paths, and finally update incident response plans so they cover vendor-hosted AI. Ask any partner to split the timeline by these phases in the written scope.

What does the work need from our team?

The work needs decisions and ownership from people who know the business, plus engineering time for technical changes. Typical roles include a risk owner who decides which third-party AI systems are high-risk, platform or infrastructure engineers who configure redundancy and restore paths, security staff who extend the incident response plan to cover vendors, and procurement or legal staff who confirm what vendors must provide during an outage. The Playbook suggests planning for third-party failures and verifying that incident response plans address third-party AI systems, so these owners must agree on those actions. Name each role in the scope and confirm availability before work starts.

Can we do GOVERN 6.2 ourselves without an outside partner?

Yes, a capable internal team can do this work, because the AI RMF is voluntary and it does not require an external provider. The main questions are whether your team has the time, the infrastructure skills and the independence to test failover honestly. Teams often keep ownership and risk decisions in-house and bring in a partner for specific technical work, such as building a self-hosted backup and restore path or running fallback tests in a controlled environment. Whichever route you choose, the organization owns its controls. An implementation partner prepares systems and evidence, and only an independent auditor or assessor issues any report.

Is there an audit or certificate that proves GOVERN 6.2 is met?

No. The NIST AI RMF has no certification, accreditation or conformity assessment program, and NIST does not validate or endorse any organization's use of it. Any firm that offers an AI RMF certificate is not offering a NIST program. Your customers or regulators may still ask for evidence, so you should prepare documents, test records and vendor agreements that show how your contingency work was designed and tested. If a customer or regulator requires an independent opinion, ask the requesting party which assessor they accept and what evidence format they expect.

What should we request in a quote for GOVERN 6.2 work?

Ask for a written, fixed-scope proposal that names each third-party AI and data system in scope, its risk classification basis and the failure scenarios to be covered. The quote should list deliverables such as the contingency design, fallback and redundancy configuration, backup and restore tests, updated incident response procedures and an evidence register. It should separate one-time build work from recurring items such as testing, vendor reviews and plan updates, and state which tasks your staff must perform. Also ask what is excluded, how changes to scope are priced and who signs off on acceptance.

How self-hosted tools support contingency evidence

Self-hosted open-source tools can produce much of the evidence an assessor will ask for under GOVERN 6.2, but they do not decide whether a third-party AI failure is high-risk or whether a fallback is acceptable. The organization owns those decisions. Its job is to make sure that when a vendor's model, data feed or hosted service fails, the response is recorded in a form that someone independent can later inspect. DFIR-IRIS is the most direct fit for the incident side. It keeps each case as one record of assets, indicators of compromise, tasks and evidence, with a full audit trail, and it can triage alerts from SIEM, EDR and REST sources into cases. It also builds a consolidated investigation timeline and logs evidence with SHA-256 verification and chain of custody. Reports are generated from case data, so the vendor-related incident file can be reproduced from the record rather than rebuilt from memory.

Backup and restore evidence supports the fallback side of the outcome, including the redundancy and rollover actions that NIST AI 600-1 lists for generative AI. Bareos (AGPL-3.0-only) schedules and supervises backup, restore, verify and archive jobs, keeps a SQL catalog of backed-up files, and can restore files from the current backup or from one taken before a given date and time. That catalog is useful when an assessor asks which copy of a model artifact, configuration or prompt set was available on a specific date. restic (BSD-2-Clause) offers a check command that verifies the structural consistency of snapshots, trees and pack files, and with --read-data or --read-data-subset it reads pack files back to confirm the stored data is unmodified. Run the check on a schedule and keep the output. A restore test is still required, because a passing check shows the data is intact, not that a system can run on it.

CISO Assistant (AGPL-3.0-only) ships more than 200 frameworks, including ISO 27001, NIST CSF, SOC 2, PCI DSS, NIS2, DORA and GDPR, and can run audits and assessments against them with automatic mapping between frameworks. For GOVERN 6.2, its value is tracking which contingency evidence supports which obligations, so that one incident exercise or restore test is not written up separately for every framework. Before relying on any mapping, confirm with your compliance lead that it matches the mapping your auditor or customer accepts, because automatic mapping is a starting point, not an agreed equivalence. Also check each license with your legal team, since AGPL-3.0 terms can affect how modified code is shared if you customize these tools, and confirm that each tool fits your hosting, identity and retention requirements before you commit.

How DeployOpen works on this

DeployOpen treats GOVERN 6.2 as an engineering and evidence task. We scope which third-party AI and data systems your organization has deemed high-risk, then plan redundancy, fallback and incident response for them inside your own infrastructure. Your organization owns the policy and the decisions, and an independent assessor issues any report.

How we scope

We confirm which third-party AI and data systems your organization has classified as high-risk before any build work starts.
The written scope lists the vendor dependencies, failure modes and fallback paths covered for GOVERN 6.2 contingency for third-party failures.
Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work begins, and the quote follows from that scope.

How we build

We set up backup and restore jobs for model artifacts, configuration and data using Bareos, with restore points you can select by date and time.
We configure restic repositories and verification runs so stored backup data can be read back and confirmed as unmodified.
We test rollover and fallback paths, including manual processing where a third-party AI service becomes unavailable, and record the results.

How we hand over

We deliver incident response playbooks that name third-party AI vendors, escalation contacts and decision points for your own staff.
We load incident cases into DFIR-IRIS, with assets, timelines and evidence logged under chain of custody for later review.
We document the contingency design, test records and open items so your assessor can trace each claim back to a working control.

How we support

Ongoing support, upgrades and continuous testing of contingency paths are available as a retainer after handover.
Retainers can cover periodic restore tests and tabletop exercises that include vendor failure scenarios, as agreed in writing.
Ask us to confirm the current version and capabilities of each tool in your environment before relying on it for evidence.