What MAP 4.2 internal risk controls for components asks for
MAP 4.2 is an outcome in the Map function of NIST AI 100-1, the AI Risk Management Framework 1.0. It asks that internal risk controls for AI system components, including third-party AI technologies, are identified and documented. If your team has bought or built AI components and cannot yet show which internal controls cover each one, this outcome describes the gap. The risk it addresses is unmanaged exposure from data, software and models your team did not build, where the people deploying a system may not know what it depends on, what it was trained on, or which controls apply to it.
The gap is usually organizational before it is technical. Ownership is split between the data science group that selected a model, the platform team that hosts it, and procurement that signed the contract, so no one holds the full list. There is often no inventory that ties each model, dataset, library and API to a named owner and a set of controls. Vendor documentation is frequently thin, covering features and pricing but not training data provenance, known failure modes or vulnerability handling. The first practical step is an inventory that names an accountable owner for every component, followed by a record of which existing procurement, security and privacy controls apply to it.
The AI RMF is voluntary and NIST does not certify anyone against it, so no certificate follows from meeting MAP 4.2. The evidence you produce serves your own governance and the customers, partners or regulators who ask how you manage third-party AI. Before you commit to a scope, confirm with your legal and procurement teams which third-party terms, audit rights and data handling clauses already exist, because those determine what evidence a vendor can actually provide. The NIST AI 100-1 publication sets out the outcome in full, and the wording of its Map function table is the reference your evidence should be checked against.
Which components, data, teams and third parties MAP 4.2 covers
MAP 4.2 has no fixed scope. Your organization decides which components, third parties, teams and deployment stages fall under internal risk controls, and those decisions set how much mapping and documentation work follows. The cards below list the decisions that most often change the effort and the people who must be involved.
Pre-trained models and fine-tuned weights
Pre-trained models you download, fine-tune or embed are components with their own provenance, licenses and known weaknesses, so they belong in MAP 4.2 even when your team never trained them. For each model, record the source, version, license terms and any fine-tuning data. The Playbook suggests reviewing third-party models for bias, privacy and security vulnerabilities, so confirm who runs those reviews and where the results are stored. Decide whether model files are tracked in the same inventory as code dependencies.
Hosted APIs and inference services
A hosted model endpoint or third-party API sends your data and prompts outside your boundary, which changes both the security and the legal risk picture. Decide whether the service is in scope as a component, a third party, or both, and document what data it receives, where it is processed and how long the provider retains it. Confirm whether the provider's terms allow you to audit, obtain documentation or receive notice of model changes. Those answers determine which controls you can actually apply.
Datasets and training data sources
Datasets acquired from vendors, scraped sources, public corpora and internal records each carry different intellectual property, consent and privacy obligations. MAP 4.2 asks you to identify internal controls over this data, so record the license or basis of use, the personal data it contains and the review that approved it. Decide whether synthetic or augmented data inherits the risk of its source material. Teams often overlook data used only for evaluation, which still needs documented controls.
Open-source libraries and software dependencies
Frameworks, inference runtimes and utility packages that your AI system imports are software components subject to the same procurement and security controls as other dependencies. Decide how deep the inventory goes, whether transitive dependencies count and which license types require review. Tools such as Dependency-Track consume and produce CycloneDX SBOMs and track license use by SPDX license ID, and Trivy can generate an SBOM from a target or scan an existing one. Confirm which of these outputs your procurement and security teams will accept as evidence.
Third parties that hamper risk mapping
The Playbook suggests treating a third party that will not provide documentation or access for risk mapping as a sign of higher risk, which makes this a scoping question as well as a due diligence one. List each supplier that provides a model, data, software or hosting, and record what documentation it has agreed to provide. Decide in advance how a refusal changes the risk rating, the approval path and the contingency plan. Procurement, legal and the system owner should agree on this rule before contracts are signed.
Internal teams that own each component
The Playbook tags MAP 4.2 with the AI actor categories AI Deployment, TEVV, Operation and Monitoring, and Third-party entities, so each component should have a named owner in each relevant group. Deployment teams own configuration and integration, TEVV teams test and validate, operations teams monitor in production, and procurement or vendor management handles the third-party relationship. AI 100-1 Appendix A describes the tasks of each actor category. Map every component to a responsible owner in each category and confirm the handoffs in writing.
Deployment stages in scope
Decide whether MAP 4.2 covers only production components or also development, evaluation and retirement stages. A model used in a pilot may carry different data and third-party exposure than one in production, and a retired component may still hold retained data or active credentials. Document which stage each component is in and which controls apply at that stage. Revisit the scope when a component moves between stages, since controls that were adequate in testing may not cover live customer data.
How the Playbook's suggested actions for MAP 4.2 shape the control set
The NIST AI RMF Playbook offers suggested actions, documentation prompts and references for MAP 4.2, but NIST is explicit that the Playbook is neither a checklist nor a set of steps. Treat its entries as a menu of candidate controls that you select, adapt and justify for each component of your AI system. Your organization owns the decision about which controls apply, and an independent assessor will test whether the choices are documented and followed, not whether every suggestion was copied verbatim.
The suggested themes are practical. Where a third party makes it hard to map risk, such as by withholding model documentation or data lineage, the Playbook suggests treating that opacity as a sign of higher risk. Other suggestions include documentation templates for third-party AI, software safelists that define which components may enter the environment, reviews of third-party data and models for bias, privacy and security vulnerabilities, and application of procurement, security and privacy controls to all acquired AI technologies. For each component on your inventory, record which theme applies, which internal control covers it, and who approves the exception when a supplier cannot provide what you ask for.
Confirm the current wording before you rely on any of this. The Playbook's audit log shows its last content update in August 2023, and AIRC has said it will update the Playbook after the AI RMF itself is revised. The Generative AI Profile (NIST AI 600-1) lists no suggested actions for MAP 4.2, so generative AI components need their own documented controls drawn from the Playbook and your existing procurement and security baseline. Check the NIST AIRC Playbook for the Map function against your version of the framework before you finalize the control set.
How an assessor tests MAP 4.2 and what evidence passes
This table compares four test approaches an internal audit or independent reviewer uses for MAP 4.2, the evidence each one requests, and the findings that show up most often. Because the AI RMF has no conformity assessment, the reviewer checks the organization's own records against its own documented controls, and the main takeaway is that a control only passes when the documentation matches what happened.
| Test approach | Evidence requested | Common finding |
|---|---|---|
| Inventory completeness | Current AI component inventory covering models, datasets, software libraries and hosted AI services, with owner and version for each entry | A component in production or in a pipeline is missing from the inventory |
| Documentation review | Written internal risk controls for components, including procurement, security and privacy requirements, plus documentation templates completed for each third-party AI technology | Controls are described in policy but no component-level record shows they were applied |
| Sampling of components | For a selected sample of components, records of bias, privacy and security review of third-party data and models, with dates and reviewer names | A third party has no recorded review, or the review is dated after deployment |
| Walkthrough of a recent acquisition | Procurement file for one recent AI purchase or open-source adoption, traced from intake through security review, approval and inventory entry | Controls are documented but not followed, for example the purchase closed before the security review started |
| Third-party risk signals | Log of cases where a third party was slow to provide documentation or was assessed as a higher risk, and what the organization did in response | No record exists of how poor third-party transparency affected the risk rating |
| Software dependency evidence | Software bill of materials for deployed AI services, with the scan output and the date it was last reviewed | SBOMs are missing for internally hosted components or are out of date with the running version |
How to implement MAP 4.2 in six steps
This sequence moves from knowing every AI component to keeping its internal controls current, so that each third-party AI technology has an owner, mapped controls, documented gaps and a review cadence that the compliance lead can inspect.
Build a complete component inventory
Start by listing every AI component the system depends on, including models, datasets, training and inference software, APIs, hosted AI services and open-source libraries, whether built internally or bought. Engineering and platform teams usually do this, with input from procurement for anything paid for. Dependency and bill of materials tools such as Trivy can help list software components, but they will not find hosted AI services or data sources, so those need manual entries. The output is a component register with a unique identifier, supplier, version and deployment location for each item. You know the step is done when a reviewer can pick any production AI feature and trace every component it uses to a register entry.
Assign a named owner to each component
Give every register entry one accountable internal owner who can answer for its use, its contract terms and its risk decisions. Owners are normally drawn from the team that operates the component, with procurement or legal named as reviewers where contracts or licenses apply. Ownership is the link that lets MAP 4.2 controls survive staff changes. The output is the owner field completed for every component, along with a backup owner. Compliance leads should check for entries where the owner is a team mailbox or a departed employee, since those usually mean no one is actually accountable.
Map the internal controls applied to each component
For each component, record which internal controls apply and who performs them. The controls usually fall into four groups: procurement review, security testing, privacy review, and data and model bias review. The NIST AI RMF Playbook expects procurement, security and privacy controls to be applied to all acquired AI technologies, so a component with no control recorded is a finding. Security testing evidence may come from software composition analysis, vulnerability scanning or a vendor security assessment, and dependency tools such as OWASP Dependency-Track can track known vulnerabilities and license risk against CycloneDX or SPDX data. The output is a control matrix that links each component to its controls, the responsible person and the evidence location. You know it is complete when every register entry has a row for each control group, even if the answer is that it does not apply and the reason is written down.
Record third-party documentation and gaps
Request and file the documentation each third party provides, such as model cards, data sheets, security attestations, SBOMs, license terms and incident notification commitments. Compare what was received against what the control matrix needs and log each missing item as a gap with an owner and a request date. Where the Playbook's documentation templates or software safelists are used, record which template version or list was applied. The output is a documentation register showing, per component, what was received, what is outstanding and who is chasing it. Confirm with each vendor which documents they will provide under contract, since many will only release some materials under a non-disclosure agreement.
Set the rule for third parties that hamper mapping
Write a rule that treats a third party which refuses documentation, delays it repeatedly or limits access needed for bias, privacy or security review as a higher-risk component. The Playbook suggests treating this lack of cooperation as a sign of higher risk, so the rule should state what changes in practice: an elevated risk rating, a narrower approved use, extra internal testing, or a required decision by a named accountable executive before further use. Legal and procurement should agree the wording so it can be applied in contract negotiations. The output is an approved, dated rule in the AI governance policy set, with the risk rating applied to the affected entries in the register. Compliance leads can inspect whether any non-cooperating supplier has been rated and whether the rule was applied consistently.
Schedule recurring reviews tied to change events
Set a review cycle for each component and define the events that trigger an earlier review, such as a new model version, a change of supplier ownership, a change in the data the component processes, a new vulnerability or license finding, or a change in the intended use of the AI system. The review rechecks the owner, the control matrix, the documentation register and the risk rating. Confirm with each relevant team how often the review cycle should run, since the Playbook does not set a fixed interval. The output is a review calendar with trigger conditions and a log of completed reviews. You know the step is working when the log shows reviews that were prompted by real change events, not only by the calendar.
Evidence artifacts that satisfy MAP 4.2 and how to keep them current
MAP 4.2 asks for internal risk controls on AI components, including third-party technologies, to be identified and documented. The artifacts below are the records an assessor or internal reviewer would expect to see, and each one only stays useful if it is updated when the underlying component changes.
AI component inventory with owners
A single register of every AI component in scope: models, datasets, APIs, pre-trained weights, libraries and hosted services, each with a named owner, version, source and the system it supports. Without this list, no other artifact can be shown to cover the full set of components. Keep it current by requiring an inventory entry as part of onboarding a new component and by checking entries against deployed versions each quarter. Ask whether software bills of materials from tools such as Dependency-Track can feed the software portion so entries are not maintained by hand.
Control register per component
For each inventoried component, a record of the internal risk controls that apply to it, such as access restrictions, logging, bias review, privacy checks and vendor monitoring, with the control owner and the evidence location. This shows that controls were identified and documented for each component rather than only at the program level. Update the register whenever a control changes or a component is replaced, and confirm during each review that every control still points to working evidence.
Third-party due diligence records
Completed documentation templates, software safelist entries, and review notes on third-party data and models covering bias, privacy and security vulnerabilities. The Playbook suggests treating a third party that hampers risk mapping as a sign of higher risk, so the record should also note what information the vendor declined or could not provide. Tie refreshes to contract renewal and to vendor notices of model updates, since a review of an earlier version may no longer describe what is running.
Procurement and security review sign-offs
Signed approvals showing that procurement, security and privacy controls were applied to each acquired AI technology before use. Each sign-off should name the reviewer, the scope reviewed, the date and any conditions attached, such as data restrictions or required monitoring. Re-open the sign-off when the contract changes, when the vendor's data use terms change, or when the component is used for a new purpose, and record the outcome of each re-review.
Component change log
A dated history of when components were added, replaced, retired or re-reviewed, linked to the ticket that authorized each change. This proves the controls were kept current over time, which an assessor will test by sampling recent changes. Connect the log to model change tickets and deployment pipelines so a new model version cannot reach production without a matching entry. Ask your team to confirm that emergency changes are logged too.
What meeting MAP 4.2 costs in money and effort
The table compares the cost components of MAP 4.2, who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to scope a quote, since the AI RMF itself carries no certification fee and any price or duration must come from your own written quote or environment.
| Cost component | One-time or recurring | What drives it up | What keeps it down |
|---|---|---|---|
| Tooling and licenses | Recurring for commercial tools, one-time setup | Commercial SBOM or AI asset platforms priced per component or per seat, multiple tools for separate teams | Self-hosted open-source tools such as Dependency-Track and Trivy carry no license fee, though hosting and staff time still apply |
| Engineering time for inventory and control mapping | One-time initial build, recurring upkeep | Number of AI components, undocumented models and datasets, inconsistent naming across teams | Automated SBOM generation in CI pipelines and a single component register with agreed fields |
| Evidence upkeep | Recurring | Frequent model or dependency changes, many releases, control records kept in spreadsheets | Evidence captured as part of the release process, with documentation templates reused across components |
| External review or testing of third-party AI | Recurring, usually per engagement | Number of third parties, depth of bias, privacy and security review, limited vendor transparency or missing documentation | Standard vendor questionnaires, documentation templates, and requiring SBOMs or model cards in contracts |
| Assessor or internal audit time | Recurring, usually per review cycle | Scope of MAP 4.2 across the portfolio, gaps found in earlier reviews, unclear ownership of controls | Clear control owners, a repeatable evidence pack, and reviews scoped to the highest-risk components |
| Procurement and legal review of AI acquisitions | Recurring with each new acquisition | Frequent new vendor tools, negotiation of data and model terms case by case | Standard contract clauses for data use, model changes and disclosure, agreed before purchase |
Which self-hosted open-source tools produce MAP 4.2 evidence
MAP 4.2 asks for internal risk controls on AI system components, including third-party AI technologies, to be identified and documented. The three tools below produce inventory, vulnerability, license and framework-mapping records that support that documentation. None of them assesses AI model or dataset risk on its own, so the gaps must be closed with your own records.
Software inventory with Trivy
Trivy identifies the OS packages and software dependencies present in a target, such as a container image, filesystem or repository, and can output them as a software bill of materials. For MAP 4.2, that inventory is the starting record of which third-party software sits inside an AI system's runtime. It can also scan SBOMs supplied by vendors, which helps you check what a supplier delivered against what it claimed. Confirm whether your AI model artifacts, weight files and training data sets appear in the output, since a package scanner may not list them as components.
Component risk tracking with Dependency-Track
OWASP Dependency-Track consumes and produces CycloneDX SBOMs and VEX, flags components with known vulnerabilities, outdated or modified components, and license risk, and tracks license use by component using SPDX license IDs. This turns a one-time inventory into a continuing record of component risk, which is what MAP 4.2 documentation needs to stay current. Its license tracking is useful for reviewing third-party model and library terms. Note the license: Dependency-Track is Apache-2.0, so review your own use and redistribution terms before deploying it at scale.
Framework mapping with CISO Assistant
CISO Assistant ships more than 200 frameworks, including ISO 27001, NIST CSF, SOC 2, NIS2 and DORA, and runs audits and compliance assessments against them with automatic mapping between frameworks. For MAP 4.2, it is the place to record each internal control applied to a component and the procurement, security and privacy controls tied to it, so an assessor can trace a control from a framework requirement to its evidence. Its license is AGPL-3.0-only, which carries network-use obligations if you modify and host it for others. Ask your legal team to confirm those obligations before adoption.
What your team, a partner and the auditor each do for MAP 4.2
Your organization owns the AI system, its components and every internal risk control that covers them. No partner or auditor can take over these decisions. Your team decides which third-party models, datasets and software are acceptable, what risk tolerance applies to each, and which controls must be in place before a component is used. The MAP 4.2 outcome is that these controls are identified and documented, so the people accountable for them must be named and must sign off on them.
- Component inventory ownership: Keep the authoritative list of AI components, including third-party models, data sources and software, and assign an accountable owner for each entry.
- Control decisions: Decide which procurement, security and privacy controls apply to each acquired AI technology, and record the rationale for any exception.
- Third-party relationships: Own the contracts, data processing terms, security questionnaires and escalation paths with each vendor, including vendors that are slow to share documentation.
- Review cadence: Set how often the control register and component list are reviewed, and trigger a review when a model, dataset or dependency changes.
- Sign-off: Document who approved each control and each residual risk.
Before relying on any of this, confirm that each control has a named owner, a stated purpose and a recorded review date.
An implementation partner such as DeployOpen can help your team build the systems and records that show MAP 4.2 controls exist and work. The partner prepares the tooling, templates and evidence, and works inside your environment. It does not decide which risks you accept and it does not issue any report or attestation about your controls. Partner work is usually fixed-scope, with the scope, deliverables and timeline agreed in writing before work starts.
- Inventory tooling: Set up software bill of materials generation and scanning, for example with tools such as Trivy or OWASP Dependency-Track, so component records stay current.
- Control register: Build a register that links each component to its internal controls, owners and evidence locations.
- Documentation templates: Provide templates for vendor assessments, data and model review records, and safelist entries.
- Evidence packs: Assemble the logs, scan results, approvals and review records that an assessor will ask to see.
- Testing support: Help test third-party AI for bias, privacy and security weaknesses, where your contracts and the vendor allow it.
The auditor's independence means the partner must not review or test the same controls it helped build when those results support an attestation. Ask for the partner's written scope to show which work is preparation and which work, if any, is independent testing.
An independent auditor, assessor or certification body tests whether the controls for MAP 4.2 are designed appropriately and operate as described. Only that party issues a report, attestation or certificate. The AI RMF itself has no certification, so any assessment of MAP 4.2 will depend on the framework or contract that asked for it, and the scope of that assessment should be agreed with the assessor in advance.
- Design testing: Check that the component inventory, control register and vendor assessment process cover the intended scope.
- Operating effectiveness testing: Sample components and vendors, then check that the documented controls were applied and that the evidence exists and is dated.
- Independence: The assessor cannot design or operate the controls it tests, and it reviews the partner's preparation only as an input, not as proof.
- Reporting: Issue findings and any report in its own name, based on criteria the client and assessor agreed on.
- Scope questions: Confirm with the assessor which frameworks, sample sizes and evidence periods it will use.
Before engaging an assessor, confirm its qualifications and whether it has accepted this type of AI assessment.
Where organizations fall short on MAP 4.2 and how to close each gap
MAP 4.2 asks organizations to identify and document internal risk controls for AI system components, including third-party AI technologies. The gaps below share one root cause: AI components enter the organization faster than the inventory, ownership and review processes that should track them. Each card names a gap and one action to close it.
AI components hidden in SaaS and developer tools
Many AI components arrive as a feature inside an existing SaaS product, a browser extension, a code assistant or an open-source library pulled in by a developer, so they never pass through procurement. Start by asking engineering, business units and security teams to list every tool with generative or predictive features, then reconcile that list against your AI inventory. Confirm which components send data to external models and which store prompts or outputs.
Third-party AI with no documented review
A vendor model or API may be in production with no record of who assessed its training data sources, intended use limits or security posture. Create a short review record for each third-party AI technology that captures its purpose, data flows, known limitations and the date of review. Without this record, you cannot show that the component was mapped at all.
Policy controls not applied to acquisitions
Procurement policies may require security questionnaires, privacy terms and data processing agreements, yet AI purchases often bypass them because they are priced as usage fees or trials. Add a rule that any AI technology, including free tiers and pilots, passes the same security, privacy and contract checks as other acquired software. Check a sample of recent AI contracts against the policy to find where the rule was skipped.
Bias and privacy reviews never repeated
A review completed at purchase can stop reflecting the component once the vendor changes the model, retrains on new data or alters its default settings. Set triggers for re-review, such as a vendor version change, a new data category or a change in the population the output affects, and record each re-review with its findings. Confirm with vendors how they notify customers of material model updates.
Components with no named owner
An AI component without an accountable owner cannot be reviewed, patched, retired or questioned by anyone. Assign one named person or team to each component in the inventory, with responsibility for its documentation, its review dates and its decommissioning plan. Record the owner in the same register that lists the component so that ownership is checked whenever the register is.
Vendors without documentation or escalation
Some vendors will not share model cards, data handling terms, security attestations or vulnerability notices, and the contract gives you no route to demand them. Before signing, request the documentation you need and write into the contract how and by when the vendor must respond to requests and notify you of incidents. Treat a vendor that refuses to supply documentation as a higher-risk component and record that decision.
Questions buyers ask about MAP 4.2 cost, effort and outside help
Does MAP 4.2 require a certification?
No. MAP 4.2 is a subcategory of the NIST AI RMF, and the AI RMF is a voluntary framework with no certification, accreditation or conformity assessment program. NIST does not validate or endorse any individual organization or its approach to using the framework. What an organization can show is its own documented internal risk controls for AI components, tested by its own teams, by a customer's assessors or by an independent third party if a contract asks for one. Ask any firm that offers an AI RMF "certificate" to explain what body issues it and what standard it tests against.
How long does it take to implement MAP 4.2?
No supplied source gives a duration for MAP 4.2, so no fixed timeline is safe to promise. The main drivers are the number of AI components in use (models, datasets, software libraries and hosted AI services), how many of them are already inventoried, how many third parties supply them, and whether the organization builds or buys most of its AI. Organizations with an AI inventory and existing vendor onboarding usually have less to document than those starting from scratch. Ask for a schedule tied to a written scope with named components and deliverables.
What does MAP 4.2 need from our staff?
MAP 4.2 needs time from people who know each component and the controls around it. In practice that means AI deployment owners, the teams that run testing and evaluation (TEVV), operations and monitoring staff, and the people who manage third-party contracts and procurement. Security and privacy staff review how components are protected and what personal data they touch. Expect the heaviest load in the first pass, when each component is identified and its existing controls are written down, and a lighter recurring load when new components are added or vendors change their terms.
Can our own team do MAP 4.2 in-house?
Often yes, if the team has the right people and enough time. The NIST AI RMF Playbook suggests actions for MAP 4.2 such as documentation templates, software safelists, and reviews of third-party data and models for bias, privacy and security weaknesses. These are ordinary procurement, security and privacy tasks that many organizations already run for other software. The gaps usually appear where AI components are not in the existing asset register, or where no one owns the review of a model supplied by a vendor. An outside team can help close those gaps, but the organization still owns its risk decisions.
What does a partner handle, and what stays internal?
DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, and it prepares systems and evidence for assessments. For MAP 4.2, that can include setting up component inventories, software bills of materials, and documentation records that feed the controls. The organization keeps ownership of its controls, its risk tolerance, its vendor decisions and any sign-off on whether a third-party AI product is acceptable. DeployOpen does not issue reports, attestations or certificates, which only independent auditors or certification bodies do.
What should a quote for MAP 4.2 work include?
A quote should follow from a written scope that names the AI components in play, the third parties behind them, and the systems where evidence will be stored. Ask the provider to state the deliverables (for example, an inventory of components, a documented control set per component and the evidence each control produces), who does each task, what the client must supply, and what is one-time versus recurring. Ask whether third-party software scanning, such as dependency analysis, is included and what happens if the scope grows. DeployOpen does not publish a price list; a quote follows from the written scope.
How does MAP 4.2 relate to MAP 4.1?
MAP 4.1 covers mapping the technology and legal risks of AI components, including third-party data, software and intellectual property infringement risks, and checking that those approaches are in place, followed and documented. MAP 4.2 builds on that work by identifying and documenting the internal risk controls that apply to the same components, including third-party AI technologies, and applying procurement, security and privacy controls to them. In practice, one component inventory can serve both subcategories: MAP 4.1 records what the risks are, and MAP 4.2 records what the organization does about them.
How DeployOpen scopes and prepares MAP 4.2 evidence
DeployOpen works on MAP 4.2 as an implementation partner: we help you identify and document the internal risk controls that cover each AI system component, including third-party AI technologies. Your organization owns the controls and the risk decisions, and only an independent assessor issues any report.
How we scope
- We agree a written, fixed scope listing the AI system components, third-party models, data and software to be covered by MAP 4.2.
- We inventory which procurement, security and privacy controls already apply to each acquired AI technology, and record the gaps.
- We confirm with your team which AI actor categories own each control, such as deployment, testing and operations, and third-party entities.
How we build
- We set up a component register and documentation templates that record each component's internal risk controls and their owners.
- We configure software bill of materials collection and component scanning, using tools such as Trivy and OWASP Dependency-Track where they fit your environment.
- We prepare checks for third-party data and models covering bias, privacy and security review, and document the results for your assessors.
How we hand over
- We deliver the component register, control documentation, scan outputs and review records in formats your audit and risk teams can use.
- We walk your owners through each record so they know what to maintain, review and update as components change.
- We confirm with your assessor or auditor which evidence they expect, since independent bodies decide what satisfies their testing.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, which keeps the component register current as models and vendors change.
- We can re-run component scans and update control records when a third-party AI technology is added, replaced or retired.
- Ask us to confirm in the written scope which systems, teams and review cycles a retainer would cover before work starts.
