MEASURE 2.7 Security and resilience requirements

What MEASURE 2.7 security and resilience requires in practice

MEASURE 2.7 asks you to evaluate and document the security and resilience risks that you already identified in MAP, and to show the results. It is an outcome in the AI RMF Core, not a certification. NIST does not validate or endorse any organization's approach to using the framework, and no independent body issues an AI RMF certificate. Your evidence will be judged by whoever reviews your program, whether that is an internal audit function, a customer security team or a regulator, and the question they will ask is whether the risks named in MAP were tested, what the results were and what changed as a result.

AI 100-1 Section 3.3 names several security concerns that are specific to machine learning. Adversarial examples are inputs crafted to cause incorrect outputs. Data poisoning corrupts training or fine-tuning data. Exfiltration through system endpoints can expose models, training data or other intellectual property to someone who only has access to the interface. These failures are hard to test with classic application methods. A model can pass functional tests and still follow a hostile instruction embedded in a document it retrieves, or reveal fragments of its training data under repeated querying. Testing therefore has to exercise the model's behavior, its retrieval and tool connections and its surrounding pipeline, not just the web application in front of it.

The evidence has to trace back to MAP. Start by pulling the security risks recorded for the system during MAP, such as which endpoints are exposed, which data sources feed retrieval, and which third-party models or components are in use. For each one, define the test, the adversarial conditions, the metric and the acceptance threshold, and record who approved that threshold. Confirm with your security and TEVV teams which of these tests are in scope for the system's risk tier, and document where a risk is accepted rather than countered. A test log that cannot be matched to a MAP risk will not satisfy an assessor, even if the test itself was sound.

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

MEASURE 2.7 applies to the security risks already identified in MAP, so scope starts there rather than with the whole AI estate. The decisions below determine which systems, data flows and owners the security evaluation must cover, and each one changes how much testing, documentation and monitoring the work requires.

Production and pre-production systems

Decide whether security evaluation covers only the production system or also staging, pilot and development environments that hold real data or real credentials. A production model that was tested only on a sandbox copy does not show that its security holds in the deployment setting. Confirm which environments the MAP security risks apply to, and document the environments in scope so an assessor can trace each test to the system it covered. Environments with production data usually belong in scope even when they are not customer facing.

Generative versus predictive models

Generative models accept free-form input, so prompt injection, jailbreaks and abuse through generated content are in scope for MEASURE 2.7. Predictive models face different threats, such as adversarial inputs, data poisoning and model extraction through their scoring endpoints. NIST AI 600-1 adds generative-specific suggested actions under MEASURE 2.7, so organizations running generative systems should plan red-team scenarios for both model types and record which attack classes each system was tested against.

Endpoints and tools an agent can reach

An AI system that calls APIs, databases, file shares or code execution tools extends its attack surface to every resource it can reach. For each agent, list the tools, credentials and network paths it holds, and decide which of them the security evaluation must exercise, including attempts to make the agent misuse them. Scope the review of permissions as well as the model, because excessive privileges often matter more than the model's own weaknesses.

Third-party models and APIs

Hosted models, embedding services and external APIs sit outside the organization's control, yet their failures and data handling still affect MEASURE 2.7 outcomes. Decide which third-party components are in scope, what security audit evidence the provider can supply, and how the organization will learn about vulnerabilities in pre-trained models it did not build. Ask providers for their own security test results and incident notification commitments before relying on them.

Training, fine-tuning and retrieval data

Training, fine-tuning and retrieval corpora can be poisoned, and fine-tuning can weaken safety and security controls that the base model had. Include the data pipelines that feed the system, the access controls on training stores, and the sources of retrieved documents. NIST AI 600-1 suggests verifying that fine-tuning does not compromise safety and security controls, so fine-tuned variants should be evaluated as new systems, not assumed to inherit the base model's results.

Teams that own TEVV and monitoring

Name the owners of each security activity: the TEVV team that runs tests, domain experts who judge impact, operations staff who watch for anomalies, and deployment owners who act on findings. The NIST AI RMF Playbook tags MEASURE 2.7 to several AI actor categories, so a gap in ownership often shows up as untested endpoints or unreviewed alerts. Record who is accountable for each test result, metric and countermeasure, and confirm which of those roles an implementation partner or outside tester will fill.

How an assessor tests security and resilience evidence

This table sets out what an independent assessor checks for MEASURE 2.7, what evidence they request and where programs usually fall short. Read each row as a test question and the evidence that answers it, and note that the assessor issues any conclusion, not the implementation partner or the organization.

Assessor check	What the assessor looks for	Common finding
Security risks carried from MAP	Security risks identified under MAP appear as named test items in the TEVV plan, with an owner and a linked MEASURE 2.7 entry for each.	TEVV plans test accuracy only and never mention the threats the MAP function recorded for the system.
Security metrics with dates and versions	Red-team results, anomalous event rates, downtime and time to bypass are recorded with test dates, model or system versions and the configuration tested.	Metrics exist as dashboard screenshots with no date, version or method attached, so results cannot be reproduced.
Thresholds on metrics	Each security metric has a documented acceptance threshold tied to the organization's risk tolerance, with the decision taken when a threshold is missed.	Metrics are reported with no threshold, so no one can say whether a result is a pass, a failure or a finding to act on.
Red-team exercises with written scope	A written scope names the attack classes tested, such as prompt injection or data exfiltration, the adversarial conditions, the testers, the rules of engagement and the findings log.	Red-team work is described in an email or a meeting note with no scope, so the assessor cannot tell what was and was not covered.
Countermeasures tested, not declared	Controls such as authentication, throttling and differential privacy are shown working against the attacks they target, with test records before and after each change.	The security policy lists countermeasures, but no test shows that they block the attack or that they still work after a model update.
Fine-tuning checked for security regression	Records show that safety and security controls were retested after fine-tuning, following the MS-2.7 actions in the Generative AI Profile where generative AI is used.	Models are fine-tuned or swapped for a new version with no retest of guardrails, so earlier security results no longer describe the running system.
Third-party AI security audits	Independent or contracted security audits of third-party AI resources exist, with dates, scope, findings and the remediation status for each finding.	Vendor security questionnaires are on file, but no audit covers the model, the hosted endpoint or the data flows the system depends on.
Attack information sharing documented	The organization records what attack patterns it shared, with which incident database or internal group, and when, along with the decision rule for sharing.	Sharing happens informally with no record, or no rule defines what the organization shares or with whom.
Evidence package and independent review	A dated evidence set maps each MEASURE 2.7 test to its results. An independent auditor or assessor reviews it and issues any conclusion. Implementation partners prepare the evidence but do not issue reports.	Evidence is assembled after the fact from memory, so dates, versions and results cannot be traced to the tests that produced them.

Implementing MEASURE 2.7 step by step

This sequence turns the MAP security risks for an AI system into documented metrics, tested countermeasures, monitoring and third-party audit requirements, so the organization can show that security and resilience were evaluated and recorded. Each step ends with an artifact the reader can hand to an assessor.

Confirm the security risks from MAP
Start from the MAP outputs for the system: the context, the components and the impacts already identified. Security and resilience concerns usually include adversarial examples, data poisoning, and exfiltration of models, training data or other intellectual property through system endpoints, as AI 100-1 Section 3.3 notes. For generative AI, add prompt injection, jailbreaks and fine-tuning that could weaken controls. The TEVV lead, a security engineer and the system owner should agree the list. The step is done when every security risk has a MAP reference and an owner, and the list is signed off before metrics are chosen.
Select security metrics and thresholds
For each confirmed risk, choose measures the team can collect repeatedly. The NIST AI RMF Playbook points to red-team results, anomalous event rates, downtime and time to bypass as examples. Set a threshold or acceptance condition for each metric, and record who can accept a result that falls outside it. Where the numbers do not yet exist, record the metric and the baseline you intend to establish rather than inventing a target. The output is a metric register that names the metric, its data source, its threshold and its decision owner.
Define red-team scope and adversarial conditions
Write the red-team charter before testing begins. Specify the systems, endpoints, data and tools in scope, the attacker profiles and the adversarial conditions to simulate, such as malicious prompts, poisoned inputs or abuse of model endpoints. For generative AI, the Generative AI Profile in NIST AI 600-1 calls for red-teaming against malicious code generation and attacks such as prompt injection and machine learning attacks. Record the rules of engagement and who can stop the test. The output is an approved scope document that the independent testers and the system owner have both signed.
Put countermeasures in place
Implement the controls that address the confirmed risks and the metrics. The Playbook suggests countermeasures such as authentication, throttling and differential privacy where the data justifies it. Each countermeasure should map to one risk and one metric so the effect can be measured. Confirm, for generative AI, that any fine-tuning step has been verified not to weaken safety and security controls, as the Generative AI Profile suggests. The output is a countermeasure register linking each control to its risk, its configuration record and the test that checks it.
Set up logging and monitoring
Instrument the system so the metrics in step two can be produced from real data. Application traces can record inputs, outputs, tool calls and timing for each request. Host and endpoint vulnerability data can come from tools that inventory installed software and match it against known vulnerabilities. Open-source options such as Langfuse, garak, Wazuh and Fleet can each produce part of this evidence, but the team should confirm what each platform captures in its own environment before relying on it. The output is a monitoring configuration and a sample report showing each metric being produced.
Document third-party security audit requirements
List every third-party AI resource in the system, including models, APIs, datasets and hosting services. The Playbook suggests requiring security audits of these resources. For each one, record which audit evidence the organization will request, such as a current independent report or a test summary, who reviews it, and what happens if the evidence is missing or stale. Coordinate with the supplier governance work under GOVERN 6 and MANAGE 3. The output is a third-party audit requirements table, with the evidence type, reviewer and review date for each supplier.
Document attack information sharing
Decide how confirmed attack patterns will be recorded and shared, internally and, where appropriate, with external incident databases or industry groups. The Playbook suggests sharing attack patterns with such databases. Define what is shared, what is withheld for confidentiality or legal reasons, who approves release and how sharing links to incident handling under MANAGE 4. Confirm any legal or contractual limits with counsel before sharing. The output is a written information sharing procedure and a log of shared items, even if the log is empty at the start.
Record results and evidence for assessors
Bring the outputs together into one evaluation record for MEASURE 2.7. Include the risk list, metric register, red-team reports, countermeasure register, monitoring samples, third-party audit table and sharing log. Note any metric that failed its threshold and the decision taken under MANAGE 1. The record should show dates, owners and versions so an independent assessor can trace each claim. Because the NIST AI RMF has no certification, the organization owns this record, and any outside assessor reviews it without issuing a certificate. The output is a versioned MEASURE 2.7 evaluation file, reviewed and approved by the accountable owner.

Evidence that satisfies MEASURE 2.7 and how to keep it current

An assessor reviewing MEASURE 2.7 looks for a current chain from the security risks identified in MAP to tests, results and countermeasures. The six artifacts below connect that chain, and each one has a refresh rhythm and a set of events that should force an update before the next scheduled review. Confirm the cadence you choose with your own risk owners, since the AI RMF sets no fixed intervals.

Security test plan tied to MAP risks

The plan lists each security risk recorded in MAP for the system, such as adversarial inputs, data poisoning, prompt injection or model extraction, and maps each one to the tests, metrics and owners that will evaluate it. Include the AI actor categories responsible for each test, drawn from the Playbook tags for MEASURE 2.7. Check that every MAP security risk has at least one test and that out-of-scope risks are recorded with a reason. Refresh the plan at each scheduled review and whenever the MAP risk register changes. Illustrative trigger: a new tool connection adds an attack surface that no existing test covers.

Red-team reports with scope and results

Each red-team exercise produces a report that states its scope, the adversarial conditions tested, the testers and their independence from the build team, the attack classes attempted and the outcomes. For generative systems, the Generative AI Profile expects red-teaming against abuse such as malicious code generation and attacks such as prompt injection. Verify that findings link to tracked remediation items and that retests confirm closure. Re-run exercises after any model change, new fine-tune or new tool connection, not only on the calendar.

Metric dashboards with thresholds and trends

Security metrics such as red-team results, anomalous event rates, downtime and time to bypass should be stored with the threshold each one must stay under and the trend over time. A metric without a threshold cannot show that the system stays within risk tolerance. Review the thresholds with the risk owner, and record each breach with the response taken. Keep the raw history so an assessor can see how values moved across model versions. Refresh the data continuously where monitoring allows, and review the thresholds at least at each scheduled review.

Countermeasure test records

Countermeasures such as authentication, request throttling and differential privacy need test records showing they work as designed under attack conditions. Record the control under test, the attack it was meant to stop, the test inputs and the observed behavior. Include any configuration keys, file names and version numbers so the test can be repeated. Retest a countermeasure whenever the model, its serving layer or its access policy changes, because a safeguard that passed on one version may not hold on the next. Confirm the fine-tuning safety checks described in the Generative AI Profile are part of this set for generative systems.

Third-party security audit reports

When a model, dataset, plug-in or hosted component comes from a third party, MEASURE 2.7 expects its security to be audited. Keep the audit report, its scope, the date it covers and a list of the findings that affect your deployment. Ask suppliers which versions the report covers, because an audit of one release does not cover the next. Record any finding you accept without remediation and who approved it. Request an updated report or a targeted review on each supplier version change, and treat a supplier that cannot provide one as a risk to be recorded in MAP.

Attack-information sharing log

The Playbook suggests sharing attack patterns with incident databases. A sharing log records each attack pattern the team observed or reproduced, the channel it was shared through, the date and what was shared, with sensitive details withheld where needed. The log also shows when your organization received external attack information and how it changed a test or countermeasure. Review the log at each scheduled review and after any significant incident. Confirm with legal and security leads which information can leave the organization before entries are created.

What meeting MEASURE 2.7 costs in money and effort

This table lists each cost component of evidencing MEASURE 2.7, who is paid for it, whether it is one-time or recurring, and what pushes it up or down. Use it to build a scope and quote request, since no supplied figures exist for dollar amounts or durations, so the reader should ask vendors and auditors for their own estimates. The main takeaway is that open-source tools can remove license spend, but the labor to build, run and evidence the tests remains.

Cost component	Who is paid	One-time or recurring	What drives it up or down
Tooling and licenses	Tool vendors, or none for Apache-2.0, MIT and GPL-2.0 tools	Recurring if commercial or hosted; often none for self-hosted open source	Count of endpoints and hosts, number of models under test, support tier. Open-source choice removes license lines but not operating cost
Engineering time for test harnesses and logging	Internal platform or ML engineers, or an implementation partner under a written scope	One-time build, then recurring maintenance	Number of model endpoints, logging depth such as traces covering tool calls and retrieval, and how often models change
Red-team labor (internal or external)	Internal security staff or a testing firm	Recurring, usually per exercise or per release	Attack surface, number of generative AI features, adversarial scope such as prompt injection and model extraction, and whether results must be reproduced
Evidence upkeep	Internal compliance or engineering owners	Recurring	Frequency of model updates, number of owners of each metric, and whether attack logs and test reports are kept in one repository
Third-party security audits of AI resources	External auditors or assessors, and the vendors who must supply documents	Recurring per audit cycle, plus one-time onboarding of each vendor	Number of third parties and models in the supply chain, contract terms that require audit access, and how much vendor documentation exists
Auditor sampling and testing	The independent auditor or assessor (the auditor issues any report)	Recurring per audit cycle	Sample size requested, number of systems in scope, and how well evidence is organized before fieldwork begins
Incident and attack information sharing	Internal security and AI operations staff	Recurring	Volume of anomalous events, number of external channels used, and whether reporting steps are documented in advance

Which self-hosted open-source tools support MEASURE 2.7 evidence

MEASURE 2.7 asks organizations to evaluate and document the security and resilience of AI systems identified in MAP. The four tools below each produce a different kind of evidence, from model-level probe results to runtime traces and host-level vulnerability findings. Use them to build the record, then have your red-team lead and assessors judge what the records mean.

garak for model probing

garak is an Apache-2.0 scanner that probes language models for prompt injection, jailbreaks, data leakage, hallucination, misinformation and toxic output. It writes a JSONL report of every attempt and evaluation, plus a hit log of attempts that found a weakness. For MEASURE 2.7, the hit log and the full report together show which attacks were tried, which succeeded, and how the results changed after each countermeasure. Confirm that the probes you need exist in your garak version and that the target model can be reached from your test environment.

Langfuse for runtime traces

Langfuse is an MIT-licensed observability platform. Each trace records every operation in a request, including LLM calls, retrieval steps, tool executions and custom logic, with timing, inputs, outputs, token usage and metadata. For MEASURE 2.7, traces show how an attack or misuse moved through retrieval and tool calls, and they supply the timing data used for downtime and response-time metrics. Check how your team handles personal data in inputs and outputs before you store traces, because they often contain it.

Wazuh for endpoint vulnerabilities

Wazuh is GPL-2.0-only software. Its vulnerability detection correlates the software inventory from each agent with the Wazuh CTI vulnerability repository, or with a locally hosted offline copy, to identify vulnerabilities in the operating system and installed applications of monitored endpoints. For MEASURE 2.7, it documents the security state of the hosts that run model servers, gateways and vector stores. Using the offline copy suits air-gapped networks, but you must confirm how and when that copy is refreshed.

Fleet for software exposure

Fleet is an MIT-licensed device management platform. It detects vulnerable software on enrolled hosts by matching installed software against sources including the NVD, OVAL definitions, Microsoft security bulletins, Amazon Linux advisories and OSV. For MEASURE 2.7, it provides a dated view of which hosts carry vulnerable packages and supports tracking those findings to remediation. Confirm that the sources cover your operating systems, because coverage differs by platform and some hosts may fall outside the matching data.

Who does what for MEASURE 2.7: your team, a partner and the auditor

Your organization owns the AI RMF outcome. NIST describes the framework as voluntary, so there is no certificate to earn, but the organization still decides which security risks identified in MAP are acceptable, which thresholds trigger action, and who signs off on the final security documentation. A partner can run tests and assemble evidence, but it cannot accept risk on your behalf.

Risk decisions: Set the thresholds for red-team results, anomalous event rates and downtime, and decide what happens when a test fails.
Accountable sign-off: Name the individual who accepts residual AI security risk and records go or no-go decisions for each system.
Final documentation: Own the security documentation, test plans and metric definitions that describe how the system is evaluated.
Policy and scope: Define which AI systems, models, data sources and third-party components fall inside MEASURE 2.7.
Ongoing review: Decide how often tests repeat and who reviews results after each model or prompt change.

Before engaging anyone, confirm internally who holds each of these decisions and where the approvals are recorded.

Where organizations fall short on MEASURE 2.7 and how to close each gap

MEASURE 2.7 asks whether security and resilience risks identified in MAP are actually evaluated and documented. The gaps below recur across programs that have a security narrative but little tested evidence. Each card names a closing action an owner can assign and check.

Security risks dropped between MAP and TEVV

Security risks are often named during MAP, then never appear in the TEVV plan. Adversarial examples, data poisoning and model or data exfiltration through endpoints can all be listed in a risk register and still have no test attached. Close it by tracing each MAP security risk to a named TEVV test, owner and pass condition, and asking the TEVV lead to show that trace before any deployment decision.

Red-team exercises without written scope

Red-team work is frequently run as an informal session with no written rules of engagement, no adversarial conditions and no record of what was attempted. The results then cannot be compared across releases or defended to an assessor. Close it by issuing a one-page charter that defines targets, attack categories (such as prompt injection or malicious code generation for generative systems), permitted techniques, and the format in which every attempt is logged.

Metrics recorded without thresholds or owners

Teams often log red-team results, anomalous event rates, downtime and time to bypass, yet no one has set an acceptable level or assigned who reviews a breach of it. A metric without a threshold cannot show that risk stayed within tolerance. Close it by setting a threshold and a named owner for each security metric, with a documented response when the threshold is crossed.

Countermeasures declared but never tested

Authentication, throttling and differential privacy often appear in architecture diagrams without evidence that they work against the attacks they target. An untested countermeasure is a claim, not a control. Close it by writing one test per countermeasure that attempts to defeat it, recording the result, and repeating the test after each change to the affected component.

Fine-tuning that erodes safety and security controls

Fine-tuning or retrieval changes can weaken guardrails that passed earlier testing, and the model card often still shows the original results. NIST AI 600-1 addresses this directly by asking organizations to verify that fine-tuning does not compromise safety and security controls. Close it by making a rerun of the security test set a required gate in the change process for every fine-tuned model before release.

No third-party audit or attack information sharing

Third-party AI components, including pre-trained models and hosted APIs, are often accepted without a security audit, and attacks observed in production rarely reach a shared record. MEASURE 2.7 expects security audits of third-party AI resources and sharing of attack patterns with incident databases. Close it by requiring a documented security audit or equivalent assurance evidence before onboarding each third-party resource, and assigning one person to submit confirmed attack patterns to an external incident database.

MEASURE 2.7 questions buyers ask before hiring outside help

How much effort does MEASURE 2.7 take, and what drives it?

The effort depends mainly on how many AI systems are in scope, how exposed they are to users or the internet, and how much security testing already exists. MEASURE 2.7 asks you to evaluate and document the security and resilience risks identified in MAP, so the first cost driver is the size of the risk inventory from MAP. A single internal model with no external endpoint needs far less work than a customer-facing generative AI assistant connected to tools and data. Other drivers include the number of third-party models and components, whether red-team exercises are repeated, and how much logging already exists. The NIST AI RMF does not publish a price or duration for this subcategory, so ask any provider to show the effort split by system and by activity in a written scope.

Can our in-house team meet MEASURE 2.7 without outside help?

Yes, many organizations do this work internally, provided the people involved have security testing skills, access to the systems under test and authority to act on findings. The subcategory is voluntary to adopt, so no external body requires an outside firm. Internal teams usually struggle with independence, since the people who built a model are often the least able to judge its weaknesses, and with time, because security testing competes with delivery work. An outside partner can add capacity for red-team exercises, metric setup and evidence packaging, while your organization keeps ownership of the decisions. Confirm internal skills and capacity with a short gap review before deciding.

How long does MEASURE 2.7 preparation usually take?

No supplied source gives a standard duration for MEASURE 2.7 preparation, so treat any single number with caution. The length is set by the number of systems, whether a security baseline and logging already exist, how many red-team cycles you plan, and how long your change approvals and access requests take. Tooling setup is usually shorter than the work of agreeing on metrics, owners and acceptance thresholds. Ask for a timeline that lists each milestone, the dependency it waits on, and the person responsible for providing access or sign-off. A fixed-scope agreement should state those dates in writing before work begins.

What do our engineers and security staff need to provide?

Your team supplies the knowledge and access that no outside party can invent. Engineers need to explain system architecture, data flows, model versions, fine-tuning history, and where logs are kept. Security staff need to confirm threat priorities, incident response procedures, and which findings can be accepted or must be fixed. Both groups should agree on who owns each security metric and who reviews results. Expect recurring time from named people during testing windows, and plan for remediation work that follows findings. Ask a provider to list these inputs, owners and approval points in the statement of work.

Does NIST AI RMF have a certification for MEASURE 2.7?

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. NIST describes the framework as voluntary, so you cannot earn a MEASURE 2.7 certificate from NIST or any agent acting for it. What you can do is document how you evaluated security and resilience, and an independent assessor may review that documentation if a customer or contract requires it. Be cautious with any vendor that offers an AI RMF certificate, and ask which body issued it and what standard it tested against. Confirm current NIST program status on the NIST AI RMF pages before relying on any statement.

How do red-team exercises differ from automated probing?

Automated probing runs a defined set of known tests against a model or application repeatedly, which is useful for regression checks and for broad coverage. For example, garak probes language models for prompt injection, data leakage, jailbreaks and toxic output, and writes a JSONL report of each attempt and a hit log of attempts that found a weakness. A red-team exercise is a human-led, adversarial effort that designs new attacks against the specific system, its data, tools and users, and tests whether the controls hold under realistic pressure. MEASURE 2.7 expects both, since automated tests track known weaknesses while red teams find unknown ones. Ask whether the provider will record each attack, the outcome and the fix.

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

A fixed-scope quote should state the systems covered, the risks from MAP each activity addresses, and the deliverables. Ask for a list of the security tests and metrics to be tracked, such as red-team results, anomalous event rates, downtime and time to bypass, along with the tools used and how their output is stored. Require the schedule, the named responsibilities on both sides, the acceptance criteria for each deliverable, and what happens when a finding requires changes outside scope. Also ask which items recur after the engagement, such as monitoring, re-testing or evidence refresh, and how those are priced. DeployOpen does not publish a price list; a quote follows from the written scope.

How DeployOpen scopes and prepares MEASURE 2.7 evidence

DeployOpen works on MEASURE 2.7 by preparing the systems and evidence that show your AI system's security and resilience, as identified in MAP, is evaluated and documented. Your organization owns the risk decisions and the controls, and an independent assessor is the party that tests them and issues any report.

How we scope

Agree in writing which AI systems, components and MAP-identified security risks fall within the MEASURE 2.7 scope.
Confirm which AI actor categories own each test, such as TEVV, operations and monitoring, and deployment.
Define the security metrics, red-team scenarios and third-party AI resources covered, with deliverables and timelines fixed before work starts.

How we build

Deploy open-source security test tooling inside your own cloud accounts, data centers or air-gapped networks.
Configure red-team probes for prompt injection, data leakage and jailbreak attempts against language model endpoints.
Set up tracing and vulnerability detection so security metrics, such as anomalous event rates and downtime, are logged and reviewable.

How we hand over

Deliver test plans, run records, metric definitions and red-team reports mapped to the MEASURE 2.7 outcome.
Document countermeasures such as authentication, throttling and access controls, with configuration details and ownership.
Hand over runbooks so your own staff can repeat tests and produce the same evidence for an independent assessor.

How we support

Offer ongoing support, upgrades and continuous security testing as a retainer after the fixed-scope engagement ends.
Review evidence again when the AI system changes, new third-party models are added or the NIST framework is revised.
Confirm with your assessor which evidence formats and retention periods they expect before the review begins.