Should you hire a NIST AI RMF consultant or keep the work in-house?
When a customer, contract or regulator points to the NIST AI RMF, the organization still owns the work. Governance, accountability and risk decisions stay in-house, because the framework expects the organization itself to set policy, assign roles and accept residual risk. Outside help usually fits narrower tasks: independent testing, red teaming and an outside review of the evidence the program produces. NIST does not certify, accredit or endorse any organization or assessor for its use of the AI RMF, so no one can issue an AI RMF certificate, and any firm claiming one is making a claim NIST does not support. The right split depends on your size, the number and risk of your AI systems, and how much testing capacity your internal teams already have.
MEASURE 1.3 describes regular assessments that involve internal experts who were not front-line developers and, where possible, independent assessors. Section 5.3 of AI 100-1 says independent review can improve testing and reduce internal bias and conflicts of interest. The Playbook's suggested actions for GOVERN 2.1 go further by separating AI development functions from testing functions so that course correction can be independent. In practice, a team that builds a model should not be the only team that tests it or signs off its results. Confirm early whether your internal testers sit outside the development line. If they do not, plan for an outside evaluator on the highest-impact systems, and write that decision into your governance documents before a customer asks for it.
Red teaming is the area where outside expertise is most often needed. AI 600-1 notes that the quality of red-teaming output depends on the background and expertise of the red team, and that teams should understand the domain and the deployment context. It also says results need further analysis before they inform governance decisions. When you scope outside work, ask who on the team has domain knowledge of your deployment, how findings will be triaged and who decides which results reach your risk owners. Keep ownership of the response: the outside team can document what it found, but your accountable executives still decide go, no-go and residual risk. Ask any provider to state its scope in writing, including what it will test, what it will not test and what evidence it will hand over.
Which AI RMF work to keep in-house
NIST leaves the AI RMF's governance, risk decisions and daily monitoring with the organization that deploys the system, because those are the decisions that carry its accountability. The cards below cover the work an in-house team must own and be able to show, so that any outside assessor has something concrete to test.
Governance and accountability
GOVERN 1 and GOVERN 2 set the policies, documented roles, lines of communication and executive responsibility for AI risk. NIST treats these as the organization's own choices, so an outside firm can draft a policy but cannot decide who answers for AI risk. In-house staff should be able to name the accountable executive, show the approved AI policy and produce the minutes where risk decisions were made.
AI inventory and risk tolerance
Deciding which AI systems exist, what each is for and how much risk the organization will accept are core MAP 1 and GOVERN 1 decisions. An inventory built outside the business will miss shadow tools and procured features. In-house owners should keep a current register of systems, purposes, data sources and the documented risk tolerance each system was approved against.
Go or no-go and residual risk
MANAGE 1 covers the go or no-go determination, risk treatment priorities and documentation of residual risk. Outside assessors can test the reasoning, but the decision to deploy or accept remaining risk belongs to a named owner. In-house staff should be able to show the evidence behind each decision, the people who approved it and the conditions under which it would be reversed.
Workforce training and roles
GOVERN 2 expects AI risk management training and clear human roles in human-AI configurations, which the organization must define for its own operators. Training content can be sourced externally, but the organization decides who needs it and records completion. In-house staff should hold training records, role definitions for human oversight and evidence that operators understand the system's limits.
Day-to-day production monitoring
MEASURE 3 and MANAGE 4 ask for tracking of risks after deployment, including end user problem reports and incident communication. Monitoring runs continuously inside the operating environment, so it is the work least suited to periodic outside help. In-house teams should own the alert paths, incident logs and the record of how reported problems were answered.
Independent testing and review
MEASURE 1.3 and GOVERN 2.1 call for testing by people who were not front-line developers, and for independent review where conflicts of interest exist. Organizations usually keep the internal testing owner and bring in independent assessors or red teams for periodic review. Ask any outside provider for their domain expertise with the deployment context, since AI 600-1 says red team output quality depends on that background.
What NIST says about independence in AI risk testing
NIST expects the people who test an AI system to be separate from the people who build it, but it does not require outside firms. The clearest statement is MEASURE 1.3 of NIST AI 100-1, which describes regular assessments carried out by internal experts who were not front-line developers, and or by independent assessors. The phrasing gives an organization a choice. It can use internal staff who sit outside the development team, bring in an external assessor, or combine both. Section 5.3 of the framework adds the reason: independent review can improve testing and reduce internal biases and conflicts of interest. A team that grades its own work tends to test the scenarios it already expects to pass.
The Playbook makes the same point at the governance level. Its suggested actions for GOVERN 2.1 include separating AI system development functions from AI system testing functions, so that course correction can be made independently. Appendix A of AI 100-1 adds that verification and validation actors should ideally be distinct from the actors who perform test and evaluation. Read together, these passages ask you to decide who can stop a release, who writes the test plan and who signs off on the results. Document those three roles separately, even if a single engineer holds more than one of them in a small organization, and record who approves any exception.
Separation is therefore a design decision you can make with internal staff, and it is the first thing to check before deciding whether outside help adds value. Confirm with your own risk and audit functions whether an internal reviewer meets the independence test your governance body will accept. Where it does not, an external assessor is one option, and the framework leaves the choice of assessor to you. NIST does not maintain an approved assessor list, and its use case pages state that it does not validate or endorse any organization's approach to the framework, so any firm you engage should be assessed on its own method, its conflicts and its evidence trail.
Which outside help fits which AI RMF gap
Independent assessment is the outside review of trustworthiness evaluations that the organization has already run. MEASURE 1.3 describes regular assessments that involve internal experts who were not front-line developers and or independent assessors, and Section 5.3 of AI 100-1 says independent review can improve testing and mitigate internal biases and conflicts of interest. An assessor reviews test plans, metric choices, results and the reasoning behind go or no-go decisions. The assessor brings distance from the team that built the system, but it does not take ownership of the risk decision.
- Independence provided: reviewers outside the development chain who can challenge metric selection and results.
- Scope to agree in writing: which subcategories, which systems and which evaluation records the review covers.
- Evidence the organization owns: the test plans, raw results, risk acceptance records and the decisions made from them.
- Limits: NIST does not maintain an approved assessor list or accreditation program, so ask the firm how its reviewers were qualified for AI evaluation.
- Outputs: a written review memo that the organization decides how to act on.
Confirm with any firm whether it will issue a formal opinion or only advisory findings, because those are different deliverables.
A separate internal testing team keeps evaluation work inside the organization but moves it out of the development chain. The Playbook's suggested actions for GOVERN 2.1 include separating AI system development functions from AI system testing functions so that course correction can be independent. Appendix A of AI 100-1 says verification and validation actors should ideally be distinct from those who perform test and evaluation. This option is often built with staff, sometimes supported by a partner that trains or sets up the testing process.
- Independence provided: reporting lines that keep testers separate from the product team's delivery targets.
- Staffing decision: whether testers come from security, quality engineering or a risk function, and how many are needed for the system portfolio.
- Outside help: a partner can design the test harness and train staff, but the team runs the tests.
- Evidence the organization owns: the team charter, reporting lines, test records and escalation logs.
- Recurring cost: staff time and tooling continue after any setup project ends.
Check whether the testing team can stop a release or only comment on it, since that authority determines how much independence the arrangement really provides.
External red teaming brings in adversarial testers who attack an AI system to find failures the internal team did not anticipate. AI 600-1 says the quality of AI red-teaming outputs depends on the background and expertise of the red team, that red teams should show domain expertise and awareness of the deployment context, and that results need further analysis before they inform governance decisions. The red team finds issues, but the organization must still decide what they mean and how to treat them. For generative systems, the Generative AI Profile is the reference point for the risks to cover.
- Independence provided: attackers with no stake in the system's design choices.
- Expertise to verify: prior work on AI systems in the same domain, and familiarity with the deployment context.
- Rules of engagement: the systems, data, time window and permitted techniques, agreed in writing before testing starts.
- Evidence the organization owns: the findings, reproduction steps, severity analysis and remediation tracking.
- Limits: a red team report is one input to MEASURE, not a complete evaluation of trustworthiness.
Ask the provider to show how it analyzes results before they reach governance, not only how it finds them.
Evaluation procedure design is the work of building a repeatable method for measuring active AI systems, often with an outside partner. San Jose's AI RMF review listed exploring a partnership with a third party on an improved evaluation procedure for active AI systems among its next steps. This option produces a procedure, not a verdict: metrics, test cadence, triggers for re-evaluation, and the documentation each test must produce. The partner contributes method; the organization keeps the procedure in force.
- Independence provided: a method set by people who do not run the system day to day.
- Deliverables to request: the metric definitions, test cadence, sampling approach, escalation thresholds and documentation templates.
- Ownership: the organization must approve the procedure, assign owners and run it after handover.
- Recurring work: procedures need updates when the system, its data or its risk tolerances change.
- Scope questions: which of the 72 subcategories the procedure supports, and which remain manual.
Confirm who maintains the procedure after the engagement ends, since an unowned procedure decays quickly.
Implementation support covers the systems, logging and evidence infrastructure that an AI RMF program needs, usually deployed inside the organization's own environment. This is not independent assurance. The partner helps set up the platforms that record inventories, test results, incidents and approvals, so that the organization can show its work later. Because the partner builds the evidence system, the organization must still judge whether the records are complete and accurate.
- Independence provided: none for assurance; the value is operational.
- Typical work: configuring logging, ticketing and document repositories, and integrating them with test pipelines.
- Scope to agree in writing: systems, environments, retention periods and access controls.
- Evidence the organization owns: the system configuration, logs, access records and the content in them.
- Handover: runbooks, credentials and admin roles transferred to the organization.
Ask for a written list of the records the system produces so the team can verify completeness before an outside reviewer does.
How to judge red teaming expertise before you buy it
The quality of red-team findings depends on who runs the test. NIST's AI 600-1, the Generative AI Profile, says the quality of AI red-teaming outputs depends on the background and expertise of the red team, and that red teams should show domain expertise and awareness of the deployment context. A generic adversarial test of a chatbot will not tell you how a credit decision model or a clinical triage assistant fails. Before you sign a statement of work, ask the firm to describe the sector and data types its testers have worked with, how they learned the deployment context of your system, and which failure modes they would look for first. Answers that stay at the level of prompt tricks or tool names suggest the team lacks the domain depth AI 600-1 describes. Ask for a written test plan that ties each planned attack to a risk your own mapping already identified, since that link is what makes the results usable. Several questions separate domain knowledge from general security skill. Ask how the team would decide that a model output is harmful in your context, and who on your side would confirm that judgment. Ask what they would do if a finding depended on data they could not see, and how they would document the limit. Ask them to explain a past engagement in general terms, such as the kind of failure they found and how the client's controls responded, without naming clients. Ask whether testers will work alongside your system owners during scoping, and whether they will show the test cases and prompts they used so your team can rerun them. Confirm which parts of the work the firm will do in your environment and which parts it will do in its own tooling, because that affects data handling and evidence. These are questions to put to any provider, and none of them presumes a particular firm holds any credential.
Red-team results are input to your decisions, not the decision. AI 600-1 says red-teaming results need further analysis before they inform governance decisions. That work stays with your organization. Your risk owners must decide whether a finding changes the go or no-go determination, which risks need treatment, and what residual risk you accept, as the AI RMF's MANAGE 1 category describes. Plan for an internal review step in which people who did not run the test triage each finding, check its severity against the deployment context, and record the decision and its rationale. Confirm with the provider who owns the raw outputs, how long they are retained, and how they are handed over, because those records will later support your documentation. The independence point also applies here: a red team that was built by the same people who developed the system should not be the only reader of its results. Keeping interpretation in-house is what lets the findings flow into your risk register, your monitoring plan and, where a customer or regulator asks, your evidence file.
Who owns which part of an AI RMF program
The organization owns its AI risk program. The framework is voluntary and NIST does not certify anyone against it, so the organization is the party that decides which AI systems are in scope, what risk tolerance applies, and whether a system goes live. These decisions sit with named people who can be held to account, not with an outside firm. Govern outcomes, such as policies, role assignments and executive responsibility for AI risk decisions, are the clearest examples of work that should stay inside the organization.
- Risk decisions: go or no-go determinations, risk acceptance and residual risk sign-off remain with accountable executives.
- Policy and accountability: the AI policy, documented roles and lines of communication are written and approved internally.
- AI inventory: the organization maintains its own list of AI systems and their owners.
- Operational monitoring: day-to-day tracking of deployed systems and incident response stay with internal staff.
- Independent testers: internal experts who were not front-line developers can perform regular assessments, as the Measure outcomes describe.
Check that each Govern and Manage decision has a named internal owner and that no outside party holds sign-off authority by default.
An implementation partner such as DeployOpen helps the organization prepare its systems, testing and documentation under a written, fixed scope. Typical work includes setting up the platforms that hold AI inventories, evaluation pipelines and logs, drafting documentation against Playbook prompts, and organizing evidence so the internal owners and an assessor can find it. The partner acts on the organization's behalf and under its direction. It does not own the risk decisions and does not issue reports or certificates.
- System preparation: deploying and configuring self-hosted open-source platforms inside the client's own environment.
- Testing services: security testing of applications, APIs, infrastructure and AI systems, where scope is agreed in writing.
- Documentation support: drafting records that the organization reviews, approves and maintains.
- Evidence collection: structuring logs, test results and approvals so they can be produced on request.
- Ongoing support: retainers for upgrades, continuous testing or updates when the framework is revised.
Ask the partner to state in the statement of work which artifacts it drafts, which it only configures, and that the organization approves all final documents.
An independent assessor tests whether the program works and reports what it found. This is the party whose independence a customer or regulator is most likely to question. NIST does not validate or endorse any organization's use of the AI RMF, and it describes no accredited assessor program, so there is no approved list to draw from. Organizations choose assessors on their own criteria, such as domain expertise, familiarity with AI evaluation methods and freedom from conflicts with the system's developers.
- Independent testing: testing performed by someone outside the team that built or configured the system.
- Evaluation procedures: review of metrics, test methods and results against the organization's stated risk tolerance.
- Red team expertise: red teams need domain knowledge and awareness of the deployment context, and their results need analysis before governance use.
- Reporting: the assessor writes its own findings and, where a formal attestation exists, issues it. The implementation partner does not.
- Conflict checks: confirm that the assessor has no role in building, selling or operating the system under review.
Confirm in writing that the assessor's engagement and any report are its own work product and that no implementation firm holds a copy of the final conclusions for editing.
Why there is no approved AI RMF assessor list
There is no list of approved AI RMF assessors, and no firm can truthfully sell an AI RMF certificate. NIST states that it does not validate or endorse any individual organization or its approach to using the AI RMF, and its framework pages, FAQ, Playbook and Roadmap describe no certification, accreditation or conformity assessment program. An outside firm can help you assess against the framework, but the output is a report or readiness review written by that firm, not a NIST credential. Treat any claim of an "AI RMF certified" status as a warning sign that needs an explanation before you sign.
Before you engage anyone, ask four questions in writing. What standard or internal criteria does the assessment use, and does it map each finding to specific AI RMF subcategories? Which independence rules apply, meaning who on the assessor side has built, tuned or sold the system being reviewed? What is the deliverable called, and who signs it? And how will the firm handle the Playbook, which NIST says is not a checklist? Vague answers to any of these usually mean you are buying an opinion you cannot test against anything. Ask for a sample deliverable with names and dates removed so you can judge its structure before the contract is written.
If your customer or regulator specifically asks for an accredited certification, the route is different. ISO/IEC 42006:2025 sets requirements for bodies that audit and certify AI management systems, and it applies to ISO/IEC 42001 rather than to the AI RMF. You can confirm its scope and status directly in the IEC Webstore. Use that check to separate what an accredited certification body can issue from what a consultant can provide, and tell your buyer which of the two you are offering.
How to decide what to outsource in four steps
This sequence sorts AI RMF work into what your own staff can test, what needs a second line of review, and what belongs in a written, fixed scope before any outside party starts. It begins with a scored current profile against the 72 subcategories so every outsourcing decision traces to a stated gap.
Score the current profile against the subcategories
Before deciding anything about outside help, your governance lead scores the current state of each of the 72 AI RMF subcategories across Govern, Map, Measure and Manage. Use a simple scale your team defines and record the evidence behind each score. The output is a current profile that lists which outcomes exist, which are partial and which are missing. NIST describes the Core as non-sequential and not a checklist, so the scoring tells you where to look, not what order to follow. The step is done when every subcategory has a score and a named owner for the evidence review.
Inventory AI systems and their risk
Build or refresh the AI system inventory and rank each system by its mapped risk, using the MAP outcomes for context, intended purpose, categorization and impact. Product, legal, privacy and the business owner usually supply the inputs, and the governance lead approves the ranking. The output is a register that lists each system, its purpose, its impacts and its priority tier. Systems that affect people in high-impact decisions and systems that rely heavily on third-party models should be ranked first. The step is done when every system in scope has a risk tier and a documented owner.
Map outcomes your own staff can test
For each prioritized system, list the GOVERN and MEASURE outcomes your internal teams can test without a conflict of interest. NIST's Measure 1.3 describes regular assessments by internal experts who were not front-line developers, so teams outside the build group are a useful starting point. Also check the Playbook's suggested action under GOVERN 2.1 about separating development from testing. The output is a list that marks each outcome as internally testable, internally testable with a separated team, or needing independent review. The step is done when every high-priority outcome has one of those three labels.
Write the scope before any outside work starts
For outcomes that need independent review or specialist testing, such as red teaming, write the scope as a fixed-scope agreement before work begins. The scope should name the systems, the outcomes, the deliverables, the evidence the provider will hand over, and the people who receive findings. NIST notes that red team results depend on the team's expertise and deployment context, so ask for those qualifications in writing. Confirm with any provider that it does not issue certifications or assessor reports under the AI RMF, since NIST does not run an approved assessor program. The output is a signed scope that ties each outside task to a named outcome. The step is done when the scope is agreed in writing.
Checks to run before hiring an assessor or consultant
The AI RMF has no certificate and no approved assessor list, so the buyer carries the vetting. The checks below test whether a firm's claims, structure and written commitments match what NIST describes about independence, expertise and documented decisions.
Certificate claims
Ask whether the firm offers or implies any AI RMF certificate, badge or accreditation. NIST does not validate or endorse any organization's use of the framework, and its pages describe no certification or accredited assessor program. A firm that sells an AI RMF certificate is describing something NIST does not issue, so treat the claim as a reason to stop the conversation and ask what the firm actually delivers. If the buyer needs a certifiable standard, ISO/IEC 42006:2025 covers bodies that audit AI management systems and is a separate question.
Separation from development
Ask who will test the system and who built it. AI 100-1 says verification and validation actors should ideally be distinct from those who perform test and evaluation, and the Playbook's suggested actions for GOVERN 2.1 call for separating development from testing so course correction can be independent. Request the reporting line of each tester. If the same people who tune the model also sign off on its results, the firm's findings carry the same internal bias that independent review is meant to remove.
Domain and context expertise
Ask for evidence that the team has worked in the sector and deployment context of your system, such as credit decisions, clinical support, hiring or public services. AI 600-1 notes that the quality of red-teaming outputs depends on the background and expertise of the red team, and that red teams should understand the deployment context. Ask which sector work the named testers have done, how they learned the affected users' risks, and how they would handle a use case outside their experience.
Findings for governance decisions
Ask how findings will be written so that accountable owners can decide on go or no-go, risk treatment and residual risk. AI 600-1 says red-team results need further analysis before they inform governance decisions, so a firm that hands over raw test logs has not finished the work. Ask for a sample report that separates observed behavior, severity, affected context, and the recommended decision owner, and confirm that the report will be retained under your own records process.
Written scope and deliverables
Ask for the scope, the AI systems covered, the RMF categories and subcategories addressed, the deliverables and the acceptance criteria in writing before any work starts. Confirm which parts the firm will perform and which remain with your staff, including who owns control decisions, who approves evidence and who receives the final output. Fixed-scope agreements with named deliverables make it possible to compare quotes and to tell whether the work was completed as agreed.
Verifiable references
Ask for references you can contact directly, including a client in a comparable sector, and ask the firm to confirm what it can share under its confidentiality obligations. Verify each reference with the client, not only with the firm. Ask whether the work was scoped and documented in the same way you would require. A firm that will not name or allow contact with any reference should explain why, and you should weigh that refusal as part of the evaluation.
Questions buyers ask about outsourcing AI RMF work
Can an outside firm certify our organization against the NIST AI RMF?
No. The AI RMF has no certification, accreditation or conformity assessment program, and NIST does not validate or endorse any organization's use of the framework. Any firm that offers an AI RMF certificate is selling something NIST does not recognize. What an outside firm can do is help you prepare systems, documentation and testing evidence, and an independent assessor can then review that work and issue its own findings. Ask any provider to state in writing exactly what deliverable they will produce and who signs it.
Does outsourcing AI RMF work cost more than doing it in-house?
It depends on the scope you agree, not on a standard rate, because the framework itself is free to use. Costs fall into outside fees, internal staff time, and tooling, and some of each recurs as systems change. The main drivers are the number of AI systems in scope, how much testing evidence already exists, whether you need independent review, and how many Measure activities you assign to outside testers. NIST's guidance on Measure 1.3 notes that independent review can reduce internal bias and conflicts of interest, which is a reason to buy some outside work even when you have capable staff. Request a quote that separates one-time setup from ongoing review.
How long does outside AI RMF work take?
No supplied source gives a standard duration, so treat any timeline you hear as an estimate until it appears in the written scope. Duration depends on how many systems are covered, how far your Govern outcomes already reach, and how much testing has to be performed before a review. Ask the provider to break the schedule into phases with named deliverables, dependencies on your staff, and the point where work hands back to your team. Fixed-scope agreements, which DeployOpen uses for most engagements, make the schedule easier to hold the provider to.
What does the work require from our own staff?
Outside help still needs named people inside your organization. NIST's Govern guidance expects documented roles, lines of communication and accountable executives for AI risk decisions, and those cannot be delegated to a consultant. Expect to commit owners for each AI system, people who can explain how the system is built and used, someone who can approve risk decisions, and staff who can grant access to logs, data and test environments. Developers should be kept separate from the people who test their systems, as the Playbook's suggested actions for GOVERN 2.1 recommend, so plan for testers who are not the builders.
Can a small team run the AI RMF without outside help?
Yes, a small team can adopt the framework alone, because NIST says the AI RMF is voluntary and lets users choose which categories and subcategories to apply. The harder question is independence. NIST's Measure 1.3 describes regular assessments by internal experts who were not front-line developers and/or by independent assessors, so a small team can keep reviews internal if people who did not build the system perform them. When no one on the team can do that separation, or when a customer wants outside review, that is the point to bring in an independent party. Start with a current profile and decide which reviews must be external.
A customer asks for an independent AI RMF report. What should we do?
Explain that no independent AI RMF report or certificate exists, because the framework has no assessment program. Then offer the evidence the customer actually needs: your documented Govern roles, your AI inventory, Playbook-based documentation, and test results with clear independence arrangements. If the customer needs an independent opinion, the usual options are an independent assessment of your practices against the AI RMF by a firm the customer accepts, or a different standard that does have an assessment path, such as ISO/IEC 42001, which is covered elsewhere on this site. Agree the scope and the form of any deliverable in writing before the work begins.
How do we pick a firm for independent AI red teaming?
Look for demonstrated domain expertise and awareness of your deployment context, because NIST's Generative AI Profile (AI 600-1) says red team output quality depends on the background and expertise of the team. Ask who will test, what their relevant experience is, how they will separate their work from the development team, and how results will be analyzed before they reach governance decisions, since AI 600-1 says raw red-team results need further analysis. DeployOpen provides security testing that covers applications and APIs, cloud and infrastructure, and AI systems and agents, and its engagements are fixed-scope with written deliverables. Confirm the exact test scope, rules of engagement and reporting format in writing before you sign.
How DeployOpen works on this
DeployOpen helps organizations prepare the systems, controls and evidence that an AI RMF program needs, inside the client's own infrastructure. Independent assessment and any external reviewer's conclusions stay with the organization and the reviewer the organization chooses.
How we scope
- Engagements are fixed-scope, with the systems, functions and deliverables agreed in writing before work starts.
- Scope names which AI RMF categories and subcategories the work covers, and which parts remain with your internal teams.
- Written scope records who owns each control, so the separation between development and testing is explicit.
How we build
- We set up self-hosted open-source platforms in your cloud accounts, data centers or air-gapped networks to host evaluation and monitoring work.
- Testing is delivered as a separate function from development, including application, API, AI system and agent security testing.
- Red teaming scope covers domain expertise and deployment context, with results analyzed before they reach governance decisions.
How we hand over
- Deliverables include the configured systems, test procedures, evaluation records and documentation that your assessor can review.
- We document the evidence trail for each agreed subcategory so your team can show how each output was produced.
- Handover sessions walk your staff through running and maintaining the platforms without DeployOpen involved day to day.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial scope is delivered.
- Retainers can cover periodic re-testing and evidence refresh when AI RMF guidance is revised, such as the pending NIST update.
- Independent auditors and certification bodies issue any reports or certificates; DeployOpen prepares systems and evidence for them.
