MEASURE 2.6 Safety evaluation: requirements and evidence

What MEASURE 2.6 safety evaluation requires and why it is hard

A team that builds or runs an AI system under MEASURE 2.6 must show that the system is safe, not just accurate. The subcategory expects regular evaluation of the safety risks identified during MAP, evidence that residual risk sits within the organization's stated tolerance, proof that the system fails safely when it reaches the limits of its knowledge, and safety metrics covering reliability, robustness, real-time monitoring and failure response times. NIST AI 100-1 directs the most urgent prioritization and the most thorough risk management process to safety risks that could cause serious injury or death, so the evidence for those systems needs to be deeper than for a low-consequence tool. The framework is voluntary and has no certification, so no body grants a safety rating. The evidence is what the organization produces and what its own auditor, customer or regulator checks.

The difficulty is that safety depends on context and on failure modes that a standard accuracy score does not reveal. A model can score well on a held-out test set and still behave unsafely when input data drifts, when load spikes, or when users phrase requests the test designers never considered. Under MEASURE 2.6, the test plan therefore has to start from the risks recorded in MAP and ask whether each one has been exercised under realistic conditions, including conditions that resemble past incidents or near misses. Illustrative example: a triage assistant that is accurate on last year's cases may still route urgent cases incorrectly after a change in intake forms, and only a scenario built from the MAP risk register would catch that. The team should confirm which MAP risks are in scope, who on the TEVV, domain expert and operations side signs off on residual risk, and what the stated risk tolerance says in measurable terms.

Before committing budget, ask three questions of the internal team or any outside partner. First, can the team show a traceable link from each safety risk in MAP to a test, a metric and a monitoring signal? Second, is there a documented record of the conditions under which the system has been shown to fail safely, and of the conditions where it has not? Third, can the team measure how long detection and response take when a safety failure occurs, and has it practiced that response? Outside help can prepare the test harness, metrics and evidence, but the organization owns the risk decisions, and an independent assessor or auditor tests the result. Where the AI system is generative, the NIST AI 600-1 Generative AI Profile adds specific MEASURE 2.6 actions that should be checked against the plan.

Which AI systems, data, teams and third parties fall under MEASURE 2.6

MEASURE 2.6 applies to any AI system where a failure could cause harm, but the amount of safety evaluation work depends on a few scoping decisions. The cards below name each driver and what it changes, so the organization can size its program before agreeing on scope with an implementation partner or assessor.

Systems that can cause physical, financial or health harm

Start with the consequence of a wrong output, not the model type. A system that informs clinical triage, industrial control, credit decisions or payment routing can cause serious injury, death or large financial loss, and AI 100-1 Section 3.2 calls for the most urgent prioritization and the most thorough risk management process for those cases. Scoping in these systems adds stress tests under extreme inputs, documented fail-safe behavior and incident response drills to the workload. Confirm with domain experts which outputs can reach a human or a machine without review.

Systems with safety risks recorded in MAP

MEASURE 2.6 begins from the safety risks identified during MAP, so the MAP risk register sets the minimum scope. Every system with a recorded safety risk needs an evaluation that shows residual risk sits within the stated tolerance, and every risk without an evaluation is a gap an assessor will find. Check that the register names the system, the risk and the owner, and that each entry links to a test or monitoring result. Systems missing from MAP are a scoping problem to fix before measurement starts, not after.

Generative AI systems under the Generative AI Profile

Generative AI systems bring the MEASURE 2.6 actions from NIST AI 600-1 into scope. The profile lists 7 suggested actions for this subcategory, tagged to 11 of its 12 generative AI risks, including checks that the system handles queries that could facilitate manipulation, extortion, targeted impersonation, cyber-attacks or weapons creation, and regular tests for circumvention of safety measures. Scoping in a generative system therefore adds adversarial prompt testing and jailbreak evaluation to the workload, even when the team is only configuring a vendor model.

Third-party models and APIs under restricted testing

When the organization consumes a hosted model or API it cannot test directly, the safety evaluation must still cover the system it deploys. Scope in the third party for what the organization can observe: documented vendor safety testing, version pinning, output logging, and behavior checks run through its own prompts and inputs. Ask the vendor which safety evaluations it has performed, how it notifies customers of model changes, and what access it provides for independent testing. Gaps in that evidence should appear in the scope as named risks, not as assumptions.

Teams and data sources that feed evaluations

MEASURE 2.6 work is shared across TEVV staff, domain experts, operators and impact assessors, as the Playbook's actor tags show. Scope each team by its function: TEVV runs the stress and incident tests, domain experts judge whether failures are safe in context, and operations owns real-time monitoring. Include the data sources used for testing, such as past incident records and near-miss logs, because test conditions similar to those events are part of the expected work. Confirm who signs off on test results before a go or no-go decision.

Production environments and monitoring pipelines

Safety evaluation extends into production, so the scope must include the monitoring stack that collects safety statistics and triggers alerts. Each system needs a defined telemetry path, such as traces of inputs, outputs and tool calls, metrics on response times and failures, and alert rules routed to a named responder. Systems without this path can be tested before release, but they cannot show that they stay within tolerance afterward. Confirm which environments are in scope, including staging systems that mirror production load.

How to build a safety evaluation cycle step by step

This sequence turns the safety risks found in MAP into measured tolerances, tested behavior, production monitoring and incident drills, so MANAGE decisions rest on documented evidence rather than assumptions. The organization owns the cycle; an implementation partner can help prepare the systems and records that support it.

Pull safety risks from MAP outputs
Start with the MAP documentation for the system and extract every risk where the consequence could be harm to people, property or essential operations. Give the most serious items priority, since AI 100-1 Section 3.2 says risks that could cause serious injury or death call for the most urgent prioritization and the most thorough risk management process. Include the knowledge limits and deployment context recorded under MAP 2 and MAP 3, because those define where the system is expected to fail. The output is a safety risk inventory with a named owner for each risk. The step is done when the risk owners, including domain experts, have signed off that nothing identified in MAP is missing.
Build a risk-to-metric register with tolerances
For each safety risk, define the metric that will show whether it is controlled, such as error rates on high-consequence inputs, latency under load, or the rate of unsafe outputs, and record the residual risk tolerance the organization accepts. The register links each risk to its metric, its threshold, the data source, and the accountable decision maker. TEVV staff and domain experts draft it, and the accountable business owner approves the tolerances. The output is a versioned register that MEASURE 1 and MANAGE 1 can reference. Confirm that every metric has a documented method of collection before moving on.
Stress-test under likely scenarios before deployment
Run pre-deployment tests that reflect how the system will actually be stressed. The NIST AI RMF Playbook suggests testing performance under likely scenarios such as concept drift and high load, and under conditions similar to past incidents or near misses. Test engineers execute the scenarios against a staging environment that matches production as closely as the organization can confirm, and record inputs, outputs, timing and failure modes. The output is a test report that states, for each risk, whether the metric stayed within tolerance. Failed scenarios go back to the risk owner rather than being closed by the test team alone.
Document the conditions for safe failure
Describe the conditions under which the system has been shown to fail safely, including what triggers a fallback, a refusal, a human handoff or a shutdown, and what the user sees at that point. Test each fallback path explicitly, because a documented safe state that has never been exercised is not evidence. For generative systems, also record how the system handles queries that could facilitate manipulation or circumvention of its safety measures, a point that NIST AI 600-1 addresses under MEASURE 2.6. The output is a fail-safe specification with a test result for each path. The step closes when the risk owner confirms the documented conditions match the tested behavior.
Instrument production monitoring for safety signals
Connect the metrics in the register to production telemetry so the safety signals are measured after release, not only in testing. Instrumentation typically covers traces of model calls, retrieval and tool execution, metrics for latency and error rates, and alert rules on the thresholds set earlier. Open-source options such as Langfuse for traces, Prometheus for time-series metrics, and Grafana Alerting for rules and dashboards can produce this evidence in the organization's own infrastructure, but the team must confirm that each tool captures the fields the register needs. The output is a monitoring specification and a working dashboard showing each safety metric. The step is done when a test alert fires and reaches the responsible team.
Define incident response and run drills
Write a runbook for each safety alert that names the first responder, the escalation path, the criteria for pausing or rolling back the system, and the record that must be kept. Then run drills that simulate the incidents recorded in the register, including an alert from a high-load or drift scenario. The Playbook suggests practicing and measuring AI incident response, so record how long each step took and where the handoffs failed. The output is a runbook set and a drill report with corrective actions assigned to owners. Confirm that the people who would respond know their roles before the drill is scored.
Feed results into MANAGE decisions
Bring the test reports, monitoring statistics, drill results and open safety findings to the go or no-go review and to ongoing risk treatment. The accountable owner decides whether residual risk is within tolerance, whether the system continues, is restricted, or is deactivated, and records the reasons. Those decisions update the risk register and feed the next MEASURE cycle. The output is a dated decision record linked to the evidence behind it. The cycle is working when every safety finding has a documented disposition and a scheduled re-test.

How an assessor tests MEASURE 2.6 and which findings they raise

This table compares four checks an independent assessor may run against MEASURE 2.6, the approach for each, the evidence they ask for and the findings they commonly raise. Read it as a preparation list: each row shows what the organization should be able to produce before an assessment begins. An assessor reports findings only, and NIST does not certify or endorse any organization's use of the AI RMF.

Check	Test approach and evidence requested	Common findings
Safety risks from MAP map to evaluations	Assessor traces each safety risk recorded in MAP to a named test, metric or monitor. Evidence: the MAP risk register, linked test plans and a record of which risks have no test.	Risks listed in MAP with no matching evaluation, or safety risks identified only in narrative documents
Deployment-like conditions and stress scenarios	Assessor reviews test scenarios for concept drift, high load and inputs resembling past incidents or near misses. Evidence: scenario definitions, test run results and the data sets used.	Tests run only on clean development data, or stress scenarios defined but never executed
Documented fail-safe conditions were tested	Assessor asks for the conditions under which the system is shown to fail safely and checks test records that exercise those conditions, including behavior beyond knowledge limits. Evidence: fail-safe specification, test logs and recorded outcomes.	Fail-safe behavior asserted in design documents without test evidence, or failures handled differently in production than documented
Safety metrics and residual risk within tolerance	Assessor checks that reliability, robustness, monitoring and failure response time metrics have defined thresholds and that results are compared against the risk tolerance set under GOVERN 1. Evidence: metric definitions, thresholds and dated results.	Metrics collected without thresholds, or residual risk accepted without a documented comparison to tolerance
Real-time monitoring is operating	Assessor samples monitoring dashboards, alert rules and alert history to confirm that safety signals reach a responsible person. Evidence: alert rule exports, on-call records and sample alert tickets.	Alert rules exist but route to no owner, or monitoring covers availability but not safety-relevant outputs
Incident response has been exercised	Assessor reviews incident response plans and asks for tabletop or live exercise records, including timings and lessons learned. Evidence: exercise reports, incident tickets and post-incident reviews.	Plan documented but never rehearsed, or no record of how long detection and response took
Generative AI safety actions (where applicable)	For generative AI, assessor checks the MEASURE 2.6 actions in NIST AI 600-1 on manipulation, impersonation and circumvention queries, and whether vulnerability evaluations are repeated. Evidence: adversarial test results and retest dates.	Circumvention testing run once before launch and not repeated after model or prompt changes
Independence and reporting	Assessor confirms who performed each test, whether the tester was independent of the build team, and that the report states findings only. Evidence: test ownership records and the assessor's written findings.	Self-assessment presented as independent review, or readiness work treated as an audit opinion

Evidence that passes a MEASURE 2.6 review and how to keep it current

A MEASURE 2.6 review looks for a connected trail: risks named in MAP, metrics with thresholds, test results tied to configurations, live monitoring and drilled responses. Each artifact below needs a set refresh rhythm and a named sign-off, and the organization owns every one of them. Refresh intervals are set by your own policy, so confirm them with your assessor and internal audit before you commit.

Safety risk register linked to MAP

The register lists each safety risk identified in MAP, its likelihood and severity, the hazard scenarios behind it, and the control or test that addresses it. For MEASURE 2.6, an assessor checks that every MAP safety risk appears here and that the register records which risks could cause serious injury or death, since AI 100-1 calls for the most urgent prioritization of those. Refresh it at each material system change and at least at the review cycle your governance policy sets. The AI risk owner signs it, with the safety or domain expert confirming hazard entries.

Safety metric definitions and thresholds

Each safety metric needs a written definition, measurement method, data source, and a tolerance threshold that sets the residual risk the organization will accept. Cover reliability, robustness, monitoring coverage and failure response time, and state what happens when a threshold is breached. Review the definitions whenever the use case, population or model changes, and confirm the thresholds against the risk tolerance approved under GOVERN 1. The accountable business owner and the TEVV lead sign off, and the risk function countersigns any threshold change.

Stress and fail-safe test reports

Test reports record each run with its date, system version, dataset, hardware, load profile and configuration, so the result can be reproduced. Include stress tests under concept drift and high load, replays of past incidents or near misses, and documented conditions where the system was shown to fail safely. Rerun the suite after each material change and on the schedule in your test plan. The TEVV lead signs each report, and a domain expert reviews the fail-safe conclusions.

Production monitoring dashboards and alert history

Dashboards show live safety metrics, drift signals and response times, while the alert history shows what fired, when, who acknowledged it and how it was resolved. Keep the alert rules under version control so an assessor can see what was watched at each point in time. Review rules and thresholds at least once per review cycle and after every significant alert. The operations owner maintains the history, and the AI risk owner signs the periodic review of alert trends.

Safety statistics and incident drill records

Safety statistics include counts of safety events, near misses, unsafe outputs blocked, and time to detect and contain each one. Incident response drills record the scenario, participants, timings, gaps found and corrective actions with owners and due dates. Refresh statistics monthly or on the cadence your monitoring policy defines, and run drills at least on the schedule your incident response plan sets. The incident response lead signs the drill records, and the accountable executive reviews the statistics.

Residual risk sign-offs

A residual risk sign-off states which safety risks remain after controls, whether each sits within the approved tolerance, and the conditions attached to deployment. It is the go or no-go record that connects test results, monitoring data and drills to a decision. Reissue it whenever the risk profile changes, a threshold is breached or a new test result alters the picture. The accountable executive signs it, and the independent reviewer confirms that the evidence supports the stated residual risk.

What the Generative AI Profile adds to MEASURE 2.6

NIST AI 600-1, the Generative AI Profile published July 26, 2024, lists 7 suggested actions for MEASURE 2.6, numbered MS-2.6-001 to MS-2.6-007. These actions are tagged to 11 of the profile's 12 generative AI risks. The only risk without a MEASURE 2.6 tag is Environmental Impacts. For a team running or buying a generative model, the profile turns the general safety evaluation in MEASURE 2.6 into checks aimed at how a language model behaves under misuse. Read the actions as suggestions to adopt, adapt or reject, not as a checklist, and record which ones you adopted, which you set aside and the reason for each decision.

Two of the seven actions deserve early attention because they test conditions that generic performance tests often skip. The first, MS-2.6-006, asks you to verify that the system handles queries that could facilitate manipulation, extortion, targeted impersonation, cyber-attacks or weapons creation. In practice, this means building a test set of such prompts, recording the responses and deciding in advance what counts as a failure. The second, MS-2.6-007, asks you to evaluate regularly how vulnerable the system is to circumvention of its safety measures. This is a recurring activity, not a one-time test, so the owner, the cadence and the trigger for an unscheduled run should be written down. Ask your model provider which safety measures it applies and what evidence it has tested them, then decide what your own tests must still cover.

Several decisions follow from these two actions. Name the accountable owner for the adversarial test set and confirm that the TEVV team, domain experts and operations staff named in the Playbook for MEASURE 2.6 each have a defined role. Decide whether your red-team results feed the go or no-go determination and the risk tolerance set under GOVERN 1. Keep the test set, the prompts, the outputs and the pass or fail criteria under version control so that a later assessor can reproduce a result. If a regulator or customer later cites the Generative AI Profile, you will need to show which of the seven actions you adopted and why. The profile is also expected to be reviewed alongside the pending AI RMF revision, so confirm the current status with NIST before you treat its wording as final.

What meeting MEASURE 2.6 costs in money and effort

This table lists the cost components of a MEASURE 2.6 safety evaluation, who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to structure a request for quote, since no fee or duration figures are supplied for this control. The main takeaway is that open-source tooling removes license spend but not the staff time needed to define safety metrics and keep evidence current.

Cost component	One-time or recurring	What drives it	How to reduce it
Engineering time to define safety metrics and build tests	One-time, then recurring as risks change	Number of risks carried forward from MAP, system complexity, and how many failure modes must be tested	Scope the first cycle to the highest-severity risks from MAP and reuse test templates across systems
Test environment and compute	Recurring	Load and stress scenarios, frequency of runs, size of the deployment-like environment	Run heavy scenarios on a schedule rather than on every change, and reuse infrastructure already hosted in the client's own environment
Tooling and licenses	Recurring where commercial tools are used	Choice of monitoring, tracing and LLM probing tools, and whether support contracts are needed	Self-hosted open-source options such as Prometheus, Grafana, Langfuse and garak remove license fees, but staff time to operate and tune them remains
Real-time monitoring and incident response practice	Recurring	Alert volume, number of monitored components, on-call coverage, and frequency of incident response drills	Tune alert rules to safety-relevant signals and run tabletop drills with the teams that already own the system
Evidence upkeep	Recurring	Frequency of system changes, number of test runs to archive, and retention rules set by the organization	Automate export of test results, metric snapshots and hit logs into a single evidence store with a defined retention schedule
External red teaming or independent review	Per engagement	Scope of adversarial testing, depth of safety scenarios, and whether independent assessors review results	Fix the scope in writing, test the highest-risk paths first, and ask for findings in a format the internal team can act on
Auditor or assessor sampling	Per assessment cycle	Which evidence the assessor selects, how many samples are drawn, and how well records are organized	Keep test records traceable to specific MAP risks so samples can be pulled quickly

Who owns safety evaluation, who can help and where the auditor stops

The organization owns the safety decisions that MEASURE 2.6 depends on. NIST AI 100-1 frames the outcome as a system that is regularly evaluated for the safety risks identified in MAP, shown to be safe, with residual risk within tolerance. Only the organization can set that tolerance, because it depends on the harms the organization accepts for its users, its mission and its regulatory exposure. Accountable leaders also make the go or no-go determination and decide when a system must be restricted, rolled back or switched off.

Risk tolerance: Define in writing the residual safety risk the system may carry, and who approved that level.
Safety decisions: Record which failure modes are accepted, mitigated or prohibited, and why.
Go or no-go determination: Name the accountable role that signs each release and each material change.
Incident response authority: Assign who can pause the system during a safety event and who is notified.
Review cadence: Schedule periodic reassessment of tolerance as the system, its users and its context change.

Before any outside engagement, confirm that a named executive has approved the tolerance and that the decision record is complete.

How long, costly and hard is MEASURE 2.6 for our team

Can our team do MEASURE 2.6 in-house without an outside partner?

Yes, the organization owns its safety evaluation work and can do it in-house, provided it has people who can design tests, run them and keep the records. MEASURE 2.6 is voluntary under the NIST AI RMF, so no regulator sets a fixed method. The work is heavier than it looks because it touches several roles at once: TEVV staff, domain experts, operations and monitoring teams, impact assessors and deployment owners, as the Playbook tags them. Outside help is most useful for preparing test harnesses, monitoring dashboards and evidence trails, while the organization keeps accountability for the safety decisions themselves. Ask any partner to state in writing which parts they prepare and which parts your staff must perform.

What drives the effort of a MEASURE 2.6 safety evaluation?

The main driver is how many safety risks MAP identified and how severe they are. AI 100-1 says risks that could cause serious injury or death call for the most urgent prioritization and the most thorough process, so a system with physical or clinical consequences takes far more work than a low-impact internal tool. Other drivers include:

The number of scenarios to stress-test, such as concept drift, high load and conditions similar to past incidents or near misses.
Whether real-time monitoring and failure-response metrics already exist or must be built.
How many components, models and third-party services sit in the system, since each adds failure modes.
Whether generative AI risks apply, which adds the Generative AI Profile actions MS-2.6-001 to MS-2.6-007.

Illustratively, a chat assistant with tool access will need circumvention and manipulation testing that a rules-based scoring model does not.

What skills and staff time does MEASURE 2.6 need from our team?

The work needs engineers who can build repeatable test suites, operators who can read monitoring signals, and domain experts who can judge whether a failure is safe. Test design needs people who understand the system's knowledge limits, since the outcome requires the system to fail safely beyond them. Incident response practice also needs named responders who can rehearse and measure their response times. Staff time is recurring, not one-time: scenarios must be rerun after model, data or configuration changes, and monitoring alerts need someone to triage them. Before committing, confirm which of these roles already exist, who can release time, and who signs off on residual risk.

Does an auditor certify that we comply with NIST AI RMF MEASURE 2.6?

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. An independent auditor or certification body cannot issue a NIST AI RMF certificate. What you can do is show evidence that your safety evaluation was planned, run and documented against the MEASURE 2.6 outcome, and some customers or regulators may ask for that evidence in a due diligence review. If a contract requires a certificate for the AI RMF, ask the requester which standard they actually mean, since ISO/IEC 42001 is a certifiable AI management system standard that works differently.

How could the planned NIST revision change the MEASURE 2.6 work?

NIST says AI RMF 1.0 is being revised as part of the White House AI Action Plan and has not published a revised version as of October 2026. The July 2025 AI Action Plan recommends removing references to misinformation, diversity, equity and inclusion, and climate change. MEASURE 2.6 itself concerns safety, reliability, monitoring and failure response, so it is not one of the named topics, but the Playbook is also expected to be updated after the revision, and its current content was last updated in August 2023. Plan your safety evaluation so the core engineering work stays stable, and keep your mapping of MEASURE 2.6 to your own documentation so a revised version is easy to reconcile. Confirm the current status on NIST's AI RMF pages before setting a deadline.

What should we ask for in a fixed-scope quote for MEASURE 2.6?

Ask for a written scope that lists the systems covered, the MAP safety risks being evaluated, and the test scenarios to be built and run. A useful quote separates one-time work from recurring work. One-time items usually include scenario design, harness and test setup, monitoring and alert configuration, and documentation of fail-safe conditions. Recurring items include reruns after changes, alert triage support and periodic reviews. Ask which deliverables you receive, such as test records, monitoring configuration and incident response exercise reports, and who keeps custody of them. Also confirm the assumptions behind the price, the staff you must provide, and what happens if a test uncovers a risk that needs redesign. DeployOpen fixed-scope engagements are agreed in writing before work starts, and a quote follows from that written scope.

Which open-source tools can produce MEASURE 2.6 evidence, and what do they cover?

Several open-source tools each cover part of the evidence. garak (Apache-2.0) probes language models for hallucination, data leakage, prompt injection, toxicity generation and jailbreaks, and writes a JSONL report of every attempt plus a hit log of vulnerabilities found. Langfuse (MIT) captures traces of LLM calls, retrieval steps and tool executions with timing and token usage, which supports reviewing failures. Prometheus (Apache-2.0) collects metrics over HTTP and stores them as time series for queries in PromQL, while Grafana Alerting (AGPL-3.0-only) builds alert rules across data sources. Tools do not decide whether a system is safe. Confirm that each tool fits your model type and data handling rules, and that its outputs are retained as evidence.

How DeployOpen prepares safety evaluation evidence for MEASURE 2.6

DeployOpen helps organizations prepare the safety evaluation evidence that MEASURE 2.6 asks for, working inside the client's own infrastructure on self-hosted open-source platforms. DeployOpen prepares systems, test records and monitoring evidence, while the organization owns its risk decisions and any outside assessment is performed by independent parties.

How we scope

Engagements are fixed-scope, with the MAP safety risks to evaluate agreed in writing before work starts.
The written scope names which AI systems, deployment settings and safety metrics are covered under MEASURE 2.6.
The scope states which TEVV, domain expert and monitoring roles the client will staff, and which DeployOpen will support.

How we build

We set up stress tests for concept drift, high load and past incident conditions, with each test case recorded.
We configure real-time monitoring and alert rules for reliability, robustness and failure response time metrics.
We document the conditions under which the system has been shown to fail safely, and where it has not been tested.

How we hand over

Handover includes test plans, test results, safety statistics and documented incident response exercises for the client's files.
Every deliverable is mapped to the MEASURE 2.6 actions it supports, so the client can show which evidence answers which action.
The client receives configuration records and runbooks so its own staff can operate and update the evidence after handover.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the initial scope is delivered.
Retainers can cover rerunning safety evaluations after model, prompt or data changes, which the client should confirm in its scope.
DeployOpen does not issue audit reports or attestations, so the client should confirm assessor requirements with its independent auditor.

MEASURE 2.6 Safety evaluation