MAP 3.3 Targeted application scope: NIST AI RMF evidence

What MAP 3.3 targeted application scope asks you to write down

MAP 3.3 asks you to specify and document the targeted application scope of an AI system, built from three inputs: what the system is capable of doing, the established context it will operate in, and the system's categorization under MAP 2. If you are the compliance lead, engineer or buyer being asked where an AI system is allowed to operate, your answer is a written scope statement that ties those three inputs together. NIST AI 100-1 describes the outcome but does not prescribe a format, template or level of detail. That means the document can be a short controlled page, a section of a system card or a record in your AI inventory, as long as an assessor can trace each boundary back to a capability, a context and a category. Confirm how your organization's existing policies and documentation standards define a controlled document before you choose where the scope lives.

The risk this outcome addresses is simple to state and common in practice: a system is used for something it was never built, tested or categorized for. A scoring model validated on one customer population gets applied to another, or a tool designed for internal drafting ends up producing content that customers read. Scope statements are often vague ("customer support assistance") or written after deployment, when someone asks for a description and the team reconstructs it from memory. A scope written after the fact describes what the system does, not what it was approved to do, and that gap is exactly what an assessor will probe. Writing the scope before go-live, and revisiting it when the context changes, is what turns it into a control rather than a description.

Practically, a useful scope names the affected groups the system may touch, the geographies and languages it may serve, the time between retrainings or model refreshes it assumes, and the misuse scenarios you consider likely enough to exclude explicitly. The Playbook suggests considering narrowing deployment contexts along these lines, and it recommends involving legal and procurement functions when the target scope is set. Ask those functions which contractual, licensing and data-use limits already apply, because they often define boundaries the engineering team has not considered. Illustratively, a document-summarization tool scoped to internal policy documents in one jurisdiction is easier to defend than one described only as "document AI for the business."

Which systems, groups and decisions the target scope must cover

MAP 3.3 asks an organization to fix the targeted application scope before the system is built or bought out to full use. The cards below set out the decisions that most change the work, drawn from the Playbook's suggested actions for this subcategory. The Playbook is a set of suggestions, not a checklist, so each team decides which of these apply to its system.

Affected groups

Start by naming the people and groups the system's outputs will reach, including those who are not users, such as applicants, patients, customers or staff being evaluated. The Playbook suggests narrowing deployment by affected group, because a system limited to internal analysts carries a different impact profile from one that makes decisions about members of the public. Check whether each group is in scope and whether the evidence you plan to collect covers it. Illustrative example: a model scoped to rank internal support tickets may be narrowed to exclude customer-facing decisions.

Geography and jurisdiction

Record the countries, regions and legal regimes where the system will operate, since the same model can carry different obligations across borders. The Playbook suggests considering geography as a narrowing factor. Confirm with legal counsel which local rules apply to each location and whether a rollout can start in one region before expanding. Scope decisions made here feed directly into the deployment and monitoring plans that follow.

Retraining interval

Document how often the model will be retrained, refreshed or re-tuned, and what triggers an unscheduled update. The Playbook suggests considering the time between retrainings when narrowing deployment, because a system that changes frequently needs more frequent testing and a longer evidence trail. Specify who approves each retrained version before it reaches production. A fixed, documented interval is easier to evidence than ad hoc updates.

Likelihood of misuse

Assess how the system could be used outside its intended purpose, by internal staff or by outside parties who gain access. The Playbook suggests narrowing deployment according to the likelihood of misuse, which can mean restricting access, limiting outputs or blocking use cases the team has not tested. Document the misuse scenarios considered, the controls chosen for each, and the uses that are explicitly out of scope so reviewers can see the boundary.

Legal and procurement sign-off

The Playbook expects legal and procurement functions to take part when the target scope is set. Legal review identifies the obligations that attach to the chosen groups and locations, while procurement confirms what contracts with AI vendors and data providers permit. Ask each function to sign off on the written scope, and record any terms that limit use, such as restrictions on data reuse or on the vendor's model updates.

Scope boundaries and exclusions

Write down what the system will not do, along with the components and data sources it will not touch. A narrower scope limits the risks to assess and the evidence that auditors or customers will ask for later. Review the boundary whenever a new feature, user group or data source is proposed, and treat an unapproved expansion as a scope change that repeats the decisions above. Keep this statement with the system's documentation.

How an assessor tests the target scope documentation

This table walks through how an assessor reviews MAP 3.3, from comparing the written scope against stated capability to sampling live deployments and checking change records. Read each row as a test step, the evidence it calls for and the findings that usually appear when it fails. Note that NIST AI RMF has no certification, so these tests are internal or independent reviews, and only an independent assessor issues any report.

Test step	What the assessor checks	Evidence requested	Common findings
Compare scope to capability	The written target scope matches what the system can do, its tasks, methods and known limits	Scope statement, system capability description, model or tool documentation	Scope names tasks the system cannot perform reliably, or omits capabilities it has
Check context records	The scope reflects the established context from MAP 1, including intended users and mission	MAP 1 context records, stakeholder list, intended purpose statement	Scope written without reference to the context record, so the two drift apart
Check categorization support	The scope follows from the MAP 2 categorization of tasks, knowledge limits and human use of output	MAP 2 categorization record, known limitations log, human review procedures	Categorization says outputs are advisory, but scope permits automated decisions
Test narrowing decisions	Deployment contexts are narrowed by affected groups, retraining interval, geography and misuse likelihood, with reasons recorded	Decision records showing each narrowing factor and its rationale	No record of why a context was included or excluded, or narrowing covers only one factor
Sample live deployments	Sampled deployments stay inside the documented scope on user groups, regions and use cases	Deployment inventory, access logs, configuration exports for the sampled systems	Production use in a region or user group the scope does not name
Review scope changes	Each change to the scope was assessed, approved and communicated before the change took effect	Change tickets, approval records, version history of the scope document	Scope never updated after a new feature, data source or customer segment was added
Confirm legal and procurement input	Legal and procurement functions were involved when the target scope was set, as the Playbook suggests	Meeting records, sign-off from legal and procurement, vendor contract terms	Scope set by the AI team alone, with no record of contract or legal review
Check scope limits are explicit	The document states prohibited uses and boundaries, not only intended uses	Scope document with an explicit exclusions section and enforcement controls	Scope lists what the system is for but names no limits, so out-of-scope use cannot be detected

Steps to specify and document the target scope

This sequence turns the MAP 1 context and MAP 2 categorization into a written, approved statement of where the AI system may and may not be used. The result is a scope record that legal, procurement and accountable owners have reviewed and that feeds the go or no-go decision.

Confirm the MAP 1 context and MAP 2 categorization
Start by pulling the intended purpose, mission, risk tolerances and system requirements from the MAP 1 record, along with the tasks, methods, knowledge limits and human use of output from MAP 2. Check that both still describe the system as it will be deployed, not as it was first proposed. The step closes when the product owner and the risk lead sign off that the two inputs are current and consistent with each other.
Define capability in operational terms
Describe what the system can do in terms a deployment team can test against, such as the inputs it accepts, the decisions or outputs it produces, the users who receive those outputs and the actions it can trigger. Separate what the system is capable of from what the business intends it to do, because the gap between the two is where scope creep begins. The output is a short capability statement with explicit exclusions, reviewed by the AI design and development leads.
Decide the narrowing dimensions
Work through the dimensions the Playbook suggests for MAP 3.3: affected groups, time between retrainings, geography and likelihood of misuse. For each dimension, record the boundary you will enforce, such as which populations or regions are in scope, how long a model version may run before review, and which misuse patterns the design must block. The output is a dimension table in which every boundary names the control or configuration that enforces it.
Obtain legal and procurement input
Send the draft capability statement and dimension table to legal and procurement, as the Playbook suggests. Legal reviews whether the boundaries match applicable obligations and contract terms, and procurement confirms that third-party models, data and services support the proposed scope and its limits. Record each comment and how it changed the draft. The step closes when both functions have replied in writing and their comments are resolved or formally accepted as residual.
Record the scope with named approvers
Write the final targeted application scope as a controlled document that states the intended use, excluded uses, narrowing boundaries, assumptions and the date of review. Name each approver by role and person, and make sure the approval reflects the accountability structure set under GOVERN 2. The output is an approved scope record with version history, so any later change can be compared against the version that was approved.
Link the scope to the go or no-go decision
Attach the approved scope to the MANAGE 1 go or no-go determination so the decision is made against a defined use, not a general idea of the system. Flag any MAP or MEASURE findings that would require the scope to change before launch. The step closes when the decision record cites the scope version it relies on and the accountable executive has recorded the outcome.
Hold the scope under change control
Set a trigger list for reopening the scope, including new user groups, new geographies, model retraining, changed vendors or misuse reports, and route each trigger back through the earlier steps. Confirm that the platform used to store the scope keeps change history and access controls, so reviewers can see who changed a boundary and when. The step is complete when the trigger list and the storage arrangement are documented and the owner has confirmed them.

Evidence that shows a documented target scope and how to keep it current

MAP 3.3 is satisfied by a set of linked records, not a single document. The scope statement, its approval, the context and categorization it rests on, and the deployment records that show use inside the boundary all need to agree. The cards below cover each artifact and the change control that keeps them accurate between assessments.

The scope statement

This is the written specification of the targeted application scope: the capabilities the system is built for, the users and affected groups it serves, the deployment contexts it covers, and the uses it excludes. Write exclusions as explicitly as inclusions, since an unstated boundary is the most common gap an assessor finds. Check that each deployment context named here narrows the scope where the Playbook suggests it, such as by affected group, geography or retraining interval.

Approval record and sign-off

Record who approved the scope, when, and on what basis. Legal and procurement functions should appear here where the scope touches contracts, data rights or regional rules, as the Playbook suggests. Name the approver's role, not only a name, so the record still makes sense after staff change. Keep the approval tied to the version of the scope it covers, so an assessor can see which boundary was in force on a given date.

Linked context and categorization records

The scope should cite the MAP 1 context record (intended purpose, mission, risk tolerances) and the MAP 2 categorization (tasks, methods, knowledge limits, human use of output). A scope that cannot be traced back to these records is hard to defend. Confirm that each link points to the current version of its source, and that a change to either source prompts a review of the scope.

Deployment records showing use within scope

Keep records of where the system actually runs: environments, user groups, regions, and the date each deployment or expansion occurred. Compare these against the scope statement regularly. A deployment outside the documented boundary is a finding even when the system performs well. Ask your team to confirm which logs or configuration exports can produce these records without manual reconstruction.

Change control and review triggers

Define the events that force a scope review before the next scheduled audit: a new deployment context, a new affected group, a model or data source change, a new geography, or a change in the legal requirements that apply. Record each trigger, the reviewer, and the outcome. Without written triggers, scope drift tends to happen quietly between audits.

Wiki options for version history and access

XWiki, under LGPL-2.1-or-later, keeps every page change under version control, recording what changed, when and by whom, and lets reviewers compare any two versions and roll back. BookStack, under MIT, assigns abilities through roles that can be overridden per shelf, book, chapter or page. Confirm which fits your needs: XWiki suits teams that prioritize change history, while BookStack suits teams that need fine-grained access control over sensitive scope records.

What specifying the target application scope costs

This table breaks down the internal and external effort behind documenting a MAP 3.3 target scope, marking each component as one-time or recurring. Read it as a checklist for where time goes and what to request in a written quote. No prices or durations are given because none are supplied for this topic.

Cost component	Who does the work	One-time or recurring	What drives it up or down
Defining capability and limits	Product owners, AI design and development staff	One-time per system, then recurring on change	Number of systems and capabilities; the more tasks a system performs, the more limits must be written and tested
Narrowing deployment contexts	AI design, development and human factors staff	One-time, recurring when contexts are added	Number of deployment contexts, affected groups, geographies and retraining intervals named in the playbook actions
Legal and procurement review	Legal counsel and procurement staff	One-time per contract or scope, recurring at renewal	Contract count, vendor-supplied components and how often third-party terms change
Governance approvals	Accountable executives and risk committee	Recurring at each scope change or review cycle	Frequency of scope changes and the approval tiers already defined under GOVERN policies
Evidence upkeep	Document owners and platform or wiki administrators	Recurring	Volume of scope documents, version history depth and how many reviewers sign off each revision
Platform licensing for documentation	Platform or IT team	Recurring license fees for commercial wiki or repository tools	Seat count and tool choice; self-hosted open source such as XWiki or BookStack can remove or reduce per-seat wiki spend, subject to hosting and support costs
External review or auditor sampling	Independent auditor or assessor, if engaged	Periodic, per engagement	Number of systems sampled and how well scope records trace to the system's categorization; confirm the auditor's fee basis in writing
Implementation partner preparation	Implementation partner, under a written scope	One-time setup, optional retainer for upkeep	Number of systems, existing documentation quality and whether templates are built once and reused

Who writes the scope, who reviews it and what a partner can prepare

The MAP 3.3 outcome is an organizational decision, so your own people own it. The Playbook tags this subcategory with three AI actor categories: AI Design, AI Development and Human Factors. NIST AI 100-1 Appendix A describes the tasks of each actor category, and those task descriptions are the starting point for deciding who signs off on what. Design people shape the intended use and the contexts the system is meant for. Development people know the system's capability limits and the conditions under which its performance degrades. Human factors people understand who uses the output and how they might misuse or over-rely on it.

AI design: Defines the intended application and the settings where the system is meant to operate.
AI development: States the technical capability, known failure conditions and the points where retraining or model changes alter the scope.
Human factors: Identifies the users, affected groups and likelihood of misuse that should narrow deployment contexts.
Legal and procurement: The Playbook suggests involving these functions when specifying the target scope, so contract limits and jurisdictional constraints are written in.
Named approver: One accountable owner who accepts the final scope record.

Confirm that each named role has a written responsibility in your GOVERN 2 accountability structure before the scope is drafted.

Where target scopes fail in practice and how to close each gap

Targeted application scope tends to fail in predictable ways: the wording is too broad, it arrives too late, or it is never connected to the rest of the risk work. The cards below cover six gaps an assessor or auditor is likely to notice, with a concrete way to close each one.

Intended use without exclusions

A scope that says what the system is for but never says what it must not be used for leaves the boundary open to interpretation. Teams then drift into adjacent uses, such as a summarization tool being reused to rank job candidates. To close this gap, write a list of excluded uses, affected groups and decisions the system must not inform, and have the product owner sign it. Check that each exclusion maps to a control or a monitoring check.

Scope written after launch

When the scope is documented after a system is already in production, the documentation describes what was built rather than what was approved to be built. MAP 3.3 expects the scope to be set from the system's capability and context before deployment decisions are made. Close this gap by making a dated scope statement a go-live prerequisite, and by recording any later change as a version with a stated reason.

No link to categorization

A scope that does not reference the system's categorization under MAP 2 can be correct in wording and still miss the risks that matter most. Two systems with the same interface may carry very different categories based on tasks, knowledge limits and how humans use the output. Close this gap by citing the MAP 2 categorization record in the scope document and checking that each permitted context fits within the categorized tasks.

No legal or procurement sign-off

The Playbook suggests involving legal and procurement functions when specifying the target scope. Without them, contract terms, data licenses and vendor restrictions can contradict what the scope allows, and a third-party model may be used outside the terms it was supplied under. Close this gap by adding named legal and procurement reviewers to the scope approval record, with the vendor terms and data sources they reviewed listed beside the scope.

No trigger for revisiting scope

Scope is often approved once and then left alone while the model is retrained, a new region is added or a new customer group starts using the system. Each of these can move the system outside its documented boundary without anyone deciding that it should. Close this gap by writing explicit triggers into the scope document, such as a retraining, a new geography, a new affected group or a change in misuse likelihood, each with a named owner who must reassess the scope.

Generative AI with no MAP 3.3 actions

NIST AI 600-1 does not list suggested actions for MAP 3.3, and the profile states that not every subcategory is covered. Teams deploying generative AI can wrongly read this as no scope work being needed. Close this gap by using the base Playbook suggestions for MAP 3.3 alongside the profile, and by documenting the narrowed deployment contexts for each generative use, such as the user groups, languages and content types the tool supports.

Questions buyers ask before bringing in help with MAP 3.3

Will an auditor certify MAP 3.3 for us?

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. Your organization can document how it specified its targeted application scope, and a reviewer such as an internal audit team, a customer assessor or an ISO/IEC 42001 auditor may read that record. Only an independent auditor or certification body issues reports or certificates. If a customer asks for a MAP 3.3 certificate, ask them what document they actually need, usually a written scope record with supporting evidence.

How much effort does MAP 3.3 take, and what drives it?

The effort depends mostly on how many AI systems are in scope, how many deployment contexts each one has, and how much of the system is built from third-party models and data. Costs are split between internal staff time (product owners, AI developers, legal and procurement reviewers) and any external help you buy. Most of the work is one-time for each system, then recurs when the system's capability, user groups or geography change. Ask any partner for a written scope that lists the systems, contexts and reviewers involved before you accept a quote.

Can our own team do MAP 3.3 without outside help?

Often yes, if you have people who know the system's capabilities and the business context. The NIST AI RMF Playbook gives suggested actions and documentation prompts for MAP 3.3, but it states it is neither a checklist nor a set of steps, so your team still has to make the decisions. Teams usually need outside help when they lack engineers who can describe model behavior, when legal or procurement reviews are unclear, or when they want an independent reviewer to test whether the narrowed scope holds up.

What does MAP 3.3 need from engineering and legal?

Engineering supplies the facts that define the scope: what the system can and cannot do, how its outputs are used, how often it is retrained and which data sources feed it. Legal and procurement review the limits that matter to contracts and obligations, such as which affected groups, geographies and uses are permitted. The Playbook tags MAP 3.3 with the AI Design, AI Development and Human Factors actor categories, so product, development and human factors staff should all review the draft. Record who approved each limit and when.

How long does a first MAP 3.3 scope record take to produce?

No duration can be given without knowing the system, its contexts and the review process. The time usually depends on how quickly engineering can describe the system's capability, how many reviewers must sign off and whether the team already has a documented context from MAP 1 and a categorization from MAP 2. Ask a prospective partner to tie the timeline to a written scope with named deliverables, and ask your own reviewers to commit to dates before work starts.

Does MAP 3.3 apply to generative AI systems?

Yes, the outcome applies to any AI system you specify, including generative AI. NIST AI 600-1, the Generative AI Profile published July 26, 2024, lists no suggested actions for MAP 3.3 and says not every subcategory is included. That means you should use the base AI RMF Playbook guidance for MAP 3.3 and document how your generative AI scope narrows deployment contexts, such as limiting user groups or likelihood of misuse. Confirm the current profile content directly on NIST's site, because the AI RMF is under revision.

What should a partner do for MAP 3.3, and what should it avoid?

A partner can help prepare the system description, document the scope record, set up version-controlled storage for the record and review the evidence against the Playbook suggestions. DeployOpen prepares systems, controls and evidence; it does not issue audit reports, attestations or certifications. A partner should not decide your risk tolerance, approve the scope on your behalf, or promise that a reviewer will accept it. Under a fixed-scope agreement, the deliverables and responsibilities should be listed in writing before work begins.

How DeployOpen works on this

DeployOpen helps teams that run self-hosted open-source platforms write down the targeted application scope for each AI system, then keeps the scope record current as the system changes. The work covers scope, build, handover and ongoing support inside the client's own infrastructure, and DeployOpen does not issue any assessment report or certificate.

How we scope

Engagements are fixed-scope, with the MAP 3.3 scope record, deliverables and timeline agreed in writing before work starts.
We review the system's capability, its established context and its categorization to define which deployment contexts are in and out of scope.
The written scope lists the narrowing decisions, such as affected groups, geography, retraining interval and misuse likelihood, with the reasons for each.

How we build

We set up the scope record in the client's documentation platform, with named owners and approval steps for each scope boundary.
We configure access so that only assigned roles can edit scope statements, with overrides limited to the shelf, book, chapter or page where needed.
We connect scope statements to the related context, categorization and risk records so an assessor can trace each boundary to its source.

How we hand over

Handover includes the final scope record, change history and a list of the people who approved each boundary.
We document where legal and procurement reviews of the target scope are recorded, so the client can show who was involved and when.
The client receives a short guide explaining how to request a scope change and how the record is revised when the system changes.

How we support

Ongoing support and scheduled reviews are available as a retainer, so scope records stay aligned with changes to the AI system.
We can help the client confirm the scope record against the current NIST AI 100-1 and Playbook wording before each review cycle.
Assessment decisions and any independent review remain with the client's own team and an independent auditor or assessor of the client's choosing.