GOVERN 1.1 Legal and regulatory requirements: evidence guide

What GOVERN 1.1 legal and regulatory requirements asks your AI program to prove

GOVERN 1.1 asks your AI program to show that the legal and regulatory requirements involving AI are understood, managed and documented. When a customer, regulator or board asks how AI is covered by law, this outcome is the answer you should be able to produce on request. The NIST AI Risk Management Framework is voluntary guidance, and there is no AI RMF certification, so no one will issue a badge for meeting GOVERN 1.1. An assessor or customer will judge whether your register of applicable laws is current, whether it matches the systems you actually run, and whether the other GOVERN 1 policies trace back to it. The work is hard because the requirements differ by sector, by use case and by jurisdiction, and they change while you are still building the register.

The NIST AI RMF Playbook suggests a few concrete habits. Track the legal and regulatory requirements specific to your industry, sector, business purpose and deployment context. Align your AI risk management with those standards rather than treating them as a separate exercise. Keep training policies so staff who design, build and deploy AI understand the legal considerations that affect their work. The Playbook also notes that some rules, such as nondiscrimination and data privacy requirements, can mandate documentation, disclosure and greater transparency, and that bias testing methods such as disparate impact analysis are not applied the same way in every legal context. Decide who owns the register, how often it is reviewed, and which AI systems it is linked to, and write those decisions down before an assessor asks.

Confirm the current status of the framework itself before you cite it. NIST says AI RMF 1.0 is being revised under the White House AI Action Plan and has not yet published a revised version, so ask your legal and compliance leads which version your policies reference and whether any state law you are subject to names a specific version. Read the NIST AI 100-1 document and the Playbook directly, and check their dates against your own review calendar. Your evidence will be the register, the mapping from each requirement to the affected systems and policies, the training records and the review history, which your team owns and maintains. Any outside help can prepare that evidence, but the legal judgment and the statements you make to regulators remain with your organization and its counsel.

Which AI systems, data, teams and vendors fall under GOVERN 1.1

Before an organization can understand and document its legal obligations, it has to decide what the legal review covers. The cards below set out the scoping decisions that change the work for GOVERN 1.1 Legal and regulatory requirements, from which systems and jurisdictions are in view to who owns the legal input and how vendor and generative AI are brought in.

Which AI systems are in scope

Start with a working definition of an AI system and apply it to the full inventory, including tools bought as features of other software, scoring models inside workflow products and internal experiments that touch personal or customer data. GOVERN 1.1 applies to every system whose outputs can affect people, so a narrow definition creates gaps. Check that the inventory records each system's deployment context, because the same model can carry different legal duties in a lending decision and in an internal search tool.

Deployment context and affected people

Legal exposure follows the setting in which the system is used and the people it reaches. A system used for employment, credit, health or public services can trigger sector rules that do not apply to the same model used for marketing analytics. For each system, record who the decisions affect, whether those people are customers, employees or the public, and whether they can contest outcomes. These facts determine which requirements the legal review must track.

Industry and use-specific rules

Sector regulators and use-specific rules set requirements that a general AI policy will not capture. Map each system to the rules for its industry and business purpose, such as financial services supervision, health privacy or public procurement. Ask the legal team to confirm the list in writing and to name the owner of each rule. The Playbook suggests tracking requirements specific to industry, sector, business purpose and deployment context, which is the test this card applies.

Jurisdictions where systems operate

List every jurisdiction where a system is built, hosted, operated or used, and where its outputs reach people. An organization headquartered in one country can still be bound by rules where its customers or employees sit. Include state and national AI laws, data protection regimes and cross-border transfer rules. Where a law names the NIST AI RMF or its Generative AI Profile, note that too. Confirm the jurisdiction list with counsel, because the mapping depends on facts about each deployment.

Vendor-supplied AI

Models, APIs, embedded features and datasets supplied by third parties still carry the buyer's legal obligations for their use. Include every vendor AI feature in the inventory, and ask each vendor for the documents that show its legal position, such as data processing terms, intellectual property warranties and model documentation. Confirm which party holds each obligation under the contract. Vendor AI often reaches production through business units that never route it through legal review, so the scope has to name them.

Generative AI and training data

Generative AI adds legal questions that traditional models do not raise, including the source and licensing of training and fine-tuning data, copyright in outputs, personal data in prompts and retained logs, and the consequences of harmful or biased content. NIST AI 600-1 ties its suggested action for GOVERN 1.1 to data privacy, harmful bias and intellectual property, so bring prompts, retrieval sources and fine-tuning sets into scope along with the model. Ask the team to state which of these inputs it has rights to use.

Teams that own legal input

Decide who brings legal findings into AI decisions and who is accountable for acting on them. Typically legal or compliance owns interpretation, the AI or product owner owns the system, and privacy, security and HR each review the rules in their area. Write these roles down so that a regulatory change reaches the system owner, not only the legal file. Without a named owner per rule, GOVERN 1.1 documentation tends to exist but does not stay current.

How an assessor tests legal and regulatory tracking for AI

The NIST AI RMF has no certification, so no one issues a GOVERN 1.1 certificate. In practice the assessor is usually one of three people: your own internal audit team, a customer's due diligence team reviewing your program during procurement, or a sector regulator examining your AI use. Each tests the same underlying question: can you show which laws apply to your AI, how you know, and what you did about them. Only an independent auditor or certification body issues a formal report, and none of these reviews produces one under the AI RMF itself.

A reviewer will look first for a legal and regulatory register for AI: a maintained list of the laws, regulations and contractual obligations that touch your systems, with an owner, a review date and the sector and deployment context each item applies to. The Playbook's suggested actions point at industry, sector, business purpose and deployment context, so a generic list copied from a vendor blog will read as weak. Next they will check whether the register links to specific entries in your AI inventory (GOVERN 1.6). If a hiring model or a customer-facing chatbot cannot be traced to the rules that govern it, the register is not doing its job.

The assessor then follows the register into decisions. They will ask for a recent risk assessment or go or no-go record and look for a reference to the legal requirements it relied on, such as nondiscrimination or data privacy duties that call for documentation or disclosure. Finally they check training records for staff who design, approve or operate AI, confirming that the course covers the legal points relevant to their role. Confirm before any review that your evidence set includes the register, its change history, the decision records and the training completion data, because a gap in any one of these is usually where findings begin.

What an assessor requests and where GOVERN 1.1 findings usually come from

This table sets out what a reviewer typically asks for under GOVERN 1.1, the evidence that answers each request, and the gaps that tend to surface. Read it as a preparation checklist: each row names an area of the legal baseline and what a reviewer will want to see for it.

Area	What the reviewer asks	Evidence that satisfies it	Where findings usually come from
Legal register	Which laws and regulations apply to each AI system, and who keeps that list current	A dated register with owner, scope, review date and the systems each entry affects	Register exists but has no owner, or lists laws without linking them to any system
Mapping to AI systems	How each applicable requirement is tied to the specific systems, uses and deployment regions in scope	A mapping table linking register entries to inventory records and intended use	Systems in production with no mapped obligations, often shadow or vendor-supplied tools
Sector and use-specific rules	Whether requirements for the industry, business purpose and deployment context were identified and tracked	Written analysis per system showing the sector rules considered and the conclusion reached	Generic analysis that ignores hiring, lending, health or public-sector use rules
Nondiscrimination and data privacy documentation duties	Whether documentation, disclosure and transparency duties that these rules impose are identified and scheduled	Disclosure templates, notice records and documentation prepared for each affected system	Duties identified in the register but no matching documentation or notice exists
Bias testing approach by legal context	Whether the chosen fairness or bias testing method fits the legal context it is meant to support	Documented method choice with the legal rationale and any limits noted in the test plan	One bias metric applied everywhere, even where the legal test for that context is different
Training records	Whether staff who design, deploy or approve AI were trained on the legal considerations that affect them	Training policy, role-based curriculum, attendance records and dates of completion	Policy promises training, but records cover only a few teams or predate system changes
Change and review trail	How the register responds when laws, guidance or system scope changes	Version history showing review dates, reasons for change and approvals	Register is accurate at one point in time but has not been reviewed since launch

How to build a legal and regulatory baseline for AI in six steps

This sequence turns GOVERN 1.1 into a working record: which laws apply to each AI system, who owns them, how they shape policy and training, and when the baseline is checked again.

Identify applicable laws by sector and purpose
Start by listing the legal and regulatory requirements that bear on AI in your organization, using the industry, sector, business purpose and deployment context of each use. Legal counsel and the business owners of each use case should work through this together, because the same model can fall under different rules depending on where and how it is used. The output is a register of laws and regulations, each with a short note on why it applies, the jurisdictions it covers and the date it was last reviewed. Confirm the list against current texts with counsel, since the register is only as good as its sources.
Assign a single accountable owner
Name one person who owns the legal baseline, with a named delegate who covers the register when the owner is unavailable. This role usually sits with legal, compliance or the risk function, working alongside the AI governance lead described under GOVERN 2. The owner decides how disputes about applicability are resolved and who signs off changes to the register. The output is a written role description or charter entry that states the owner, the delegate, their authority and the escalation path to senior management.
Map each requirement to AI systems in the inventory
Connect every requirement in the register to the AI systems it affects. Use the AI system inventory as the starting point (see GOVERN 1.6), and record for each system which obligations apply, including those triggered by data type, affected people, automated decisions or geography. Requirements that apply to nothing in the inventory are a signal that the inventory is incomplete or that the requirement is out of scope, and both need a recorded decision. The output is a matrix linking laws to systems, with the owner of each system named and gaps logged for follow-up.
Align risk management and policy to obligations
Update the AI risk management approach and internal policies so that each mapped obligation has a control, a documented procedure or an explicit acceptance decision. Where a legal requirement mandates documentation, disclosure or greater transparency, write that into the policy, and where a requirement affects testing, such as nondiscrimination rules and bias testing, specify how that testing is done and which legal standard it follows. The output is a gap list showing each obligation, its mapped control or policy clause, and any open item with an owner and a target review date.
Set training and retraining rules
Write a policy that defines which staff must learn about legal considerations affecting AI design, development, procurement and deployment, what each group needs to know, and how often training is repeated. Retraining should also trigger when a law changes or when an AI system's purpose or deployment context changes. Training records should be kept alongside the register. The output is a training policy, a role-based curriculum outline and a completion record that links each training event to the laws it covered.
Schedule review and track legal change
Set a review schedule for the register, the system mappings and the policies, and assign a trigger list that forces an earlier review, such as a new law, a new AI system, a material change in use or a regulator's new guidance. Watch for changes to the NIST AI RMF itself, since NIST says AI RMF 1.0 is being revised and has not yet published the revision. The output is a dated review log showing what was reviewed, what changed, who approved it and which obligations were affected.

Who does what: your legal, engineering and compliance teams, and an implementation partner

Your legal function owns the interpretation of the laws and regulations that apply to your AI systems. GOVERN 1.1 asks that these requirements are understood, managed and documented, and only your counsel can decide which obligations attach to a given use, sector or jurisdiction. Counsel also decides how a requirement such as a nondiscrimination rule or a data privacy duty translates into internal policy language.

Applicability decisions: Determine which laws, regulations and contractual terms apply to each AI system, based on sector, business purpose and where the system is deployed.
Interpretation and escalation: Resolve conflicts between requirements and record the legal reasoning behind each position.
Policy wording: Approve the legal language in AI policies, customer-facing disclosures and vendor terms.
Training content review: Confirm that the legal points in staff training are accurate and current.
Horizon tracking: Watch for new AI rules, including state laws and the EU AI Act, and decide when the register must change.

Check that counsel has signed off on the applicability register and that the sign-off date is recorded alongside it.

Evidence that satisfies GOVERN 1.1 and how to keep it current

GOVERN 1.1 is about understanding, managing and documenting the legal requirements that apply to AI, so an assessor will look for a living record rather than a one-time memo. The six artifacts below connect: the register names what applies, the mapping shows where it touches each system, and the training, sign-offs and change logs show the register is used and kept up to date.

Legal requirements register

A register lists each law, regulation or contractual duty that applies to your AI, with the jurisdiction, the business purpose it covers, a named owner and a review date. It is the first document an assessor will ask for under GOVERN 1.1. Check that every entry has an owner who can actually interpret it, that review dates fall within a cycle you can keep, and that entries cover sector rules as well as general privacy and nondiscrimination law. Keep it in a controlled wiki or document system with version history so the state of the register at any past date can be shown.

Mapping to AI systems

A register alone does not show which obligations touch which models. Map each legal requirement to the AI systems, data sets and use cases it affects, and record the reason for each link. Between audits, update the mapping whenever a system is added, retrained for a new purpose, or moved into a new market, and confirm that the AI inventory and this mapping agree. Gaps usually appear where a business team deploys a tool that was never reviewed against the register.

Legal review records and sign-offs

Each legal assessment should leave a record: the question asked, the sources reviewed, the conclusion, the reviewer and the approver. Sign-offs show that counsel or a compliance lead accepted the position before a system went live. Retain these records with the system version they cover. Between audits, schedule periodic re-reviews and record them even when nothing changed, because a dated review with no change is still evidence that the process runs.

Training records and curricula

The Playbook suggests policies for training and retraining staff on legal considerations that affect AI design, development and deployment. Keep the curriculum, the audience for each module, attendance or completion records, and the date each course was last revised. Check that engineers, product owners and procurement staff receive different content, and that training is refreshed when a material legal change lands. Records should show who was trained, on which version of the material, and when.

Policy documents with version history

Policies that state how the organization tracks and applies legal requirements need approval dates, owners and a visible revision history. Under XWiki, every page change is kept under version control with what changed, when and by whom, and any two versions can be compared. BookStack lets you restrict who can edit a policy through roles and permissions at the shelf, book or page level. Confirm that the approved version in force on any given date can be retrieved.

Change logs for law changes

Laws and guidance change, and an assessor will ask how you learned of a change and what you did about it. Keep a change log that records each new or amended requirement, the date it was identified, the systems affected, the decision taken and the owner who closed it. Watch for changes to the NIST AI RMF itself: NIST says AI RMF 1.0 is being revised as part of the White House AI Action Plan, so track revisions to the framework alongside statutes. Review the log at each periodic review so open items do not age unnoticed.

What meeting GOVERN 1.1 costs in money and effort

This table breaks down the cost components of meeting GOVERN 1.1, showing who is paid for each, whether it is one-time or recurring, and what drives it up or down. No public price data was available for these components, so use the right-hand column to decide what to request in a written quote. The main takeaway is that the largest recurring cost is usually keeping the legal register current, not building it once.

Cost component	Who is paid or who does the work	One-time or recurring, and main cost driver
Legal counsel time	External counsel or in-house legal staff	Recurring. Driven by the number of jurisdictions, sectors and AI use cases in scope, and by how often laws change.
Tooling or licenses	Software vendors for GRC, wiki or document platforms	Recurring license fees. Self-hosted open-source tools such as XWiki or BookStack remove license spend but not hosting or administration effort.
Engineering time to link the register to systems	Internal platform engineers or an implementation partner	One-time for the initial linkage, then recurring as AI systems are added or changed. Driven by the number of AI systems in the inventory.
Training delivery	Internal compliance staff, HR, or an external trainer	Initial course build is one-time. Delivery and refresher training recur. Driven by headcount of staff working on AI and by retraining cycles.
Evidence upkeep	Internal compliance or governance owners	Recurring. Covers version history, change records and periodic review of the register. Driven by the rate of regulatory change and the number of owners.
External review	Outside counsel or a consultant reviewing the register	Typically periodic, not continuous. Ask the provider to state the review scope, number of reviews and whether updates are included.
Assessor sampling	Independent auditors or assessors, if an assessment is requested	Occasional. Auditors sample evidence, so cost depends on how many systems and records they select. Confirm the scope with the assessor before work begins.

Where organizations fall short on AI legal requirements and how to close each gap

GOVERN 1.1 is easiest to satisfy on paper and hardest to sustain in practice. The gaps below appear again and again when organizations review how they track AI-related law, and each one breaks the chain between a legal requirement, the system it governs and the evidence that shows the organization handled it. Work through them in order, because the register comes first and everything else depends on it.

No legal requirements register

Many organizations have obligations spread across legal memos, procurement files and individual inboxes, with no single list of the laws and regulations that apply to their AI. Without a register, nobody can show that requirements were understood, managed and documented, which is the outcome GOVERN 1.1 describes. Close it by creating one register that names each applicable law or regulation, the jurisdiction, the business purpose it touches, the date it was last reviewed and the accountable reviewer. Check that legal counsel has signed off on the initial scope.

Register not linked to systems

A register that lists laws but does not say which AI systems each law governs cannot drive decisions. A hiring model, a customer chatbot and an internal summarization tool can fall under different rules, and the gap usually appears only when an auditor or regulator asks which system is affected. Close it by linking every register entry to the system identifiers in the AI inventory, so each system shows its applicable requirements and each requirement shows the systems it reaches. Confirm the link is reviewed whenever a system changes purpose.

Generative AI copyright and privacy duties missing

Generative AI brings obligations that traditional software registers often skip, including data privacy, copyright and intellectual property law. NIST AI 600-1 ties its GOVERN 1.1 action to the risks of data privacy, harmful bias and homogenization, and intellectual property. Teams that deploy a third-party model may assume the vendor carries these duties, when the deploying organization still needs to document how training data, prompts and outputs are handled. Close it by adding a generative AI entry for each model in use, recording the data sources, retention rules and IP terms that apply, and checking them against the vendor contract.

Sector rules overlooked

General AI policies often miss the requirements that apply because of an industry, such as financial services, health care or critical infrastructure. The Playbook asks organizations to track requirements specific to their sector, business purpose and deployment context. Nondiscrimination and data privacy rules can also require documentation, disclosure and transparency that a general policy does not provide. Close it by assigning a sector owner to review regulator guidance each cycle and adding any sector-specific documentation duty to the register with a named evidence artifact.

Training not refreshed after law changes

Staff trained on AI law once at launch will not know when a requirement changes. The Playbook suggests a policy for training and retraining staff on legal considerations affecting AI design, development and deployment. Retraining that is triggered only by an annual calendar, rather than by a change to the register, can leave developers and product owners working from outdated rules for months. Close it by setting a rule that every register change generates a training note for affected roles, and recording completion so an assessor can see who was trained on which requirement and when.

No named owner for legal tracking

When no one is accountable for keeping the register current, each team assumes another team is watching the law. The result is a register that was accurate on the day it was written and has drifted since. GOVERN 1.1 asks that legal requirements be managed as well as understood, which needs a person with time, authority and a review date. Close it by naming one accountable owner in writing, giving that owner a review date for each entry, and escalating overdue entries to the governance body that oversees AI risk.

Questions buyers ask about GOVERN 1.1 cost, effort and outside help

Can we do GOVERN 1.1 in-house without an outside partner?

Yes, in most organizations the core work can be done in-house, because NIST AI RMF is voluntary and no one issues a certificate for it. The organization owns its legal register, its policies and its training. What usually needs outside help is the time to build the register across many jurisdictions, the engineering work to connect legal requirements to real systems, and the evidence that stands up when a customer or regulator asks. Ask whether your team has the hours, the legal reviewer and the tooling to keep the register current after the first pass. If any of those are missing, a partner can prepare the systems and evidence, while your legal team keeps the legal judgment.

What drives the cost and effort of GOVERN 1.1?

The main drivers are the number of AI systems in scope, the number of jurisdictions and sectors that apply to them, and how many of those systems use personal data, generate content or make decisions about people. Effort also rises when no AI inventory exists, when contracts with AI vendors lack data or intellectual property terms, and when training records are scattered. Costs fall when use cases are grouped and the register is kept in one place with clear owners. Ask any provider to split the quote into one-time work (initial mapping, policy drafting, tooling setup) and recurring work (register updates, staff training, periodic review).

How long does it take to get GOVERN 1.1 in place?

The duration depends on scope and on how much legal and regulatory material already exists, so no fixed figure applies here. Teams with a current inventory, a legal contact and a documented data governance practice usually move faster than teams that must first discover which systems exist. Time also depends on how quickly legal reviewers can respond and how many approval cycles the policies require. Ask for a timeline tied to named deliverables, such as a requirements register, a training plan and a review schedule, with dependencies on your own team listed separately.

What does GOVERN 1.1 need from legal and engineering teams?

Legal owns the interpretation of which laws apply, the risk of each requirement, and sign-off on policy wording. Engineering owns the mapping of those requirements to systems, data flows, logging, access controls and documentation. Specifically, legal must confirm sector rules, privacy and nondiscrimination obligations, and intellectual property terms, while engineering must show where personal data is processed, how bias testing is run where the law requires it, and how records are kept. Agree on these responsibilities before work starts so neither team is asked to review what they cannot assess.

Does an auditor certify that we meet NIST AI RMF?

No. NIST AI RMF has no certification, accreditation or conformity assessment program, and NIST does not validate or endorse any organization's use of the framework. An independent auditor or assessor can review your evidence against your own stated approach, but that review is not a NIST certificate. Organizations that need a formal, certifiable report often look at other frameworks instead. A provider such as DeployOpen can prepare systems and evidence, but only an independent party issues reports or certificates. Confirm the wording any customer or regulator expects before you commit to a deliverable.

What should a written scope for GOVERN 1.1 include?

A written scope should name the AI systems and business units covered, the jurisdictions and sectors whose requirements will be tracked, and the legal sources the register will use. It should list deliverables such as the requirements register, the alignment of risk management to each requirement, the training content and audience, and the review schedule. Add the responsibilities of your legal, engineering and procurement teams, the evidence format, and what is excluded. Fixed-scope engagements, where scope, deliverables and timelines are agreed in writing before work starts, make these items easier to compare across quotes.

Which parts of GOVERN 1.1 are ongoing after the first delivery?

Legal requirements change, new AI systems enter use, and vendors update their models and terms, so the register needs ongoing upkeep. The recurring work includes reviewing new laws, updating the register and policies, refreshing training, and checking that vendor contracts still match legal obligations. It also includes keeping version history and approval records. Ask whether a provider offers retainer support for upgrades and periodic review, and whether your own team will own the register after handover. The recurring share of the cost depends mostly on how often your legal landscape and system portfolio change.

How should we keep the GOVERN 1.1 records that show compliance?

Keep the register, policies and training records in a system that records every change, who made it and when, and that lets you compare or roll back versions. Open-source wiki tools such as XWiki provide version history of this kind, and BookStack supports role-based permissions at the shelf, book, chapter or page level. Confirm with your own security and records teams how long records must be retained and who may approve changes. For teams that also track framework mappings, CISO Assistant is an open-source option that supports more than 200 frameworks, but confirm its fit with your requirements before adopting it.

How DeployOpen prepares GOVERN 1.1 evidence inside your environment

DeployOpen can prepare the systems and records that show how your organization tracks and documents the laws that apply to its AI, but the legal determinations stay with your organization. Our work happens inside your own infrastructure, whether that is your cloud accounts, data centers or air-gapped networks. We plan, implement and document the platforms that hold the evidence, such as a legal requirements register, a policy repository and the training records for staff. Your legal, privacy and compliance owners decide which laws apply to each AI system, how they interpret them and what the organization accepts as residual legal risk.

Engagements are fixed-scope. Before work starts, the scope, deliverables and timelines are agreed in writing, so you can see exactly which artifacts will exist at the end: for example, the register fields, the review cadence, the approval workflow and the training materials. Ask for the list of named deliverables in the quote and check it against what your counsel and internal audit expect to see. Any requirement that is not written into the scope is outside the engagement and should be planned separately.

DeployOpen does not issue audit reports, attestations or certifications. NIST does not offer an AI RMF certificate, so no one can certify GOVERN 1.1 on the organization's behalf. If an independent assessor, customer auditor or regulator asks for proof, the evidence you hold is your own record, reviewed on your terms. Confirm with your assessor early which format and retention period they will accept, and keep the legal determinations, sign-offs and training attestations in the names of accountable people inside your organization.

How DeployOpen scopes and delivers GOVERN 1.1 readiness

DeployOpen prepares the systems, documentation and evidence an organization needs to show how it tracks and documents the legal and regulatory requirements that apply to its AI. The organization owns its legal obligations and its risk decisions, and only an independent assessor can issue any report on the outcome.

How we scope

Engagements are fixed-scope, with the AI systems, jurisdictions and sectors in view agreed in writing before work starts.
The written scope lists which requirements register, policy records and training materials are in and out of the work.
We confirm with your legal and compliance team which obligations they own, so the scope does not assume legal conclusions.

How we build

We set up a tracked register of legal and regulatory requirements linked to each AI system in the inventory.
We configure version-controlled policy and procedure pages so changes to legal mappings are recorded with who made them and when.
We configure role-based access so compliance, engineering and legal reviewers each edit only the pages they are responsible for.

How we hand over

You receive the requirements register, policy set, training plan and change history in formats your teams can maintain.
We document how each entry is reviewed, who approves changes and how the register feeds into the GOVERN 1.5 review cycle.
We walk your owners through the records so they can explain them to internal auditors and to any independent assessor you engage.

How we support

Ongoing support, upgrades and periodic register reviews are available as a retainer after handover.
Retainer scope, response expectations and review frequency are set in writing, so confirm them against your own obligations.
Requests for changes to the written scope are handled as a documented change before any additional work begins.