How does a financial institution apply the NIST AI RMF through the FS AI RMF?
A bank, insurer, investment firm or vendor asked how it governs AI needs a structure it can self-assess against and show as evidence. The Financial Services AI Risk Management Framework (FS AI RMF), released with the U.S. Treasury on February 19, 2026 and launched by the Cyber Risk Institute on February 12, 2026, adapts the NIST AI RMF to financial services through 230 control objectives. It is a free download after registration. The NIST AI RMF itself has no certification, so the FS AI RMF gives the institution a way to map its AI activities to control objectives, decide which apply and collect evidence for each. The institution owns its controls and decides how it is governed. An independent auditor or examiner, not the framework or its authors, issues any opinion on whether those controls work.
Three factors determine what the answer looks like for each firm. The first is adoption stage. The FS AI RMF includes an *AI Adoption Stage Questionnaire* that places the organization at a stage and maps that stage to the control objectives that apply, so a firm that only uses AI in limited ways will work through a different set than one that builds models or deploys them in customer decisions. The second is size and complexity, which affects how much governance, documentation and monitoring the Risk and Control Matrix requires in practice. The third is reliance on third parties. The framework extends to third-party providers, so a firm that buys AI from a core processor or model provider must determine which evidence it can obtain from that vendor and which it must produce itself.
Before starting, confirm three things with your own risk, compliance and legal teams: the adoption stage that fits your current and planned AI use, which control objectives your examiners or auditors expect you to address, and which third-party AI services need contractual evidence rights. Review the executive summary and the quick start guide for the initial adoption stage, then read the NIST AI RMF use cases page, which lists the FS AI RMF among documented implementations. Confirm with your regulators how they will treat the framework, since its adoption is voluntary and the framework does not replace existing enterprise policies.
How the AI Adoption Stage Questionnaire sets your control scope
The questionnaire comes first and decides which control objectives apply to your institution, so the Risk and Control Matrix work that follows is scoped to how you actually use AI. Each step below produces an artifact that the next step depends on.
Inventory your AI use cases and third-party AI
Before answering the questionnaire, list every AI system in use or planned, including models embedded in vendor products and AI services your third parties run on your behalf. Assign an owner to each entry and note whether it is built in-house, bought or configured. The output is a working inventory that the adoption stage questionnaire can be answered against. You know this step is done when every business line has signed off that its AI use is listed, even where the list is incomplete for now.
Complete the AI Adoption Stage Questionnaire
Work through the AI Adoption Stage Questionnaire against the inventory, answering for the institution as a whole and noting exceptions for specific business lines. Involve risk, compliance, information security and the business owners of the AI use cases, since the answers describe how AI is used rather than how it is governed. The output is a recorded adoption stage. Confirm the stage definitions and the questionnaire wording in the framework download before answering, because the stage labels and criteria are set by the publisher, not by this guide.
Confirm the adoption stage with accountable owners
Have the accountable executive or AI governance body review the recorded stage and sign off on it. Check that the answer matches what the inventory shows, especially where a team has started a pilot that moves the institution toward a later stage. The output is a documented, approved adoption stage with the date and approvers recorded. You know this step is done when the stage is in the governance record and any disagreement between business and risk teams has been resolved in writing.
Map the stage to control objectives
Use the adoption stage to select the control objectives that apply. The framework organizes its 230 control objectives by adoption stage, so the stage result determines the subset your program must address. Record which objectives are in scope, which are out of scope for this stage and why. The output is a scoped list of control objectives tied to the stage. You know this step is done when every in-scope objective has a named owner in your records and each exclusion has a documented rationale.
Start with the quick start guide for initial adoption
If the questionnaire places you at the initial adoption stage, the quick start guide included with the download is the intended starting point. Use it to set up the first governance artifacts, such as the executive summary for leadership and the initial control set. Smaller institutions and first-time adopters should begin here before working through the full matrix. The output is a short plan of initial actions tied to the scoped objectives. Confirm with the publisher whether the quick start guide covers stages beyond the initial one before relying on it for later stages.
Work the Risk and Control Matrix for scoped objectives
Using the scoped list, work through the Risk and Control Matrix, which pairs risk statements with the control objectives. For each in-scope objective, record the existing control, the gap, the control owner and the evidence that would show the control operates. Where a third party provides a capability, note the dependency. The output is a populated matrix with a gap register. You know this step is done when every in-scope objective has either a documented control or a gap entry with an owner and a remediation decision.
Check evidence against the control reference guide
Compare the evidence you plan to show with the Control Objective Reference Guide, which gives illustrative controls and examples of effective evidence. Treat these as examples to test your own design, not as a required checklist. Ask whether an independent reviewer could trace each control to a record. The output is a list of evidence items per control, reviewed by internal audit or an equivalent second line. You know this step is done when each in-scope control has at least one named evidence source.
What is in the four FS AI RMF components
The AI Adoption Stage Questionnaire is the entry point. It asks the organization how it uses AI today and identifies the adoption stage that applies. That stage determines which control objectives in the Risk and Control Matrix are in scope, so the questionnaire sets the boundary for everything that follows. Compliance leads use it to document the starting position and to explain to executives why certain objectives apply now and others do not. Model risk teams use the answers to confirm that every model in production, and every model under development, is captured at the right stage. Internal auditors treat the completed questionnaire as the scoping record and test whether it matches the AI inventory.
- Stage identification: the questionnaire maps the organization to an adoption stage, which then links to a set of control objectives.
- Scope evidence: the completed answers become the record that shows why the in-scope objectives were selected.
- Inventory alignment: auditors compare stated AI use against the AI inventory and the list of third-party AI services.
- Re-scoping triggers: a move to a more advanced adoption stage changes the objectives in scope, so the questionnaire needs revisiting when AI use expands.
- Business unit input: answers from lines of business often differ from the central technology view, so both should be gathered.
Before relying on the questionnaire, confirm with the Cyber Risk Institute which stage definitions and mapping logic apply to your institution's size and AI use.
The Risk and Control Matrix is the core working document. It lists risk statements and the 230 control objectives, organized by adoption stage, so an institution can see which objectives apply at its stage and what each one addresses. Compliance leads use the matrix as the master tracker for ownership, status and gaps. Model risk teams use it to connect model-level risks to specific objectives and to identify which controls their validation work must cover. Internal auditors use it as the test plan, selecting objectives and checking the evidence each one points to.
- Stage-filtered view: the 230 control objectives are arranged by adoption stage, so the working set is smaller than the full list.
- Risk statements: each entry frames the risk the objective is meant to control, which helps teams explain purpose to non-specialists.
- Ownership columns: assign a named owner per objective, since the matrix does not assign responsibility for you.
- Gap tracking: record which objectives are met, partially met or not yet addressed, with dates and remediation owners.
- Traceability: link each objective to policy sections, model documentation and monitoring reports.
Confirm the matrix version and download it from the Cyber Risk Institute source, because objective wording and numbering may change between releases.
The guidebook explains how to read and apply the framework. It describes the purpose of the components, how they fit together, and how an institution can work through adoption and documentation. It is the document that teams return to when an objective is ambiguous or when they need to explain the approach to a board or a regulator. It does not replace the matrix or the reference guide. Compliance leads use it to plan the program and brief stakeholders. Model risk teams use it to align validation vocabulary with the framework's terms. Internal auditors use it to understand the intent behind objectives before judging whether an institution's approach meets that intent.
- Program design: the guidebook explains how to sequence adoption work across teams.
- Shared vocabulary: it helps compliance, technology and risk teams use consistent terms for AI risk.
- Interpretation support: it clarifies intent where an objective could be read more than one way.
- Governance context: it shows how the framework complements existing enterprise policies rather than substituting for them.
- Briefing material: teams can cite it when presenting the program to senior management.
Read the guidebook alongside the matrix version you use, and record in your own documentation which interpretation you adopted for any objective that needs one.
The Control Objective Reference Guide adds practical depth to the matrix. For each objective it provides illustrative controls and examples of effective evidence. These examples show what an assessor might expect to see, but they are not mandatory designs. Compliance leads use the guide to decide how to meet an objective in their own environment and to plan the evidence collection. Model risk teams use the illustrative controls to test whether their validation and monitoring work is sufficient. Internal auditors use the effective evidence descriptions to design test procedures and to judge whether evidence presented is credible.
- Illustrative controls: examples of how an objective could be satisfied, adaptable to different institutions.
- Evidence examples: descriptions of records that show an objective is operating, such as approvals, test results and monitoring reports.
- Test design support: auditors can translate evidence descriptions into walkthroughs and sample selections.
- Evidence gaps: comparing the guide's examples with existing records reveals where documentation is missing.
- Tailoring: institutions must still justify their own controls when they differ from the examples.
Treat the examples as a starting point, and confirm with your examiner or auditor how they expect evidence to be presented for your institution.
How the FS AI RMF maps to the NIST AI RMF Govern, Map, Measure and Manage functions
The Cyber Risk Institute describes the FS AI RMF as closely aligned with the NIST AI RMF, and NIST lists it among documented AI RMF implementations. The cards below show what a financial institution typically builds under each function, so teams can plan work before they open the control objectives. Treat every category-level link as something to confirm in the framework's own tables.
Govern: set the rules first
Govern is the cross-cutting function that sets the policies, accountability and risk culture the other three functions depend on. In a bank, insurer or investment firm this usually means an AI policy that fits existing enterprise risk and model risk frameworks, a named owner for AI risk decisions, and a maintained inventory of AI use. Check that the FS AI RMF's adoption stage questionnaire places your institution correctly before you assign owners, because the control objectives that apply depend on that stage. Confirm the Govern category links in the framework's tables before you assume them.
Map: define each AI use case
Map establishes context for each AI system: its intended purpose, the people it affects, its benefits and costs of error, and the third-party models, data and software it depends on. For financial institutions, this is where a credit, fraud or claims model is written down with its decision scope, human review points and vendor components. Mapping vendor components is often the hardest step, so ask each third party for the model and data documentation it can provide. Use the NIST Playbook and the framework's risk statements to test whether each map is complete.
Measure: test and monitor performance
Measure covers the evaluation of each AI system against trustworthiness characteristics, including validity, fairness, explainability and privacy, and tracks risks after deployment. Examiners and internal audit typically ask for test records, validation results, drift monitoring and documented metric choices tied to the risks identified during mapping. Ask whether your validation team can reproduce results and whether monitoring thresholds are approved and reviewed. Keep in mind that the control objectives set the evidence expected, so compare your test plan against them rather than against generic practice.
Manage: decide, respond and recover
Manage turns mapping and measurement results into decisions: go or no-go determinations, risk treatment, residual risk acceptance, and responses when a system fails or a third-party model changes. In financial services, this includes documented escalation paths, the ability to deactivate a model, and communication of incidents to relevant stakeholders. Confirm how your incident process from existing operational resilience work covers AI failures, and how contract terms with AI vendors support intervention. Verify the Manage category mapping against the framework's tables before reporting it as covered.
How to get the FS AI RMF and what the download includes
The FS AI RMF is available as a free download after registration from the Cyber Risk Institute, which launched the framework on February 12, 2026. Registration is the only gate mentioned in the published materials, so the practical first step is to register with the work email that your AI governance, risk and compliance leads will use, then confirm that the downloads are accessible to every team that will contribute to the adoption stage decision. Keep the source of the file in your evidence records, since an assessor or examiner will later ask which version your program was built against.
The download bundle includes an *executive summary* for senior leaders and a *quick start guide* for the initial adoption stage, alongside the full framework components. Start with the quick start guide if your institution is new to AI risk management, because it shows how the AI Adoption Stage Questionnaire leads to a set of control objectives. Use the executive summary to brief the board or the risk committee on scope before the detailed Risk and Control Matrix is opened. Confirm the exact file names, version numbers and release dates on the Cyber Risk Institute page before you plan work or quote an engagement, because the bundle may be updated after this page is published.
Before you schedule any gap assessment, confirm three things on the CRI page: which files are currently posted, whether the components listed in the download match the framework description, and whether any companion material, such as the AI Lexicon published by Treasury, is included or linked separately. The Treasury press release on the two new resources is the natural companion read for the lexicon and the framework's origin. Record the version you used in your scoping document so that later changes to the files can be traced to your decisions.
Which institutions and vendors does the FS AI RMF apply to
CRI intends the FS AI RMF for all financial institutions and their third-party providers, so scope is less about whether a firm qualifies and more about which adoption stage and control objectives fit its AI use. Each card below names the scope question that usually decides where to start, and the supervisory check that sits outside the framework.
Community banks and credit unions
Smaller institutions often buy AI through core banking, fraud, or lending platforms rather than building models. The usual scope question is which AI features arrive inside vendor products and whether the institution can document them at its adoption stage. Start with the AI Adoption Stage Questionnaire to see which control objectives apply. Confirm with the institution's own regulator how supervisory expectations treat purchased AI at this size.
Banks
Larger banks typically run AI across credit decisions, fraud detection, customer service and internal productivity tools, often at several adoption stages at once. The scope question is whether each use case is mapped to its own stage and whether control objectives are tracked per system. Confirm with the bank's prudential regulator which AI uses fall under existing model risk or third-party expectations.
Insurers
Insurers use AI in underwriting, claims triage and pricing support, where outputs can affect policyholders directly. The scope question is which models influence coverage or claim decisions and how their risks are documented against the Risk and Control Matrix. Confirm with the state insurance regulator or other supervisor how AI in underwriting and claims is reviewed.
Investment firms
Investment firms use AI in research, portfolio analytics, trading support and client communications. The scope question is which tools inform investment decisions and which generate client-facing content, since each raises different evidence needs. Confirm with the relevant securities regulator how recordkeeping and supervision duties apply to AI-assisted advice and research.
Third-party providers serving institutions
CRI extends the framework to third-party providers, so vendors that supply AI models, data or software to financial institutions face questions their customers will ask. The key scope question is how much of the vendor's AI depends on third-party models and how those dependencies are evidenced. Confirm with each customer which control objectives they expect the vendor to support, since institutions set their own contract terms.
Who owns the controls, who prepares evidence and who issues the opinion
The institution owns the AI controls, the risk appetite and every decision about whether an AI system is adopted, restricted or retired. The FS AI RMF is a framework the institution adopts, so the control objectives it selects, the adoption stage it declares and the residual risks it accepts all sit with the board and senior management. An implementation partner can help build these artifacts, but it cannot accept risk on the institution's behalf.
- Adoption stage and scope: The institution decides which AI systems fall in scope and records the adoption stage it identifies through the questionnaire.
- Risk appetite and tolerances: Board-approved limits for AI risk, with named owners for each system.
- Accountable executives: Named individuals who sign off go or no-go decisions, exceptions and residual risk acceptance.
- Policies and third-party oversight: Internal AI policies, vendor due diligence and ongoing monitoring of AI supplied by third parties.
- Sign-off records: Dated approvals and committee minutes that show the decisions were made by the right people.
Before engaging anyone, confirm which executive owns each control objective and whether that owner has the authority and time to maintain it.
An implementation partner such as DeployOpen prepares the technical and documentary material the institution needs to show how its controls work. Under a fixed-scope engagement, the partner works on systems the institution owns and runs, typically inside the institution's own cloud accounts, data centers or private networks. The partner's output is preparation, not opinion: it does not decide whether a control is effective.
- Systems and logging: Configuration of self-hosted platforms, access controls, audit logging and monitoring that generate records of AI system behavior.
- Documentation: Drafts of system descriptions, model inventories, risk and control mapping and runbooks, for the institution to review and approve.
- Evidence packs: Organized, dated artifacts keyed to control objectives, so the institution and its assessors can trace each claim to a record.
- Testing support: Security testing of applications, APIs and AI systems that feeds measurement and remediation records.
- Scope and deliverables in writing: Scope, deliverables and timelines are agreed before work starts, and the partner's responsibilities end at the agreed deliverables.
DeployOpen does not issue reports, attestations or certifications, and no outcome of an examination or assessment is guaranteed by its work. Ask any partner to confirm this in writing.
The independent party is the examiner, external auditor or assessor who tests the institution's controls and issues any report or opinion. Depending on the institution, this might be a bank examiner, an external audit firm or another qualified assessor selected by the institution. Its independence is what gives its conclusions weight, so it should not design the controls it later tests.
- Testing approach: The assessor selects samples, inspects records, interviews owners and checks whether evidence matches what the institution claims.
- Reports and opinions: Only the independent party issues a formal report, opinion or finding.
- Independence: The assessor should not be the team that built the systems or wrote the evidence packs being tested.
- Scope agreed up front: The assessor and institution agree on the control objectives, period and sample methods before testing starts.
- Findings and remediation: Exceptions go back to the institution, which owns the corrective action and its timing.
Before engaging an assessor, confirm its qualifications, its engagement terms and whether the institution's supervisor expects a particular form of report.
How a FS AI RMF readiness project moves from scoping to evidence
This sequence turns the FS AI RMF from a framework download into a scoped set of systems, controls and evidence that an independent assessor can test. Each phase closes with a named output, so the organization can decide what to do next before committing to the rest of the work.
Confirm adoption stage and scope
The organization completes the AI Adoption Stage Questionnaire, which identifies its adoption stage and points to the control objectives that apply at that stage. Its risk, compliance and technology owners agree which business units, AI systems and third parties sit inside the scope, and which are excluded and why. The output is a written scope statement and a stage determination signed off by an accountable executive. The step is done when every in-scope system has a named owner.
Register and download the framework
A team member registers with the Cyber Risk Institute to download the FS AI RMF, including its executive summary, quick start guide, guidebook, Risk and Control Matrix and Control Objective Reference Guide. The team reads the guidebook before working through the matrix, so that the terms and component relationships are understood. The output is a versioned copy of the framework kept in the organization's document control system, with the download date recorded. Confirm current access terms directly with CRI at registration.
Gap the Risk and Control Matrix against the AI inventory
The implementation partner and the organization compare the control objectives for the agreed adoption stage against the current AI inventory, existing AI policies, model documentation and vendor contracts. Each objective is marked as met with evidence, partly met, not met or not applicable, with a reason for every non-applicable entry. The output is a gap register that lists each open objective, its owner and the evidence that would close it. The step is done when the register has been reviewed by the accountable executive.
Agree a fixed-scope work plan
Using the gap register, the partner and the organization write a work plan that lists the remediation tasks, deliverables, responsibilities and review points for the agreed scope. Items the organization will perform itself are separated from items the partner will prepare. The plan states what is excluded, including any attestation or assessment work performed by an independent assessor. The output is a signed statement of work. Timelines depend on the agreed scope and are set only in that document.
Prepare systems and evidence
The team updates AI policies, documents accountability and approval paths, sets up monitoring and logging for in-scope models, and records third-party due diligence. Where the platform is self-hosted, the partner configures access controls, logs, change records and test results inside the organization's own infrastructure. Each control objective is linked to the artifact that shows it operating, such as a dated approval, a test report or a monitoring alert. The output is an evidence index that maps each objective to its artifacts and their locations.
Review evidence internally
An internal reviewer who did not prepare the evidence checks each artifact against its control objective, confirms that dates and approvals are authentic, and records any gaps that remain. Owners resolve or formally accept residual risk with a documented rationale. The output is a review log with a disposition for every item, and a list of accepted risks signed by the accountable executive. The step is done when no objective in scope lacks an assigned status.
Hand over the evidence pack to the independent assessor
The organization delivers an evidence pack to its independent assessor, containing the scope statement, stage determination, gap register, evidence index, review log and system documentation. The assessor decides what testing it will perform and issues whatever report or opinion its engagement covers. DeployOpen prepares systems, controls and evidence but does not issue audit reports, attestations or certifications. The output is an accepted evidence pack and a written list of assessor questions for the organization to answer.
Where financial institutions get stuck with the FS AI RMF
The most common delay is treating the 230 control objectives as a checklist to clear in sequence. NIST says its AI RMF is not a checklist or an ordered set of steps, and the FS AI RMF is built on it. The practical effect is that teams start with the Risk and Control Matrix, work through every objective for their adoption stage, and only then ask which objectives their systems actually touch. A better first step is to run the AI Adoption Stage Questionnaire, confirm which objectives apply to each system, and document why any objective is out of scope. Confirm the adoption stage logic and any scoping rules in the guidebook before you commit staff time.
Ownership is the second frequent stall. Model risk management and information security each hold part of the evidence for an AI system, and when neither function is named as accountable for a given objective, gaps stay open for months. Decide in writing which team owns each control objective, who signs off on the go or no-go decision, and how model validation records feed the security evidence set. Illustrative example: a credit model may have validation files in one team and access logs in another, and the assessor will ask for both under one objective.
Third-party AI is where inventories most often fall short. Many institutions track their own models but not the AI features inside vendor platforms, embedded scoring tools or pre-trained models their vendors use. The FS AI RMF extends to third-party providers, so an incomplete inventory undermines the whole adoption stage. Build the inventory from procurement records, contract reviews and vendor questionnaires, and ask each vendor which models and data sources it relies on. Evidence gathered after the fact is the last trap: logs, approvals and test results need to be captured as the system runs, not rebuilt for the assessment. Confirm retention periods for these records with your own legal and records teams.
Questions buyers ask about the FS AI RMF
Is the FS AI RMF mandatory for financial institutions?
No, not on the basis of the material supplied for this page. The FS AI RMF is a framework that Treasury released alongside its AI Lexicon, and the Cyber Risk Institute describes it as intended for all financial institutions and their third-party providers. It complements existing frameworks rather than replacing enterprise policies. Whether a particular regulator, examiner or contract expects its use is a separate question. Confirm with your primary prudential regulator, your examiners and any customer contracts that cite it, and get the answer in writing. The NIST AI RMF it adapts is itself voluntary, so organizations should not assume a mandate exists until a regulator or contract names one.
Is there a certificate for the FS AI RMF?
No certificate or accreditation program for the FS AI RMF appears in the material supplied for this page. The framework is a free download after registration, and it is organized around control objectives, a risk and control matrix and a guidebook. Independent auditors or assessors can test your controls against it if your customers or examiners ask for that, but the report they issue belongs to them, not to the framework or to any implementation partner. Ask any firm offering a "certified" FS AI RMF badge to name the issuing body and the scheme's rules before you rely on it.
How much effort does FS AI RMF adoption take, and what drives it?
Effort depends mainly on your adoption stage, the number of AI systems in scope and how much of your current governance can be reused. The FS AI RMF starts with an AI Adoption Stage Questionnaire that identifies your stage and maps it to control objectives, so an organization that only uses third-party AI tools will face a different set of objectives than one that builds models. The framework contains 230 control objectives, so scoping the stage and the systems is the first cost driver. Other drivers include the state of your AI inventory, existing model risk and third-party risk processes, and the evidence you must produce. Costs are mostly staff time, which is one-time for the initial mapping and recurring for evidence collection, reviews and monitoring. Ask any quote to break down internal effort, outside help and tooling, and to state which objectives it covers.
Can our team apply the FS AI RMF without outside help?
Yes, many institutions can do much of the work internally, because the framework is free and its components are published. Internal teams usually own the decisions: which stage applies, which objectives are in scope, which risks are accepted and who signs off. The areas where outside help is most often requested are gap assessments against the Risk and Control Matrix, configuring technical evidence on self-hosted platforms, and preparing documentation for an independent review. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or attestations. Those come from independent auditors or assessors. Your organization still owns its controls. If you hire help, define the scope in writing before work starts.
What should we ask a consultant before signing?
Start with the written scope. A reputable provider should state which adoption stage and control objectives are covered, which deliverables you will receive, what the timeline depends on and what you must supply. Ask who performs each task and who is accountable for the output. Confirm that the firm will not issue audit reports, attestations or certifications, and that any independent review will be done by a separate assessor you choose. Ask how they will handle evidence from your environment, where it is stored and who can access it. Request a fee structure that separates one-time setup from recurring support, and ask what triggers a change order. For a fixed-scope engagement, the scope document is the contract's core, so review it with your legal and risk teams before signature.
How does the FS AI RMF relate to ISO/IEC 42001?
The FS AI RMF and ISO/IEC 42001 address overlapping AI governance concerns but serve different purposes. The FS AI RMF is built on the NIST AI RMF, which CRI describes as closely aligned, and it is tailored to financial services through control objectives and adoption stages. ISO/IEC 42001 is an AI management system standard that can be certified by an accredited certification body. Because the two are different kinds of instrument, a single program can often reuse the same governance records, inventories and risk registers for both. Any specific mapping between control objectives and ISO/IEC 42001 clauses should be verified line by line with your assessor, since no mapping was supplied for this page. Confirm with your examiners whether they accept evidence prepared against one framework for the other.
How DeployOpen prepares financial institutions' systems and evidence
DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, and prepares systems and evidence that support an institution's work against the FS AI RMF. The organization owns its controls and adoption stage decisions, and only an independent auditor or assessor issues any report or certificate.
How we scope
- We agree a written scope that names the AI systems, business units and adoption stage the work covers.
- The scope lists which FS AI RMF control objectives are in play and which sit with the institution or its third parties.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We configure self-hosted platforms in your cloud accounts, data centers or air-gapped networks to produce the logs and records controls need.
- We test AI systems and their supporting infrastructure, documenting findings against the relevant control objectives.
- We align each evidence source to the Risk and Control Matrix so reviewers can trace a control to its proof.
How we hand over
- We deliver documentation, configuration records and evidence packages mapped to the agreed control objectives.
- We walk your risk, compliance and technology teams through what each artifact shows and where gaps remain.
- We hand over ownership of runbooks and records so your staff can maintain evidence after the engagement ends.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer tied to the same written scope.
- Retainers can cover evidence refreshes when the FS AI RMF, your adoption stage or your AI systems change.
- Ask your auditor or assessor to confirm which evidence they accept before we finalize any evidence package.
