What MAP 3.5 human oversight processes require and why they fail in practice
An AI system is about to go live, or is already answering customers and staff, and someone must show that people can step in when it goes wrong. MAP 3.5 is the NIST AI RMF subcategory that asks for this. It expects the organization to define, assess and document its human oversight processes, and to keep those processes consistent with the policies set under GOVERN. In practice, that means an assessor will want to see who can intervene, under what conditions, through which mechanism, and how the organization knows the intervention would actually work. The risk being addressed is simple: a system that makes errors at speed, with no one positioned to catch or reverse them, turns a model defect into an operational incident. Oversight is the control that bounds that exposure.
Oversight often exists on paper and fails in operation for predictable reasons. A policy says a human reviews outputs, but nobody has defined which outputs, the reviewer has no interpretable documentation about the model's limits, the review queue is so long that approvals become rubber stamps, or the override path has never been exercised. AI 100-1 Appendix C makes an important point here: some systems, such as models used to improve video compression, may not require human oversight, while others specifically do. The first decision is therefore classification. Confirm with the business owner and risk function which features and decisions need oversight, and record why the rest do not. That record is itself evidence that the organization considered the question.
Before buying tooling or writing procedures, ask three questions of the team that owns the system: which features require human oversight, who is trained and authorized to act on them, and how the organization will test that a reviewer can detect and correct a failure. The Playbook suggests training overseers on the system's limitations and on suggested warning labels, and evaluating oversight practices for validity and reliability. Confirm with your internal audit or assessor which evidence they will accept for these points, because the answer determines whether you need logs, training records, test results or all three. Plan that work as a dependency of the go or no-go decision, not as a task after launch.
Which AI systems, teams and third parties fall under MAP 3.5 oversight
MAP 3.5 work starts with a scoping decision: which systems, features and people need defined human oversight and which do not. The cards below cover the decisions that change the work, the roles involved, and how vendor-supplied AI is brought into the same assessment. Each decision should be recorded so an assessor can trace why a system was included or excluded.
Systems that require oversight
Start with the AI systems in the inventory and decide, system by system, whether a person must be able to review, override or stop their outputs. NIST's Appendix C notes that some systems, such as models used to improve video compression, may not require human oversight, while others specifically do. Record the rationale next to each decision, including the intended use, the consequence of an error and the people affected. Revisit the decision when the system's scope or user base changes.
Automated decisions with individual effects
Systems that make or strongly shape decisions about people, such as eligibility, pricing, screening or access, are the most common trigger for oversight. Confirm which decisions the system makes alone, which it recommends, and where a person can review the rationale before action is taken. Ask whether affected individuals can challenge an outcome and who handles that challenge. Systems in this group usually need the most documented oversight procedures.
Generated content and staff-facing recommendations
Generated text, code, summaries and recommendations shown to employees can influence decisions even when no automated action follows. Map which outputs reach customers, regulators or other external parties, because those outputs carry higher error costs. Identify the staff who read, edit or act on the output and whether they can tell when it may be wrong. Features that display confidence or source information should be listed, since overseers depend on them.
Teams that share oversight roles
Oversight involves several AI actor groups named in the Playbook: operators who run the system, domain experts who judge its outputs, end users who act on them, and AI designers who shape its features. Record which group holds each oversight task and who can override the system. Human Factors specialists can help determine whether staff will realistically catch errors. Unclear ownership is a common reason oversight exists on paper but does not work in practice.
Vendor-supplied AI systems
Third-party AI still needs an oversight decision made by the deploying organization. Request the vendor's documentation on intended use, known limitations, warning labels and any built-in review or override features. Confirm whether the vendor changes the model or its behavior without notice, since that changes what overseers were trained on. Where the vendor provides no interpretable documentation, record that gap and the compensating controls you put in place.
Evidence of the scoping decision
The scoping decision should be stored in a place where it can be reviewed, versioned and approved. A wiki with page version history can show who changed a scope statement, when, and what the previous wording said. A documentation platform with role-based permissions can limit editing to the governance owners while letting operators read the result. Keep the link between each decision and the AI inventory entry it covers.
How to define oversight processes for an AI system, step by step
This sequence turns MAP 3.5 into working artifacts: a register of features that need human oversight, an approved oversight procedure tied to GOVERN 1 policies, overseer documentation and warnings, trained overseers, and a tested method for judging whether oversight works.
Identify features that require human oversight
Walk through the system's functions with product owners, domain experts and the people who will run it, and record each feature where a human must review, approve, override or stop the output. Include outputs that drive decisions about people, money, safety or regulated obligations, and note where the system is allowed to act without review. Record the result in a feature register that lists each feature, its decision impact, the oversight type and the named owner. The step is done when every feature in the system inventory has an explicit oversight decision, including a documented reason where none is needed. AI 100-1 Appendix C notes that some systems may not require human oversight, so the reason matters as much as the decision.
Set oversight practices under GOVERN 1 policies
Map each register entry to the organization's existing AI policies, risk tolerances and legal requirements set under GOVERN 1, and write an oversight procedure that states who reviews, when review is triggered, what the reviewer can do, and how escalation works. Legal and risk owners approve the procedure, and the policy owner confirms it fits the organization's risk tolerance. Done means a versioned, approved oversight procedure exists, each feature in the register points to a section of it, and the approval record names the approvers and date.
Prepare interpretable documentation for overseers
Produce documentation that a non-developer overseer can use to understand what the model does, what inputs it relies on, how confident its outputs are and when it is known to fail. Write the limitations as plain language and attach warning labels to the interfaces where overseers see outputs, so the warning appears at the point of decision. The NIST Playbook lists interpretable model documentation and warning labels as suggested actions for this subcategory. Done means each overseer role has a documentation set and each high-impact feature displays its limitation text, with the document version recorded alongside the procedure.
Train overseers on system limitations
Deliver training to the people who perform oversight, covering the system's known limitations, the failure patterns in the documentation, the escalation path and the criteria for overriding or stopping an output. Include domain experts and operators, and record who completed each module and when. Training content should be updated whenever the system or the oversight procedure changes. Done means every named overseer has a completion record for the current version of the training, and the training owner has a process to reassign overseers who have not completed it.
Define how oversight is tested for validity
Decide how the organization will test whether oversight actually works. Typical methods include sampling overseer decisions and comparing them with later verified outcomes, measuring how often overseers override outputs and whether those overrides are justified, and running scenario exercises that include known failure cases. Define the metrics, sample sizes, review cadence and the independent reviewer who checks the results, and link these tests to the measurement plan under MEASURE. Done means a written test plan exists, each oversight feature has at least one defined test, and the test owner has agreed on what result triggers a change to the procedure.
Record evidence and review oversight on a schedule
Store the register, procedure, documentation versions, training records, warning label screenshots or configuration, and test results in a controlled repository with version history and access rules. Record each test result, the findings and the changes made in response. Set a review trigger for changes to the model, data, use case or regulation, and confirm that findings flow back into the feature register. Done means an assessor could trace any oversight decision to its policy, its documentation, its trained overseer and its most recent test, with the change history visible.
How an assessor tests MAP 3.5 human oversight
This table compares what an assessor checks for MAP 3.5, the evidence they ask to see, and the findings that most often come up. Read each row as a test: the question asked, the artifact requested, and where the oversight process usually breaks down. NIST does not certify or assess against the AI RMF, so these tests describe how an internal review or an independent assessor would examine the organization's own records.
| Test area | What the assessor checks | Evidence requested | Common finding |
|---|---|---|---|
| Oversight feature register | Whether every system feature that needs human oversight is identified and justified | Register listing features, the reason each needs oversight, and the date last reviewed | Register lists the model but not the specific outputs or actions that need a human decision |
| Link to GOVERN 1 policies | Whether oversight practices trace back to the organization's written AI policies and risk tolerances | Policy clauses mapped to each oversight practice, with approval records and version history | Oversight rules exist in a team wiki but cannot be traced to any approved policy |
| Overseer training records | Whether people who oversee the system were trained on its limitations and on suggested warning labels | Training content, attendance logs, role assignments and the materials given to overseers | Attendance is recorded but the course covers general AI awareness, not this system's failure modes |
| Training assessment | Whether training results show overseers can apply what they learned | Knowledge checks, scenario results or observed review sessions with pass criteria | Training completed but no assessment exists, so competence is assumed rather than shown |
| Operational evidence of oversight | Whether reviews, approvals and overrides happened in production, not only on paper | Review logs, approval and rejection records, escalation tickets and override reasons over a sampled period | Oversight is documented as a control but no review or override has ever been recorded |
| Error-catching tests | Whether overseers actually catch seeded or known errors and whether the process corrects them | Test cases with planted errors, reviewer decisions, miss rates and follow-up actions | No test has ever been run, so the organization cannot show that oversight catches errors |
| Interpretable documentation for overseers | Whether reviewers receive documentation they can use to judge outputs | Model documentation given to overseers, version references and records of questions raised | Documentation is written for engineers and overseers report they cannot interpret it |
| Change and review cadence | Whether oversight arrangements are revisited when the system, its data or its context changes | Change records, periodic review minutes and updated feature register entries | Oversight design was set at launch and never revisited after model or scope changes |
Which evidence shows MAP 3.5 oversight works and how to keep it current
An assessor will look for a chain of records: which features need oversight, how overseers were prepared, whether the oversight measures were tested, and what happened when people intervened. Each artifact below should have an owner, a review date and a version history so it stays accurate between assessments.
Oversight feature register
This is the list of system features that need human oversight, with the reason each one was flagged and the people responsible for it. The Playbook suggests identifying these features as a first step for MAP 3.5, so the register is the anchor for every other artifact. Check that each entry names a specific decision point, such as a model output that triggers an action, and that the register is re-reviewed whenever a model, prompt, data source or use case changes. Keep the owner and review date on the register itself. Ask the system owner to confirm that features added after launch have been added.
Approved oversight procedures
These are the written steps overseers follow, including when to review an output, when to pause the system and who can approve an override. The procedures should trace back to the policies set under GOVERN 1, so an assessor can follow the line from policy to practice. Store each procedure in a controlled wiki with its version history, so you can show what changed, when and who approved it. A procedure without a named approver and a review date will be hard to defend, even if it reads well.
Training materials and completion records
Overseers need training on the system's limitations and on the warning labels or interpretation notes that accompany its outputs, as the Playbook suggests for MAP 3.5. Keep the training content versioned alongside the procedures, and record who completed each version and on what date. Refresh the material when the model or its documented limits change, and confirm that anyone who joined the oversight role after the last session has completed training before they act as an overseer.
Overseer documentation
Overseers must be able to read the model's interpretable documentation, which explains what the system does, its known failure modes and the conditions under which its output should not be relied on. Access rights matter here. Use role-based permissions so the people who need this documentation can read it, and keep an audit trail of who changed it. Review the documentation at the same cadence as the feature register, and confirm that the version an overseer reads matches the version running in production.
Oversight effectiveness test results
Written procedures do not show that oversight works. Test results do. Evaluate whether overseers catch seeded or known-bad outputs, whether they follow the procedure under time pressure and whether the warning labels change their decisions. Record the test design, the sample, the results and the corrective actions, then repeat the tests after material changes. An assessor will ask what failed the last time and what changed as a result, so keep the failed tests as well as the passed ones.
Override and escalation logs
Logs of overrides, escalations and paused deployments are the most direct evidence that oversight operates in practice. Each entry should record the output, the reviewer, the decision, the reason and the time. Langfuse traces can capture inputs, outputs and metadata for each request, which helps connect an override to the underlying call. Confirm that logs are retained for as long as your policy and any applicable regulation require, and that they cannot be edited by the people whose decisions they record.
Which self-hosted open-source tools produce oversight evidence
garak is an Apache-2.0 licensed scanner that probes language models for hallucination, data leakage, prompt injection, misinformation, toxicity generation and jailbreaks. For MAP 3.5, its value is evidence that overseers can see where a model fails before people rely on its output. Each run produces a JSONL report that records every attempt and its evaluation, along with a hit log of attempts that found a vulnerability.
- Failure evidence: The hit log gives overseers a list of prompts that produced unsafe or incorrect output, which can feed warning labels and training material.
- Full attempt record: The JSONL report keeps every attempt and evaluation, so reviewers can check coverage and not only the failures.
- Repeatable runs: Re-running the same probe set after a model or prompt change shows whether oversight needs were affected.
- Limits of the probes: garak tests the probe categories it includes. It does not show that a deployed system behaves safely with real users or real data.
Confirm which probe families your use case needs, who reviews the hit log, and how long reports are retained. Ask the test team to explain which findings triggered a change to oversight procedures.
Langfuse is an MIT licensed observability platform. Each trace captures every operation in a request, including LLM calls, retrieval steps, tool executions and custom logic, with timing, inputs, outputs, token usage and metadata. For oversight, traces let a reviewer reconstruct what the system did and what it showed a person before a decision was made.
- Decision reconstruction: Traces connect an output to the inputs, retrieval results and tool calls that produced it, which supports review of escalated cases.
- Review queues: Metadata such as user role or risk flag can route traces to the overseers responsible for them, if your configuration records it.
- Sampling and retention: Confirm what share of traffic is traced, how long traces are kept, and whether personal data in inputs is masked before storage.
- Tool and retrieval visibility: Traces record tool executions, so overseers can check when the system acted on its own rather than only advising.
Traces show activity, not judgment. Confirm that a named person reviews them, that review outcomes are recorded somewhere else, and that access to traces containing personal data is restricted.
XWiki is an LGPL-2.1-or-later wiki. Every change to a page is kept under version control, recording what changed, when and by whom. Users can compare any two versions and roll back to any earlier version. For MAP 3.5, this is the natural home for the written oversight process, the list of features that require oversight and the training records that support it.
- Change history: Each revision of an oversight procedure shows who changed a threshold or escalation step and when, which is the trail an assessor will ask for.
- Comparison and rollback: Reviewers can compare the procedure in force on a given date with the current version and restore an earlier version if a change was wrong.
- Documented review cycle: Pages can hold the review date and the approver for each procedure, though the review process itself must be defined by the organization.
- Documentation, not operation: The wiki records what oversight should look like. It does not show that oversight happened.
Confirm who may edit oversight pages, how approvals are recorded (inside the wiki or in a separate ticketing system), and whether page history is backed up outside the server.
BookStack is an MIT licensed documentation platform. User abilities come from the roles assigned to them, and permissions can be overridden per role at the shelf, book, chapter or page level. For oversight, this controls who may approve a release, override a model output or change an oversight procedure, and it shows an assessor how those rights were limited.
- Role-based approval rights: Assign approval and override permissions to named roles, such as a reviewer role for high-impact decisions, rather than to individual accounts.
- Page-level restriction: Restrict the pages that hold oversight training records or escalation contacts so only authorized staff can view or edit them.
- Permission inheritance: Overrides at shelf, book or chapter level change what applies to pages beneath them, so check the effective permissions on each page.
- Access evidence: Export or screenshot the role and permission configuration at each review point to show who could approve or override.
Confirm how roles map to your organization's approval matrix, who administers the permissions, and how role membership changes are reviewed and recorded. Permissions alone do not prove that a named overseer was trained or that approvals were made.
What meeting MAP 3.5 costs in money and effort
This table lists the cost components of putting MAP 3.5 human oversight into practice, who is paid for each, whether it is one-time or recurring, and what moves it up or down. No figures are supplied for these costs, so use the table to structure a written quote and to compare what each proposal includes.
| Cost component | Who is paid or who spends effort | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Tooling and licenses | Software vendors for commercial monitoring, logging or review platforms | Usually recurring (subscription or per-seat) | Number of AI systems in scope and users needing access. Self-hosted open-source tools such as Langfuse (MIT) or XWiki (LGPL-2.1-or-later) can remove license spend, but hosting and administration remain. |
| Identifying oversight-required features | Internal risk, product and AI design staff, sometimes with an outside facilitator | One-time per system, revisited on material change | Number of features and decision points. Ask whether the quote covers workshops, documentation of each feature and sign-off. |
| Engineering time to instrument reviews | Internal platform engineers or an implementation partner | One-time build, then recurring maintenance | Whether review points, approval steps and traces already exist. Ask what logging of overseer actions is included and where it is stored. |
| Policy and procedure writing | Internal governance, legal and compliance staff, or a consultant | One-time, then recurring periodic review | Alignment with existing GOVERN 1 policies. Organizations with no current policy set usually spend more time here. |
| Overseer training | Internal trainers or an external provider, plus staff time away from work | One-time for onboarding, recurring for refreshers and new versions | Number of overseers, role complexity and turnover. Training should cover system limitations and warning labels, so ask who writes the content. |
| Interpretable documentation for overseers | Internal technical writers or AI engineers | One-time, then recurring with each model or configuration change | Number of model versions and how often they change. Ask how documentation is versioned. |
| Testing oversight effectiveness | Internal QA or independent testers, or an external security or assurance firm | Recurring, at a cadence set by the organization | Number of oversight processes tested and test depth. Ask whether test scripts are reusable and who reviews results. |
| Evidence upkeep | Internal compliance staff or the operator of the logging system | Recurring | Log volume, retention rules and how many reviews must be retrievable. Confirm storage and access control costs with the vendor or host. |
| External testing or review | Independent assessors or specialist testing providers | Recurring or per engagement | Scope, system criticality and whether the reviewer must be independent of the team that built the process. Ask for scope in writing. |
| Auditor or assessor sampling | Independent auditors or assessors, paid by the organization | Per assessment cycle | Sample sizes, number of systems and quality of evidence. Well-organized review records usually reduce sampling effort. Note that DeployOpen prepares evidence but does not issue reports. |
Who owns oversight, who prepares the evidence and who assesses it
Oversight under MAP 3.5 splits into three jobs that should never blur. The organization decides which features need human review, who is accountable and what the oversight policy says. An implementation partner prepares the systems, procedures, training and records that show those decisions are carried out. An independent auditor or assessor is the only party that reaches a conclusion on whether the controls work.
Oversight decisions stay with the organization
The organization decides which system features need a human in the loop, who holds the authority to pause or override the system, and which oversight practices follow from its GOVERN 1 policies. These are business and risk decisions tied to the organization's risk tolerance. A partner can document options and trade-offs, but the named accountable owner must approve them. Check that the approving role appears in the organization's own accountability structure, not only in a partner's deliverable.
Procedures and training prepared by the partner
A partner can draft the oversight procedures, escalation paths, override steps and training material for overseers, including the limitations and warning labels that the Playbook suggests for MAP 3.5. Once drafted, the organization must review, adopt and version these documents, and the people who deliver training must be named. Ask who signs off on each document and how often the material is refreshed when the system or its use changes.
Evidence collection and system configuration
Implementation work includes configuring logs, traces, access roles and document version history so that oversight activity leaves a record. This might mean recording which reviewer approved an output, what the reviewer changed and when. The partner builds and tests these mechanisms, and the organization runs them day to day. Confirm that each piece of evidence can be exported in a form an assessor can read without help from the partner.
Testing whether oversight works
Testing whether overseers can actually catch errors is a joint activity. The organization sets the test criteria and decides what counts as acceptable performance. The partner can prepare test scenarios, run them under agreed scope and record results. The organization then interprets the results and decides on remediation. Limit the partner's role to preparation and execution, and keep the findings and risk acceptance decisions within the organization.
The independence line for assessors
An independent auditor, assessor or certification body reaches the conclusion on whether oversight processes meet the organization's stated requirements. NIST does not validate or endorse any organization's use of the AI RMF, and no AI RMF certification exists, so any report must come from a party the organization hires for that purpose. Partners must not write the assessor's conclusions, pre-select which evidence the assessor sees, or describe their work as an assessment or attestation.
Boundaries a partner should respect
A partner should not decide on the organization's behalf that a feature needs no oversight, sign approvals for overseers, certify that training was effective or present its own readiness work as a compliance result. Where a regulation applies, the organization confirms the legal requirement with counsel. Put these boundaries in the statement of work so that responsibilities are clear before work begins.
Common questions about MAP 3.5 human oversight
How much effort does human oversight take to put in place?
The effort depends mainly on how many system features need oversight and how consequential their decisions are. Each feature needs a documented oversight practice, a defined reviewer role, training for that reviewer and a test that shows the practice works. A narrow system with one human checkpoint is a small body of work. A system that touches credit, clinical or safety decisions across several features requires far more documentation, more reviewers and more testing cycles. NIST AI 100-1 does not assign hours or headcount, so the reader should ask any provider to break its quote into feature inventory, policy alignment, reviewer training, testing and evidence collection, and to state which parts recur after go-live.
How long does it take to set up oversight processes?
The timeline is driven by the state of existing governance, not by the framework itself. If the organization already has an AI policy under GOVERN 1, an inventory of AI systems and named accountable owners, setup mostly involves mapping features to oversight decisions and writing procedures. If those foundations are missing, they must be built first, which adds time. Other drivers include how many reviewers must be trained, whether the system is already in production, and how long it takes to run a meaningful test of whether overseers catch errors. Ask any partner for a milestone plan tied to the written scope before work begins, because the schedule depends on those inputs.
What does the internal team need to provide?
Oversight processes only work when the people who own the system and the people who will oversee it are involved. The internal team needs to provide:
- A system owner who can state the intended purpose, the decisions the system influences and the consequences of errors.
- Domain experts who know what a correct output looks like and can judge when to override it.
- Operations and monitoring staff who will receive alerts, log overrides and escalate incidents.
- Someone accountable under GOVERN 2 who approves the oversight design and accepts residual risk.
An outside partner can document and test these practices, but it cannot decide what the organization considers acceptable risk or who should be trusted to override the system.
Can we do human oversight work ourselves without an outside partner?
Many organizations can do it internally, especially when they have experienced risk, compliance and engineering staff and the system is limited in scope. Outside help is most useful for the parts that are hard to do objectively from inside the team: testing whether oversight actually works, building reproducible evidence and documenting interpretable model information for overseers. Whichever route is chosen, the organization owns its controls and its risk decisions. Be clear in any engagement which deliverables are prepared by the partner, which are produced by the organization and who signs off each one.
Is there a certificate for NIST AI RMF human oversight?
No. The NIST AI RMF is voluntary, and NIST does not operate any certification, accreditation or conformity assessment program for it. NIST also does not validate or endorse any individual organization's use of the framework. Anyone offering an AI RMF certificate is not offering one that NIST recognizes. Organizations that need an external opinion can ask an independent assessor to review their oversight documentation and testing, but that review produces an assessment, not a NIST certificate. If a customer or regulator asks for proof, the practical answer is a documented, tested and current set of oversight records that an assessor can examine.
How do we decide whether a system needs human oversight?
Start from the system's intended purpose and the consequences of its errors, not from its technology. NIST AI 100-1 notes that some systems, such as models used to improve video compression, may not need human oversight, while others specifically require it. Useful questions include whether an incorrect output can cause material harm to a person, whether a decision is legally or contractually consequential, whether the system acts without review, and whether affected people can contest outcomes. Record the decision and its rationale for each feature, and revisit it when the scope, data or user population changes. This decision should be made by the accountable owner, with input from domain experts and risk staff.
What evidence will an assessor or customer ask to see?
Assessors and customers usually look for a feature inventory showing which features need oversight and why, the written oversight procedure with named reviewers, training records that cover system limitations and warning labels, test results showing whether overseers catch errors, and interpretable documentation provided to reviewers. Logs of overrides, escalations and incidents show that the process runs in practice. Confirm the retention period and access controls for these records with your own legal and records teams, because the framework does not set them. Wiki version history and role-based permissions can help show who changed a procedure and who could approve it.
How DeployOpen works on this
DeployOpen helps organizations prepare the systems, documentation and evidence behind MAP 3.5 Human oversight processes, inside the client's own infrastructure. The organization still owns its oversight decisions and policies, and only an independent assessor can judge whether the outcome has been met.
How we scope
- Agree in writing which AI systems and features fall under the oversight review before work starts
- Identify with the client which features need human oversight and which do not, with reasons recorded
- Confirm the GOVERN 1 oversight policies the work must follow, and name the people who own each one
- Define the deliverables, exclusions and timeline in a fixed-scope document before any build begins
How we build
- Set up documented oversight procedures and review steps inside the client's own wiki or document system
- Configure role-based access so overseers, reviewers and approvers see only what their role requires
- Enable tracing of model inputs, outputs and overrides so reviewers can reconstruct individual decisions
- Run oversight practice tests against the documented procedures and record results for the client's review
How we hand over
- Deliver overseer training materials covering system limitations, known failure modes and suggested warning labels
- Provide version-controlled procedures, test records and an evidence index mapped to MAP 3.5 for assessor review
- Document the open items, residual gaps and owner for each, so the client can decide how to close them
- Walk the client's team through the handover so they can operate and update the evidence without us
How we support
- Support is available as a retainer for updating oversight procedures when systems, models or policies change
- Retainers can also cover periodic re-testing of oversight practices and refresh of overseer training
- Confirm with DeployOpen during scoping which support terms, response arrangements and exclusions apply
- Use an independent auditor or assessor for any formal review, since DeployOpen does not issue reports or certificates
