# Zovos AI — Documentation (full text) > Agentic compliance infrastructure for financial institutions of every size. Every customer documentation article below, concatenated in section order. Machine-readable index: https://zovos.ai/docs/index.json — per-article markdown at https://zovos.ai/docs/docs-.md. Facts are grounded in shipped behaviour. --- # Onboarding your institution Section: Get started · Updated: 2026-10-07 · https://zovos.ai/docs-onboarding.html We set Zovos up together with you. There is no self-serve signup and no trial account to create. Onboarding starts with your Zovos contact, and it ends with a workspace connected to your own identity provider and an owner who can bring the rest of the compliance team in. This guide is for the chief compliance officer or program owner running that process at a bank or credit union, whatever its size. Once you are inside, [Getting started with Zovos](docs-getting-started.html) covers the workspace itself and [Set up your team and SSO](docs-team-setup.html) covers ongoing team administration. ## What we provision and what you supply We create the workspace. That means your own database schema, a dedicated key for your stored documents, the identity organization your sign-ins resolve against, and the record of your contracted terms. You do not install anything, and there is nothing to run on your own infrastructure. What we hold and how it is separated is described on the [security page](security.html). Three things have to come from you before we can start: - **Your institution's display name.** This is the name shown in the product and on anything you export from it. - **A short identifier.** It uses lowercase letters, numbers and underscores, begins with a letter, and names your workspace internally. It is **permanent**. There is no rename path once the workspace exists, so pick something you will still recognize in five years. - **Your identity provider administrator.** We need the name and contact details of the person who can create an application in Okta, Entra ID, Google Workspace, or whatever your institution runs. You will need them for the step below. We record your commercial terms against your workspace, so you do not enter them yourself. Those terms are the plan, the contracted seat count and the renewal date. ## Connecting your identity provider Once the workspace exists, we send you a **one-time setup link** for the identity connection. It is short-lived by design, so treat it as a scheduled step rather than something to forward and get to next week. If it lapses before you use it, ask your Zovos contact for a fresh one. That costs nothing but a message. Have your identity provider administrator ready when you open it. Everything the connection needs is entered on that link rather than inside Zovos. That includes the metadata URL or XML, the certificate, the reply and entity identifiers, and the email domains. The product's own single sign-on panel shows the state of the connection and never asks you for a secret. You may want membership and roles to flow from your directory rather than from invitations. If so, we set up directory synchronization with you in the same session. There is no self-serve link for it. What happens *after* the connection exists is yours. Mapping your directory groups to Zovos roles is an in-product screen an owner edits, and it is covered under [Set up your team and SSO](docs-team-setup.html). An owner can also map directory groups to access groups, which bundle roles, job families and a scope. ## Your first sign-in Everyone in your institution reaches Zovos at **https://app.zovos.ai/login**. There is one address, one **Continue with SSO** button, no institution picker and no Zovos password. Your workspace is determined by the identity you sign in with, which is why the link is the same for every customer. The first person in is whoever we map to the owner role on the identity connection. That is normally the CCO or the program owner. Tell us who it is before the connection call, because that person has to sign in before anyone else can be brought in. Invitations are sent from inside the product by someone who already holds the owner role, and an account that has never signed in is not yet active. Examiners do not arrive this way. A regulator gets a time-boxed session, read-only apart from a few fieldwork actions, that an owner issues during an examination and hands over as a one-time token, pasted on the same sign-in page. See [Exam management and audit readiness](docs-exam-management.html) and [Roles and permissions](docs-roles-permissions.html). ## What your network team needs to allow Most institutions need nothing more than normal outbound HTTPS, but corporate proxies and allow-lists sometimes need these named: - **app.zovos.ai over HTTPS on port 443, including the WebSocket upgrade.** The collaborative drafts editor uses a WebSocket on that same host and port. A proxy that strips the upgrade header breaks co-editing in Drafts and nothing else, because the rest of the product is plain HTTPS. - **WorkOS, our identity partner, and your own identity provider.** Signing in is a top-level redirect out to them and back, so both have to be reachable from the browser. - **Our document storage endpoint.** Document uploads and downloads go directly between the browser and object storage rather than through the application. Ask [support](support.html) for the allow-list entry for your environment. Two related facts are worth passing on. Zovos cannot be embedded in an intranet portal frame, because the product deliberately refuses to be framed. An owner can also restrict the whole workspace to a list of your own IP ranges if you choose. That is a real feature, and [Set up your team and SSO](docs-team-setup.html) describes it, including how not to lock yourself out. ## Day one, in order The order matters more than it looks, because several steps are prerequisites for the ones under them. 1. **Set your institution profile and timezone.** Settings ships with generic defaults. They describe a bank under one billion dollars in assets, on UTC, with no charter states recorded. Until you correct the charter type, asset band and states, regulatory-change applicability is being judged against those defaults, and the daily digest and the obligations calendar run on UTC rather than your business day. 2. **Enroll your frameworks.** This is owner-only, and it is the step that scopes everything downstream. Until it is done, the framework library, Citations and the Gap report are all empty. See [Frameworks and citations](docs-frameworks.html). 3. **Invite your second approver and get them signed in.** Critical decisions require two distinct signers, and an invited person is not an approver until they have signed in themselves. See [Set up your team and SSO](docs-team-setup.html). 4. **Give each teammate their job families.** A job family says what a person does, such as compliance, AML/CFT or internal audit, and a person can hold several. Families order the sidebar and choose the dashboard panels for that person. They never grant a permission and never change the price. Set them on the invitation or later on the Team screen. See [Roles and permissions](docs-roles-permissions.html). 5. **Bring in your policies and controls.** Import your control baseline and upload your policy documents so analysis is grounded in your real program rather than a template. See [Policies and document management](docs-policies.html) and [Controls, testing and evidence](docs-controls.html). 6. **Ask your Zovos contact to confirm the regulatory library is indexed for your workspace.** Agents cite the library, and until it is indexed they decline to run rather than answer without sources. Confirm it before the first agent run, not after. 7. **Run mapping on the Gap report, then run the gap analysis.** Mapping is what produces the gaps. The Gap Analysis agent then works against a gap that already exists. Running them the other way round is the most common first-week stumble. Agent output is a proposal and never a decision. See [How AI works in Zovos](docs-ai-in-zovos.html). 8. **Triage the first finding.** Assign an owner, a due date and a root cause, and you have the beginning of a record an examiner can follow. See [Findings and remediation](docs-findings.html). ## Email during onboarding **The product does not send email today.** Notifications are delivered in the workspace, through the bell in the top bar and the panels on the Dashboard. The email preferences in settings record your choices but stay inert until email delivery is switched on for the deployment. The product says so on the screen rather than quietly dropping messages. Plan onboarding on the assumption that nobody gets nudged by email. There is exactly one email in the whole flow. It is the **teammate invitation**, which is sent by WorkOS, our identity partner, from its own sending domain rather than from Zovos. Ask your mail team to let it through before you start inviting people, or your first invitations will sit in quarantine. ## Who does what | Task | Who does it | | --- | --- | | Creating the workspace and recording your terms | Zovos | | Connecting your identity provider | Your IdP administrator, on the one-time setup link | | Directory synchronization (SCIM) | Set up with Zovos during onboarding | | Mapping directory groups to Zovos roles | You, on the Access & SSO tab in Settings | | Assigning job families to teammates | You, on the Team screen or through directory group mappings | | Enrolling frameworks, importing policies and controls | You | | Inviting teammates and granting examiner access | You | | Indexing the regulatory library for your workspace | Zovos | | Recovering an IP allowlist you locked yourself out of | Zovos support | If anything in the sequence above stalls, [contact support](support.html). We prioritize anything blocking an examination. --- # Getting started with Zovos Section: Get started · Updated: 2026-10-07 · https://zovos.ai/docs-getting-started.html Zovos is the compliance workspace for every line of defense at community banks, credit unions and national institutions. First-line owners in the business handle their own tasks, attestations and vendor records, and they complete the risk and control self-assessments for their business units. The second line runs the compliance and risk program, and internal audit works behind its own independence wall. Zovos holds your frameworks, policies, controls, risks, findings and exam evidence in one place, and it keeps a record of who decided what. This guide covers your first session. If you are the person standing the workspace up for your institution, start with [Onboarding your institution](docs-onboarding.html) and read this alongside [Set up your team and SSO](docs-team-setup.html). ## Signing in You sign in through your institution's own identity provider. There is no separate Zovos password to remember and no local account to manage. Your administrator grants access, and single sign-on carries your identity into the workspace. If you were invited by email, your first sign-in is what accepts the invitation and turns your access on. Nobody can activate the account for you from inside the product, and that is by design. An account that has never signed in is an unverified identity, and we will not count one as an approver. If sign-in is refused, contact your administrator first. The usual cause is a directory group or role assignment that has not been mapped yet, and that is fixed on your side of the connection. If your administrator confirms the mapping and sign-in still fails, [contact support](support.html). Examiners do not sign in this way. A regulator gets a time-boxed, scope-limited session, read-only apart from a few fieldwork actions, that an owner grants for a named examination. See [Roles and permissions](docs-roles-permissions.html). ## The workspace at a glance The layout is the same on every screen. The sidebar on the left holds the navigation, grouped by the work each person does. The top bar holds four things you will use constantly: - The approvals pill reads **Approvals** and has a count beside it. It counts only the decisions *you* are entitled to make, so it is never a queue of other people's work. Open it and the drawer heads the list **Awaiting your sign-off**. - The notification bell shows items routed to you. - The command palette opens with **Command-K** (or **Ctrl-K**) and jumps to any screen by name without navigating. - Your user menu holds the in-app help center and **Report a bug**. For owners, it also holds the control that grants an examiner access. Two conventions are worth knowing on day one. First, anything you do not have permission to see is **hidden rather than greyed out**, so the workspace you see is the workspace you have. Second, panels that are withheld from your role render nothing rather than showing a fabricated zero. ## Find your starting point The sidebar is grouped by the work each person does. Every group header folds, so you can close the groups you rarely open. If you hold one or more job families, the sidebar puts My work first and your families' groups next, and only those groups start open. The **All sections** switch at the top of the sidebar brings back the full order with every group open. Job families only arrange the sidebar. Your permissions still decide which items you see, and a group with nothing you can open does not appear at all. Three groups belong to everyone. **My work** holds the Dashboard, Tasks & plans, Findings, Audit requests, Audit responses, the Obligations calendar, Drafts, Documents, and Agent runs. Audit requests and Audit responses are the auditee's side of internal audit, so they sit here and not with the audit function. **Library** holds your regulatory content. That means Frameworks, Governing docs, the Control catalogue, Control objectives, Citations & Authorities, Coverage, the Proposal inbox and the Content library. **Administration** holds Team, Governance, the Audit trail, and Settings. Exam prep, Supervisory actions, Reg updates and the other regulatory-change screens sit in the **Exams & regulatory change** group. The rest of the sidebar follows the job families. Find the family closest to your job below and read its pages in order. At a community bank or credit union, one person often holds several families, so read every list that describes your work. ### Compliance, including fair lending & CRA The **Compliance** group holds the Gap report, Monitoring & testing, Absence testing, Training oversight, the Advisory log, the CMS scorecard, Complaints, Disclosures, and Marketing reviews. HMDA and CRA sit under their own heading, **Fair lending & CRA**. A credit union's sidebar leaves CRA out. 1. [Frameworks & reg updates](docs-frameworks.html) 2. [Consumer compliance](docs-consumer-compliance.html) 3. [Monitoring & absence testing](docs-monitoring.html) 4. [Policies & documents](docs-policies.html) 5. [Findings & remediation](docs-findings.html) ### AML/CFT & fraud The **AML/CFT & fraud** group holds the AML/CFT program, Fraud losses, and the Fraud case log. The AML/CFT program is where the AML/CFT officer evidences the five pillars. Fraud losses reads the fraud events in the loss-event register by channel, and the Fraud case log records the two-person SAR decision on each escalated case. 1. [AML/CFT program & training oversight](docs-bsa-program.html) 2. [Risk management](docs-risk-management.html) 3. [Connecting integrations](docs-integrations.html) 4. [Monitoring & absence testing](docs-monitoring.html) ### Enterprise & operational risk The **Risk** group holds the Risk register, Assessments, KRIs, Appetite, Exceptions, Loss events, Emerging risks, and the Decision register. Assessments are the risk and control self-assessments, and Exceptions holds exceptions and waivers. 1. [Risk management](docs-risk-management.html) 2. [Controls & testing](docs-controls.html) 3. [Approvals & authority](docs-approvals.html) 4. [Findings & remediation](docs-findings.html) ### Third-party risk The **Third parties** group holds TPRM, Partner programs, and Questionnaires. 1. [Third-party risk](docs-third-party-risk.html) 2. [Risk management](docs-risk-management.html) 3. [Findings & remediation](docs-findings.html) 4. [Connecting integrations](docs-integrations.html) ### Cybersecurity The **Cybersecurity** group holds the Cybersecurity page, Security incidents and Continuity (BCM), the business continuity register. The Cybersecurity page brings together your information security and continuity frameworks, the findings and controls tied to them, the open security incidents with the notices still due on them, and the annual report to the board. **Security incidents** is the incident register, where each incident's notification deadlines are tracked. See [Cybersecurity](docs-cybersecurity.html). 1. [Controls & testing](docs-controls.html) 2. [Test with your AI assistant](docs-ai-control-testing.html) 3. [Business continuity](docs-business-continuity.html) 4. [Findings & remediation](docs-findings.html) ### Model & AI governance The **Model & AI** group holds Model risk and AI systems. Model risk has two tabs, the Model inventory of your institution's models and the Model governance pack for the AI inside Zovos. AI systems is the registry of every AI use case in the institution. 1. [Model & AI governance](docs-model-ai-governance.html) 2. [How AI works in Zovos](docs-ai-in-zovos.html) 3. [Controls & testing](docs-controls.html) 4. [Findings & remediation](docs-findings.html) ### Credit risk review The **Credit risk review** group holds the Loan universe, Credit reviews, and Review exceptions. A reviewer cannot be assigned a credit they originated or approved, and the universe holds loan references and no borrower names. 1. [Credit risk review](docs-credit-risk-review.html) 2. [Findings & remediation](docs-findings.html) 3. [Approvals & authority](docs-approvals.html) 4. [Roles & permissions](docs-roles-permissions.html) ### Internal audit The **Internal audit** group holds the audit Universe & plan and audit Engagements. It is visible only to the audit function and the board. Management, including the chief compliance officer, does not see in-progress audit work, because management is the auditee. 1. [Internal audit](docs-internal-audit.html) 2. [Roles & permissions](docs-roles-permissions.html) 3. [Controls & testing](docs-controls.html) 4. [Findings & remediation](docs-findings.html) 5. [Audit trail & exports](docs-audit-trail.html) ### Board or Supervisory Committee The **Board** group holds the Board portal. A credit union sees this group as **Supervisory Committee**. 1. [Board & governance](docs-board-governance.html) 2. [Approvals & authority](docs-approvals.html) 3. [Findings & remediation](docs-findings.html) 4. [Internal audit](docs-internal-audit.html) ### Executive management Executives read across the program rather than working one register, so the reading path starts with the Dashboard. 1. [Dashboard & triage](docs-dashboard-triage.html) 2. [Risk management](docs-risk-management.html) 3. [Exam management](docs-exam-management.html) 4. [Approvals & authority](docs-approvals.html) 5. [Board & governance](docs-board-governance.html) ### Business-line owner Business-line owners in the first line work their own tasks, attestations, vendor records, and self-assessments, so most of their day starts in My work. 1. [Tasks & action plans](docs-tasks-action-plans.html) 2. [Policies & documents](docs-policies.html) 3. [Risk management](docs-risk-management.html) 4. [Third-party risk](docs-third-party-risk.html) ## Where the day starts Open the Dashboard. It leads with what needs you today rather than a wall of charts. You get a **Needs your attention** panel, overdue and at-risk work, the approvals queue, the findings tracker, framework health, recent agent runs, audit readiness, incoming regulatory updates, and recent activity. Every tile drills through into the register behind it, so triage is one click from the number. [Dashboard and daily triage](docs-dashboard-triage.html) covers that routine in detail. If an owner has turned on the AI assistant connector, you can also ask the assistant you already use what is on your plate. It reads your open tasks, the attestations and certifications waiting on you, and your approvals queue, under your own role. It can create a task or comment on a finding or a risk after showing you a dry run, and it never approves or signs off anything. See [Connect your AI assistant](docs-connect-ai-assistant.html). A new workspace also shows a short getting-started checklist, titled **Set up your compliance workspace**, which is the fastest honest path to a program you can show an examiner. Its four steps, in the product's own words, are these: 1. **Enroll your regulatory frameworks.** Pick the ones you are actually examined against, in the [framework library](docs-frameworks.html). Only an owner can enroll a framework, and until one is enrolled both the framework library and Citations are empty. 2. **Import your controls and policies.** Bring in your control baseline and upload your policy documents, so analysis is grounded in your real program. See [Policies and document management](docs-policies.html) and [Controls, testing and evidence](docs-controls.html). 3. **Run your first gap analysis.** This step has two prerequisites the checklist itself does not mention. First, the regulatory library has to be indexed for your workspace, or the agents decline to run rather than answer without sources. Confirm that with your Zovos contact before the first run. Second, choose **Run mapping** on the Gap report before you go to Agent runs. Mapping is what produces the gaps, and the Gap Analysis agent works against a gap that already exists. Agent output arrives as a proposal and never as a decision. See [How AI works in Zovos](docs-ai-in-zovos.html). 4. **Triage a finding.** Assign an owner, a due date and a root cause. See [Findings and remediation](docs-findings.html). Two settings are worth correcting in the same sitting, because both ship with generic defaults. Your institution profile starts as a bank under one billion dollars in assets with no charter states recorded, and regulatory-change applicability is judged against whatever is there. Your workspace timezone starts on UTC, which skews the daily digest hour and calendar due dates until an owner sets it. Notifications, meanwhile, are delivered in the workspace. The product sends no email today, so nothing in this list will chase you by inbox. [Onboarding your institution](docs-onboarding.html) walks through the whole sequence. ## Where to get help The product ships an in-app help center in your user menu, with task guides and the **Report a bug** entry point. A bug report carries the screen you were on and your recent actions, and you see exactly what is attached before it sends. This portal is the fuller reference. If a term in the product is unfamiliar, start with the [glossary](docs-glossary.html). If something is behaving unexpectedly, start with the [FAQ and troubleshooting](docs-faq.html). For anything else, [contact support](support.html). Support is staffed Monday to Friday, 9am to 6pm Eastern. We usually acknowledge new requests within a week, and we prioritize anything blocking an examination. --- # Roles & permissions Section: Get started · Updated: 2026-10-07 · https://zovos.ai/docs-roles-permissions.html Access in Zovos is role-based, and the roles are built around the separation of duties an examiner expects to see. This article explains the roles that ship with the product, the rules that stop one person signing their own work, and how regulator access is handled. It also covers how one person holds several roles, how access groups bundle roles, job families and a scope, and how job families personalize the workspace for each person without changing what they are allowed to do. Owners who need to invite people or change a role should read [Set up your team and SSO](docs-team-setup.html). ## How the model works Every action in the product is gated by a fine-grained permission. Reading a register, writing to it, approving a specific class of decision, changing settings and granting examiner access each have their own permission. The catalog of permissions is fixed in the product and cannot be extended by configuration. What each role holds *is* configurable. Role-to-permission assignments are your data, and an owner can edit them or build custom roles for your institution without waiting on us. Enforcement fails closed. A role the system does not recognize gets nothing rather than a default. You will notice two consequences day to day. Navigation you cannot use is hidden rather than disabled, and a permission change takes effect on the member's next request. ## The six roles | Role | Who holds it | What it can do | What it deliberately cannot | | --- | --- | --- | --- | | Owner | The chief compliance officer or program owner | All reads and writes, all approvals outside internal audit, settings, examiner grants, publishing documents | See in-progress internal-audit work, because the owner is an auditee | | Compliance Analyst | Compliance officers and analysts | Read everything outside internal audit. Write drafts, findings, agent runs, exam prep, risk, controls, third-party risk, partner programs, consumer compliance, AML/CFT and fraud, models, continuity, credit review and security records | Approve anything, including the risk approvals that gate partner-program stages. Change settings, manage the team, or grant examiner access | | Internal Audit | The chief audit executive and audit staff | Everything the audit function needs, including audit work. Write findings. Approve finding closures and audit deliverables | Approve risk acceptances or control effectiveness, which are management decisions audit will later test | | Board Read-only | Directors and audit, risk or supervisory committee members | Read the oversight surfaces. Approve policies and the audit plan and reports | Write into any operating record, because it is a consumption and approval surface | | Risk Approver | The second-line independent approver, often a CRO or senior risk director | Read everything outside internal audit. Approve risk acceptances, control effectiveness, finding closures, policies, mappings and routing decisions | The owner's write set, settings, examiner grants, and internal audit | | Examiner | An external regulator, for one examination | A scoped read-only set plus a closed set of fieldwork actions, for the granted scope and window | Everything else. Every screen refuses an examiner unless it is explicitly examiner-scoped | The Risk Approver holds every approval that the default Delegation of Authority matrix names it for, so it can fill its signer seat on any governed decision. It approves, and it does not operate. ## Custom roles Custom roles are defined over the same permission catalog, so you can build, for example, a read-only role for a consultant or a narrow role for a business-line owner. An owner creates and edits them in Settings on the **Access & SSO** tab. Each custom role also carries three behaviour flags that an owner can switch on or off. The first decides whether the role sees internal notes and pending evidence. The second decides whether it sees every committee rather than only the committees it holds seats on. The third decides whether it is mailed the board pack when the pack is published. The flags are fixed on the six system roles. A new role can start blank or from one of two starting points. The **External auditor** starting point is meant for an outsourced internal-audit firm or an independent AML/CFT tester. The role reads everything, writes only its own internal-audit engagement work, and sits on the internal audit side of the independence wall. It approves nothing, changes no settings, grants no examiner access and carries no behaviour flags. It is not the examiner role, which stays reserved for the time-boxed grant described below. The **Business-line owner** starting point is meant for a first-line manager. The role reads tasks, vendors, risk and control self-assessments, policies and controls, and it writes only what that person does on their own work. That covers task status, self-assessment responses, vendor due diligence and signing off the control certifications addressed to them. It approves nothing, sits outside the independence wall and carries no behaviour flags. It is meant to be held through the Business-line owner access group described below, whose scope keeps it to the person's own records. ## Several roles A member can hold more than one role, and what they may see and do is the union of those roles. A chief risk officer who holds Compliance Analyst and Risk Approver can both write risk records and approve risk decisions. Maker-checker follows the person rather than the role, so nobody approves a decision they submitted under any of the roles they hold. An owner sets a member's roles on the Team screen and marks one of them as primary. A member can also hold roles through an access group or from your directory. Every change is written to the audit trail and takes effect on the member's next request. ## Roles that cannot be combined Three rules limit which roles one person can hold together. The product refuses a change that would break one, whether it comes from the Team screen, an access group or your directory. - **Internal audit stands apart.** A role on the internal audit side of the independence wall, including a custom role built from the External auditor starting point, cannot be combined with any role outside internal audit. An auditor cannot also hold the work they audit. - **The board role stands alone.** A member who holds Board Read-only holds no other role. - **The examiner role stands alone.** It is held only through the time-boxed grant described below, never beside another role and never through an access group. ## Access groups An access group is a named bundle that an owner builds once and gives to many people. It holds roles, job families and a scope. Giving someone a group gives them its roles and families, and taking the group away removes them again. Anything the person holds directly or through another group stays. Editing a group's roles changes them for everyone who holds it, and a change that would break one of the rules above for any holder is refused with their names. Owners build groups in Settings on the **Access & SSO** tab, under **Access groups**, and a group cannot be deleted while anyone holds it. A group can be built by hand or started from a preset: - **Compliance & AML/CFT officer** gives Compliance Analyst with the Compliance and AML/CFT & fraud families. - **Chief risk officer** gives Compliance Analyst and Risk Approver with Enterprise & operational risk, AML/CFT & fraud, Third-party risk, and Cybersecurity. - **Risk & compliance officer** gives Compliance Analyst with Enterprise & operational risk and Compliance. - **AML/CFT & fraud** gives Compliance Analyst with AML/CFT & fraud. - **Vendor & continuity** gives Compliance Analyst with Third-party risk and Cybersecurity. - **Chief audit executive** gives Internal Audit with Internal audit. - **Director** gives Board Read-only with Board. - **External auditor / independent AML/CFT tester** gives the External auditor custom role with Internal audit. The role is created the first time the preset is used if your workspace does not have one yet. - **Business-line owner** gives a custom role named Business line, built from the Business-line owner starting point, with the Business-line owner family, limited to the person's own records. The role is created the same way. An owner gives a member groups on the Team screen, in the same editor as their roles. If directory synchronization is on, an owner can also map a directory group to an access group on the Directory Sync panel under Integrations in Settings. When your directory adds a person to that group, they receive the access group. When your directory removes them, they lose it and every role and family it granted, while a role they hold another way stays. A directory membership that would break one of the combination rules is not applied, and the refusal is written to the audit trail. Members provisioned by your directory receive their groups only from the directory. Members who sign in with single sign-on but are not managed by your directory are edited in the product like anyone else. ## Scope A group's scope decides which records its roles reach. There are three settings. - **Everything** is the default, and every preset except Business-line owner uses it. - **Own records** limits the group's roles to the records the person owns. - **Business units** limits them to the records of the chosen business units and the units beneath them, plus the person's own records anywhere. Scope covers reading and writing alike. Only the screens a business-line owner works from accept a scoped member. Those are My work, their tasks, the findings in their scope, the vendors they own, the risk and control self-assessments in their scope, and the attestation and certification campaigns addressed to them. Search and record links return only records in their scope. Every other screen is closed to a scoped member and is absent from their sidebar. A record outside the scope reads as not found, and the scoped screens carry a line saying whose records they show. Scope limits only what a person holds through scoped groups alone. If the same permission also comes from a role held directly, from your directory, or through a group scoped to everything, the person is not limited. A role held only through a scoped group also never counts as another approver or administrator. It cannot fill a signer seat, it does not stop the sole-operator override, and it does not count as the last member with settings access. ## Job families A role decides what a person may see and do. A job family describes what the person does, and Zovos keeps the two apart on purpose. A family is never a permission, so it cannot show anyone a screen or record their role does not already allow. A family never changes the price of your subscription either. A person can hold several families, because most people at a community bank or credit union wear more than one hat. The families follow the three lines of defense, and each one that has a page in Solutions by role is linked below. | Job family | Line of defense | Read more | | --- | --- | --- | | Executive management | First line | [Executive management](role-executive.html) | | Business-line owner | First line | [Business-line owners](role-business-line.html) | | Compliance | Second line | [Compliance](role-compliance.html) | | Fair lending & CRA | Second line | [Fair lending and CRA](role-fair-lending-cra.html) | | AML/CFT & fraud | Second line | [AML/CFT and fraud](role-aml-cft-fraud.html) | | Enterprise & operational risk | Second line | [Enterprise and operational risk](role-risk.html) | | Third-party risk | Second line | [Third-party risk](role-third-party-risk.html) | | Cybersecurity | Second line | [Cybersecurity](role-information-security.html) | | Model & AI governance | Second line | [Model and AI governance](role-model-ai-governance.html) | | Credit risk review | Second line | [Credit risk review](role-loan-review.html) | | Internal audit | Third line | [Internal audit](role-internal-audit.html) | | Board | Governance | [Board](role-board.html) | One more family exists. Platform administration is for the people who run the workspace, and it sits outside the three lines. At a credit union the Board family reads Supervisory Committee, and Fair lending & CRA reads Fair lending, because the Community Reinvestment Act does not apply to credit unions. The labels follow the charter type in your institution profile. ### Presets A preset fills in a common combination of families in one step. You can add or remove families after choosing one. - **Compliance & AML/CFT officer** fills in Compliance and AML/CFT & fraud. - **Chief risk officer** fills in Enterprise & operational risk, AML/CFT & fraud, Third-party risk, and Cybersecurity. - **Risk & compliance officer** fills in Enterprise & operational risk and Compliance. - **AML/CFT & fraud** fills in AML/CFT & fraud. - **Vendor & continuity** fills in Third-party risk and Cybersecurity. - **Chief audit executive** fills in Internal audit. - **Director** fills in Board. ### What a family changes - **Sidebar order.** My work comes first, followed by the groups the person's families own and then the other groups. Library and Administration come last. Only My work and the groups the families own start open. - **All sections.** A switch at the top of the sidebar restores the default order with every group open. That choice and any group a person folds or unfolds are saved for that person. - **Dashboard panels.** The dashboard shows every panel that any of the person's families calls for. It never shows more than the person's role allows. - **My work.** A person whose only family is Business-line owner opens on a My work home. It lists their own open tasks, the attestation and certification campaigns awaiting them, and the vendors, risks and self-assessments they own. A person who holds Business-line owner with other families sees My work as a panel above the standard dashboard. Which items appear in the sidebar is still decided by the role alone. A person with no family sees the default sidebar and the dashboard for their role. Owners set families on the invitation, on the Team screen, or through an access group, including one mapped from a directory group, as [Set up your team and SSO](docs-team-setup.html) describes. ## Separation of duties - **Maker-checker.** The person who submits a decision cannot be the person who approves it. When you look at something you submitted, the queue tells you plainly that it is not yours to approve. - **Four eyes on critical items.** Critical decisions require two distinct signers. - **Delegation of Authority.** An owner-editable matrix decides, for each object type and severity, which roles may approve and how many signatures are needed. Policies route by document tier. The internal audit plan always routes to the audit committee. - **Rationale, always.** Every decision requires written rationale, and the approver sees a preview of exactly what they are signing. - **Sole-operator override.** In a one-person compliance shop there may be nobody else holding the required permission. Rather than disabling the control, the decision proceeds with a mandatory justification and is tagged in the audit trail as a sole-operator decision, so the compensating disclosure exists. This is the honest handling of a real situation, and it is visible to your examiner. - **Independent AML/CFT testing.** Someone who wrote, published, submitted or approved the AML/CFT program or customer due diligence policy during the tested period, or created or edited an AML/CFT training program, cannot prepare or review the workpapers of the internal audit engagement that tests that program, issue its report or sign its approvals. See [Internal audit](docs-internal-audit.html). More on the queue itself is in [Approvals and delegation of authority](docs-approvals.html). ## The internal audit wall The internal audit group is structurally separated as well as permission-gated. Audit titles, metadata and rationale are redacted at the source before they can reach audit rows, notifications, email or chat, so downstream systems are clean by construction. Exports produced by someone without audit rights include audit events as verifiable stubs rather than content. The existence of audit records is visible, but their content is not. That distinction is deliberate, because hiding existence would break the integrity of the record. ## Examiner access An owner grants an examiner a session that is time-boxed, limited by framework, finding and date range, revocable, read-only apart from a closed set of fieldwork actions, and optionally pinned to an IP range. The examiner sees a persistent banner naming their scope and a countdown to expiry, and every grant and revocation is audited. Within the grant, an examiner can open the control catalogue with its tests and attestations, documents, findings, and record links and search, and each shows only what the grant covers. A grant that names no framework shows no controls. Internal notes are hidden. Whole areas refuse examiner access entirely as management work product. Those areas are board governance and minutes, the live decision register, and launch delta. Material from one regulator is never visible in another's session. ## Notes and limits - The examiner role cannot be granted through your identity provider or an access group. It is reserved for the time-boxed grant, so a directory misconfiguration can never hand a regulator standing access. - Guardrails prevent locking yourself out. System roles cannot be deleted, the examiner permission set is locked, and you cannot strip settings access from your own role or from the last role that holds it. - Every role and permission change is written to the audit trail, and you can export access-control evidence for an exam binder. See [Audit trail and exports](docs-audit-trail.html). --- # Set up your team & SSO Section: Get started · Updated: 2026-10-07 · https://zovos.ai/docs-team-setup.html Team administration lives on the **Team and roles** screen, listed as **Team** in the Administration group of the sidebar. This guide is for the owner setting up access. It covers bringing teammates in, deciding what they can do, connecting single sign-on, and producing the access evidence an examiner will ask for. For what each role means, read [Roles and permissions](docs-roles-permissions.html). ## How access works Zovos signs people in through your institution's identity provider using single sign-on. There is no Zovos-specific password, which means your existing joiner, mover and leaver process stays the control of record. When someone leaves your directory, they lose the workspace with everything else. There are two supported ways for a person to arrive in your workspace, and one separate path for regulators. ## Invite a teammate On **Team and roles**, choose **Invite member**. You provide an email address and an initial role. You can also add a job title and job families, either one by one or from a preset. Then choose **Send invitation**. The invitee receives an invitation email and appears in the member list as **Invite pending**. That email is sent by WorkOS, our identity partner, from its own sending domain rather than from a Zovos address. Tell your mail team before you start, so the first invitations do not sit in quarantine. Their access turns on when they sign in for the first time. That sign-in is what accepts the invitation, and it cannot be done for them from the admin screen. A pending row carries **Re-invite** and **Cancel** actions and nothing else. Every system role except Examiner, including Risk Approver, comes with a directory mapping, so you can invite into it straight away. A custom role you create has no mapping, and an invitation into it is refused until an owner adds one on the **Access & SSO** tab in Settings. Get a second approver signed in early. Maker-checker means the person who submits a decision cannot approve it, and critical decisions need two distinct signers, so a workspace with one signed-in person cannot complete them. An invitation is not enough. The second person has to sign in themselves. ## Members provisioned by your directory Directory synchronization is enabled with us during onboarding. There is no self-serve switch for it in the product. Once it is on, membership and roles flow from your identity provider instead. You add the person to the directory group, or assign the role directly in your provider. They are then provisioned into Zovos on the next sync and sign in with your organization's normal SSO button. No separate invitation is involved. A directory-managed member's row shows **Role from your identity provider** in place of the role editor, because their role is resolved from your directory at every sign-in. Change it in your provider, not here. An unmapped directory group is refused rather than defaulted to a role, so a brand-new person who cannot sign in usually needs a group or role assignment on your side. ## Assign and change roles For members who are not directory-managed, edit the roles on the member row. A member can hold several roles and access groups, within the combination rules that [Roles and permissions](docs-roles-permissions.html) describes. The change takes effect on the member's next request and is written to the audit trail with your name against it. Each row also carries lifecycle actions: - **Suspend.** Access is turned off and membership is retained. Use this for leave or an investigation. - **Offboard.** This is the departure state, and it keeps the historical record intact. - **Reactivate.** This restores a suspended member. Two guards keep the workspace from being emptied by accident. You cannot suspend yourself. The product also refuses to suspend, offboard or demote the last active member who holds settings access, including through a role change, so there is always somebody left who can administer the workspace. You also cannot remove settings access from your own role or from the last role that holds it. ## Set job families and titles Job families say what a person does, and they personalize the workspace for that person. They order the sidebar, choose the dashboard panels, and give a business-line owner a My work home. They never grant a permission and never change the price. [Roles and permissions](docs-roles-permissions.html) lists the families and presets and explains exactly what they change. Each member row on **Team and roles** shows the person's title and job families beside their role. Choose **Families** on the row to edit them. You can pick several families, start from a preset such as Chief risk officer or Director, and set a job title. Editing families needs the permission to manage the team, which the Owner role holds. Every change is written to the audit trail. Settings also lists each member's families, read-only, on the **Access & SSO** tab. If directory synchronization is on, an owner can map directory groups to access groups on the Directory Sync panel under Integrations in Settings, and a group's job families come with it. When a person joins a mapped directory group, they receive the access group. When they leave it, they lose the group and every role and family it granted. Families set on the person directly stay until you edit them on the Team screen. ## Add an external examiner or auditor Regulators are not invited as teammates. An owner grants an examiner a time-boxed, scope-limited session for a named examination, read-only apart from a few fieldwork actions, and the examiner role cannot be handed out through single sign-on or directory sync. The examination workflow is covered in [Exam management and audit readiness](docs-exam-management.html). An outsourced internal-audit firm or an independent AML/CFT tester is different. Give that firm's staff a custom role built from the **External auditor** starting point, which [Roles and permissions](docs-roles-permissions.html) describes. ## Access reviews and evidence The Team and roles screen carries a periodic access review, so recertification is a recorded exercise rather than a spreadsheet emailed around the compliance team. You can also export access-control evidence as CSV or PDF straight into an exam binder. The export covers the member list, roles, statuses and the review record. Every membership, role and status change is in the append-only [audit trail](docs-audit-trail.html), which is the artifact an examiner asks for when they ask how you control access. ## Notes and limits - Connecting your identity provider is done outside the product, on the one-time setup link we send during onboarding, and so is turning on directory synchronization. Mapping your directory groups and role slugs to Zovos roles is different. That is an owner-editable panel on the **Access & SSO** tab in Settings, and you change it yourself whenever your directory changes. See [Onboarding your institution](docs-onboarding.html). - Everyone signs in at the same address, https://app.zovos.ai/login, with one SSO button and no institution picker. A session ends after 30 minutes without activity, and in any case at the end of its lifetime. The lifetime is eight hours unless an owner sets it between one and twelve hours under **Session lifetime** on the **Access & SSO** tab, and a change applies from the next sign-in. An owner can end a member's sessions early from the **Sessions** panel on their row on the Team screen. No separate Zovos password exists to expire. - An owner can optionally restrict the workspace to a list of your own IP ranges, per tenant, IPv4 or IPv6. It is maker-checker gated. A change is staged and only takes force once a second approver signs it off. Examiner sessions are exempt, because regulators come from networks you do not control. Take the lockout warning seriously. If the allowlist excludes your own address, recovering it needs Zovos support. - A member who has been invited but has never signed in cannot approve anything, and the product will not let an administrator mark them active. - Seat usage in settings is drawn live from your active members and shown beside your contracted number. It is informational. The figure is there for your own planning and for a renewal conversation, and the product does not enforce it as a cap. --- # Glossary Section: Get started · Updated: 2026-10-03 · https://zovos.ai/docs-glossary.html Zovos uses the vocabulary of bank and credit union compliance, plus a few terms specific to how the product records decisions. These are the meanings inside the product. If a term in the app is not explained here, tell [support](support.html) and we will add it. ## A to C - **Absence testing.** This means deterministically searching your own records for conduct that should not exist and stating which population was searched, rather than claiming nothing ever happened. - **Access group.** An access group is a named bundle of roles, job families and a scope that an owner gives to a set of people, directly or from a directory group. Leaving the group removes what it granted. Like a job family, an access group never changes the price. - **Agent run.** An agent run is one immutable record of one AI call. It holds the agent, target, model, prompt template version, hashed inputs, tokens and confidence. - **AML/CFT Officer.** The AML/CFT Officer is the person designated to run the anti-money laundering and countering the financing of terrorism program. Regulations and citations that name the role the BSA officer keep that wording. - **Append-only.** An append-only record has no edit or delete affordance. Corrections are new entries. - **Attestation.** An attestation is a named person signing that a policy or control is in place, with a date and rationale. A certification, by contrast, is a management sub-certification round. - **Auditee.** An auditee is anyone whose work internal audit examines. The Owner, Compliance Analyst and Risk Approver roles are auditees, so in-progress internal-audit work is hidden from them. - **Authority Engine.** This is the check on whether the person deciding actually held delegated authority to decide. It runs off, in monitor (dry run), or in enforce mode. - **CAE.** The chief audit executive leads internal audit and reports to the board or its audit committee. At a credit union that reporting line runs to the supervisory committee. - **CAP.** A corrective action plan holds the remediation steps, owner and target date attached to a finding. - **Challenge record.** This is the attributed, append-only capture of board questions, concerns, challenges and directions. A direction opens a finding. - **Citation.** A citation is one regulatory clause, with its code, section, title, version and effective date. - **Claim lineage.** This is the trace from a figure in a board pack back to the records behind it. On re-verification each claim reads unchanged, drifted, or unknown. - **Corpus.** The corpus is the shipped, read-only regulatory library that citations are drawn from. - **Coverage graph.** The coverage graph visualizes the linkage between obligations, policies, controls and evidence, and shows where it is thin. - **Credit risk review.** Credit risk review, often called loan review, is the independent check of how the institution rates its loans. In Zovos it samples a locked loan universe, and a reviewer cannot review a credit they originated or approved. - **CRO.** The chief risk officer leads the second-line risk function at a community bank or credit union and often holds the Risk Approver role in Zovos. - **Crosswalk.** A crosswalk is the linkage between a citation and the controls and policies that answer it. - **CSI.** Confidential supervisory information. One regulator's material never appears in another regulator's session. - **CUEC.** A complementary user entity control is a control *you* must operate for a vendor's SOC opinion to hold for you. ## D to G - **DDQ.** A due-diligence questionnaire can be outbound to a vendor or inbound from a customer. - **Delegation of Authority matrix.** This owner-editable table maps object type and severity to the required approver roles and number of signers. - **Design vs operating effectiveness.** Design asks whether the control is built right. Operating asks whether it actually works, and it is derived from testing. - **Display ID.** The display ID is the human-facing business key on every record. It is stable enough to cite in a memo or an examiner response. - **Effective challenge.** Effective challenge is documented second-line push-back. Open challenges block attestation of a self-assessment. - **EUC.** End-user computing refers to a spreadsheet consequential enough to be governed as a model. - **Examiner grant.** An examiner grant is the time-boxed, scope-limited session an owner issues to a regulator for one examination. It can be revoked at any time, and it is the only way the examiner role is ever held. - **Finding.** A finding is the tracked issue, whatever its source. The source can be an examiner matter, an internal audit issue, a self-identified issue, or a board direction. - **First-day letter.** This is the examiner's opening document request list, also called the PBC list. Zovos ingests it and maps it to your evidence. - **Five pillars.** These are the statutory AML/CFT program elements under the Bank Secrecy Act. They are internal controls, independent testing, a designated officer, training, and risk-based customer due diligence. - **Framework enrollment.** Enrollment marks which of the catalogued frameworks your institution is examined against, and it scopes everything downstream. - **Fraud case log.** The fraud case log is the oversight record of fraud cases escalated for a SAR decision. One member recommends whether to file and a different member decides. It records the decision, its rationale and the dates, and never the SAR itself. - **Gap.** A gap is an obligation with no adequate policy or control coverage. AI-generated gaps stay proposed until a person accepts them. ## H to O - **Hide, never disable.** An action or navigation item you lack permission for is absent from the screen rather than greyed out. - **Honest empty state.** A panel with nothing behind it renders nothing rather than a fabricated zero. - **Independence wall.** The independence wall separates internal audit from the work it audits. Audit content is redacted at the source for anyone outside the internal audit side, and a role on that side cannot hold first-line or second-line operate or approve permissions. - **Inherent vs residual risk.** Inherent risk is likelihood times impact before controls. Residual risk is what remains after control effectiveness. Both are computed and never typed. - **ISO.** The information security officer runs the institution's information security program. In Zovos the ISO usually holds the Cybersecurity job family. - **Job family.** A job family describes what a person does, such as compliance, AML/CFT or internal audit. A person can hold several. Families personalize the sidebar, the dashboard and the home page, and they never grant a permission or change the price. - **KRI.** A key risk indicator is a measured value with thresholds and a direction. Its red, amber or green status is derived rather than declared. - **LAR.** The HMDA loan and application register is validated for data integrity against the FFIEC layout. Zovos is not a filing tool. - **Launch delta.** Launch delta is the computed obligation difference for a product you are considering. Each obligation shows as newly applicable, already covered, or needing amendment. - **Lines of defense.** The first line is the business, meaning the executives and business-line owners who take and manage risk. The second line is the independent risk management and compliance functions that set standards and challenge the first line. The third line is internal audit, which tests both and reports to the board. Every job family in Zovos sits on one of the three lines except two. The Board family oversees all three, and Platform administration sits outside them. - **Loan universe.** A loan universe is the loan population a credit review samples from, as of one date. It is imported or entered as a draft and then locked, after which it cannot change. It holds loan numbers and descriptions, and no borrower names. - **Maker-checker.** This is the rule that the approver may not be the submitter. Critical items need two distinct signers. - **Material vs editorial change.** A material policy change invalidates sign-off and forces re-attestation. An editorial one does not, and it needs a documented justification. - **Monitoring activity, review, workpaper.** A monitoring activity is the recurring test. A review is one execution of it, and a workpaper is the documented evidence that execution produces. - **MRA and MRIA.** These stand for matter requiring attention and matter requiring immediate attention. They are the examiner-issued findings that carry the most weight. - **Over-relied control.** This is a control so many obligations depend on that it has become a single point of failure. ## P to R - **Partner program.** A partner program is a fintech or banking-as-a-service program under sponsor-bank oversight. It is governed through gates that are earned rather than set. - **Proof ledger.** The proof ledger is the per-tenant, append-only hash chain that seals governance events as they happen. - **Proof pack.** A proof pack is an export a third party can verify offline with the bundled verifier, without trusting us or the export. - **RCSA.** A risk and control self-assessment is run per business unit per cycle and closed by attestation. - **Review exception.** A review exception is a deficiency found in a credit review, with a corrective action, a responsible person and a target date. It is resolved only by someone independent of the credit, or promoted into a finding. - **Risk appetite.** Risk appetite is the maximum residual risk the board accepts, by category. A risk above the band is a breach requiring a decision. - **Root cause.** A root cause is required before a High/Critical or examiner-source finding can close. Every finding also needs remediation evidence. Root cause is the basis of the repeat-finding analysis examiners look for. ## S to Z - **Scope.** A scope limits an access group's roles to the person's own records or to chosen business units. Every screen that does not accept a scoped member is closed to them. - **Sealed artifact.** A sealed artifact is a generated document whose content hash is recorded in the proof ledger. Board packs, minutes, workpapers and exam binders are all sealed artifacts. - **Shadow AI.** Shadow AI is AI in use across the institution that never went through intake. The AI systems registry exists to surface it. - **Shadow vendor.** A shadow vendor is a payee appearing in accounts-payable spend with no record in the vendor inventory. - **Sole-operator override.** When nobody else in the workspace holds the required permission, a decision proceeds with a mandatory justification and is tagged as such in the audit trail. - **Supervisory Committee.** At a credit union the supervisory committee oversees internal audit and the annual audit, much as an audit committee does at a community bank. When your institution profile records a credit union charter, Zovos labels the Board job family Supervisory Committee. - **Systemic cluster.** A systemic cluster is a complaint pattern by category and regulation at or above a threshold. It is the signal a consumer regulator would act on. - **Time machine.** The time machine reconstructs your program as it stood on a past date and labels which elements are exact and which are approximated. - **UDAAP.** This stands for unfair, deceptive, or abusive acts or practices. It is the lens applied to marketing reviews and complaint analysis. - **Vendor tier.** The vendor tier is the band derived from data sensitivity, system access and spend. It sets how much diligence a vendor needs. --- # Dashboard & daily triage Section: Everyday work · Updated: 2026-10-07 · https://zovos.ai/docs-dashboard-triage.html The Dashboard is the first screen most people on the compliance and risk team see when they sign in. It answers one question, which is what needs you today. Every number on it drills through to the register behind it. Directors are the exception. A board principal lands on the Board portal instead, which is built for oversight instead of daily work. A business-line owner in the first line opens on their own work, described under My work below. ## What the dashboard shows The headline counts the items waiting on you. The panels below break that count down: - **Overdue & at-risk.** This panel lists findings that are overdue or due soon, policies past their review date, risks past review, and records due for a disposition decision. - **Approvals queue.** This panel previews the governed decisions pending across the workspace. It is capped, and it is not filtered to the ones you personally can sign. The count of items actually awaiting your sign-off lives on the topbar pill. - **Findings tracker.** This panel shows the open issue register at a glance, with severity and aging. - **Framework health.** This panel shows coverage for each enrolled framework, with its gap count. - **Needs your attention.** This panel lists items the platform could not resolve without a person. - **Recent agent runs.** This panel shows what the AI agents produced and what is still awaiting review. - **Audit readiness.** This panel shows how prepared you are for the next examination. - **Regulatory updates.** This panel lists new rules and guidance, ranked by likely impact on you. - **Recent activity.** This panel shows the latest activity on records you are allowed to open. It leaves out internal-audit work, internal-marked entries and security or administrative events, so it is not the audit trail. The full record is on the **Audit trail** screen. Panels are gated by role on the server. If you hold job families, your families choose which panels you get, and your role still caps that set. A panel you do not get is omitted instead of shown as a zero. That pattern holds across the product. We hide what you are not entitled to see instead of greying it out, and we never invent a number to fill a space. ### My work **My work** is the first group in the sidebar. It holds the Dashboard, Tasks & plans, Findings, Audit requests, Audit responses, the Obligations calendar, Drafts, Documents and Agent runs, so the screens you open every day sit together. The Dashboard has a My work view for the first line. If your only job family is Business-line owner, the Dashboard opens on your own work instead of the standard panels. It lists your open tasks with the soonest due first, the policy attestations and control certifications waiting on you, the vendors whose relationship you own, and the risks, key risk indicators, self-assessments and risk exceptions you own. You can attest to a policy or certify your controls from the row itself. If you hold Business-line owner alongside another family, the same list sits above the standard panels. A member whose access is limited to their own records or to chosen business units also opens on My work. [Roles & permissions](docs-roles-permissions.html) covers job families and scope. ## Working the queue Daily triage runs top to bottom. Start with **Overdue & at-risk**, because those items have dates an examiner can check. Anything overdue either needs a new owner, a revised due date with a documented reason, or a corrective action plan that is actually moving. Next, clear the **Approvals queue**. Approvals are the bottleneck in most compliance programs. A policy that has been sitting in pending approval for six weeks is a finding waiting to happen. See [Approvals & delegation of authority](docs-approvals.html) for how routing and sign-off work. Then work **Needs your attention** and **Recent agent runs**. Agent output is a proposal and never a decision. High-confidence results are auto-cleared for review, mid-range results wait for you, and low-confidence results are flagged. Auto-cleared is not approved. [How AI works in Zovos](docs-ai-in-zovos.html) covers the confidence bands and the accept, dispute, and escalate actions. Finally, scan **Regulatory updates**. Most items are a two-minute applicability call. The ones that apply to you become work in the [compliance library](docs-frameworks.html). Assigned work that is not a finding lives in **Tasks & plans**, in the My work group of the sidebar. Task due dates ride the same date machinery as everything else, so they reach the obligations calendar and your reminders instead of sitting in a separate list. See [Tasks & action plans](docs-tasks-action-plans.html). ## Working a register The big registers share a set of tools, so learning them once is enough. Those registers are findings, the risk register, third parties, the control catalogue and policies. - **Saved views.** The filters, sort order and hidden columns you use on a register save as a named view, with update, delete and make-default. Views are yours, not the workspace's. - **Bulk actions.** Select rows and apply one change to all of them. A bulk action runs as separate changes, each bound by that record's own lifecycle rules, so a partial outcome is normal. Every record that could not take the change is listed back to you by identifier with the reason it was refused. Nothing is rounded up into a success it was not. - **Spreadsheet import.** The importer accepts CSV or XLSX and offers a dry-run validation pass first. It reports errors row by row without abandoning the rest of the file. It matches on the register's natural key, so a re-import updates records instead of duplicating them. - **Import-ready CSV export.** This is a server-side, audit-logged export of the whole register in the exact column shape the importer accepts. It is distinct from the quick CSV in the toolbar, which saves only the rows currently on screen. - **Custom fields.** Your workspace can define its own fields for risks, findings, third parties, policies and controls in Settings, and they then appear on the record alongside ours. ## Notifications and the approvals pill The topbar carries a notification bell and an approvals pill. The pill counts only the items *you* can actually decide. It does not badge you for work sitting with someone else. Notifications are toned by urgency, and the routing matrix in Settings decides whether an event also reaches you by email digest, Slack, or Microsoft Teams. The bell shows the notifications addressed to you, plus workspace-wide notifications about records you are allowed to see. A board meeting notice, for example, reaches only the members who sit on that committee. A member whose access is limited to their own records or to chosen business units sees only the notifications addressed to them. Your workspace owner sets that matrix, but the volume of mail is yours. Each person chooses, for each class of notification, whether it emails them immediately, waits for the daily digest, or sends no email at all. Email delivery is not switched on yet, so those choices take effect when it is. The same panel shows when the reminder sweep that raises most of those notifications last ran, which is the first thing to check when a reminder you expected never arrived. ## Getting around quickly The command palette opens with Command-K or Control-K from any screen and jumps by name to any area you are entitled to see. Type two characters or more and it also searches your records. It covers findings, risks, controls, third parties, policies, documents, complaints, regulatory changes, examinations and decisions, and it lists the matches under the areas in the same keyboard list. Paste a record identifier and that record is the first thing selected. Examiner sessions get the navigation half only. Compliance teams of one to three people live in this palette, and it is the fastest way to move between the risk register, findings, and the policy library without touching the sidebar. New workspaces also get a **Getting started** checklist on the Dashboard. It asks you to enroll your frameworks, import your data, run a gap analysis, and triage your first finding. It tracks real workspace state and hides itself once you are set up. ## The obligations calendar The Dashboard shows what is late. The **Obligations calendar** shows what is coming. Its first tab aggregates the dates your registers already hold into one view. Those dates cover control tests and owner attestations, policy and risk reviews, vendor renewals, exception expiries, examination requests, evidence freshness, continuity exercises, complaint response clocks, partner-program dates, board meetings and open tasks. You can download it as an ICS file, or generate a personal subscription URL in Settings, so the compliance calendar can live in Outlook or Google Calendar next to everything else on your week. The second tab, **Statutory obligations**, holds the deadlines the rules fix on the wall calendar instead of deriving from a cadence. Examples are the HMDA loan application register submission, the currency date on your CRA public file, the Call Report cycle, and the OFAC blocked-property report. Three things happen here that the aggregated view cannot do. You scope an obligation to your institution, so one that does not apply is marked not applicable instead of nagging forever. You move an institution-set date onto your real board cycle. And you record a filing, after which the obligation rolls forward on its own schedule. Rows read overdue, due soon, scheduled, not applicable, or complete. Anyone who can see the Dashboard can read the register. Changing it is an owner permission, so a read-only role sees the dates and none of the controls. Dates are institution-local. An owner sets your timezone in Settings, and every date-only deadline in the product then means the end of that day in that zone. That zone also sets the hour the daily digest goes out. ## Notes and limits The Dashboard is a view over the registers, not a separate report. Every tile is computed from live records, which means a number is only as current as the underlying work. It also means a fresh workspace looks empty on purpose. Until you enroll frameworks and bring in your policies and controls, there is nothing honest to show. Panel composition is role-based and is not currently customizable per person. If your team wants a panel you do not have, or a tile that would help your board reporting, [tell us](support.html). The Dashboard is one of the areas we revise most often. --- # Findings & remediation Section: Everyday work · Updated: 2026-10-07 · https://zovos.ai/docs-findings.html The **Findings tracker** is your issue register. It is the single place where examiner matters, internal audit issues, self-identified problems, and board directives are tracked to closure. It is the register examiners open first, because the repeat-finding question is the one they always ask. This article walks a finding from creation to closure. ## Where findings come from A finding records its source, and the source matters to how it is read later: - **Examiner MRIA.** This is a matter requiring immediate attention. - **Examiner MRA.** This is a matter requiring attention. - **Examiner violation** and **Examiner observation.** These cover the rest of the exam report. - **Internal audit.** Your internal audit function issued the finding. - **Self-identified.** The first or second line found the problem before anyone else did. - **Board directive.** This is a direction recorded in the board or committee challenge record, which creates the finding automatically. An examiner-sourced finding also carries the supervisory record behind it. That is the basis the examiner communicated, either **Unsafe or unsound practice** or **Violation of law**, and the date the communication was issued. A violation of law must name the law cited. Under the OCC and FDIC rule on matters requiring attention that takes effect on November 2, 2026, an MRA or MRIA issued on or after that date must record its basis. The register can filter findings issued before that date or on and after it. Findings are also promoted into the register from elsewhere in the product. The source can be a failed monitoring test, an absence-testing exception, a HMDA edit cluster, a mock-exam result, an accepted gap, a continuity-exercise result, a model-bias or fair-lending review, or a partner-program indicator that has breached its threshold. Promotion is an explicit human action. Where the platform suggests a severity, as it does on a breached program indicator, the person promoting can override it. ## Triage Open a finding and set the four things that drive everything downstream. They are **owner**, **severity** (critical, high, medium, or low), **due date**, and **root cause**. When the owner you type matches exactly one member of your team, the finding is linked to that person. That link is what their My work view and an own-records access scope read. A name that is not on your roster is still accepted as text. The list view and the Kanban board both show an aging badge of on track, due soon, or overdue. The badge is computed from the due date, so nothing quietly ages past its date. Root cause is not optional paperwork, but what closure requires depends on the source. An **Examiner observation** closes on the independent sign-off and its rationale alone, with no evidence, plan or root cause required. Otherwise, a finding cannot close without remediation evidence. High/Critical and examiner-source findings also need a root cause, and an examiner MRIA, MRA or violation also needs a corrective action plan. Root cause feeds the trends panel, which groups opened and closed volumes, the aging distribution, and repeat findings by root cause. That last chart is the early warning you want before an examiner builds it for you. Two further blocks on the record matter to a consumer-compliance examination. **Consumer harm and restitution** records how much redress is owed, to how many consumers, over what lookback period, and where it stands. The status is one of not assessed, assessed, redress in progress, redress paid, or no redress required. A figure you have not recorded shows as a dash instead of a zero, because "not quantified" and "quantified at nothing" are different answers and the second has to be claimed deliberately. This is the evidence an examiner reads when deciding whether a self-identified problem earns credit. **Custom fields** your workspace has defined for findings sit on the same record, so the attributes your program tracks do not end up in a spreadsheet next to the tool. ## The corrective action plan Remediation is tracked as a corrective action plan, which is a set of steps with owners and target dates. Completing a step needs evidence attached, or an explicit evidence waiver with a reason. The waiver exists because real remediation sometimes cannot produce an artifact. Even so, it is recorded as a decision and never as a silent gap. If your team works remediation in Jira, ServiceNow, Azure DevOps, GitHub, or GitLab, a finding can be pushed to the tracker and re-synced, so the engineers do not have to live in a compliance tool. See [Connecting integrations](docs-integrations.html). Discussion about the finding stays on the finding, in a comment thread with an @mention typeahead. Threads are append-only like the rest of the record, so there is no edit and no delete. A mention resolves against your live team roster, so you cannot address someone the workspace does not actually have. Risks carry the same thread. ## Statuses and the Kanban board Findings move through **Open**, **In progress**, **Remediation**, **Awaiting review**, **Approved** and **Closed**, with **Reopened** for anything that comes back. Both a list view and a Kanban board are available, and you can drag a card between most columns. The list and each Kanban column load 50 findings at a time, with **Load more** for the next page. You can filter the register by text, overdue only, business unit, and the supervisory issue date. A member whose access is limited to their own records or to chosen business units sees only the findings they own or that belong to those units, and the trends count the same set. A banner on the screen says so. They can read those findings and acknowledge them from Slack, but cannot edit their details. **Closed is not a drop target.** Closure is a governed decision, and you cannot make it by dragging a card. When remediation is complete you submit the finding for independent closure, and it appears in the approvals queue for someone else to sign. The list view carries the shared register tools described in [Dashboard & daily triage](docs-dashboard-triage.html). They are saved views, column control, bulk actions, spreadsheet import and the audited import-ready export. You can bulk-assign an owner, bulk-change status, or submit several findings for independent closure under one rationale. Bulk status changes deliberately exclude the closing statuses, because closure needs a sign-off block a bulk form cannot collect. ## Closure and segregation of duties Closing a finding requires an approver, a date, and a rationale, and the platform enforces who that approver can be. The person who signs the closure must not be the finding's owner, its remediation owner, or the person who last changed its status. This is the same maker-checker rule that governs policy approval and risk acceptance, described in [Approvals & delegation of authority](docs-approvals.html). The closure decision, its rationale, and the identity of the signer are written to the append-only [audit trail](docs-audit-trail.html) and sealed into the proof ledger. A closed finding can be reopened, which is recorded as a new event instead of an edit to the old one. ## What an examiner sees Findings are one of the areas an examiner can be granted scoped, time-boxed read access to. In that mode they see the finding, its owner, its dates, its corrective action plan and its evidence. They do not see the finding's discussion thread or any activity marked internal. Nothing in the register can be edited from an examiner session. ## Notes and limits Findings are an oversight register, not a project management tool. There is no resource planning, no dependency graph, and no time tracking. If your remediation needs those, push the work to your ticketing system and let the finding hold the governance record. Severity is set by a person. The product does not derive it. The one place severity is computed for you is in risk exceptions, where it comes from the linked risk's residual band so a requester cannot claim a softer rating. --- # Tasks & action plans Section: Everyday work · Updated: 2026-10-07 · https://zovos.ai/docs-tasks-action-plans.html Not every piece of compliance work is a finding. **Tasks & plans**, in the My work group of the sidebar, is where assigned, dated work lives. These are the things someone has to do by a date. They can come out of a regulatory change, a calendar obligation, an assessment answer, a consent order, a finding, an exam request, a risk treatment, the failed procedures of a mock exam, a security incident, or a conversation. It uses the same permissions as the [Findings tracker](docs-findings.html), so the people who work remediation already have it. ## What a task holds A task is deliberately small. It holds an identifier, a title, an owner, an optional due date, and where it came from. The owner field offers your team roster and links the task to the member you pick. A name that is not on the roster is still accepted as text. A member whose access is limited to their own records or to chosen business units sees only the tasks they own, with a banner saying so, and cannot move a task out of that scope. Status runs **Open**, **In progress**, **Complete** and **Cancelled**, with reopening available from either end state. The moves are enforced on the server and not just hidden in the interface, so a task cannot be walked through a path the lifecycle does not allow. A task that came from somewhere shows its source on the row. That matters more than it sounds. Months later, the record answers "why was this being done" and you do not have to find whoever set it up. ## Action plans An action plan groups ordered tasks under one owner and rolls their completion up as a percentage. It is the pattern the corrective action plan on a finding already uses, generalized so it can hang off anything. Use a plan when the work has a shape, meaning several steps in order that together answer one obligation. Use standalone tasks when it does not. Both live in the same register and both feed the same dates. ## From a regulatory change to a plan The most common way a plan starts is from **Reg updates**. Once you have triaged an item as one that matters to you, you create a plan from it. The plan gets an owner and one task per line of work the change opens. The reg-change item then carries its plan identifier and a progress rollup, and links straight through to the tasks. That closes a gap examiners notice. A triage queue proves you saw the rule. A plan with completed tasks against it proves you did something about it. See [Frameworks & regulatory updates](docs-frameworks.html) for the triage half. ## Where task dates show up Task due dates ride the same date machinery as every other deadline in the product, which means they are not stranded in this screen. They appear on the obligations calendar alongside control tests and policy reviews, and they raise the same reminders, in your institution's timezone. See [Dashboard & daily triage](docs-dashboard-triage.html) for the calendar and the notification settings. ## Notes and limits This is a work register, not a project management tool. There are no dependencies between tasks beyond the order in a plan, no effort estimates, and no time tracking. If your remediation genuinely needs those, run it in your own tracker and let Zovos hold the governance record. The ticketing connectors in [Connecting integrations](docs-integrations.html) exist for exactly that. Tasks are not approvals. Completing one records that a person did the work, but it does not sign anything off. Where a governed decision is required, the work still routes through [Approvals & delegation of authority](docs-approvals.html). --- # Approvals & delegation of authority Section: Everyday work · Updated: 2026-10-07 · https://zovos.ai/docs-approvals.html Almost nothing important in Zovos takes effect because someone clicked save. Policies, finding closures, risk acceptances, vendor onboardings, monitoring workpapers, audit reports, board minutes and model approvals all become authoritative only when a second person signs them. This article explains how that routing works and what you will see when a decision reaches you. ## The approvals drawer Every governed decision lands in one queue, opened from the topbar pill or from the Dashboard's approvals panel. The drawer is titled **Approvals queue**. The items awaiting your sign-off come first, counted in the header. Below them, under **In the queue**, sit the other pending items you are allowed to see but cannot sign. Each of those says why, for example that you submitted it or that the delegation-of-authority matrix routes it to another role. The topbar pill counts only the first group. It loads a page at a time and says so as soon as a page comes back full, with a control to widen the window, so a long queue is never quietly truncated. Each item carries: - A **change preview** shows the specific diff you are signing, not a summary of it. - An effect sentence in plain language makes the button say what will happen. A policy reads **Approve & publish**. A finding closure reads **Approve closure**. A vendor reads **Approve & onboard**. A monitoring review reads **Sign off workpaper**. - A return path that is not a rejection lets you send the item back. It is usually **Request changes**, which sends the item back to its author with your reasons. - A **rationale field, which is required**. Every affirmative and every return is recorded with the words you typed. - Where the record has a screen of its own, an **Open** link takes you to it. For a board meeting, it opens that meeting's detail. If you submitted the item yourself, the drawer says so and gives you no decision buttons. You submitted it, so it is not yours to approve. ## How routing is decided Routing comes from the **delegation-of-authority matrix**, which lives in Governance settings and is editable by your workspace owner. Each cell in the matrix pairs an object type with a severity and names two things. The first is which roles may sign, and the second is how many distinct signers are required. The defaults follow the way a bank or credit union already delegates authority: - **Critical items require two distinct signers.** This four-eyes rule draws the signers from your owner and risk-approver roles. - **High, medium and low items require one signer.** A high item goes to the owner role by default, and a medium or low item to the owner or risk-approver role. - **Policies route by document tier.** A policy goes to the board. A standard, procedure or guideline goes to a single management signer from the owner role. - **The internal audit plan always goes to the audit committee.** That holds regardless of how the rest of the matrix is set. Changing the matrix is itself an audited change, and each cell must name at least one role and a signer count before it can be saved. ## When you are the only person who can sign Small teams hit a real problem. Sometimes nobody else in the institution holds the permission a decision requires. Zovos does not block the work or pretend a second person existed. It offers an audited **sole-operator override** instead. The drawer asks for a justification in addition to the rationale, the decision proceeds, and the audit row is tagged as a sole-operator action so an examiner sees exactly what happened and why. ## The Authority Engine Above the matrix sits the Authority Engine, which checks at decision time whether the person deciding was actually delegated that authority. That check includes delegations with an expiry. It runs in one of three modes, which are **Off**, **Monitor**, and **Enforce**. Monitor is the default. Every decision is checked and recorded but never blocked, so you can read the authority exceptions report for a few cycles before turning enforcement on. In Enforce mode a decision outside someone's delegation is stamped and not applied, unless the signer supplies a justification. Beside the clean result of within authority, the authority exceptions report records five outcomes: - **Escalated.** The decision exceeded the signer's authority, and the row names the nearest role that does cover it. - **Lapsed authority.** A delegation existed, but it had expired. - **Blocked · no grant.** No covering delegation existed at all. - **Break-glass override.** The signer supplied a justification and the decision proceeded. It is filed as an authority exception for ratification afterwards. It answers the same community-bank reality as the sole-operator override, and it is recorded just as visibly. - **Monitor-flagged.** This is what Monitor mode records. The decision proceeded, and the row says what enforcement would have done instead. ## What happens after you sign An affirmative decision does three things at once. It applies the change. It writes the decision, signer and rationale to the [audit trail](docs-audit-trail.html). It also appends a hash-chained row to the proof ledger. That ledger row is what lets you prove, months later, that the approval existed in that form on that date. ## Notes and limits Approvals are deliberately not automatable. Zovos publishes a Zapier app and supports Make and n8n, but no governance decision is exposed to them. You can automate opening a finding, but you cannot automate signing one. Approvals are never assignable to a named individual. Sometimes a decision is stuck because the role it is waiting on cannot act. In that case you can **Reassign** it from the drawer. That retags the waiting signer slot with a different required *role*, and it requires a rationale that goes on the record. The picker offers only live roles that hold the permission the decision needs, and never the reserved examiner role, so a reassignment cannot park an item on a role with no authority to sign it. Reassigning is an administrative act gated on settings permissions instead of on the permission to approve. That keeps unsticking a queue and deciding an item in separate hands. A reassignment you keep having to make is still a signal to fix the delegation-of-authority matrix in Governance settings, which is the record an examiner will read anyway. Roles and what each one can approve are covered in [Roles & permissions](docs-roles-permissions.html). --- # Audit trail & exports Section: Everyday work · Updated: 2026-10-07 · https://zovos.ai/docs-audit-trail.html The **Audit trail** is the complete, append-only record of every action taken in your workspace. It shows who did what, to which record, and when. It is read-only by construction. There is no edit affordance and no delete affordance anywhere in the product, and the underlying store grants no update or delete rights. Corrections are new entries, never rewrites. The store records every action, but the Audit trail screen and its exports show each reader only the rows their access allows. Internal-marked rows are hidden from directors and examiners. Fraud-case rows need the permission to read financial-crimes work, and rows about suspicious activity report decisions are not shown in the trail to anyone. A row that records a change to a link between two records appears only when you can open the record at one end, and the other end is shown only by its kind. ## What is recorded Every write is an event. Creating a finding, editing a policy, running an agent, granting examiner access, changing a role, approving anything and exporting anything each produce a row. The row holds the actor, the action, the object type and identifier, and a timestamp. Human and system actors are visually distinct, so an automated control test is never mistaken for a person's decision. Two categories of row are marked specially, because examiners ask about them: - **Sole operator.** The only person in the institution who held the required permission made the decision. The row carries the justification that was given at the time. - **Authority override.** The Authority Engine flagged the decision, and the row carries the outcome that was recorded. Both are explained in [Approvals & delegation of authority](docs-approvals.html). ## Filtering The trail is filterable by date range, actor, object type, action, and source IP or CIDR range. The IP filter matters more than it sounds. It is how you answer an access question about a specific session. It is also part of how examiner access is evidenced, since an examiner grant can be pinned to an IP range for its duration. ## Integrity verification An append-only claim is only worth what you can prove. Key events are sealed into a per-institution hash chain, with roots anchored and externally timestamped. Those events are approvals, risk acceptance decisions, attestations, policy releases, evidence attachment and exam artifacts. The **Integrity verification** panel on the Audit trail screen recomputes that whole chain on demand. Choose **Verify now** and the result is one of two things. Either the chain is verified, with the count of sealed events, or there is an integrity break with the exact sequence number where the chain first fails. There is no partial credit and no reassuring middle state. ## Proof packs A proof pack is an export a third party can verify without logging in to Zovos and without trusting us. It bundles the sealed artifacts, their manifest hashes, and a standalone verifier that runs offline. This is the artifact to hand an external auditor, a regulator, or a counterparty who asks you to prove that a document existed in a particular form on a particular date. Sealed artifacts include board packs, finalized minutes, monitoring workpapers, exam binders and absence-testing run manifests. Each records a SHA-256 content hash at the time it was sealed, so re-verification later tells you whether anything behind a claim has drifted. You do not have to open the zip to see what you delivered. Expand a built package in Settings and it shows its ordered item index and its sealed manifest in the product, so "prove exactly what was in that pack" is answerable without a download. ## Exports The Audit trail exports directly to **CSV** for spreadsheet work and **JSONL** for your SIEM. Beyond the trail itself, the product produces the register exports an examination tends to ask for: - Server-stamped **PDF** and **XLSX** exports cover the risk register, gap report, findings, loss events and program inventory. - Quick client-side CSVs are available from most register screens for ad hoc analysis. These save the rows currently on screen. - An **import-ready CSV** covers a whole register of risks, third parties, controls, policies or findings. It is streamed from the server and audit-logged, in the exact column shape our own importer accepts. This is the export to reach for when someone asks whether you can get your data out. - **Scheduled exports** run on a cadence you set. Each one is kept for you to download from Settings through a short-lived secure link, or dropped on your own SFTP server with a pinned host key. Email is configurable as a destination too, but Zovos does not send email today, so that leg stays inert until delivery is switched on. - A continuous audit-log feed goes to the SIEM forwarder you configure on the **Integrations** tab of **Settings**. It sends each new audit row to a generic HTTPS collector, Splunk HTTP Event Collector, or Microsoft Sentinel, so the record also lives in your own stack. Exports require the settings read permission. On a scheduled export, a failed delivery leg marks the whole run as an error and raises a delivery alert naming the leg that failed. Nothing degrades quietly to a partial success. ## Reading it during an examination In practice, three questions come up in almost every exam, and the trail answers all three. The first is who approved this and whether they were entitled to. The second is whether this record has been altered since it was signed. The third is what an examiner from another agency saw in their session. The audit rows answer the first, the integrity verification answers the second, and the scoped access log answers the third. ## Notes and limits The audit trail records actions in Zovos. It is not a general-purpose log of your bank's systems, and connecting a connector does not import that system's own audit history. Internal audit work is walled off. Outside the internal audit function, internal-audit rows are left out of the Audit trail and its exports entirely, so not even their existence shows. The board sees only approved or issued internal-audit artifacts, such as the approved audit plan, sent independence confirmations and issued reports, and never the workpapers, draft findings or fieldwork behind them. A proof pack exported by someone outside the audit function contains hash-only stubs for those entries, which still verify offline. That is by design. An auditee should not be able to read in-progress audit work through the audit trail. Retention of the trail and of your exports is covered in [Your data: exports, backups & retention](docs-data-handling.html). --- # Frameworks & regulatory updates Section: Compliance library · Updated: 2026-10-07 · https://zovos.ai/docs-frameworks.html The **Framework library**, opened from **Frameworks** in the Library group of the sidebar, is where you tell Zovos which regulations your institution is actually examined against. Everything downstream is scoped by what you enroll here, including coverage, gaps, agent mapping and the citation crosswalk. This article covers enrollment, the regulatory corpus behind it, and how incoming rule changes reach your desk. ## Enrolling frameworks Zovos ships with dozens of frameworks already indexed, grouped by category: consumer compliance, financial crime, prudential, cyber and technology, AI, audit and privacy, and payments. Each framework card shows a health donut, its citation count, and its open gap count. Choose **Add framework** to enroll one. Enrollment is the signal that you are mapped against that framework, and it puts the framework's obligations into your coverage picture. You can also set a framework out of scope, or unenroll it entirely. Out of scope is useful when a framework applies to part of your business but not the part you are assessing this cycle. Unenrolling is deliberately non-destructive. Mapping stops and proposed gaps retire, but accepted gaps and any remediation already in flight are kept. Removing a framework should never quietly delete evidence of work you did. For a community bank, a typical enrollment is the FFIEC IT Examination Handbook, BSA/AML, GLBA privacy and safeguards, the consumer regulations you originate under, and your prudential regulator's expectations. Credit unions swap in NCUA guidance and set the CRA program screen to not applicable, because NCUA-supervised credit unions have no federal Community Reinvestment Act requirement. ## The corpus behind it Enrollment draws on a read-only regulatory corpus that we maintain. Its citations are broken to the clause, each with its code, section, title, version and effective date. You browse it from **Citations & Authorities library**, where you can also register your own **internal authorities**. Those are your board-approved charters, committee mandates, and any supervisory correspondence you want treated as an obligation source alongside published rules. Open any citation and its crosswalk drawer shows what it touches on your side: the controls that answer it, the policies that address it, and any open gaps against it. Each citation carries a coverage chip of covered, gap, or uncovered. The drawer also lists **Same ground in other frameworks**. These are the citations in other frameworks that share an approved mapping to one of your active control objectives, so a single tested objective shows every framework it speaks to. Each row names the objective that bridges the two citations and how completely that objective covers the citation, as equal, subset, superset, intersects or related. Choose a row to open that citation in the drawer. A retired objective bridges nothing. You can also record that a citation does not apply to your institution. Marking it **not applicable to this institution** requires a rationale, and the call is audited like any other scoping decision. The reason a clause is out of scope then sits on the clause itself, rather than in the memory of whoever made the call. Internal authorities are yours to maintain. A charter, mandate or supervisory letter you registered can be corrected or removed later, along with its citable sections. The code you gave it is the stable identifier and does not change. The corpus keeps growing. We add new citations, such as state AI laws, as they are published, and an enrolled framework picks them up without any work from you. ## Regulatory updates The **Regulatory updates** screen is the incoming feed of published rules, guidance and supervisory statements, ranked by likely impact on you. Ranking uses your institution profile, which you set once in Settings. The profile records your charter type, asset band, product lines, charter states, and primary examiner. The feed reads the Federal Register and the published releases of the OCC, FDIC, the Fed, NCUA, CFPB and FinCEN. It also reads the state regulator in your charter state where we have a source for it. Today that covers nine charter states, which are California, Georgia, Illinois, Iowa, Kansas, Missouri, Ohio, Texas and Wisconsin. A state we have no source for is stated as such on the **Watch** tab, so a quiet feed never reads as a quiet month. Working an item follows a short lifecycle from pending, to assessed, to actioned, to closed: 1. **Assess applicability.** Mark the item as applying to you, worth monitoring, or not applicable. If an agent drafted the assessment, you confirm or override it. The draft never stands on its own. 2. **Run impact analysis.** This proposes the gaps the change opens and the policies and controls it touches. 3. **Map to policy** and link **affected records**. Linking a policy, control, disclosure or training program raises a review task on that record, so the change actually reaches the document. 4. **Export the change-management log** as a PDF when you are done. That log is the artifact an examiner asks for when they want to know how you knew about a rule and what you did about it. Rule-change monitoring feeds the same screen. It reads rule-making feeds such as the Federal Register, the eCFR, regulations.gov and agency releases. Each item carries a band for whose rule it is: your examiner, your charter state, another federal agency, or out of scope. Items go through a short triage queue of relevant, not relevant, or confirm impact. The **Watch** tab shows which sources are covered and the history of each sweep. Two more actions sit on each item. Where the eCFR shows that a part you follow was amended, **Rule redline** shows what changed in the rule text, section by section, with deletions struck through and insertions highlighted. The text it compares is the before-and-after snapshot stored when the change was detected. **Comment letters** records a public comment letter your institution filed or co-signed on a rulemaking, with the filing date, the position taken, the docket, the trade association that filed it and your rationale. A recorded letter cannot be edited or deleted, because a filed letter is a fact. Triage is not where it ends. From an item you have decided matters, create an **action plan** with an owner and one task per line of work the change opens. The item then carries its plan and a progress rollup, so the queue shows how far your response has actually got rather than only that someone looked at the rule. See [Tasks & action plans](docs-tasks-action-plans.html). ## Reading your coverage Three screens answer "are we covered?" from different angles. The **Gap report** lists obligations with no adequate policy or control coverage, tabbed by all, open and breach, with statuses of compliant, review or breach. Agent-generated rows carry a proposed chip until a person reviews them. You accept, dismiss, promote to a finding, or draft a policy straight from the gap. A proposed row also shows the confidence behind it, on the same confidence bar used everywhere an AI proposal is reviewed. A gap with no evidence behind it shows no bar at all rather than a zero. **Coverage**, in the Library group, has two tabs. The **Coverage graph** shows the whole crosswalk visually. Frameworks, citations, controls, policies, risks, findings and gaps appear as connected columns. Two badges matter here. One is uncovered, and the other is **over-relied**, which marks a control that so many citations depend on that it has become a single point of failure. An over-relied control is not a defect, but it is a concentration you should be able to explain. **Obligation coverage** scores each obligation in each business unit from the approved mappings between your control objectives and that obligation, weighted by how effective each unit's control is. Each row reads covered, partial or gap. The scores are a snapshot, so the tab always shows when it was taken and says so when it lags your latest changes. An examiner session sees the coverage graph but not this tab. The **Proposal inbox** holds the relationships the mapping engine suggests, strongest first. Nothing there counts toward coverage until a person approves it. A rejected suggestion is kept on record, and the same pair is not offered again for 180 days. ## Notes and limits We maintain the corpus. We do not maintain your interpretation of it. Applicability calls, scoping decisions and materiality judgments are yours, and the product records them as your decisions with your name on them. Enforcement content is read-only. The enforcement radar and enforcement tracker show published actions against other institutions and decompose them into the obligations that failed, so you can read them against your own coverage. They never write to your registers without an explicit action from you. Frameworks feed the rest of the library. See [Policies & document management](docs-policies.html) and [Controls, testing & evidence](docs-controls.html) for the two things coverage is measured against. --- # Policies & document management Section: Compliance library · Updated: 2026-10-07 · https://zovos.ai/docs-policies.html Zovos treats a policy as a governed object with a lifecycle rather than a file in a folder. This article covers the whole path of drafting, approval, publication and attestation. It also covers the document library that holds everything else your program produces. ## The policy register **Governing docs** is the register. Each row shows the document, its tier, its version, its owner, its status, its review date, and how many citations it maps to. Tiers run policy, standard, procedure, and guideline, and the tier matters. It decides where the document routes for approval, with policies going to the board and lower tiers routing to management. Review status reads current, due soon, or overdue, and overdue reviews surface on the Dashboard. Row actions cover attesting and retiring. An overflow menu holds edit review window, coverage, version diff, waivers, version history, attestation campaigns, and custom fields where your workspace has defined fields for policies. A policy reads **In breach** when an open finding linked to it is past its remediation date. The pill names each such finding and the date it was due. Nobody sets it by hand, because it is derived from the findings linked to the policy. **Edit review window** is the answer to "our review dates are wrong". It takes the effective date, the review cadence, and the approval record for a key policy, meaning the approving body and the date it approved. The next review date is recomputed from the first two rather than typed in. Name, version, owner and tier are not editable through that route, and there is still no delete. Retiring a policy is the end of its life. The register carries the shared register tools too: saved views, spreadsheet import and the audited import-ready export described in [Dashboard & daily triage](docs-dashboard-triage.html). ## Drafting Authoring happens in **Drafts**, a collaborative editor with presence, organized in a folder tree for policies, standards, procedures, AI drafts, gap reports and exam packages. The editor has four tabs for edit, history, comments and suggestions. A citation rail keeps the obligations you are writing against next to the text. Two things make it usable for a compliance team rather than a document tool: - **Suggesting mode** turns your edits into tracked changes instead of direct edits, so a reviewer sees exactly what you proposed. - **Comments can be marked internal**, which hides them from any examiner session. Internal deliberation stays internal. Exports are PDF, DOCX and **redline DOCX**. If your legal counsel or a board member works in Word, **Send for Word review** sends the draft out as a redline and pulls tracked changes back as a review-pass version. This needs your SharePoint connection in place first. Without one, the send is refused rather than half-completed. It is a checkout rather than a sync. There is one active review session per draft, an explicit conflict state if the base document moved underneath, and no silent merge. You can always cancel a review session. Sign-off inside the editor is a native e-signature. It requires you to re-authenticate before signing, binds the signature to the document's content hash, and is blocked while unresolved suggestions remain. ## Approval and publication From a draft you either submit for approval or publish a version directly with a recorded rationale. Submitting routes the version through the approvals queue described in [Approvals & delegation of authority](docs-approvals.html). On approval the version becomes effective. Version history is where the governance record lives. Each version can carry a **record reference** with the approving body, the board minute reference, and the meeting date. It exports as an official DOCX or PDF. If you publish approved policies to SharePoint, that happens from here too. Every new version declares its change type, and the distinction is enforced rather than advisory: - **Material.** A material change invalidates the existing sign-off and requires re-attestation. - **Editorial.** The sign-off stands and no re-attestation is needed, but calling a change editorial requires a justification. ## Attestation Attestation is a named person recording that they have read and accept a document. The **Attest** row action is an approver sign-off, open to people whose role can approve policies, such as owner and board, and it requires a rationale. Everyone else confirms they have read a document by responding to its **attestation campaign**. Launch a campaign with a name, a due date and a recipient list. The register rolls up completion as a count, exports a completion record, and closes when you close it. A material change puts a **Needs re-attestation** badge on the policy until the affected people sign again. A policy that has never been signed on any version reads **Never attested** instead. Exceptions and waivers against a policy are handled separately, with a reason, an expiry date, compensating controls and an approving body, and they move through active, pending, expired or revoked. ## Sending a version for signature From a policy version's history you can send the **filed official PDF** out for signature. It is the artifact you filed that goes out, never a generated stand-in, so the document a board chair signs is provably the document your reviewer approved. There are two routings: - **Policy attestation.** The request is routed into an open attestation campaign for that same version. Recipients come from the campaign's roster. On completion the attestation records are written and the signed copy lands back as evidence against the version it belongs to. - **Board sign-off.** The request is addressed to named signers picked from your team roster, whose addresses come from your identity provider. Manual entry stays available for an external signer such as an outside director or counsel. A member the roster holds no address for is shown as unpickable rather than guessed at. On completion the signed PDF is archived and audited. Sending is an owner-level action and is refused in an examiner session. Which e-signature provider you can send through depends on what you have connected. See [Connecting integrations](docs-integrations.html). ## The document library **Document review**, opened from **Documents** in the My work group, is where everything else lands. That includes evidence, board memos, vendor artifacts, and procedures you have not yet brought under governance. Drag and drop PDF, DOCX, TXT and Markdown files. The processing pipeline is visible, and it fails closed. A file uploads, is quarantined pending a virus scan, then indexes for retrieval, and only clean, scanned versions are ever indexed. A file that fails the scan is blocked and reported as blocked. Re-uploading a document you already hold is handled explicitly as a **New version** of that record, rather than as a second copy in the library. The reader pane shows evidence links, version history, and mapped frameworks with a match percentage. It also carries **records disposition**: a retention class and a status of within retention, due for disposition, on legal hold, or disposed. When a record reaches the end of its retention, it queues a **record disposition review** with an outcome of retain or clear for disposal. The review itself destroys nothing. It records a human decision, and disposal remains a separate, deliberate act. A legal hold is more than a status on a document. Open the hold and you see what it actually preserves. That is the documents scoped under it, which you add to and remove while the hold is active, and afterwards its release record. A hold cannot be edited or deleted. Release is its auditable end, and the scope of a released hold stands as the historical record of what was preserved. Retention classes themselves are editable and removable, although the platform refuses to remove one that is still in use or is your default. ## Notes and limits Zovos is not your document management system of record. It ingests from SharePoint, Confluence, Google Drive, Box and legal DMS platforms, and it publishes approved policy versions back out to SharePoint and the legal DMSs. Most connectors are one-way ingest, though, and the Word round-trip is explicitly a review cycle rather than continuous sync. Drafting agents produce proposals. A drafted policy carries a banner saying so, and it is never published without a person approving it. --- # Controls, testing & evidence Section: Compliance library · Updated: 2026-10-07 · https://zovos.ai/docs-controls.html Controls in Zovos come in two layers. A **control objective** states what has to be true. A control in the **Control catalogue** is one business unit's instance of that objective, with its own owner, test history and effectiveness rating. Together they record what each control covers, who runs it, how it is tested, and which regulations it answers to. Controls are one of the two things coverage is measured against, the other being your policies. ## Control objectives and the catalogue ### Control objectives **Control objectives**, in the Library group, is the register of templates. Each objective has an identifier, a family, a status of draft, active or retired, and the citations it maps to. The citation mappings live on the objective rather than on each instance, so coverage counts an obligation once instead of once per business unit. An objective can also carry a template test procedure, which each instance may override for its own unit. Choose **Instantiate** on an objective to create a control for one or more business units. Each unit gets its own control with its own owner, test history and effectiveness rating, and the objective stays the single statement of what has to be true. Retiring an objective requires a reason, and its consequence is shown before you confirm. Every approved link on the objective and on its instances, citation mappings included, drops back to needs review, so coverage that relied on those links stops counting until someone approves them again. Nothing is deleted. The objective, its instances and their test history stay on the record, and the objective can be made active again. ### Building the catalogue The fastest start is **Import baseline**, which offers five baselines: - **NIST 800-53 Rev. 5 Moderate Starter Set.** A representative starter set of NIST SP 800-53 Rev. 5 controls for a moderate baseline. - **CIS Controls v8 Implementation Group 1 Starter.** A representative starter set from CIS Controls v8 Implementation Group 1. - **FFIEC IT Examination Core Control Set.** A core control set aligned to the FFIEC IT Examination Handbook booklets. - **Cyber Hub: FFIEC IS, NIST CSF 2.0, CRI Profile, GLBA, NCUA Part 748, ISO 27001.** Sixteen cybersecurity objectives, each mapped across the frameworks in its name. - **AI and Model Risk Hub: SR 26-2, ISO 42001, NIST AI RMF, FS AI RMF, Colorado and state AI laws.** Ten objectives for governing models and AI, each mapped across the frameworks in its name. Importing a baseline creates one control objective for each baseline control, already mapped to the citations it answers to, and one enterprise-wide instance of each, so the catalogue is usable immediately. Importing the same baseline again duplicates nothing. The two hubs are crosswalks. One tested objective shows where it lands in every framework an examiner works across. Each hub mapping states how completely the objective covers the citation, as equal, subset, superset or intersects, and the citation drawer shows that relation under **Same ground in other frameworks**. See [Frameworks & regulatory updates](docs-frameworks.html). You can also import your own controls or add them one at a time. The importer takes a CSV or an XLSX spreadsheet and validates it in a dry-run pass first. It reports errors row by row without abandoning the rest of the file. Each row is matched on the control objective's name and lands on the instance for the business unit it names, so a re-import updates the same records instead of duplicating them. Each control needs an objective, an owner, and the citations it satisfies. That last part is what turns a list of controls into coverage, because gap analysis compares your obligations against the controls and policies you actually have. Controls carry a few attributes that examiners read closely: - **Type.** A control is preventive, detective, or corrective. - **Automation.** A control is automated, hybrid, or manual. - **Key control.** A key control is one whose failure would be material. Key coverage is tracked as its own percentage. - **Evidence freshness.** Evidence reads fresh, expiring, or stale, so a control that passed a year ago does not read as current. The catalogue's needs-attention chips surface tests due, tests overdue, and stale drafts, which is the shortest path from opening the screen to knowing what is actually late. The catalogue lists one row per instance and can be filtered by business unit. It also carries the shared register tools described in [Dashboard & daily triage](docs-dashboard-triage.html). Those are sortable columns, column visibility, saved views of the filter and layout you work in, and an audited import-ready CSV export of the whole catalogue. Any custom fields your workspace has defined for controls appear on the control itself. A control's link to its governing policy opens that policy's **Coverage** view in **Governing docs**, which lists every control that implements it. If you license a publisher's control catalogue, the **Content library** is where that imported content becomes readable. It shows each imported control, the framework crosswalk the publisher shipped with it, and how it lines up against your own catalogue. Mapping suggestions are proposals. Nothing links to your controls until you confirm it, and each decision is audited. Importing the file itself still happens in Settings, and an examiner session never reaches this screen. ## Design versus operating effectiveness Zovos tracks two effectiveness ratings and does not let them collapse into one. **Design effectiveness** asks whether the control is built to achieve its objective, that is, whether it would work if it ran as written. **Operating effectiveness** asks whether it actually works in practice, and it is test-derived. You cannot simply declare a control operating effective. The rating comes from testing and from an independent review. Both roll up on the catalogue screen as stacked bars, with values of not yet assessed, effective, partial, ineffective, or exception. The distinction matters at exam time, because a well-designed control that has never been tested is a different finding from a control that was tested and failed. ## The test workflow Testing a control runs in a short loop: 1. **Schedule the test** on the control's cadence. 2. Choose **Run test** and record the result, which is the samples tested and the samples passed. 3. **Attach evidence** of the test to the control. Evidence carries its own freshness clock. 4. **Attest** to the control, recording that a named person stands behind it. 5. Choose **Request effectiveness review** for an independent sign-off, which is what can raise operating effectiveness. The last step is the important one. A control owner attesting to their own control is a useful record, but it is not independent assurance. The effectiveness review routes to someone else through the approvals queue, and only that independent sign-off moves the operating rating. ## Automated and external tests ### Continuous control monitoring Where a control can be evidenced by a system rather than a person, add an automated test. Choose a **Connector**, a **Check**, and a **Cadence**, then let it run. The **Check** list offers only the checks the chosen connection can actually run, and a check paired with a connection that cannot run it is refused. You can also choose **Run now** for an ad hoc check. Typical checks cover multi-factor authentication enforcement, second-step verification enrollment, vulnerability posture, endpoint coverage, mobile device management, cloud configuration in AWS, and automated backups that are configured and current. A failed automated run opens a remediation finding for you. There is one open finding per control, so a test that keeps failing does not pile up duplicates. That is one of the few places in the product where a finding is created without a human click. Automated checks need a connected system. The panel points you to Settings and integrations if nothing is connected yet. See [Connecting integrations](docs-integrations.html). ### External test review Some tests are performed outside Zovos by your own AI assistant and submitted over the Zovos Evidence Protocol. **External test review**, in the Library group, is the reviewer inbox for them. Its **Pending review** tab lists submissions waiting for acceptance. Its **Re-perform** tab lists submissions that random re-test sampling flagged for an independent re-performance. Each row shows the control, the test period, the outcome, the tester of record, the target system and the attached artifacts. The tester of record is the verified person who submitted the test. The assistant's name is self-declared, so it is badged as unverified. Open a row to review the full submission on the control. A reviewer who is not the tester and who holds the control-approval permission accepts or rejects it, and a rationale is required either way. For a sampled item, the reviewer records the re-performance as a match or a mismatch, with a note. An examiner never accepts, rejects or re-performs a submission. See [Test controls with your own AI assistant](docs-ai-control-testing.html). ## Management certifications The catalogue's second tab holds certification campaigns. These are the sub-certification rounds that support FDICIA and SOX internal control over financial reporting sign-offs. Open a new campaign, and each responsible manager either certifies or **certifies with exception**, optionally opening a finding at the same time. When the round is complete you submit it for close and export a committee pack as a PDF. Certification is not the same as attestation. Attestation is a named person signing that a policy or control is in place. Certification is a periodic, structured round tied to financial reporting. ## Over-relied controls The [coverage graph](docs-frameworks.html) badges some controls as **over-relied**. That means so many citations depend on that single control that it has become a concentration. If it fails, a large part of your compliance story fails with it. It is not automatically a problem, and the product does not treat it as a finding. It is a prompt to either document why the reliance is appropriate or build a second control so one failure does not cascade. Examiners ask this question in a different vocabulary, usually about single points of failure in the control environment. ## Notes and limits Zovos does not connect to core banking, loan origination or AP systems. Your testers draw populations and samples from those systems themselves, and each test records how many items were sampled and how many passed. That is a deliberate scope decision. Zovos holds the risk and control work of every line of defense, and it stays out of transactional banking. Beyond the five baselines in **Import baseline**, the control catalogue ships no third-party control content. You bring your own baseline, or import content you are licensed to use. --- # Monitoring & absence testing Section: Compliance library · Updated: 2026-10-07 · https://zovos.ai/docs-monitoring.html **Monitoring & testing** is the second line's recurring testing program. You sample transactions, work a regulatory checklist, document exceptions with root cause, and route an examiner-proof workpaper to an independent reviewer for sign-off. **Absence testing** is its mirror image. It proves that things which should not have happened did not happen. This article covers both. ## Activities, reviews and workpapers Three words are used precisely across this area: - An **activity** is the recurring test. It has an area, the regulation it covers, a risk rating, and a cadence. - A **review** is one execution of that activity for one period. - The **workpaper** is the documented evidence that review produced. What is due and what is overdue is derived from the cadence, so the program tells you what is late rather than waiting for you to notice. ## Running a review Choose **Start review** on an activity, optionally starting from a checklist template. The template is snapshotted at that moment, so a later edit to the template cannot change what you actually tested. 1. **Set scope, population and sample method.** Sample method is judgmental, random, statistical, or full population, and the method is recorded with its rationale. An examiner will ask how you chose. 2. **Add samples** to the review, one masked item reference per line. 3. **Grade the result matrix.** Every checklist step is graded against every sample as pass, fail, or not applicable. The matrix is the workpaper's core. 4. **Log an exception** on a failed cell. High-severity exceptions require a root cause. An exception can be promoted to a finding in the shared [Findings tracker](docs-findings.html). 5. **Submit for sign-off.** An independent reviewer signs the workpaper through the approvals queue, with a decision of sign off, request changes, or reject. 6. **Export the workpaper** as a PDF for your files or an examination. Workpaper states run in progress, pending approval, signed off, and changes requested. An exception promoted to a finding names that finding on the workpaper. The review's **Links** panel shows the records linked to it, such as controls, findings and citations, so the review sits in the same crosswalk as the rest of your program. ## The submit gate Submission is complete by construction. If anything is ungraded, unexplained or missing, the platform blocks the submission and names exactly what to resolve. It does not accept a partial workpaper and flag it later. The only thing that discharges an ungraded failing cell is an exception bound to that specific cell. This is stricter than most spreadsheet-based monitoring programs, and deliberately so. A signed workpaper in Zovos means every step was reached and every failure was either explained or escalated. ## Absence testing Some obligations are prohibitions. The corpus is full of clauses that say a bank shall not do something, and a normal control test cannot evidence them. There is no artifact produced by not doing a thing. Absence testing turns every prohibition into a deterministic search over your own records: complaints, findings, fair-lending reviews, document text, marketing review materials and control tests. No language model is involved. This is a search with a written protocol, because a probabilistic answer to "did this ever happen?" is worth nothing to an examiner. The screen has two tabs. **Coverage map** shows which prohibitions can be tested at all, graded direct, signal only, or not tested. Prohibitions we cannot yet test are disclosed rather than hidden, because an honest map with holes in it is more useful than a complete-looking one. **Runs** holds the executions. Each run returns one of four verdicts: - **Exceptions found.** Records matched the prohibition and need disposition. - **Nothing found.** The search ran over a sufficient population and matched nothing. - **Insufficient population.** There were not enough records to say anything. - **Not testable.** No data source can currently evidence this clause. Every run records its search protocol in plain language: which population was searched, how many records it held, the query used, and how many matched. It then seals a manifest into the proof ledger, so the run can be verified later. Saying "nothing happened" is different from saying "we searched this population, this many records, this way, and found nothing". Only the second is negative assurance. ## Dispositioning an exception A matched record is an exception pending disposition rather than a violation. Each one requires a rationale. It then gets a disposition of false positive, explained, or confirmed, or it is promoted to a finding. Dispositioning is a two-step action rather than a single click, because recording a false positive should not be something you do by accident. ## Notes and limits Monitoring samples come from your own systems. Zovos does not connect to core banking or loan origination systems, so you enter each sample as a masked item reference, one per line, rather than pulling it through a live query. Absence testing coverage grows as we extend what each prohibition can be searched against. The coverage map is the honest statement of where that stands in your workspace today. If a clause that matters to your program reads not tested, [tell us](support.html) and it goes on the list. --- # Risk management Section: Programs · Updated: 2026-10-07 · https://zovos.ai/docs-risk-management.html Risk management in Zovos is one connected set of registers rather than a folder of spreadsheets. You keep the enterprise risk register, the exceptions that waive a control, the risk and control self-assessments, the key risk indicators, the board's appetite statement, the operational loss register and the emerging-risk watch list in one place, and each of them is scored by the same engine. They sit in the **Risk** group of the sidebar as Risk register, Assessments, KRIs, Appetite, Exceptions, Loss events and Emerging risks, followed by the **Decision register**. Risk managers, the CCO and second-line approvers work here every week, and the board reads the result. ## The risk register The **Risk register** is the spine. Each risk carries a display ID, a category, an owner, a treatment, and links to the controls that mitigate it and the findings it produced. You score a risk on a 5 by 5 likelihood and impact scale, and Zovos derives the **inherent** band from that score. Zovos then suggests a control effectiveness from the linked controls' latest tests and the findings open against them. A person accepts or overrides that suggestion, the trail records both, and the **residual** band is derived from the accepted value. Neither band is ever typed by hand, so two people scoring the same way get the same answer and an examiner can see the arithmetic. Treatments are **Mitigate**, **Accept**, **Transfer**, **Monitor** and **Avoid**. The heatmap plots inherent against residual so you can see where controls are actually moving the needle. Three toggles beside the register's filters open focused views. **Uncovered** lists active risks with no mitigating control linked at all. **Awaiting confirmation** lists the risks whose control effectiveness nobody has confirmed, or whose evidence has moved since someone did. Each row links to the risk, and there is no bulk confirm. **Ownership** shows who carries the register and which owners have not attested to what they own lately. You attest only to your own risks, and an owner who has left stays listed and excused rather than disappearing. Badges call out risks that are above appetite, overdue for review, or flagged for re-assessment. A risk treated by Mitigate, Transfer or Avoid can carry a **Treatment plan**. The plan records an owner, a summary, a target date, the control health it expects to reach and the residual band it steers toward, and its actions are ordinary tasks. A Transfer plan must name its transfer instrument, such as an insurance policy, a contract clause or an indemnity. Accept and Monitor risks carry no plan. Closing a plan asks for a re-score, but it never re-scores the risk itself. Choosing **Accept** on a high or critical risk is deliberately not a dropdown change. It parks the risk at pending approval and requires a bounded acceptance expiry, a linked open finding, a compensating control (or a documented statement that there is none), and a written rationale. Acceptances expire rather than quietly persisting. Each risk's detail also shows a **bow-tie** view of its causes, consequences, preventive, detective and corrective controls and the indicators that monitor it, and a **What this risk has cost** panel. That panel reads the loss events linked to the risk and shows their frequency and their gross, recovered and net amounts over the trailing 12, 36 and 60 months. It describes what happened and predicts nothing. The register is built to be worked at volume. Select rows to reassign an owner, or to apply a status change with a rationale, in one step. Treatment is deliberately excluded from bulk editing, because changing how a risk is treated is a decision and not a data-entry task. You can save named views, add your institution's own custom fields, and discuss a risk in an append-only comment thread with @mentions of your team roster. ## Exceptions An **Exception** is a formal waiver against a policy, standard or control. It is the kind of thing that usually lives in an email thread. Each one records the compensating control, an expiry date, and an approval chain that runs from the submitter to the risk owner to a second-line approver. Tabs split the register into all, approved, pending, expiring and rejected. Approvers can request changes, reject, renew or approve. Where the exception is bound to a risk in the register, severity is derived from that risk's residual band rather than chosen by the requester, so nobody can declare their own exception low-risk. An exception raised with no parent risk carries the severity the requester records, which is one more reason to bind it to a risk. ## Assessments and key risk indicators **Risk and control self-assessments** run per business unit per cycle, moving from open to in progress to submitted to attested. Members rate both design effectiveness (is the control built right) and operating effectiveness (does it actually work). Where your institution defines workshop questions, each member also answers a **Question set**. The **RCSA program plan** lays every business unit against the periods in your cycle, so a unit nobody has scheduled shows as an uncovered row with its next-due date and a badge when it falls due. Shipped assessment content packs cover a broad catalogue, including BSA/AML and OFAC, cyber, fair lending, third party, continuity, privacy, new products, UDAAP, liquidity, and per-regulation consumer packs. You can clone a curated pack and edit its item list, or author a template from scratch, and the curated packs stay read-only. A FinCEN national-priorities panel shows which priorities your assessment actually addresses. Second-line reviewers can **Raise challenge** on any line. The owner responds, and the challenge is either resolved or withdrawn. An assessment cannot be signed off while a documented challenge is still open. **Key risk indicators** carry amber and red thresholds plus a direction (higher is worse, or lower is worse), and Zovos derives the RAG status from the reading rather than asking someone to colour it in. A sparkline plots the last seven readings, so a monthly indicator's sparkline spans seven months. An indicator that has gone quiet is badged as stale rather than shown as green. Readings can be fed from the loss-event register, or pushed by an external metric source with a scoped, expiring credential minted in the **Feed tokens** panel. The token is shown once, at mint time, and the panel lists and revokes every token that can write into the indicator. A breach never silently opens a finding. It surfaces a **Flag linked risk** action so an operator confirms the re-assessment. We would rather you decide than have the system decide for you. ## Loss events **Loss events** record operational losses, near misses and incidents, classified by the seven Basel event types and their Level 2 subtypes, with gross, recovered and net amounts and a root-cause category of people, process, systems or external. A boundary event, an operational failure whose loss is booked as credit or market risk, is marked and counted as such. A near miss has no money out and is excluded from the loss totals. The loss it avoided is recorded and reported as its own figure. Recoveries are tracked as **Recovery claims**, opened and then marked received. **Mark as duplicate** takes a second report of the same event out of the analytics and the indicators fed from them. An incident records the **Regulator notification (36-hour rule)** evidence: when the agency was notified, by whom, and its reference. Closure runs through **Submit closure** and an independent approval. Fraud losses are loss events too. A loss classified as internal or external fraud also records the channel the fraud came through, and the **Fraud losses** screen in the AML/CFT & fraud group is this same register filtered to those two event types. See [AML/CFT program & training oversight](docs-bsa-program.html). ## Appetite and scenarios The **Risk Appetite Statement** moves from draft to pending approval to active, and is superseded rather than edited. It sets a tolerance band per category and requires a catch-all row so no category falls outside the statement. It can also carry quantitative limits the board approves, each with a metric, a limit class, a unit, a ceiling or floor, and an optional business-unit sub-limit. Binding a limit to a key risk indicator means board approval writes that indicator's amber and red thresholds. When the board approves the statement, the bands are written into the enforcing configuration and the appetite fields in Governance settings become read-only. An appetite-versus-actual table shows your residual distribution, the count of risks above appetite, indicator status, and each limit as within limit or limit breached, per category. Categories can form an optional **parent and child** tree. A child with no tolerance of its own inherits its nearest ancestor's band, and each row counts its own risks and those beneath it. You can adopt a shipped starter taxonomy and map categories to the Basel event types. The **Basel event types against the risk register** panel then flags loss experience that no risk in the register points at. The **Scenario analysis** panel is scenario capture for severe-but-plausible events. A scenario is drafted, workshopped and then signed off by the board through the approvals queue, and you can adopt one from a shipped library rather than start blank. A signed scenario linked to a risk proposes a residual re-score on that risk's detail. A person accepts or overrides it, and both decisions land in the risk's score history. **Generate CRO report** produces the sealed quarterly ERM committee package. It covers appetite against actual, the limit and indicator breach log, top risks and movers, acceptances, RCSA status, treatment plans, loss experience and the emerging-risk brief. ## Emerging risks and decisions The **Emerging risks** watch list is for things you are tracking but have not formally registered. Each entry has a source type and a time horizon, and moves through watch, act, and then promoted or dismissed. **Promote to register** scores the entry on the same 5 by 5 model, so nothing is lost in the handoff. The **Decision register** closes the Risk group. It records each risk acceptance and scoping call as its own record: the question, the decision, the rationale, who approved it, and the alternatives your team rejected. When a later decision replaces an earlier one, the supersession chain links them. See [Board & governance](docs-board-governance.html) for how the chain is recorded and read. ## Notes and limits Every approval described here runs through the shared queue and the delegation-of-authority matrix. See [Approvals & delegation of authority](docs-approvals.html). The risk register and the loss-event register both export as a stamped PDF or XLSX, and an audited **Import-ready CSV** streams a whole register in the exact shape the importer accepts back. Register imports take a CSV or an Excel workbook. Risk scoring is a governed judgement surface rather than a quantitative model. Zovos derives bands from what your team records and does no statistical loss modelling. Loan review has its own group and article. See [Credit risk review](docs-credit-risk-review.html). --- # Third-party risk & partner programs Section: Programs · Updated: 2026-10-07 · https://zovos.ai/docs-third-party-risk.html **Third-party risk management** covers the vendors your institution depends on. **Partner programs** covers the fintech programs your institution sponsors. Both are oversight surfaces built for the questions an examiner asks: who are they, how critical are they, what did you check before you signed, and what have you checked since. The vendor manager works here daily, and the CCO and an independent approver sign the decisions. In the sidebar both sit in the **Third parties** group, as **TPRM** for the vendor inventory and **Partner programs**, beside **Questionnaires**. ## The vendor inventory Every third party gets a record with a display ID, an owner, a service category, a tier and a status. Statuses run prospective, approved and awaiting onboarding, active, under review, and offboarded. Onboarding is a request that an independent approver signs rather than a status you set yourself. Offboarding opens an **Offboarding checklist** covering data return or destruction, access removal, contract termination, final accounting and service transition. Each item is marked done with a note or reopened, and none can be deleted. Inventory tabs let you filter to critical vendors, concentration exposure, vendors whose SOC report or data-processing agreement is expiring or in renewal, and the spend reconciliation. Contract expiry itself is not on that tab. It lives on the contract panel and in the clause matrix. A second view, the **Clause matrix**, flips the register on its side so you can see one contract clause across every vendor at once. As on the other registers, you can save a named view, add your institution's own custom fields, and take an audited **Import-ready CSV** of the whole inventory alongside the stamped exports. A member with the Business-line owner role sees and works only the vendors they own, including uploading evidence and recording their contracts. See [Roles & permissions](docs-roles-permissions.html). **Generate TPRM program report** files the annual program report for the board as a sealed board report, listed with the other board reports. ## Tiering, assessment and due diligence Tiering runs from four inputs: **criticality**, **data sensitivity**, **system access** and **annual spend**, each recorded on a short scale. Zovos suggests a tier from those, and you accept the suggestion or set a different tier yourself. Tier drives how much diligence the vendor needs and how often you reassess. Each vendor also carries a structured 5 by 5 risk assessment on the same scoring engine as the risk register. Recording the assessment moves only a suggested residual. The **Residual risk** panel shows that suggestion beside the residual on record, and the record moves only when a named person confirms it against the evidence. A periodic reassessment is kept as a **Reassessment record**. Zovos drafts the basis from everything that changed since the last review, the reviewer records a decision, and the basis is frozen onto it. The vendor badges as due soon or overdue against its cadence. Diligence is a questionnaire plus artifacts. You send a due-diligence questionnaire to the vendor through an external portal. The respondent gets a scoped, expiring link rather than a login, and any file they upload is quarantined until it passes a malware scan. The link reaches the vendor only by email, and Zovos sends no email today, so for now the questionnaire link does not reach the vendor through Zovos. Questionnaires are issued from versioned **Questionnaire templates**, which you manage in Settings under **Data & retention**. **Import SIG / CAIQ** brings in a question set from a CSV or Excel export as a new version, and you choose which version new questionnaires use or retire one. A template is never edited in place, and each questionnaire shows the template and version it was issued from. Answers the vendor gave in an earlier cycle are carried forward and flagged for re-confirmation. Alongside the questionnaire you collect the SOC report, financials, the vendor's continuity plan and insurance certificates. Each vendor carries a **SOC state** (current, expiring, or an exception where it was never collected) and a **DPA state** (active, in renewal, or missing), so a gap reads as a gap instead of an empty cell. A renewal panel reads the SOC and DPA cadence across the inventory over a window you pick, which can be the coming month, quarter, half-year or year. An artifact that has already lapsed stays on the list whatever window you choose, and reads as overdue by so many days. ### Questionnaires you answer **Questionnaires** works the other direction. It is the intake for due-diligence and RFP questionnaires that your institution has to answer. You paste the questions in, supply them as CSV, or upload an Excel or Word file. The drafting agent proposes an answer to each question with its supporting citations, a confidence score and a review state, and flags the answers it is unsure of. You review and edit the answers, and then export the set as a CSV. ## SOC 2 review and remediation Collecting a SOC report is not the same as reviewing it, and the review here is substantive. You record items against the report by kind. The kinds are testing exceptions, **CUECs**, carve-outs where a fourth party was excluded, period gaps against your fiscal year, and opinion flags. CUECs are complementary user entity controls, the controls *you* have to run for the vendor's opinion to hold. The opinion itself is recorded as unqualified, qualified, adverse or a disclaimer. The SOC Reviewer agent can extract candidate items from the report to save the first pass. Every candidate requires explicit confirmation before it becomes part of the review, and any excerpt the agent could not ground in the document is badged as such. What the review turns up becomes work in the vendor's **Action items** panel. An action item can be raised only from a confirmed SOC exception, a contract clause recorded as absent, or a due-diligence answer that does not hold, and the source excerpt is frozen onto it. Its due date follows from the severity you pick. The vendor works its items through a scoped, expiring remediation link and can mark one ready. That link is also delivered only by email, so it waits on the same switch. That mark shows as the vendor's claim, and only your team closes an item, with a recorded rationale. ## Contracts, concentration and shadow vendors Contracts carry a required-clause checklist, with each clause marked present, absent, not applicable, or unreviewed. That fourth state matters, because "we have not looked" is different from "it is not there". The contract panel also records the term, the non-renewal notice window, auto-renewal, the right to audit, the breach-notice period and SLA metrics with their met or missed outcomes, and badges a contract nearing its notice date. The Contract Reviewer agent can read the executed contract and propose its terms and a finding for each required clause. A person accepts or rejects each proposal, and nothing on the contract changes on its own. **Concentration risk** shows the largest exposure in each service category, weighted by spend where accounts-payable spend has been reconciled and by vendor count otherwise. Each exposure carries an exit-difficulty rating, from readily substitutable to no viable alternative, and that rating adjusts how the exposure reads against your appetite. Each vendor lists its **Fourth parties**, and a provider named by two or more of your vendors surfaces as fourth-party concentration. **Shadow-vendor reconciliation** takes an accounts-payable spend export as a CSV or an Excel workbook and surfaces payees with no record in your inventory, each of which you match, dismiss or promote into the register. If you connect a security-ratings or financial-health provider, ratings arrive as time-series snapshots with deltas rather than as a single number. A material drop appends a monitoring event to the vendor record. It never silently forces a reassessment. ## Partner programs **Partner programs** is the sponsor-bank and banking-as-a-service surface. It holds one record per fintech program, pointed at the partner in your vendor register. Each program opens on a strip of tabs: the dossier, due diligence, the exit runbook, ongoing monitoring, complaints and UDAAP, oversight appetite, and the partner's BSA/AML metrics. The partner's own AML/CFT officer designation is recorded, and the exit plan has to exist before launch rather than after the relationship sours. Program status runs proposed, onboarding, live, wind-down and exited. The **live** and **exited** states are earned through gates rather than set from a dropdown. Gate chips have exactly two states, met or blocked. There is no amber, because an amber gate is a silent pass. A failed diligence item is never cleared. The maker records why the institution would proceed with the failure, an approver accepts or refuses that waiver, and the line stays a failure on the packet either way. A waiver is a documented decision, and it does not erase the failure. Opening the diligence packet freezes a snapshot of the platform's checklist pack at that moment, so a later edit to the template cannot change what was actually signed. ## Overseeing a live program The fintech can answer your diligence itself. Mint a scoped link to the program's open diligence lines, send it to the partner contact, see every link that can currently reach the packet, and kill one when it has served its purpose. Answers arrive marked as unverified submissions awaiting your review, counted beside the blocking items and never inside them. The partner's own assertion never closes a gate on its own. The **exit runbook** is a tracked plan rather than a checklist. Every wind-down obligation carries an owner, a target date and an execution status of not started, in progress or blocked, with complete earned by a recorded result rather than a tick. Each line ages through no target date, on track, due soon, or overdue. Overdue lines badge on the tab and reach the reminder feed. A wind-down plan nobody is working becomes visible while the program is still live, which is the only time it can be fixed. **Oversight appetite** puts threshold lines on the program figures a sponsor bank is examined on: complaints attributed to the program, marketing reviews flagged in advertising and UDAAP review, monitoring exceptions per hundred items sampled, and the age of the oldest unresolved diligence line. Breaches are derived when the tab is read, badge on the tab, and are promoted into an ordinary finding by hand when you judge that one is warranted. Nothing here acts against the partner automatically. The **BSA/AML metrics** tab records the partner's own numbers month by month. Those numbers are alerts generated, cases opened, SARs filed, the enhanced due-diligence population, and the age of the oldest open KYC exception. Figures are keyed in or imported. Each one shows its provenance and its direction of travel, and no verdict is attached. They are counts and nothing more. No SAR narrative, no subject, and no case reference crosses into Zovos. Programs carry a review cadence of monthly, quarterly, semi-annual, annual or none, with reviews recorded against it and a badge when one is due. Review dates and exit-runbook target dates both register on the obligations calendar, so a periodic review that lapses is visible next to every other deadline. ## Notes and limits This is oversight of a program, never the running of one. Zovos does not process partner transactions, and it holds no core banking or accounts-payable connector. Spend reconciliation is a spreadsheet import by design. The partner-program inventory exports as a stamped, audited register, which is a standard sponsor-bank first-day-letter line item. Vendor onboarding, partner go-live and exit all run through [Approvals & delegation of authority](docs-approvals.html). For the buyer-facing summary of this workflow, see [third-party risk](solution-vendor.html). --- # Exam management & audit readiness Section: Programs · Updated: 2026-10-07 · https://zovos.ai/docs-exam-management.html Exam management is the war room for a supervisory examination. Look for **Exam prep**, in the Exams & regulatory change group of the sidebar. The screen itself is headed **Audit readiness**. It holds one engagement at a time: the regulator, the cycle, the period under review, the request list, and every piece of evidence attached to it. The exam manager and the compliance team work the bank side. The examiner, once you grant access, sees a separate and much smaller room. ## Set up the engagement Start with **New engagement**. You record the regulator, a title, the frameworks in scope, the cycle, the period start and end, and the examiner of record. Picking a request-list template for that regulator instantiates a pre-mapped request list in one step, so you are not retyping a first-day letter from scratch. The hero shows readiness as a share of requests complete, plus evidence coverage by control area. Readiness is computed from real request and evidence completeness. An empty engagement honestly reads as zero rather than as a comfortable default. Below the engagement sits **Next expected examinations**. It has one row per examination type: safety and soundness, IT, BSA/AML, consumer compliance, trust and other. Each row shows the regulator, the date and rating of the last examination, the next expected date, and the preparation window before it. An examination that does not apply to your charter stays on the list with its applicability switched off, rather than disappearing and being forgotten. Those expected dates feed the obligations calendar, so preparation starts on a schedule instead of on a phone call. ### Maximum examination interval Beside it, Zovos derives the longest your agency may go between full-scope safety and soundness examinations under your charter's rule. For a bank that is 12 or 18 months under 12 U.S.C. 1820(d) and the agencies' September 2026 interim final rule, where the 18-month cycle reaches institutions under $6 billion that meet every condition. For a credit union it is the scheduling policy in NCUA Letter to Credit Unions 25-CU-03. The panel lists each condition with whether it holds and the recorded datum behind it. A condition Zovos holds no datum for reads **Not recorded** and is never counted as met, so the panel reads "cannot be confirmed" when the answer depends on it. It shows the latest date each possible interval allows and flags an expected date you entered that falls after the maximum. The result is a suggestion only. The agency sets the examination date, and nothing in the panel is saved or pre-filled. Conditions Zovos keeps no register for, such as your capital category, a change in control or a change of chief executive, are confirmed with **Affirm** by a named member, with the date and an optional note. "No formal enforcement action in force" needs an affirmation too, and it fails whatever was affirmed while an action in force sits in your supervisory-actions register. An affirmation made before your last examination reads Not recorded again until it is renewed, except the charter and charter date, which stand until they change. ## The first-day letter Upload the first-day letter, which is also called the document request list or the PBC list. Then choose **Parse letter** in the exam-room panel. Zovos segments the letter into individual request lines using structural parsing, then classifies each line against a catalog of known request types. You confirm or override every classification, or mark it as no match. The classification is a suggestion, never an auto-commit. A confirmed classification maps artifacts for you: the catalog's citations resolve to your controls, with test-evidence freshness attached, and to your policies through the crosswalk. Those proposed links land for an analyst to accept or dismiss. The exam-room panel shows the coverage bar across covered, partial, gaps and to-review, with the ranked gaps listed first. ## Work the request list Each request has an owner, a due date, and a status that moves from not started to in progress to submitted, and then to accepted or returned by the examiner. Every status move on the bank side takes a written rationale, so the request history reads as a record of decisions rather than a trail of clicks. You produce evidence three ways: **Upload file**, **Attach note**, or **Reference a document** already in the library. Once at least one examiner-originated follow-up exists, a filter appears to narrow the list to those items. If you connect an AI assistant, its ready-made **Prepare an exam request list** prompt walks the open requests with you. See [Connect your AI assistant](docs-connect-ai-assistant.html). When you are ready, **Generate exam binder** assembles the package. The binder carries a content hash and its generation is sealed into the proof ledger, and past binders stay downloadable with their hash. That way "which version did we hand over in March" has an answer. ## Close out the examination Once an engagement reaches reporting, an **Exam close-out** panel tracks what the examination produced. It lists the steps still outstanding, in the product's words: file the report of examination, take the ROE to the board, take the examiner findings into the register, draft the response letter, issue the response letter, and promote the MRAs to a supervisory action. The last step appears only when the examination produced MRAs or MRIAs to promote. You upload the report of examination to Documents and then file it here, and filing it is what starts the response clock. The board review points at the board meeting where the report was taken. Findings intake opens the examiner's findings in the shared register with their source, severity, owner and due date, and marks a finding that repeats an earlier one. On each examiner finding you then record its supervisory basis, unsafe or unsound practice or violation of law with the law cited, and the date the communication was issued. An MRA or MRIA issued on or after November 2, 2026 must name its basis. The response letter is drafted in the document editor, issued with the date it was sent, and downloadable as a sealed letter. Promoting MRAs turns the findings you name into a formal MRA set, one article per finding, which you then work in [Supervisory actions](docs-supervisory-actions.html). The panel reads closed out once every step is done. Close-out is the institution's own deliberation, so examiner sessions do not see it. That chain is readable rather than merely asserted. A **proof ledger** panel on this screen lists the sealed events in order, with who sealed each one and when, and you can filter it down to a single record. Beside the events it lists the external anchoring runs. The runs that failed are included, because a gap you cannot see is not evidence of anything. ## What the examiner sees Examiner access is granted by an owner, scoped and time-boxed. You choose the scope and a duration. The scope covers frameworks, specific finding IDs, a date range and the regulator. The examiner signs in and sees a persistent banner with the scope label and a countdown to expiry. The grant screen shows the token once and tells you plainly whether it was delivered to the examiner or whether you need to hand it over yourself. Zovos sends no email today, so expect the second case. You pass the one-time token to the examiner, and they paste it on the sign-in page. The examiner does not see the war room. Exam prep opens for them as the **Exam room**, which shows their request list grouped by regulator module. Each item carries its status, the shareable evidence attached to it, and a comment thread. They can **Accept** a submitted item or **Return** it, and both take a required rationale. They can also **Request a follow-up** to add a new item to the list, without anyone emailing a zip file. The room also carries an internal-audit coverage card showing the issued audit plan, the issued reports, and the quality-assurance position. That card is what an examiner reads when deciding how far to rely on your internal audit function. A **Changed since** panel shows what moved in your program since the last examination on file. It is reconstructed from the sealed ledger, says which parts are exact and which are approximated, and lists what it leaves out. The session is revocable, its grant and revocation are audit-logged, and it can be pinned to an IP range. It is read-only at the database with a closed set of exceptions. Those are the follow-up, the accept-or-return and the comment described above, plus uploading a document into the room. They are the only writes an examiner principal can make anywhere in Zovos. Rows marked internal are hidden throughout. In the findings register an examiner reads only the findings their grant covers, and the counts at the top of the register are computed over those same rows, so the header and the list always agree. Whole areas are denied to examiners as work product: board governance and minutes, the decision register, and the mock exam. Examiner-sourced findings carry a required regulator attribution, so one regulator's confidential supervisory information never reaches another regulator's room. ## Mock exams and the as-of view The **Mock examiner** panel is the adversarial self-test. Pick a published examiner workprogram and run it against your live records. Procedures return pass, fail, not applicable or not evaluated. An empty population honestly returns not applicable rather than a pass. Failed procedures produce draft findings in examiner voice at a severity of MRA, recommendation or observation, and each one has to be explicitly promoted before it becomes a finding in the register. Mock exams are internal only. Examiner principals are denied on every route behind them. The **Program as of a date** panel reconstructs your program as it stood on a past date and exports a proof pack a third party can verify offline. It is candid about how it knows each part. The policies in force and the attestations that existed are reconstructed exactly, while the risk acceptances that were live are labelled as approximated. The panel says so on screen rather than presenting all three with equal confidence. The **Board pack lineage** panel does the same job for a sealed board pack, re-verifying each claim as unchanged, drifted, or an unknown query. ## Notes and limits Exam readiness is per engagement. There is no single always-on institution-wide readiness score independent of an open engagement. Binder exports are hash-stamped and ledger-sealed but not watermarked. Watermarking applies to external document-room delivery. An examiner in scope also reads your formal supervisory actions, filtered to their own agency's lane. See [Supervisory actions & the advisory log](docs-supervisory-actions.html). Findings raised during an exam flow into the shared register described in [Findings & remediation](docs-findings.html), and access scoping is covered in [Roles & permissions](docs-roles-permissions.html). --- # Supervisory actions & the advisory log Section: Programs · Updated: 2026-10-07 · https://zovos.ai/docs-supervisory-actions.html Two surfaces serve institutions that need them. **Supervisory actions**, in the Exams & regulatory change group of the sidebar, is the container for a formal action against your institution. That can be a consent order, a formal or written agreement, an MOU, a cease-and-desist order, or a set of matters requiring attention. **Advisory log**, in the Compliance group, is the register of "can we do this?" questions the business brings compliance and the positions compliance took. They are documented together because both answer the same examination question: what did you know, and what did you do about it. ## What a supervisory action holds An action carries its type, the issuing agency, the docket number where there is one, the effective date, an owner and a short summary. Its status runs issued, awaiting termination, terminated, or superseded. Your team files it with **File a formal action**, entering the header and the articles the agency wrote, and adds more with **Add an article** and dated milestones with **Add a milestone**. An MRA set can also arrive promoted from an examination's close-out, described in [Exam management & audit readiness](docs-exam-management.html). Underneath the action sit the **articles** the agency actually wrote, each with its number, its title, the requirement in the agency's words, and an owner. Under each article sit dated **milestones**, each with an owner and a due date. Every level rolls up: milestones complete against milestones total, articles complete against articles total, a percentage, an overdue count and the next date due. The register lists your actions with those rollups and filters by status, so the answer to "how far along are we" is the same number at every level rather than three different ones. An article can carry an action plan in the work layer, so the day-to-day remediation is tracked as tasks while the article keeps the agency-facing deadline it exists for. **Open an action plan** on the article creates it with an owner and its first tasks. The article then shows the plan and its task count and links through to it. An article has at most one live plan, so "the plan for Article III" stays a well-posed question. ## Working an article to done Articles and milestones both move through open, in progress, complete and cancelled, and a completed or cancelled one can be reopened. Three rules are enforced rather than left to good intentions. Completing a milestone requires evidence. If nothing is attached, Zovos asks for it before recording the completion. The evidence can be a note naming what proves the work was done, such as the minutes, the filing or the memo, or a document already in the library. "Done" with no pointer is the claim an examiner discounts. An article cannot be completed while any of its milestones is still open, because a rollup that says otherwise is a number that means nothing. The action itself cannot move to awaiting termination while any article is still open, because you do not ask an agency to terminate an order you have not finished. You amend the action from the screen, to correct its header or to move it to awaiting termination and then terminated. Recording a termination requires the agency's termination date and a rationale, and Zovos stamps who recorded it from the signed-in session. ## Independent validation Agencies increasingly want remediation validated and sustained before they terminate an order, and an action can be set up to require both. When **require article validation** is on, an article cannot be completed until someone independent of the work has validated it. **Open an independent validation** names the validating line, internal audit or second line, and the procedure. **Conclude the validation** records the outcome. Internal audit concludes from a reviewed workpaper and the second line from a filed document. The article's owner, the action's owner and anyone who completed the article or its milestones cannot validate it. A **sustainability** period in days sets how long every validated article must hold before the action can move to awaiting termination. Both settings can be amended while the order runs, and tightening them does not reopen articles already completed. ## Progress reports and the calendar Progress reports submitted to the issuing agency are logged against the action: the period covered, the date submitted, who it went to, and a note. **Log a progress report** records one your team wrote. **Generate a progress report** has Zovos compose the period's figures from live article, milestone, remediation, validation and board-oversight status and file them as a sealed PDF, dated the day it was produced. The log is create-only, so the submission history is a record rather than a working document. Milestone dates ride the same obligations calendar and reminder feed as every other deadline in Zovos. An open milestone on a live action appears there as it comes due and again once it is overdue, naming the action, the article, the agency and the owner. Dates are read against your institution's own calendar date, so one deadline reads the same on the action, on the calendar and in a reminder. ## What the examiner sees This is the one oversight surface an examiner in an active session can read, and that is deliberate. The examiner supervising a consent order is the party the order is for, and hiding your progress from them would be theatre. It is filtered hard. Every examiner grant names its regulator, and an examiner sees only actions issued by their own agency, so one agency's confidential supervisory information never reaches another agency's session. Every write is denied, and examiner mode stays read-only. ## The advisory log The advisory log is the register of second-line advisory work. Each entry records the question in the business's words, the business unit that asked, who asked, the topic, and the date received. An open question shows how long it has been waiting. Answering it records the position compliance took, the **rationale** behind it, the authority relied on, and who answered. The rationale is required, because an answer with no reasoning evidences nothing. The authority can be a citation from the shipped corpus or a label you type, such as an agency FAQ. A question that was withdrawn is recorded as withdrawn rather than deleted. An answered question can link the outcomes it led to: a governing document, a training program, a monitoring activity or a finding. The log filters on whether an outcome has been recorded, and an outcome that is removed is retired rather than deleted. A maintained advisory log is textbook self-identification evidence. It shows an institution that finds and resolves its own questions before they become findings. Unlike supervisory actions, it is not visible to examiner sessions at all. Advisory entries hold candid pre-decisional reasoning, so an institution that wants to show the log to an examiner produces it deliberately. ## Notes and limits The advisory log is written by your compliance team. There is no employee-facing intake queue and no ticketing workflow. Zovos is scoped to the GRC team, and a bank-wide help desk is a different product. Both surfaces sit in the same permission family as findings. Reading either needs findings read access, and working either needs findings write access. Milestone work, article action plans and the remediation behind them run through the shared machinery described in [Findings & remediation](docs-findings.html), and the examiner side of the story is covered in [Exam management & audit readiness](docs-exam-management.html). --- # Consumer compliance Section: Programs · Updated: 2026-10-07 · https://zovos.ai/docs-consumer-compliance.html The Compliance group of the sidebar holds the surfaces a consumer-compliance officer is examined on: the **CMS scorecard**, **Complaints**, **Disclosures** and **Marketing reviews**, with **HMDA** and **CRA** under their own heading, **Fair lending & CRA**. Each one is an oversight register. Zovos watches the program and produces the evidence, while the systems of record for case handling, filing and origination stay where they are. ## The CMS scorecard The **CMS scorecard** reads your compliance management system the way the CFPB's compliance management review does, in four pillars: board and management oversight, the compliance program, consumer complaint response, and compliance audit. Every score is computed from your registers, and there is no field anyone can type a score into. Each pillar is shown with the metric table behind it, each metric states which registers it reads and by what rule, and a metric whose inputs you have not populated is shown as a gap rather than hidden. A pillar's score is the plain average of its scored metrics, with no weighting. Each metric links through to the records behind it. **Exam binder (PDF)** exports the scorecard sealed. **Consumer-compliance exam package** assembles one sealed ZIP from the scorecard and the complaint, marketing review, training, HMDA and CRA exports, so the first-day letter for a consumer examination is one download. The copy served to an examiner withholds the complaint register, which holds consumer personal information, and its manifest lists that section as withheld. ## Complaint oversight Complaints arrive by import from your system of record. **Import complaints** takes a CSV or an Excel workbook, and a *validate only* checkbox previews exactly what would land without saving any of it. Tick it on the first pass, because an unticked import lands immediately. Each complaint carries a category, the regulation implicated, a status, and links out to a Finding, Control, Policy or Citation. Its root cause is picked from your institution's root-cause list rather than typed free, so the distribution counts like with like. Complaints that reach you through a portal or referral carry that channel's response clocks, and the screen publishes the timeline table it uses. CFPB company-portal complaints owe an initial response within fifteen calendar days of routing and a final response within sixty. A prudential-regulator referral owes one written response, customarily within thirty calendar days. A BBB referral owes an answer within fourteen days and closure within thirty, and the screen labels that as a reputational deadline rather than a regulatory one. Each clock reads on track, due soon, missed or met, on the register, in the complaint drawer, in the analytics headline, on the obligations calendar and in the exam binder. Recording the response stops that clock. Closing the case does not, because the portal deadline is not yours to close. A complaint that arrived by phone or on your website owes no clock and honestly shows none. The value is in the pattern rather than the individual case. Zovos surfaces **systemic clusters**, meaning a category and regulation combination at or above a threshold, because that pattern is the signal a CFPB examiner looks for. **Promote cluster** opens a remediation finding from a cluster, with an owner and a required rationale, linked to the complaints behind it. Distribution views break the population down by category, regulation, root cause, status and month, an exam binder PDF exports the whole picture, and the board pack carries a complaint-patterns section. Where a complaint pattern produces a finding, the finding carries the redress side of the story: how much was refunded, how many consumers were affected, over what lookback period, and where the restitution stands. Self-identification and voluntary remediation is credit an examiner can give you, and it has to be on the record before it can be given. Zovos ingests complaints for oversight. It is not the system of record, and it runs no case-handling workflow. ## HMDA The HMDA screen is a data-integrity tool. **Upload LAR** takes your loan/application register file, and **Validate** checks it against the FFIEC positional layout using a curated set of edits. Edits fall into syntactical, validity, quality and macro classes. You work the failures in bulk, setting each one to assigned with an assignee, resolved, or, for quality and macro edits only, verified as correct, and every disposition takes a note. The submission reads filing-ready once every failure has an answer. A re-upload for the same filing year is compared with the previous upload edit code by edit code, and you can promote an edit-code cluster straight into a finding. **Descriptive fair-lending screens** count, for each group the applicant reported, the applications and the actions taken, and how often a reported rate spread crossed the Regulation Z higher-priced threshold. They are screening, not analysis. Nothing compares one group with another, benchmarks a figure or calls a difference significant, and the tables are computed when you supply the file and never stored. A **fair-lending extract** produces a CSV for an external analytics partner, and a fair-lending review register tracks that engagement through not started, in progress, partner submitted, results received and complete. The partner's results are recorded as structured **Partner focal points**, so they trend from one review to the next. A review also carries a scheduled date, which publishes to the obligations calendar, so a review cycle that quietly stopped surfaces as overdue. A completed review can be promoted straight into a remediation finding. ## CRA CRA does not appear in a credit union's sidebar, and a direct link explains that the Community Reinvestment Act applies to banks and savings associations, not credit unions. The CRA program register has five tabs: Readiness, Modernization, Assessment areas, Performance context and Public file. **Delineate area** creates an assessment area and requires three attestations under §__.41. They confirm that the area consists of whole geographies, that it includes your main office, branches and deposit-taking ATMs, and that it does not arbitrarily exclude low- and moderate-income geographies. The area is then submitted for approval and becomes active only once an approver signs. An area can be edited while it is still a draft. Once submitted it is fixed, and retiring an approved one as your footprint changes is a recorded status change rather than a deletion. **Start performance-context file** opens the §__.21(b) performance-context file, and **Attach evidence** adds to it for the program as a whole or for a single assessment area. The public-file tab is a §__.43 checklist where each item is verified rather than assumed. **Export readiness PDF** produces the summary. The program profile records your total assets with their as-of date and how you keep the public file, physically or electronic-only. An electronic-only file needs a published location for each item. The **Modernization** tab is read-only and unscored. It shows the asset-size tiers with the basis for each, the August 2026 OCC and FDIC proposal to replace them, which the Federal Reserve did not join, and the citation crosswalk. Nothing on it moves your readiness percentage or sets your exam type. ## Disclosures and marketing reviews The **Disclosure inventory** records each disclosure with its product line, delivery channel, owner and review cadence of annual, semiannual, quarterly, biennial or none. Its governing text is bound to the document version that holds it, shown in a **Governing text** panel. The last-reviewed date cannot be typed. It comes from **Record review**, which names the reviewer, the date, the rationale and the version read. Zovos derives the next review date and its status, flags a disclosure whose review has gone stale, and publishes both to the obligations calendar. Each disclosure is linked to the citations it satisfies, and reg-change impact analysis traverses those links, so when a rule moves the disclosures affected surface without anyone having to remember which ones they were. Marketing review is pre-use review of advertising, scripts and disclosure copy through a UDAAP lens. **Log review** starts one and freezes the review checklist at creation, so a later change to the template cannot alter what was reviewed. You work each checklist item as pass, fail or not applicable, and a review can be tagged to a partner program so it counts in that program's advertising oversight. **Run AI first-pass** puts the Ad Screener over the material. It flags trigger terms and suggests checklist dispositions, each with a confidence score, and every suggestion has to be accepted or dismissed by a person. Attach the materials, then **Submit for approval** with an **Approved until** date. The outcome is approved, approved with conditions, or rejected. An approval with conditions is not in force until someone uses **Record conditions met**, which stamps who, when and what the conditions were verified against. That expiry date is the point. As it nears, the review is badged expiring soon and then expired, and it becomes a reminder source in the obligations calendar with a re-review action. A re-review shows the earlier decision and its checklist beside the new one. Advertising sign-off carries a date and is never permanent. **Export review file (PDF)** produces the packet for the exam binder. ## Dates the rule fixes Most compliance deadlines recur on a cadence your institution sets. Some are pinned to the wall calendar by the rule itself, and those ship as seeded obligations rather than as something you have to remember to create. Among them are the March 1 HMDA loan/application register submission and CRA loan data, quarterly HMDA reporting for the larger filers it reaches, the April 1 currency date for the CRA public file, small-business lending data under Regulation B, and the annual privacy notice under Regulation P. The same catalogue carries the fixed-date items belonging to other programs, including the AML/CFT program's board approval and independent testing. Each entry says whether the date is **statutory**, meaning fixed by the rule, or **institution-set**, where the rule fixes the frequency and your own calendar fixes the date. Keeping those apart matters, because a board-cycle date presented to an examiner as a statutory one is a problem you created yourself. Each entry also carries an applicability switch, so a requirement that does not reach your charter stays visible and silent rather than vanishing from the list. ## Notes and limits None of these screens originate consumer transactions or file regulatory reports. HMDA validation uses a curated edit subset, so it complements rather than replaces your filing tool's own edit checks. Fair-lending and disparate-impact analysis is a partner seam. Zovos captures the methodology, the segments and the results your partner produced, and does not compute them. Assessment content ships for this lane too. It includes marketing and UDAAP by product, a CRA self-assessment, and per-regulation packs covering Regulations E, Z, DD and CC, RESPA, the fair-credit-reporting rules and the servicemember rules. They run in the assessments register described in [Risk management](docs-risk-management.html). --- # AML/CFT program & training oversight Section: Programs · Updated: 2026-10-07 · https://zovos.ai/docs-bsa-program.html The **AML/CFT program** screen answers the question an AML/CFT officer is asked at every examination: show me your program, pillar by pillar, and show me the evidence behind each one. It is assembled from the records already in Zovos rather than from a separate narrative document. It sits in the **AML/CFT & fraud** group of the sidebar beside **Fraud losses** and the **Fraud case log**, which give the officer the oversight record for fraud. **Training oversight**, in the Compliance group, is covered here too because training is one of the pillars and is usually the hardest to evidence. ## The five pillars The screen is organised around the five statutory pillars set out at 31 CFR 1020.210(b): internal controls, independent testing, a designated AML/CFT officer, training, and risk-based customer due diligence including beneficial ownership. Each pillar is a card. The card is computed from your live registers of controls, monitoring reviews, training programs and risk assessments, so it moves as the program moves. Alongside the pillars, the screen shows the freshness of your BSA/AML risk assessment and your coverage of the FinCEN national priorities. ## Designating evidence The pillars are not auto-filled by guesswork. The AML/CFT officer explicitly designates which records evidence which pillar, through **Edit designations** and **Save designations**. A pillar with nothing pinned to it reads **Not designated** rather than showing a plausible-looking score. That is a deliberate design choice. An examiner asking "what evidences your independent testing pillar" should get the officer's answer rather than the software's inference. Because the designation is a recorded act by a named person, the answer is also defensible a year later. ## Risk assessment and national priorities The BSA/AML risk assessment runs in the assessments register, and Zovos ships assessment content packs for BSA/AML and OFAC so you are not building the question set from a blank page. You can clone one of those packs and edit it, or author your own from scratch, while the shipped pack stays read-only. Assessments run per cycle, capture design and operating effectiveness, and close by attestation. A national-priorities panel shows which FinCEN priorities the assessment addresses and which it does not. See [Risk management](docs-risk-management.html) for how assessments, challenges and attestation work. Freshness matters as much as content. The program screen surfaces when the risk assessment was last completed, so a stale assessment is visible before an examiner finds it. The program's other recurring obligations are seeded onto the obligations calendar rather than left to memory. The board's approval of the AML/CFT program and its independent testing are each flagged as a date your institution sets against a frequency the rule fixes. The OFAC blocked-property report sits alongside them, and the rule fixes its date outright. ## Board reporting **Generate AML/CFT board report** produces the report the board receives and seals its claims into the proof ledger. Every figure in the report resolves back to the records that produced it, so a claim can be re-verified later as unchanged, drifted, or no longer answerable. That is what turns a board report from a snapshot into evidence. ## Fraud oversight Two screens in the AML/CFT & fraud group give the officer the fraud side of the program. Neither one investigates fraud. They record what happened and what was decided. ### Fraud losses **Fraud losses** is the loss-event register pinned to its two fraud event types, internal fraud and external fraud. It is the same register as **Loss events** in the Risk group with a fixed filter rather than a copy, so you capture, edit and close a fraud loss here exactly as you would there, and closure still runs through independent approval. See [Risk management](docs-risk-management.html). A fraud loss also carries the channel the fraud came through. The channels are check, debit card, credit card, ACH, wire, instant payment, account takeover, new account, loan, cash and other. You can filter the register by channel, and the analytics break fraud losses out by channel, so a shift from check fraud to account takeover shows up in the numbers. Where your institution has key risk indicators fed by a fraud event type, they appear as a strip above the register with their current status. ### The fraud case log The **Fraud case log** is a second-line oversight log of fraud cases escalated for a SAR decision. It is not a case-management system. Investigation and case work stay in your monitoring or case system, and the log records the decision and the trail behind it. **New case** records a title, the fraud type, an optional channel, the date the fraud was detected, an optional amount at risk, and an owner. You can add the case reference from your case system, name that system, link the case to a booked loss event in the register, and mark the case as an insider suspect. Every case form tells you not to enter customer names, account numbers or SAR narrative, because those stay in your case system. The SAR decision is two-person. One member records a **recommendation** to file a SAR or not to file one, with a required rationale. A different member then **decides** it, either agreeing and recording the decision or returning it to the recommender, again with a required rationale. Nobody can decide their own recommendation, and the database refuses it as well as the screen. The decision is due 30 calendar days after the detection date, the window 31 CFR 1020.320(b)(3) sets for filing, and a case still waiting for a decision after that date reads overdue. Each case shows where it stands: no decision, awaiting decision, file SAR, SAR filed, or no SAR. After a decision to file, you record the date the SAR was filed. That date cannot be earlier than the decision or later than today. A case closes only once its decision path is complete, meaning a decision not to file, or a decision to file with its filing date recorded. There is no action to reopen a closed case. ### Who sees a fraud case The log is deliberately compartmented. The SAR itself, its narrative and its subject never enter Zovos. What the log holds is the decision, the rationale for it, and the dates. A SAR decision sends no notification, raises no approval in the shared queue, and writes nothing to the decision register or the proof ledger, because each of those would carry the decision outside the people entitled to it. The audit trail entries for a case are withheld from anyone who cannot read the AML/CFT & fraud area. A case marked as an insider suspect is absent, rather than refused, for any member whose role does not see internal notes, so a suspect cannot learn that the case exists. An examiner whose grant covers the AML/CFT program can read the log, and nobody in an examiner session can write to it. ## Training oversight **Training oversight** is a register of the training programs your institution runs. It is not a course library. Each program records its audience, its cadence and, most importantly, the **audience size**. The audience size is the denominator for completion until you import a roster, described below. Without a denominator, a completion percentage means nothing. You record completions two ways: **Record completion** for individual entries, and a bulk import of an export from your learning management system, which takes a CSV or an Excel workbook. Re-importing the same file does not double-count anyone. Rows are matched on your learning system's own record identifier where the file carries one, and otherwise on the program, the person's name and the period, so a file with no identifier column still dedupes. Each program also carries a citation crosswalk to the rules that training actually teaches. When a regulatory change lands, impact analysis follows those links and proposes the training affected, instead of relying on somebody remembering which course covered the rule. From that, Zovos computes completion percentage and **delinquency**, which is the audience size minus completions for the current period. Programs carry a status of current, due soon, overdue, unknown, or retired. Unknown is used honestly rather than as a default. A program with no cadence to schedule against has no next due date, so it reads unknown instead of reading as on track. **Exam report (PDF)** exports the register with its completion figures for the binder, and each program's own drawer exports its completions as a CSV. A typed audience size gives you a count of delinquent people but not their names, and an examiner asks for the list. Each program's drawer therefore carries a **roster** of the people expected to complete it. **Add person** adds one name, and **Import roster** takes the expected-audience list from your learning or HR system as a CSV or an Excel workbook. Once a roster exists, the completion rate is measured against the people it names rather than the typed headcount, and each person reads completed, delinquent or excused. Someone who has left the institution or whose access is suspended is excused, so they drop out of the denominator instead of counting as delinquent, and the reason is shown beside them. **Delinquent only** narrows the list, and **List (CSV)** exports exactly the rows on screen. A program with no roster keeps working from the typed headcount. ## Notes and limits Zovos never authors or delivers a course. It records that training happened, to whom, and when. That is the oversight half of the pillar. Zovos is also not a transaction-monitoring or case-management system, and it is not meant to be. Where you connect an AML case platform, what flows in is program-level oversight metrics, such as alert and case volumes, for reporting and trend analysis. Alerts, SARs and CTRs stay in your AML system of record. Some AML platforms connect by API and others by file import. The choice is deliberate, because this is an oversight seam and not a transactional one. Independent testing of the AML/CFT program is usually performed by internal audit or an external firm, and the results are tracked as engagements and findings. See [Internal audit](docs-internal-audit.html) for that side of the pillar. --- # Model & AI governance Section: Programs · Updated: 2026-10-07 · https://zovos.ai/docs-model-ai-governance.html Model and AI governance in Zovos is the **Model & AI** group of the sidebar, which holds two items. **Model risk** is your model risk management screen, and it has two tabs. The **Model inventory** tab is the register of your institution's models. The **Model governance** tab is the pack that documents how Zovos governs its own AI agents, for when an examiner asks about the vendor sitting in your compliance stack. **AI systems** is your inventory of AI use cases, including the AI embedded in software you bought. Each tab of Model risk appears only for people who can read it. At a smaller bank or credit union this hat usually sits on the CRO, the CCO, the CFO, or a fractional model risk officer. A larger institution typically gives it to a dedicated model risk team. ## Two registers, on purpose The model inventory and the AI systems registry are deliberately separate registers that cross-link, rather than one list with a checkbox. They answer different questions. A model is a quantitative method producing an estimate you rely on. Examples are allowance, asset-liability, credit scoring, fraud, AML/CFT transaction monitoring, valuation and stress testing models. An AI system is any use of AI in the institution, including tools with no quantitative output at all: an assistant, a chatbot, a document summariser, a feature switched on inside a product you already licence. Forcing them into one register makes both worse. Cross-linking means a vendor model that is also an AI system appears in both without duplicated data. ## Model inventory and tiering Each model records its type, its deployment type, the vendor (linked to your third-party register), the version, the first-line owner, the developer, its purpose, and its inputs and outputs. Deployment types include **spreadsheet or end-user computing**, because a spreadsheet the institution relies on is a model whatever it is stored in. Tiering runs on the same 5 by 5 engine as the risk register, so the tier is derived rather than typed. Each model carries a written tier rationale. The model record itself moves through draft, pending approval, changes requested, approved, and retired. A returned submission lands in changes requested. The model also has a separate lifecycle state of proposed, in use, under review, or retired. A **use approval** under maker-checker gates whether the model may be used at all. The model's **Change log** is the only way its version moves. Each change records what changed, who made it, and a materiality determination made at the time. Entries are append-only, so a change recorded in error is corrected by recording another one. A material change is acted on rather than noted. The model goes under review, its next validation is pulled forward, and a model already approved for use goes back through the use approval. The model's **Dependencies** panel maps which models feed it and which it feeds, read from the links you draw between models, so you know what sits downstream of a change. A **completeness reconciliation** sweeps your vendor register and requires every active vendor to be accounted for. Either it maps to a model, or someone records an explicit acknowledgement that it has none. Vendor-embedded models hiding in the vendor list are one of the most common examination findings in this area, and the reconciliation exists to close that hole. ## Validation and independence Validations carry a type of full, limited scope, targeted review or annual review. They also carry an explicit **independence** flag distinguishing an external validator from an internal but independent one, along with the validator's name or firm. A validation moves from scheduled to in progress to pending sign-off to complete. Completion is a governance act rather than a field you edit. The approver has to be someone other than the person who submitted the validation and other than the model's owner or developer. That constraint is what makes the record mean something. Each validation also has a workpaper that records the work itself. It has three pillars, which are conceptual soundness, process verification and outcomes analysis. Each pillar carries a rating of not assessed, satisfactory, satisfactory with conditions or unsatisfactory, a narrative, evidence, and preparer and reviewer stamps. Findings raised on the workpaper become ordinary limitations in the same register as every other limitation. Where an outside firm performs the validation, **Send upload link** gives its delivery contact a time-boxed, revocable link to deliver the report and workpapers without an account or a seat. What the firm delivers lands as unverified evidence on that validation, and the link reaches nothing else. Validation cadence is set per model and may be annual, semi-annual, quarterly, every two years, every three years, or no fixed cadence, and the choice carries a written rationale. Supervisory guidance on model risk management is explicitly risk-based, and a proportionate cadence at a small institution is a defensible decision when it is documented as one. ## Limitations and ongoing monitoring Validation findings are recorded as **limitations**, each with a severity, a compensating control, an owner and a target date. Dispositions run open, acceptance pending, then accepted or remediated. Accepting a limitation runs through maker-checker and requires a time bound once the risk is high enough to matter. The gate fires on either axis: when the limitation's own severity reaches your institution's hard-block tier, or when the model's residual tier does. A low-severity limitation on a critical model is gated too, which is the case people expect to slip through. Remediating one requires an evidence reference. A limitation can be promoted into the findings register so it inherits the same SLA, closure separation of duties and corrective-action-plan machinery as every other issue. **Ongoing monitoring** gives each model a plan with a cadence and named metrics. Each metric states its threshold and can carry a unit and numeric lower and upper bounds. Each cycle produces an append-only attestation with a result of within thresholds, breach, or not performed. A breach requires a written summary and can open a linked limitation. You can import the recorded value of each metric for a period from a CSV file. Re-importing a period restates its value rather than adding a second one. Each metric's recorded values are charted against its bounds, and Zovos proposes a result of within thresholds or breach from them. The proposal sits beside the owner's attested result and does not replace it. The owner's attestation stays the decision, and an attestation that departs from the proposal requires an override rationale. ## The AI systems registry The AI systems registry is your shadow-AI inventory. Every AI system is registered, whether it was built, bought, or quietly enabled inside a product. Each one is risk-tiered on the same 5 by 5 model and mapped against AI control sets from the shipped corpus, including the NIST AI Risk Management Framework and financial-services and ISO-derived AI management content. Systems move through intake, assessment, approval, approved, review and retired. The go-live gate runs under maker-checker, so no AI system reaches production because someone flipped a field. Periodic reviews close with an outcome of tier confirmed, re-tiered, or retire system. New use cases arrive through intake. The proposer's answers derive proposed tier inputs, and the second line works them from an **Intake queue** that shows what is waiting, what is flagged and the proposed likelihood and impact. Each proposal is confirmed one system at a time with the answers on screen, and there is no bulk confirm. ## Governing the AI inside Zovos The **Model governance** tab of Model risk holds the pack for the AI you are examined on because you bought it from us. It is assembled from real agent-run telemetry rather than written as marketing copy. It contains an intended-use statement for each agent, its validation telemetry, token usage and cost controls, and a section-by-section mapping to supervisory expectations for model risk management and transaction-monitoring validation. **Export PDF** puts it in your binder. An examiner session whose grant covers the frameworks the pack maps to can open the Model governance tab and read the underlying agent runs inside the grant's frameworks and date window. Runs of the internal audit agents stay behind the internal audit wall. Note the boundary. This pack reports on the platform's own model usage. Your models report through the model inventory and your board pack. ## Notes and limits There is no statistical computation anywhere in this area. Bias and fair-lending reviews are evidence capture. You record the review type, the performer, the methodology, the protected-class segments and the results your partner produced. Zovos does not run disparate-impact testing itself, and the analysis function says so rather than guessing. Capture is not the whole of it, though. A review carries a scheduled date and publishes it to the obligations calendar, so a review cycle that quietly lapsed reads as overdue, and a completed review can be promoted straight into a finding. Drift monitoring is an attestation trail rather than telemetry. Zovos records the cadence, the metrics, the thresholds, the metric values you import and each attested result, and proposes a result from those values. It does not stream live metrics from your models or compute back-tests for them. A framework crosswalk is a mapping and never certification evidence. Zovos is built for United States supervision, and we make no claim of EU AI Act coverage. --- # Credit risk review Section: Programs · Updated: 2026-10-07 · https://zovos.ai/docs-credit-risk-review.html Credit risk review, often called loan review, is the independent check that a community bank or credit union rates its loans honestly and catches problem credits early. In Zovos it is the **Credit risk review** group of the sidebar, which holds three screens: **Loan universe**, **Credit reviews** and **Review exceptions**. The loan review officer and the credit risk review staff work here, an approver who holds risk sign-off authority signs each review off, and senior management and the board read the exceptions that stay open. ## The loan universe A review samples from a **loan universe**, which is the loan population as of one date. Choose **New universe**, record the as-of date and the source, such as the commercial portfolio from your core trial balance export, and the universe opens as a draft. You fill a draft two ways. **Import a loan listing** takes a CSV or an Excel workbook exported from your core or loan system, reading the first worksheet with a header row. Headings ignore case and spacing, and common core export names such as Loan Number, Risk Rating, Loan Officer and Approved By are recognized. Rows with a problem, and loan numbers already in the universe, are listed and skipped while the other rows import. Tick the preview option to validate a file without saving any of it. You can also enter loans one by one. Each loan carries its loan number, a description, a segment, the product, the commitment and outstanding balance, the origination, last renewal and maturity dates, the officer's risk rating and regulatory classification, and its flags. The flags are watch list, policy exception, insider, nonaccrual, restructured and days past due. Each loan also records who originated it and who approved it, which is what the independence check below reads. The segments are commercial real estate, commercial and industrial, construction and land, agricultural, residential mortgage, home equity, consumer, member business, and other. A credit is its loan number and a description. Every loan entry screen asks you not to enter borrower names or other nonpublic personal information, and Zovos does not connect to your core. When the population is complete, **Lock universe** records the loan count, the total commitment, a SHA-256 content digest, your name and the time. A locked universe can never change. No loan can be added, edited or removed, and the universe cannot be deleted. Samples are drawn only from a locked universe, so the population a review rests on is the population you locked. A draft that is no longer needed can be deleted, and the deletion stays in the audit trail. ## Scoping and sampling a review **New review** on the Credit reviews screen starts a review against one locked universe. You record a title, an optional scope narrative, the segments in scope and a lead reviewer from your team roster. The scope is risk-based. You can require every loan with a commitment at or over a threshold, and every loan that carries a chosen flag, including adversely classified credits. Required loans are always reviewed, and the rest of the in-scope population is sampled. The sample method is random, statistical, judgmental or full population. A random or statistical sample is drawn from a recorded seed, which you can supply or let Zovos generate. The population is ordered by loan number before the draw, so re-performing the same selection produces the same credits regardless of the order of the original file. A statistical sample records its confidence level and its tolerable and expected rates, and a sample smaller than that basis supports is refused rather than accepted. A judgmental sample names its loan numbers. **Select sample** takes the required loans plus the sample, seals the selection with a digest and moves the review from planning to fieldwork. The scope and the method cannot change after that. The **Credit reviews** list shows each review's universe as-of date, lead reviewer, status, credits completed of the total, coverage and creation date. The review header shows how many credits are complete and what share of the in-scope commitment the sampled credits cover. The review opens on four tabs: **Scope & selection**, **Credits**, **Independence** and **Exceptions**. ## The independence rule Each sampled credit is assigned to a reviewer. Zovos checks the reviewer, by team member record, against the originator and every approver the locked universe records for that credit. A reviewer who originated or approved a credit cannot be assigned to it or record its result, and there is no override. The same records decide who cannot sign the review off, which is the reviewers and everyone who originated or approved a sampled credit. Some things Zovos cannot know, and the Independence tab says so. A name on a loan that matches no single team member leaves the credit **Unverified**, and the assigned reviewer then attests to having no involvement in it. Whether reviewers report to the lending function, or are paid in a way the assigned ratings could influence, is attested by the lead reviewer. The tab opens with **Cannot sign off this review**, which lists each person who cannot sign the review off and why, before anyone tries. A name that matches no single team member is marked as such. Below that, the tab counts the credits that are clear, unverified and attested, unverified and still needing attestation, and not yet assigned. ## Reviewing a credit For each sampled credit the reviewer records whether it was reviewed. A credit that was not reviewed needs the reason. A reviewed credit needs the reviewer's answer to one question, which is whether they agree with the officer's rating, and a written conclusion. A disagreement also records the reviewer's own rating, an optional regulatory classification of pass, special mention, substandard, doubtful or loss, and a target date for correction. Recording a disagreement also opens a risk-rating exception for that credit, at most one per credit, so a rating dispute cannot be noted and then forgotten. **Submit for sign-off** lists everything that still blocks submission at once. A review cannot be submitted with no sampled credits, with a credit still pending, with an unverified credit whose reviewer has not attested, or before the lead reviewer has attested. Submitting sends the review through the shared approvals queue to an approver holding risk sign-off authority, and fieldwork stops unless the approver returns it. Sign-off records the approver, the rationale and a manifest digest, seals the event in the proof ledger, and from then on the review and its credits cannot be changed. ## The review report A signed-off review offers **Report**, which generates the credit risk review report in one of two editions, as a PDF or a Word (DOCX) file. The **Internal report** covers every credit and reviewer. It holds the scope and as-of date of the universe, coverage, each credit reviewed with its reviewer and review date, the officer's rating against the reviewer's with the downgrades, the exceptions by status with their corrective action, person responsible and target date, the overdue exceptions called out, and the independence attestations. The **Board edition** holds aggregates only, with no loan numbers and no names. Zovos stores the file and seals it on the proof ledger. The board pack carries a **Credit risk review** section in aggregate. It covers the reviews signed off in the twelve months to the pack date, with credits and commitment reviewed against the scope, the ratings the reviewer disagreed with, downgrades and upgrades, exceptions by status, and the independence attestation. It also counts the open exceptions past their target date on any signed-off review, whatever the review's age, and how many days past target the oldest one is. An overdue exception therefore stays in front of the board after its review leaves the twelve-month window. Each figure is a sealed claim that resolves back to its records. See [Board & governance](docs-board-governance.html). ## Review exceptions A review exception is a deficiency found in fieldwork. You log it on the review's Exceptions tab, against a sampled credit or the review as a whole. Each one records its type, its severity of high, medium or low, a description, the corrective action, the person responsible and a target date. The types are risk rating, documentation, underwriting, approval, covenant, collateral, policy and other. The **Review exceptions** screen lists exceptions across every review and filters them by open, overdue, resolved and promoted, by type and by review. An open exception past its target date reads overdue, so it can be reported to senior management and the board. Resolving an exception records how the follow-up was verified, and it must be done by someone independent of the credit. That person cannot be the one responsible for the corrective action, or an originator or approver of the loan, and there is no override. A risk-rating exception also records which rating stands, either that the lower rating prevails or that the reviewer concurred with the officer. An exception can instead be promoted into the findings register as a self-identified finding linked back to it, after which it follows that finding rather than being resolved here. See [Findings & remediation](docs-findings.html). ## Notes and limits Examiner sessions never see the Credit risk review group. Zovos does not rate loans, pull data from your core, or decide a classification. It records the population you locked, the sample drawn from it, each reviewer's conclusion, and the follow-up on what they found. The group is part of the credit risk review job family, which arranges the sidebar for loan review staff. See [Roles & permissions](docs-roles-permissions.html) and, for the buyer-facing summary, [credit risk review](role-loan-review.html). --- # Internal audit Section: Programs · Updated: 2026-10-07 · https://zovos.ai/docs-internal-audit.html Internal audit is the third line, and Zovos treats it as structurally separate rather than as another module with a different label. The audit universe, the annual plan, engagements, workpapers and issued reports live behind their own permissions, and the people internal audit audits cannot see the work in progress. The chief audit executive and the audit manager work here, and the audit committee approves the plan and receives the reports. ## The independence wall The Internal audit group is hidden entirely unless you hold internal-audit read access. It is absent rather than greyed out, the same as every other permission in Zovos. The wall is more than a hidden menu. Internal-audit titles and rationale are redacted at the source before they can reach audit rows, notifications, chat integrations or email, so a name cannot leak through a Slack message about an approval. Proof-pack exports produced by someone without internal-audit access contain hash-only stubs for internal-audit rows, which still verify offline. The existence of internal-audit records is visible, but their content is walled. Two consequences are worth knowing. The account with the broadest rights over the compliance program, usually the CCO, cannot see in-progress internal-audit work, because the CCO is an auditee. The internal audit role, for its part, cannot approve risk or control decisions, because those are management decisions internal audit will later audit. No role on the internal audit side can hold first- or second-line write permissions either. It reads those registers and writes only its own engagement work and findings. ## The audit universe and annual plan The **audit universe** is the set of auditable entities, each with its own display ID. Entities are scored on five inherent-risk factors, which derive a tier and a coverage state. The coverage state measures how long it has been since the entity was last audited, relative to what its tier requires. The risk-based **annual plan** is built from that universe. When you submit the plan for approval it is always routed to the audit committee, regardless of how your delegation matrix is configured elsewhere. That routing is not editable, because a management-approved audit plan is not an audit plan. ## Engagements and fieldwork An engagement moves through planning, fieldwork, review, reporting, and then issued or closed. Transitions are forward-only, and each one requires a rationale. You cannot quietly move an engagement back to planning when the fieldwork gets uncomfortable. Each phase change also needs a supervisory **phase gate**, signed before the engagement can leave its current phase. Phase gates are signed on the internal audit side only. The board holds internal-audit approval authority but is not a signer for a phase gate and does not see the gate or its preview, because the preview is the work program. If the engagement is re-scoped after a gate is signed, the signature reads stale and the gate needs approving again. The engagement is organised in tabs: - **Planning.** This tab holds the append-only planning record of risks considered, objectives, scope, criteria and resources, with the phase gate and the history of every gate submitted. - **RCM.** The risk and control matrix is the test plan line by line. - **Workpapers.** Workpapers hold the evidence, under an enforced separation between preparer and reviewer. The person who prepared a workpaper cannot sign it off. - **Sampling.** This tab plans and works the test samples. - **Draft findings.** Findings are written in condition, criteria, cause, effect and recommendation form. - **Time.** This tab records effort against the engagement. - **Validation.** A follow-up engagement retests published findings here. A retest concluded as validated is what lets the finding be submitted for closure where your institution requires validated closure, and a failed retest leaves it open. - **Review notes.** A reviewer leaves a note on one piece of fieldwork, with a thread and a resolution. An open review note blocks its workpaper's reviewed stamp, and a coaching note never does. - **Requests.** This tab sends requests for information to auditees. Only a request's title and detail cross the independence wall, and internal audit's own notes on the thread stay on its side. - **AI drafts.** Agent proposals appear here with their citations. Nothing becomes an engagement record until a person accepts it with a rationale, and accepted content lands as a draft that still needs its preparer and reviewer stamps. - **Confirmations.** This tab handles third-party audit confirmations. - **Reliance.** This tab records where you relied on another assurance provider. - **Independence.** Each team member records a conflict-of-interest declaration for the engagement, and Zovos shows cooling-off flags it computes from their prior role and the engagement period alongside it. - **Report.** This tab assembles the output. - **Trail.** This tab shows the engagement's own audit history. - **Team.** This tab records who is staffed on the engagement, in which role, for how many hours. Once a reviewer or supervisor is named, workpaper review stamps must come from one of them. A sample plan records the population, the method, and why that method fits the test. The population entry holds its description, its source and its size. Methods are random, judgmental, statistical, or full population. Zovos draws the selection itself from a recorded seed, so re-performing the same plan produces the same items, which is what makes a sample defensible a year later. You can supply an ordered population list. Where you do not, the drawn items open as positions in the population. A plan moves through draft, selected and concluded, and each item is worked to pass, exception or not applicable. A statistical plan states its confidence level along with its tolerable and expected deviation rates, and one sized below the minimum its own stated basis requires is refused rather than quietly accepted. Concluding writes the sample's counts back onto the risk-and-control matrix line without touching the auditor's own effectiveness conclusion. Where a co-source firm does the fieldwork, **Import co-source** on Workpapers takes the firm's manifest as a spreadsheet and lands one workpaper per row, stamped with the firm, the delivery date and the firm's own reference. Sign-offs on those rows are recorded as *imported* rather than performed. They carry the historical date supplied and a statement of where they came from. Preparer-and-reviewer separation is still enforced row by row. The manifest does not ingest the binary evidence itself. That evidence rides the document pipeline and is linked by reference. ### Independent testing of the AML/CFT program An engagement tagged with the BSA framework counts as independent testing of the AML/CFT program, whether your own audit staff, a co-source firm or an outside tester does the work. The FFIEC BSA/AML Examination Manual expects that tester to stay out of the program being tested, including its policies and its training, so Zovos checks each person's own history rather than their role. Someone who, during the tested period, wrote, published, submitted or approved the designated AML/CFT program or customer due diligence policy, or created or edited an AML/CFT training program, cannot prepare or review that engagement's workpapers, issue its report, approve the report or sign its phase gates. The refusal names each conflicting act and its date. When the engagement has no period set, the trailing twelve months count. Board members are exempt, because the board approves the AML/CFT program and receives the tester's report. If nobody else on the internal audit side can do the work, the act can go ahead with a written justification, and the audit trail records it as a sole-operator decision under this rule, so the exception is visible to your examiner. ## Reports and findings **Issue report** runs under maker-checker. Every report carries a rating of satisfactory, needs improvement, or unsatisfactory. There is no fourth option and no unrated report. An issued report that published no findings says so on its face, as a clean opinion. Once a report is issued, its findings land in the shared findings register alongside examiner matters and self-identified issues, inheriting the same owner, due date, SLA aging, root cause and corrective action plan machinery. Internal audit does not maintain a private issue list that management tracks separately. See [Findings & remediation](docs-findings.html). ## Reliance and the QAIP **Reliance** lets you rate the work of another assurance provider and rely on it rather than re-testing the same control. That provider can be second-line monitoring and testing, an external firm, or a regulator's own work. The rating and the rationale are recorded, so the decision to rely is itself auditable. The **QAIP** panel sits below the engagement list, and below the issued reports in the board's view of the screen. It tracks your quality assurance and improvement program. That means periodic internal self-assessments with a conformance rating of conforms, partially conforms, or does not conform, and the clock to your next external quality assurance review. That clock is a standing question at examination, and it is easier to answer when it is on the screen. ## What the board sees Directors and the audit committee get a different view of the same screens by design. They see the approved plan and **issued** reports. In-progress fieldwork, draft findings and unfinished workpapers stay with the audit function until the report is issued. The committee approves the plan, any mid-year amendment to the approved plan, and the report. A plan amendment is proposed, frozen as it was put, and routed back to the Audit Committee rather than applied quietly when the universe re-scores. The committee does not approve the working papers or sign engagement phase gates. ## Notes and limits Zovos manages the audit process and its records. It does not perform the audit. There is no core banking connector, so a population is described or supplied by you. The drawing of the sample, the testing and the conclusion then happen here. If your institution outsources internal audit entirely, the same engagements, workpapers, sampling and reliance records support the firm's work. That firm is admitted through an access group started from the **External auditor / independent AML/CFT tester** preset rather than through the built-in internal-audit role. The preset gives a custom role on the internal audit side of the wall that reads every area and writes only engagement work, with no approval, settings or first- or second-line write permissions. Being on the internal audit side is what places the firm inside the wall, and the independence constraints then apply to whoever holds the role. See [Roles & permissions](docs-roles-permissions.html). For the buyer-facing summary, see [audit preparation](solution-audit.html). --- # Board & governance Section: Programs · Updated: 2026-10-07 · https://zovos.ai/docs-board-governance.html Board governance in Zovos covers what directors see, what committees record, and how authority to decide is delegated. Directors get a portal built for oversight rather than a read-only copy of the compliance workspace. Committee secretaries record meetings, minutes and challenge. Owners configure who may approve what. ## The board portal Board principals land on the **Board portal** instead of the Dashboard. It sits in the **Board** group of the sidebar, which reads **Supervisory Committee** at a credit union. It is a consumption surface. It holds everything a director needs to prepare for a meeting, in the order they would ask for it. The portal shows what needs the board's decision, which risks sit above appetite, key risk indicator status against the thresholds the board set, and open findings by age with examiner matters flagged. Below that sit meetings, committees, and the sealed board packs with their content hashes. The **Board packs** panel holds every sealed board report family, each labelled by kind. They are the board pack itself, the AML/CFT board report, the TPRM program report, the ERM committee package, and the annual information security program report described in [Cybersecurity](docs-cybersecurity.html). **KPI trends** plots those headline figures across pack generations, each point marked improved, worsened or unchanged, so directors see the direction of travel rather than one quarter at a time. Every point is what a sealed pack actually reported at the time. Nothing is recounted after the fact, which is the only way a trend line and a signed pack can agree. **My oversight packet** is a personal, exportable record of a director's own oversight trail. It shows what they saw, what they asked and what they approved. Opening a pack records that this director took that pack off the shelf, so the packs-received section rests on an artifact-level receipt rather than an assertion that something was circulated. Individual director accountability is increasingly a supervisory theme, and a director should not have to reconstruct their own record from email. The board role reads everything except internal work product and agent runs, and approves policies and internal-audit plans and reports. It writes nothing into operating records. See [Roles & permissions](docs-roles-permissions.html). ## Committees, meetings and minutes Committees are created and seated on the board portal's **Committees** panel. That panel is the only place a committee comes into existence, and a name already used by another committee is refused. Meetings hang off a committee and move from planned, to in session, to minutes pending, to minutes final. A meeting's date registers on the obligations calendar with every other deadline. **Edit roll** records attendance, including who was absent. Agenda items are typed as an approval, a report, a discussion, or approval of prior minutes, so the agenda itself distinguishes decisions from information. **Submit minutes** seals a manifest of the minutes and enqueues an independent approval. Minutes are approved by someone other than the person who wrote them. **Download minutes (PDF)** on final minutes produces the record with a SHA-256 integrity footer, so a copy handed to an examiner can be proven to match what was approved. Downloaded before approval, the same PDF is watermarked as a draft that is not approved and carries no integrity footer. A draft cannot be mistaken for the record. ## The challenge record The **challenge record** is the part of a meeting that examiners actually care about. It is the evidence that the board challenged management rather than received a presentation. Entries are attributed and append-only, and typed as a question, a concern, a challenge, a direction, a management response, a note, or a recusal. Nothing is edited or deleted. A correction is a new entry. A **direction** can do more than record itself. Attach a directed action to the entry and Zovos creates a finding in the same transaction. The finding is sourced as a board directive and has an owner, plus a due date where you set one. A directed action with no date files as unscheduled. A direction recorded without a directed action stays a minute entry and nothing more. Used with the directed action, this closes the most common gap in board records. That gap is a board that directed something while nobody can show what happened next. ## Board packs and claim lineage A board pack is sealed when it is generated, and its content hash is recorded in the proof ledger. Every figure in it is registered as a claim that resolves back to the records that produced it. Later, you can re-verify the pack. Each claim comes back as **unchanged**, **drifted**, or an unknown query. Drifted means the underlying records have moved since the pack was sealed. This is how you answer "was that number right when we approved it" months after the meeting, and it is what the [Exam management](docs-exam-management.html) lineage panel reads. ## Decisions and delegated authority The **Decision register** is institutional memory, and it sits at the end of the Risk group of the sidebar rather than under Board. It holds a recorded decision with its rationale, who approved it, and a supersession chain when a later decision replaces it. You record which earlier decision a new one supersedes as you create it, and the chain is then navigable hop by hop from the decision drawer. When the question "why did we do it this way in 2024" arrives during an examination, the answer is a record rather than a search of somebody's inbox. **Governance settings** is where authority is configured. The **delegation-of-authority matrix** maps object type and severity to the approver roles required and the number of signers. Critical items require two distinct signers, and lower severities require one from a defined pool. Special routing is built in: an audit plan always goes to the board, and policies route by document tier. The **Authority Engine** evaluates, at the moment of decision, whether the deciding person actually held the delegated authority. It runs off, in monitor mode, or in enforce mode. In enforce mode a decision outside someone's authority is escalated rather than applied, a lapsed grant is marked as lapsed, and a decision with no covering delegation is blocked. Monitor mode is a safe way to see what enforcement would have done before you turn it on. Once the board approves a risk appetite statement, the appetite settings on this screen become read-only, reflecting the approved bands rather than allowing an administrator to edit them. ## Notes and limits Board governance, minutes and the live decision register are denied to examiner sessions as work product. What the examiner receives is the sealed pack you choose to provide. Board packs can be exported for delivery to a board portal, and some board portals connect by API while others take an export package. See [Approvals & delegation of authority](docs-approvals.html) for how a board approval reaches a director. --- # Cybersecurity & security incidents Section: Programs · Updated: 2026-10-07 · https://zovos.ai/docs-cybersecurity.html Your information security program lives in the **Cybersecurity** group of the sidebar, which holds three screens. **Cybersecurity** is the landing page for the program. **Security incidents** is the register of incidents and the notices they trigger. **Continuity (BCM)** is the business continuity register, covered in [Business continuity](docs-business-continuity.html). The group belongs to the Cybersecurity job family, which arranges the sidebar for the information security officer and the continuity lead. See [Roles & permissions](docs-roles-permissions.html) and, for the buyer-facing summary, [cybersecurity](role-information-security.html). ## The Cybersecurity page The Cybersecurity page brings the program together from records you already keep. Anyone who can read the control catalogue can open it. It reads the information security and continuity frameworks your institution has enrolled and keeps in scope. Those are the FFIEC IT booklets, GLBA including the Interagency Guidelines Establishing Information Security Standards, NCUA Chapter VII including Part 748, the FFIEC business continuity booklet, NIST CSF 2.0, the CRI Profile, NIST SP 800-53, the CIS Controls, ISO/IEC 27001, NYDFS Part 500 and PCI DSS. - **Frameworks.** This panel shows each enrolled framework with its coverage, its citations, its open gaps and its owner, and names the frameworks on the list you have not enrolled. - **Board report.** This panel tracks the annual report to the board described below. - **Security incidents.** This panel lists the open and contained incidents with the notices still due on each, earliest deadline first. This panel appears only for people who can read the incident register. - **Open findings.** This panel lists the open findings tagged to those frameworks. - **Controls.** This panel lists the controls crosswalked to those frameworks, with each control's test status of test overdue, test due soon, no test schedule or tested, and the date its next test is due. The panel heading counts the mapped controls and the overdue tests. **Continuity (BCM)** at the top of the page takes you to the continuity register. A framework mapping is a crosswalk and never certification evidence. ## The annual report to the board The Interagency Guidelines, at section III.F, expect management to report to the board at least annually on the overall status of the information security program and the institution's compliance with the Guidelines. For a bank they are codified at 12 CFR 30 Appendix B and its counterparts, and for a credit union at 12 CFR 748 Appendix A. The **Board report** panel shows that obligation from the obligations calendar with its due date and a status of overdue, due soon or scheduled, and when it was last reported. **Generate report** produces the report for the twelve months ending on the day you generate it, as a PDF, and is available to people who can edit controls. Its seven sections follow section III.F one to one. They cover overall status and compliance, the risk assessment, risk management and control decisions, service provider arrangements, and the results of testing, which include control tests, automated tests and continuity exercises. Then come security breaches or violations and management's responses, drawn from the incident register, and recommendations for changes in the program. Sections 1 to 6 are computed from your registers, and every figure is sealed as a claim that resolves back to the records that produced it. Section 7 is your information security officer's own text. **Start recommendations** opens it as a collaborative draft, and generating the report seals the current version into the report. The report is filed as a board report, so it reaches the **Board packs** panel of the board portal alongside the other sealed board reports, and its claims can be re-verified later. See [Board & governance](docs-board-governance.html). After you generate it, someone who can manage settings can choose **Record as met** to mark the annual obligation complete on that date. Examiner sessions do not see the board report. ## Recording a security incident **Record incident** on the Security incidents screen opens a new incident. You record a title, an optional description, a severity of critical, high, medium or low, the time it was detected, the affected systems, and optionally the service provider involved, chosen from your third-party register. You also tick the information involved, which can be sensitive customer information, other customer information, employee information, credentials, or confidential business information. Then you record how many customers or consumers were affected, if you know, and whether it occurred at an entity the FTC Safeguards Rule covers, such as a non-bank affiliate or a CUSO. The register lists each incident with its severity, its detection time, the next notice due and its status of open, contained or closed, and you can filter it by status. Opening an incident shows its notification regimes, its evidence and its links to other records. The most important act on an incident is **Record determination**. A named member of your team records when they determined it, whether it is a notification incident that must be reported, and the basis for that conclusion. Zovos never makes that determination, and until one is recorded no regulator deadline runs. A determination cannot predate detection. To change it you choose **Record a new determination** and give a reason for the change, and the earlier determination stays in the audit trail. ## Notification regimes and deadlines Each incident carries a row for every notification regime. The row says whether the regime applies and why, the citation it comes from, and its deadline or the rule that sets one. - **Primary federal regulator.** A bank notifies its primary federal regulator as soon as possible and no later than 36 hours after the determination. The citation follows your primary federal regulator, which is 12 CFR 53.3 for the OCC, 12 CFR 225.302 for the Federal Reserve and 12 CFR 304.23 for the FDIC. - **NCUA.** A credit union notifies NCUA as soon as possible and no later than 72 hours after the determination, under 12 CFR 748.1(c). - **Customer notice.** Under the response-program guidance, affected customers are notified as soon as possible when misuse of their sensitive information has occurred or is reasonably possible. The guidance sets no fixed hours, and whether misuse is reasonably possible is your judgment, so once sensitive customer information is involved you mark whether this notice applies. - **Federal Trade Commission.** An entity the Safeguards Rule covers notifies the FTC as soon as possible and no later than 30 days after discovery when customer information of 500 or more consumers is involved, under 16 CFR 314.4(j). The clock runs from the detection time you recorded. - **Suspicious activity report.** The row records only that the SAR question was considered, when, and by whom. The decision and any filing stay with your BSA officer, outside this record. - **Cyber insurer and state breach-notification law.** Your policy and each state's statute set their own terms, so you mark whether each applies, and the state-law row holds the states and their terms in your own words. **Record** on a row captures the notice once it is sent. You record when it was sent, to whom, who sent it, the agency's reference, and the evidence item that proves it, which you attach under the incident's Evidence first. A regime that applies and has a deadline reads **Notice due** until its notice is recorded as sent. ## Closing and following up **Close incident** requires the root cause and the lessons learned, and a closed incident can no longer be edited. Three follow-up actions connect an incident to the rest of the program. - **Promote to finding.** This opens a self-identified finding from the incident in the findings register. This needs permission to write findings. - **Raise a task.** This creates a task with an owner, linked to the incident. This also needs permission to write findings. - **Book the loss.** This links an existing loss event or creates a new one with its event type and gross loss amount, in the loss events register. This needs permission to write risk records. See [Findings & remediation](docs-findings.html) and [Risk management](docs-risk-management.html). ## Notes and limits Zovos records the determination your team makes and the notices your team sends. It does not decide whether an incident is reportable, send any notice, or monitor your systems for incidents. The incident register has its own read and write permissions, separate from the continuity permissions, so you can staff your information security officer without handing over business continuity, or the reverse. Examiner sessions never see the incident register. --- # Business continuity Section: Programs · Updated: 2026-10-07 · https://zovos.ai/docs-business-continuity.html **Continuity management**, listed as **Continuity (BCM)** in the Cybersecurity group of the sidebar, is the oversight register for your business continuity program. It tracks the plans your institution maintains and approves, the business impact analyses that justify their recovery objectives, and the exercises that prove those plans are tested on cadence. It is a second-line tracking surface. Plan authoring and recovery execution live elsewhere, and Zovos does not run a failover. The same sidebar group also holds the **Cybersecurity** page and the **Security incidents** register, described in [Cybersecurity](docs-cybersecurity.html). The screen is headed **Continuity management**, and it has five tabs: **Coverage**, **Continuity plans**, **Business impact analyses**, **Exercise log** and **Notification linkage**. ## Continuity plans Each plan carries a display ID, a type, an owner, the processes it covers, and a lifecycle that runs draft, awaiting approval, in force, and retired. The types are enterprise BCP, IT disaster recovery, pandemic, department, and other. A plan is only in force once it has been approved, so a draft that never reached the committee cannot quietly count as coverage. Every plan commits to a recovery time objective and a recovery point objective. Those say how quickly the process must be back and how much data loss is tolerable. These are your institution's own commitments recorded against your own processes. ## Business impact analyses A business impact analysis records what a process actually **requires**: the required recovery time objective, the required recovery point objective, and the maximum tolerable downtime. It is the justification behind the plan's commitment rather than a restatement of it. Keeping the two separate is what makes the next part possible. Because the requirement and the commitment are recorded independently, Zovos can compare them and surface **recovery-objective conflicts**, where a plan commits to less than its own business impact analysis says the process needs. That mismatch is one of the most common findings in a continuity examination, and it is usually invisible when both numbers live in the same document. ## Exercises The exercise log records each test. An entry holds the plan under test, its type, the date it was conducted, a written summary, and its result of pass, partial or fail. The type is tabletop, walkthrough, functional, or full interruption. An exercise does two things beyond recording itself. First, it moves the cadence clock on the plan it tested, so the coverage grade updates from the test rather than from a calendar entry. The anchor only ever moves forward, so filing a back-dated exercise cannot rewind a plan's clock or make it look freshly tested. Second, a fail or a partial can be promoted with **Open a finding**, which takes an optional note for the finding. A failed exercise opens at high severity and a partial at medium, and whoever promotes it can override that. A failed test that produced no follow-up is exactly the pattern an examiner looks for. ## Notification linkage The fifth tab states a boundary out loud. Zovos sends no emergency alerts and holds no contact roster. Your mass-notification platform does that, and it should stay the only system that does. What Zovos does is emit a signed event when a plan goes into force and when an exercise is recorded, so that platform stays in step with the plan register instead of drifting away from it. The tab reads whether each of those events is wired or not wired, which endpoints are registered and which of them are actually live, how many live subscribers each event has, and when each event last delivered. A paused endpoint is shown but does not count as wired, and an event that has never fired makes no claim about delivery at all. Endpoints themselves are registered under Settings, on the **Webhooks** panel of Integrations. ## The coverage grade The coverage tab is where the program is read at a glance. Every process with an active business impact analysis is graded, critical processes first, into one of six states. They are covered, covered but with a test due soon, test overdue, never tested, plan not in force, and no plan at all. The headline shows how many of your critical processes are covered, and how many processes of any criticality are not. Those last three states are the point of the screen. A process with a beautifully written plan that has never been exercised is not covered, and a process with a plan still sitting in draft is not covered either. Grading them separately means the gap has a name, and the report to the board or the examiner distinguishes between missing documentation and untested documentation. ## Notes and limits This is oversight rather than orchestration. Zovos does not author continuity plans, run recovery procedures, monitor infrastructure, or execute a failover. It records what your plans commit to, what your analyses require, what your exercises found, and where those three disagree. The recovery objectives on this screen are your institution's, recorded by your team about your own processes. They are not statements about Zovos as a service. For our own posture, see [Security](security.html). Plan approval and exercise-driven findings run through the shared machinery. See [Approvals & delegation of authority](docs-approvals.html) and [Findings & remediation](docs-findings.html). Continuity plans collected from vendors as part of due diligence are tracked separately in [Third-party risk & partner programs](docs-third-party-risk.html). --- # How AI works in Zovos Section: AI in Zovos · Updated: 2026-10-03 · https://zovos.ai/docs-ai-in-zovos.html Zovos uses AI for the language work in a compliance program, such as drafting, mapping, classifying and extracting. It does not use AI to decide anything. Every model output arrives as a proposal with its citations attached, and a named person accepts, disputes, or escalates it before it becomes part of your record. This page explains what the agents do, what grounds their answers, and where you stay in control. ## What the agents do The agents are a closed set. Each one has a defined job, a versioned prompt template, and a run record you can open a year later. - **Policy mapping.** This agent crosswalks your policy sections to regulatory citations, with a confidence score on each match. - **Gap analysis.** This agent finds obligations with no policy or control covering them. Results land as proposed gaps, never as findings. - **Regulatory monitor.** This agent summarizes the impact of a regulatory change and drafts an applicability assessment for your charter. - **Drafter.** This agent drafts a policy or procedure grounded in your own library. - **Citation indexer.** This agent structures framework citations into paragraph-level references the rest of the product can point at. - **Exam prep.** This agent assembles examiner-ready binder items. - **FDL Classifier.** This agent sorts the lines of an examiner's first-day letter against your request catalog. - **Mock examiner.** This agent writes examiner-voice draft findings for procedures that failed. - **Ad screener.** This agent does a UDAAP and advertising first pass that flags trigger terms. - **SOC Reviewer.** This agent pulls exceptions, complementary user entity controls, carve-outs, period gaps, and opinion qualifications out of a vendor's SOC 2 report. - **Contract Reviewer.** This agent reads an executed vendor contract and proposes its key terms and, for each clause on your required-clause checklist, whether the contract contains it. A proposal that quotes text the contract does not contain is marked ungrounded instead of trusted. - **Horizon Scanner.** This agent reads the regulatory updates, enforcement actions and economic data published since its last scan and proposes draft watch items for your emerging-risk register. - **Internal audit drafters.** These three agents draft risk-and-control-matrix lines for an engagement, the body of a workpaper from the evidence attached to it, and a finding from the failed items of a sample. An auditor accepts each draft before it becomes part of the engagement. You meet them in context instead of choosing them from a menu. Examples are remediation guidance on a finding, a policy draft started from a gap, a suggested answer on an inbound due-diligence questionnaire, and the first pass on a marketing review. ## What the answers are grounded in Retrieval runs over two libraries. The first is the regulatory corpus that ships with the product. It holds framework citations, citation paragraphs and regulatory updates, and it is read-only to you. The second library is your own. It holds your policy sections, the text of documents you have uploaded, and drafts in progress. Retrieval never crosses a tenant boundary, and the product enforces that structurally instead of relying on review. Documents become retrievable on upload. A file is scanned for malware, its text is extracted, and only a clean version is ever indexed. A quarantined file is never read into the index. Two grounding rules matter more than anything else in this section. First, weak matches are dropped instead of being padded back in, so an empty result is a legitimate answer. The product tells you that nothing in your library supports an answer instead of returning the least-bad match. Second, a citation that does not resolve against the corpus is dropped loudly, with an audit row, instead of being stored as though it were verified. The raw model output is kept verbatim on the run record. Only resolvable citations survive into anything durable. ## Nothing binds without a person Every run comes back banded by confidence. A score above 0.85 is auto-cleared, 0.60 to 0.85 is awaiting review, and below 0.60 is flagged. Auto-cleared is not the same as approved. No agent output binds anything on its own. The top band carries one extra safeguard. When a run clears on confidence but the untrusted material it read carries instruction-like content, a system note on the run's review trail flags it for human spot-review. The confidence band itself does not change. A confident answer drawn from a document that is trying to steer the model is exactly the answer a person should look at. The review queue collects everything waiting on a decision. A reviewer accepts, disputes, or escalates, and each of those requires a name and a rationale that is written into the append-only audit trail. Generated gaps stay proposed until someone promotes them. Mock-exam findings are drafts until someone moves them into the real register. Extractions from a SOC report land in proposed fields, and the report's header facts stay blank until a person confirms them. Contract terms and clause findings wait for a person to accept or reject each one, and a draft emerging risk stays a draft until someone accepts it onto the watch list or dismisses it. ### Show your work The run record is immutable. It pins the agent, the model and provider that served it, the prompt template and its version, the resolved prompt, tokens, duration, and a content hash for every input. Re-running reproduces the same inputs verbatim, which is what makes "show me how you got that answer" answerable in front of an examiner long after the template has moved on. Your model governance evidence is assembled from that same telemetry. See [Model & AI governance](docs-model-ai-governance.html). ### Disposition review Records that reach the end of their lifecycle queue for an explicit decision instead of aging out quietly. A dashboard tile shows what is waiting, a reviewer with the right permission works the queue, and the decision is recorded like any other governed action. A reviewer records an outcome of retain or clear for disposal. Clearing a record destroys nothing, and there is no disposal action in the interface today. ## Where we deliberately use no model at all Where a deterministic answer is possible, the product does not call a model. Absence testing, the mock examiner's procedure checks, shadow-vendor matching, clause review, launch delta and first-day-letter segmentation are all deterministic. The mock examiner copies breaching record identifiers only from query results, never from model output. There is no statistical analytics engine behind any of it. Model bias testing and fair-lending analysis are evidence-capture and oversight surfaces, and the fair-lending function reports itself unavailable rather than approximating a number it cannot compute. Nothing in the product takes a governance action on its own, and the automation surface deliberately exposes no approval action. ## Controls you hold - **Turn AI off.** Governance settings carry a processing switch. With it off, every trigger path is refused before any write, for institutions whose policy forbids model processing of their content. - **Cost controls.** Agent usage is bounded by a token budget and a cap on concurrent runs, so a runaway job cannot quietly become a bill. Raising either is a conversation with your account team. - **Provenance per run.** Each run records which provider actually served it, so governance reads history instead of current configuration. ## Your own AI assistant You can also connect the AI assistant your institution already uses to your workspace over the Zovos connector. It works as you, within your own permissions, and only after an owner turns the connector on. Every tool that reads or changes your data refuses an examiner session. Over the connector the assistant can show you your own work and your approvals queue, find a record by its ID or title, and read your controls, risks, obligations, findings, key risk indicators, vendors, regulatory updates, exam request lists and policies. It can create a task or comment on a finding or a risk. Each of those is shown as a dry run first and written only when you confirm. It cannot approve, sign off or change a record's status, and it cannot reach fraud cases, SAR decisions or credit risk review. Every tool call is written to your audit trail. Two of the assistant's tools ask a model for help. One assesses the impact of a regulatory change, and the other drafts answers to a due-diligence questionnaire from your own prior answers. Each of those calls is recorded as an agent run like the ones above, with its citations, its token use and a review band, and neither writes to any of your records. The AI processing switch described above turns them off along with everything else. It also turns off the assistant's policy search, which uses a model to match your question to your policy sections. The assistant can also search and cite these published docs. We index them for that search and refresh the index as we update the pages. See [Connect your AI assistant](docs-connect-ai-assistant.html) for setup, and [Test controls with your own AI assistant](docs-ai-control-testing.html) for control tests it can submit for review. ## Notes and limits - We do not run an automated model-quality benchmark. The review queue, with its accepted and disputed decisions, is the evaluation loop today, and we would rather say so than imply a harness we do not have. - Corpus content is original paraphrase. It is not verbatim regulator text. - A framework crosswalk is never evidence of certification, including for the AI-management-system framework in the corpus. - Where inference runs, and the commitment that no customer input or output is used to train foundation models, are stated on [our security page](security.html). --- # Connecting integrations Section: Integrations · Updated: 2026-10-07 · https://zovos.ai/docs-integrations.html Most of the evidence a compliance program needs already exists somewhere else. It sits in your document management system, your identity provider, your ticket tracker and your vendors' rating services. Connectors bring that evidence in with its source and its timestamp intact, so you are not screenshotting it by hand the week before an examination. Connectors ship disabled. Nothing is fetched from or sent to an outside system until an administrator connects it with a credential your institution controls. ## How connecting works Connections live on the Integrations tab of **Settings & integrations**. Tiles are grouped by the job they do. Each tile shows its direction (inbound, outbound, or two-way), how it authenticates, and its current status. The status is one of Available, Connected, Pending, Attention needed, or Disconnected. Connecting means providing one of a small number of things: - **OAuth or admin consent.** You sign in to the provider and approve a named application against a listed set of permissions. This is how Microsoft 365, Google, Box, Confluence, iManage, NetDocuments and the GitHub repository readings connect. DocuSign uses a one-time admin consent for a service user instead of a per-signer sign-in. - **An API key or token.** You issue it in the vendor's own console and paste it once. Jira, ServiceNow, Azure DevOps, GitHub Issues, GitLab Issues, security-evidence and vendor-rating services work this way. - **A cross-account role.** Amazon Web Services connects through a read-only role you create in your own account. Zovos can assume it only with an external ID that you and Zovos share. - **A webhook secret.** Systems that push events to you use one. It is verified on every delivery and replay-deduplicated. - **A pinned SSH host key.** SFTP delivery requires one. It is not optional. Two credentials run the other way. An API key and a KRI ingest token are both issued by Zovos so your own systems can call us. Those are covered below. Credentials are encrypted at rest and never sent back to a browser. You can replace a secret, but you cannot read it. Every URL you supply must be https and is checked before it is stored or fetched. Creating or changing a connection is a settings-level permission and is written to the audit trail like any other governed change. Two habits save trouble later. First, use a dedicated service account with read-only scopes instead of a person's account, so the connection does not break when that person leaves. Second, decide who owns the credential before you connect. Connectors that pull evidence for a control test become part of your examination story. ## What the catalog covers | Category | What you get | | --- | --- | | Document sources and DMS | Ingest policies and procedures from SharePoint, Confluence, Google Drive, Box, iManage Work and NetDocuments. Some also publish approved versions back out. | | Control evidence from your IT estate | Automated control readings for multi-factor enforcement, two-step enrollment, organization 2FA, vulnerability, endpoint coverage and mobile device management. Microsoft 365 adds Conditional Access MFA, managed-device compliance and the Secure Score trend. When you set up an automated test, the picker offers only the checks the selected connection can run. | | Third-party risk feeds | Vendor security ratings and financial-health scores as dated snapshots | | Ticketing | Two-way sync of remediation work with Jira, ServiceNow, Azure DevOps, GitHub and GitLab | | E-signature | Send policies and attestations out for signature and record the result | | Messaging | Slack and Microsoft Teams notifications, including approval deep links, plus an interactive Slack app for acting on approvals, findings and attestations inside Slack | | Audit-log egress and exports | Forward the audit log to Splunk, Microsoft Sentinel or a generic collector. Deliver scheduled datasets by email, to your own object storage, or over SFTP. | | Identity | SAML or OIDC single sign-on and SCIM directory sync | | Regulatory and market data | Regulatory change feeds, enforcement activity, and public bank and credit-union data | | BSA/AML oversight metrics | Program-level case and alert metrics from your AML case system, for oversight only and never for transactional AML | | Business continuity and mass notification | Tell your alerting tool when a continuity plan goes into force and when an exercise is recorded, so call trees and templates stop drifting from the plan register | | Internal audit | Confirm balances with Confirmation.com without leaving the workpaper | | Developer and cloud | Repository and cloud configuration readings from GitHub and Amazon Web Services, including backup coverage from AWS Backup plans and each protected resource's recent backup jobs, plus HMAC-signed outbound webhooks | | Board and regulator portals | Publish board packages straight to BoardEffect. For OnBoard, Diligent Boards, FDICconnect and NCUA MERIT, Zovos builds a package with a hashed manifest that you upload yourself. | | Control content | Import a control catalog you already license | ## How we describe connector readiness The [integrations page](integrations.html) publishes where each connector stands, in one of two states: - **Available.** The connector runs against the real service today, on a credential you already have. - **Coming soon.** The adapter is still in progress. Adobe Acrobat Sign is in that state today. Its tile is visible and badged, and it is refused as a connection and as a send target instead of accepting envelopes that would fail on the first send. DocuSign is the e-signature provider you can use today. Inside the product, a tile shows something different. It shows your own connection status, which is one of Available, Connected, Pending, Attention needed, or Disconnected. A tile that is not connected says so plainly instead of showing a stale reading. ## Your own API access Not every integration is a tile. Where you want to pull your own data into a warehouse, a business-intelligence refresh, or an automation scenario in Zapier, Make or n8n, your workspace owner can mint a **tenant API key** from the integrations settings. - Scopes are chosen when the key is minted and do not change afterwards. Read scopes cover findings, the risk register and its assessments, the control catalogue, the policy register as metadata rather than document text, and the third-party register. A write scope lets a key open findings and add comments. The scope to read integration settings is required to connect an automation platform. Another scope lets it manage its own event subscriptions, which is what makes a trigger fire. - The secret is shown exactly once, and only its hash is stored. Minting, listing and revoking are audited, and a revocation takes effect on the very next request. - A key acts as your institution, not as a person. What it writes is stamped as a system actor. That is why no governance decision is reachable through it. The reference for what a key can call is generated from the live routes rather than hand-written, so it cannot describe a surface that no longer exists. Ask your Zovos contact for the current copy and your developer or integrator can work from it. There is a second, narrower credential. A **KRI ingest token** lets an external metric feed push readings into one key risk indicator. Each token covers one indicator in one workspace, has no session, and carries an expiry you set. The panel that mints it is also the live inventory of what can write into that indicator, with a kill switch on each token. ## What flows in, and what flows out Inbound, connectors bring documents into your library, where they become searchable and citable. They bring control readings that attach to a control test with the system they came from and the time they were taken. They bring vendor ratings as a time series with a delta against the previous reading. They also bring program-level AML metrics, regulatory change and market data. Outbound, Zovos forwards audit events, delivers scheduled datasets, opens and updates tickets, sends signature envelopes, posts notifications, and assembles board and regulator packages. Nothing fails silently. If one delivery leg of a scheduled export fails, the whole run is marked as an error and a delivery alert is raised. The run does not report success. Ratings that drop materially append a monitoring event automatically, but they never force a reassessment. That decision stays with the third-party risk manager. ### Acting from Slack The basic Slack and Microsoft Teams connections post notifications to a channel through an incoming webhook. The interactive Slack app goes further. An administrator connects it by pasting the app's bot token and signing secret, then links each Slack user to their Zovos member. - **Approve or reject.** A linked user can approve or reject an item from the message itself. Each decision asks for a required rationale and runs through the same approval rules as the web app, including separation of duties. - **Acknowledge.** A linked user can acknowledge a finding or an attestation, within the same permissions they hold in Zovos. - **Look up work.** The /zovos command lists your pending approvals and overdue attestations and looks up a finding by its ID. It only reads, and only you see its replies. Every action taken in Slack is written to the audit trail with Slack recorded as the channel. A Slack user who is not linked, or who lacks the permission, is told so and nothing is written. ## What an examiner sees Every sync keeps an append-only run log of what was pulled, when, and what came back. That record answers "when did you last actually check this", which is the question that follows every assertion of continuous monitoring. Evidence carries the source system and the collection time with it, so a control test shows where its reading came from. Vendor ratings are snapshots over time, so the number never changes quietly. Closure stays with a person. When a linked ticket is marked done in your tracker, the finding moves to awaiting review. It never signs off its own closure. Governance decisions are deliberately outside the automation surface entirely. Approving a policy or accepting a closure requires a named person under separation of duties, and no automation recipe can do it for them. ## Limits worth stating plainly - **No core banking or loan-origination connector.** Leaving out Fiserv, Jack Henry, FIS and Symitar is deliberate. Zovos holds the risk and control work of every line of defense. It is not a system of record for transactions. Monitoring populations and samples arrive by import. - **No accounts-payable or ERP connector.** Shadow-vendor reconciliation runs from a CSV you export. - **No two-way sync with another GRC platform.** Records do not flow back and forth between Zovos and another GRC tool. - **Zovos sends no emergency alerts.** The business-continuity connector keeps your mass-notification tool in step with the plan register by sending it a signed event. Zovos itself sends no SMS, voice or push messages and holds no contact roster. Emergency alerting stays with the operational tool you already use. - **Some connections do not refresh their own tokens.** When the vendor's token expires, runs start failing and you reconnect. Watch the Attention needed state. - **Adobe Acrobat Sign waits on an application registration** before it can be self-served. Its tile shows as Coming soon until the registration completes. If it is blocking you, [tell us](contact.html). We set connector priority by what customers are actually stuck on. --- # Connect your AI assistant Section: Integrations · Updated: 2026-10-07 · https://zovos.ai/docs-connect-ai-assistant.html *By Adam Swenson · 15 September 2026* You can connect the AI assistant you already use to your Zovos workspace. That includes Claude, ChatGPT, Cursor, Microsoft Copilot and Gemini. Once connected, it can answer questions from these docs and the API. It can show you your own work and your approvals queue, and it can find a record by its ID or title. It can read your controls, risks, findings, key risk indicators, vendors, obligations, regulatory updates, exam request lists, policies and evidence requests to help you draft. It can create a task or comment on a finding or a risk. It can bring data over from a spreadsheet or a previous tool, and it can submit a control test on your behalf. The assistant works **as you**. It acts only within your Zovos role, only in your own workspace, and only after a tenant admin has turned the connector on. There are things it **never** does. It never sees another customer's data. It never approves or signs anything, it never changes a record's status, and it never administers users or roles. It cannot reach fraud cases, SAR decisions or credit risk review. An examiner session cannot read or change any workspace data over the connector. A control test it submits waits for a reviewer other than you before any rating changes. Imports, rollbacks, tasks and comments show a dry run before anything is written. Zovos never receives your assistant vendor's credentials or your system logins. Zovos only answers the authenticated requests your assistant makes with your Zovos sign-in. ## Before you connect - **A tenant admin turns the connector on.** In **Settings → Integrations → AI assistants**, an owner enables **Remote MCP server**, which every tool requires, reads included. To let assistants *submit* control tests, the owner also enables **ZEP control testing**. Both default to off, and nothing is reachable over the connector until an owner opts in. - **Sign in with your organization selected.** Adding the connector runs your institution's usual single sign-on. You must pick your organization at sign-in. A session with no organization is refused with a message telling you to choose one. Zovos never defaults you into an organization. - **Your email must be verified.** A sign-in whose email is not verified is refused. - **Your Zovos role governs what the assistant can do.** It is the *same* role-based access as the web app. A WorkOS admin or owner maps to the Zovos **owner** role, and everyone else keeps their existing Zovos role (analyst, internal audit, board, risk approver, or a custom role). Every tool that reads or changes workspace data, and both ready-made prompts, refuses an examiner session. An examiner can only confirm who they are signed in as and search these public docs. If your access comes through a scope-limited access group, the assistant can show you your own work and find the records in your scope by ID or title. The other read tools need the permission held without a scope. There is no separate connector permission to grant. Provision the person's role in **Administration → Team** and the assistant inherits it. ## The endpoint Point your client at the Zovos MCP endpoint and complete the Zovos sign-in when prompted: `https://app.zovos.ai/api/mcp` Every client uses the same URL and the same OAuth 2.1 sign-in (WorkOS AuthKit). Major assistants register themselves automatically, so there is nothing to pre-configure on Zovos's side. Your workspace (tenant) is derived from your verified sign-in, never from the URL, so there is one URL for everyone. ## Set up your client ### Claude Code (CLI) ``` claude mcp add --transport http zovos https://app.zovos.ai/api/mcp ``` Claude Code opens the sign-in in your browser on first use. It has a local shell, so it can both run a control test and submit it. ### Claude.ai and Claude Desktop Go to Settings → Connectors → **Add custom connector**, paste `https://app.zovos.ai/api/mcp`, and complete the sign-in. These clients have no local shell, so for control testing they are submit-only. Pair them with the local bridge below to attach evidence files. ### ChatGPT - **Deep research** connectors use two read-only tools named `search` and `fetch`. Zovos's docs Q&A pair provides them, so deep research can search and cite these published docs. - **Developer mode** (Settings → Connectors → Advanced) exposes the full tool set, including writes, over the same URL. Use it for reading your GRC data, migrations, and ZEP submissions. With no local shell it is submit-only for control tests. Pair it with the local bridge for artifacts. ### Cursor Go to Settings → MCP → **Add server**, choose type **HTTP**, and enter the URL `https://app.zovos.ai/api/mcp`. Cursor completes the sign-in in-app. It has a local shell, so it can run and submit a test. ### VS Code / GitHub Copilot (agent mode) Add the server to `.vscode/mcp.json`: ```json { "servers": { "zovos": { "type": "http", "url": "https://app.zovos.ai/api/mcp" } } } ``` Copilot agent has a local shell, so it can run and submit a test. ### Copilot Studio Add a custom MCP connector pointing at `https://app.zovos.ai/api/mcp` with OAuth 2.1 against your WorkOS sign-in. Studio agents run server-side with no user shell, so they are submit-only for control tests. ### Gemini CLI Add the server under `mcpServers` in `settings.json`: ```json { "mcpServers": { "zovos": { "httpUrl": "https://app.zovos.ai/api/mcp" } } } ``` It has a local shell, so it can run and submit a test. ### Local bridge (`npx zovos-mcp`) Some clients cannot run a test themselves, such as Claude Desktop and ChatGPT, and sometimes a client's own OAuth misbehaves. In those cases, use the `zovos-mcp` bridge. It runs on your machine, signs you in, and adds the evidence-upload helper the raw connector cannot provide. - `npx zovos-mcp login` authorizes the CLI with your Zovos sign-in. - `npx zovos-mcp` starts the bridge. Point your assistant at the command `npx -y zovos-mcp`. - `npx zovos-mcp doctor` checks reachability, your token, and the workspace flags. The bridge exposes four of the connector's tools. They tell the assistant who you are signed in as, read your controls, submit a control test result and check a submission's status. The bridge never confirms a write on your behalf. > **Availability.** The `zovos-mcp` package publishes to npm when Zovos announces the connector. The commands above are how they will read once it is published. ## What the assistant can do Everything runs under your Zovos role, and every tool result is labelled as data for the assistant to read, never as instructions to obey. A tool reads only the registers your role can read, and the reads return a page or a capped list that says when there is more than it returned. - **Answer questions about the docs and the API.** These customer docs are searchable without signing in. The API reference is searchable once you are signed in. - **Tell you what is on your plate.** It can list your open tasks, the attestations and certifications waiting on you, and the vendors, risks, key risk indicators, self-assessments and exceptions you own. It can show your approvals queue and whether you can decide each item, but the decision itself is made in Zovos. - **Find and read your records.** It can find a record by its ID, legacy ID or title. It can read your findings with their corrective action plans, your key risk indicators with their status and recent readings, and your vendors with their reviews and the reports and contracts coming up for renewal. It can also read the regulatory updates your institution follows, an examination's request list and how ready it is, and cited excerpts from your current policies. Internal notes on a finding, comment text and vendor contact details are never returned, and policy search is off while AI processing is turned off for your workspace. - **Read your GRC data for drafting and evidence work.** It can read your controls, your risk register, your obligations, the impact of a regulatory change, and the evidence a request needs, so it can help you draft. - **Create a task or comment on a record.** It can create a task for a named owner, optionally tied to the record it comes from, and post a comment on a finding or a risk that notifies the people it mentions. Both show a dry run first. - **Draft answers to due-diligence questionnaires.** Answers are grounded in your own prior answers and come back as a draft for you to review. - **Bring data over from spreadsheets or a previous tool.** It maps your columns to a Zovos register (risks, vendors, controls, policies, findings, and more), shows a **dry run** first, imports on your confirmation, and can **roll back** an import if it went wrong. - **Submit a control test.** It submits a test you ran with the assistant's own tools, with the raw evidence, over the Zovos Evidence Protocol. See [Test controls with your own AI assistant](docs-ai-control-testing.html). ### Two ready-made prompts Zovos also offers two prompts that you start yourself from your client's prompt menu. A prompt is a fixed set of instructions that has the assistant gather information with the tools above, in a set order, and propose next steps. You decide what happens next, and any change still goes through the write tools with their own permissions and dry runs. - **Prepare an exam request list** (`prepare_exam_request_list`). Give it the engagement's ID as Zovos shows it. For each request that is not yet accepted, starting with the overdue ones, the assistant lists the evidence already on file, the linked controls and the gaps. It then proposes a next step for each request. - **Monthly compliance summary** (`monthly_compliance_summary`). Give it a month written as YYYY-MM. The assistant summarizes the regulatory updates published since the month began, the overdue findings, the key risk indicators in breach and the approvals waiting on you. It closes with the three items that most need attention. The prompts are not offered in an examiner's session. If your client has no prompt menu, you can ask for the same thing in your own words. ### What happens when the assistant writes Every tool that changes data is refused in an examiner's session and while Zovos has the connector in read-only mode, and every call is recorded in your workspace's audit trail. Beyond that, the write tools work in three ways: - **Imports, rollbacks, tasks and comments show a dry run first.** `run_import` and `rollback_import` return exactly what *would* change and write nothing until the assistant calls them again with `confirm=true`. Ask to see the dry run, read it, then say go. `create_task` and `add_record_comment` work the same way. The dry run shows the task it would create and its owner, or the record a comment would go on and who it would notify. A task is created open, and a comment cannot be edited or deleted. Text that contains SAR or BSA content, credentials, or personal data such as an account or Social Security number is refused. - **A control test waits for a reviewer.** `submit_control_test_result` previews the result, then files it as pending review. A reviewer other than you accepts it in Zovos before any control's rating changes. - **Uploads and saved mappings are stored when called.** `begin_artifact_upload` and `commit_artifact` stage and verify an evidence file, `begin_upload_file` and `commit_upload_file` do the same for a file to import, and `save_mapping_template` saves a column mapping for reuse. These have no confirm step, and none of them changes a register or a rating on its own. The assistant can never approve, sign, or dispose of anything, and it can never change a record's status. Those decisions stay with a named person under separation of duties. ## Sessions, audit, and revoking a client Your access token is **short-lived, lasting about five minutes**. A well-behaved client refreshes it automatically over OAuth, so a long task does not stall. If a session fails midway asking you to sign in again, that is just a refresh. Every tool call the connector makes is written to your workspace's append-only **audit trail**, recording the client, the tool, the outcome, and the signed-in person it acted for. An owner can see every connected assistant and cut one off under **Settings → Integrations → AI assistants → Connected clients**. The panel lists each client with the last person it acted for, its call count, when it was last seen, and whether it is revoked. **Revoke** stops that client's calls on their next request. A revoke can be restored later from the same panel. Owners also hold the broader switches on the same screen. They can turn the connector off for the whole workspace, and they can set the share of accepted control tests that are randomly re-performed. ## Where your data lives, and who processes it - **Which corpora need sign-in.** These product docs are public and searchable without an account. Your API reference and all of your GRC data require a signed-in session and your matching Zovos permissions. - **You choose the assistant vendor.** You decide which assistant to connect. Zovos answers only the authenticated requests it makes on your behalf and never sends your data to a vendor Zovos chose. Our [security page](security.html) and [privacy policy](privacy.html) describe what Zovos holds and how inference is handled, including that customer content is never used to train foundation models. - **Your system credentials never reach Zovos.** When an assistant runs a control test, it authenticates to *your* systems with *your* credentials on *your* machine. Zovos receives only the result and the evidence you attach. ## Troubleshooting - **The access token carries no organization.** Your sign-in carried no organization. Sign in again and choose your institution. - **This organization has not enabled the Zovos MCP connector.** An owner has not opted in yet. The switch is **Remote MCP server** in Settings → Integrations → AI assistants. - **The access token's email address is not verified.** Verify your email with your identity provider, then sign in again. - **Writes are refused but reads work.** The connector is in read-only mode for the whole deployment, which is a Zovos safety switch. Reads keep working. Try the write again later or ask Zovos support. - **The assistant stopped working after it was fine.** An owner may have revoked that client. Reconnect, and the admin can restore it from the Connected clients panel. - **A call fails asking you to sign in again.** Your five-minute token expired between steps. Let the client refresh, or reconnect. ## Related - [Test controls with your own AI assistant](docs-ai-control-testing.html) explains how to run and submit a control test with your assistant. - [How AI works in Zovos](docs-ai-in-zovos.html) covers the in-product agents and how humans stay in the loop. - [Connecting integrations](docs-integrations.html) covers connectors for the systems your evidence already lives in. - [AI assistants over MCP and ZEP control testing](platform-ai-assistants.html) is the product overview of the connector and ZEP. - [Security](security.html) · [Privacy](privacy.html) --- # Test controls with your own AI assistant Section: Integrations · Updated: 2026-10-07 · https://zovos.ai/docs-ai-control-testing.html *By Adam Swenson · 15 September 2026* You can now perform a control test with the AI assistant you already use, whether that is Claude, GitHub Copilot, Cursor, or ChatGPT. You then submit the result to Zovos as evidence for that control's test period. Your assistant fetches the published procedure, runs the test with its own tools against your own system, and hands the result plus the raw output back to Zovos. There it lands **pending human review**. This is the **Zovos Evidence Protocol (ZEP)**. It consists of an open submission contract, a published [result schema](/schemas/evidence/control-test-result/v1.json), and a set of tools. Zovos never builds glue into your systems and never receives your system credentials. This is for the compliance owner or tester who runs a control test today in the Zovos UI and wants to run it from the assistant on their own machine instead. It does not replace the reviewer. No external result changes a rating until a **different** person accepts it. ## The three-step flow 1. **Fetch the procedure.** Ask your assistant to call `query_controls` with `include_procedure=true`. It returns the control, its acceptance criteria, the expected evidence, population and sampling guidance, and the current `procedure_version`. A due-for-testing filter finds the work that is actually open. 2. **Run the test with the assistant's own tools, on your system.** The assistant gathers the evidence with its own shell, scripts, and connectors, which are already authenticated to *your* environment. Zovos supplies no probes and touches nothing on your side. Save the **raw** output to a file. 3. **Submit the result and artifacts.** The assistant uploads each evidence file out-of-band through a presigned upload, so the bytes never pass through the model or the transport. It then calls `submit_control_test_result`. Call it first with `confirm=false` to see the dry-run, then again with `confirm=true` to record it. The submission enters `pending_review`. ## What Zovos records - **The tester of record is you.** That means the verified person behind your Zovos login, derived server-side from your sign-in. It is never something the assistant declares. - **The assistant is self-declared and shown UNVERIFIED.** Its name, model, and version are recorded verbatim as metadata and are never an authorization signal. - **Raw tool output is required.** A submission whose method is `TEST` or `AUTOMATED` must carry at least one `raw_tool_output` artifact. A narrative alone is not evidence. A fail or pass-with-exceptions outcome must also list at least one exception. There is deliberately **no confidence field**, because a model could fabricate a stated confidence. Assurance comes instead from the raw artifact, its server-computed hash, an append-only audit, mandatory review, and random re-testing. - **A human distinct from you accepts it.** On acceptance the outcome maps to effectiveness. Pass maps to Effective, pass-with-exceptions to Partial, and fail to Ineffective. Not-tested and not-applicable never change a rating. Acceptance also means the control owner's **attestation cadence is satisfied for that period**. Until acceptance, attestations stay manual to the owner. - **A failed test opens a draft Finding.** On accepting a fail or pass-with-exceptions, each exception becomes a draft Finding and linked risks are re-flagged. - **Some accepted submissions are re-tested at random.** By default **5 %** of accepted submissions are flagged for a re-perform. Your administrator can move that anywhere from 0 to 100 %. A mismatch is recorded on both the control and the submission. ## What stays on your machine and what you must never upload Your **system credentials never go to Zovos.** You authenticate to your own system with your own credentials on your own machine. Zovos receives only the result and the artifacts you attach. Never upload: - Do not upload credentials, tokens, API keys, cookies, or connection strings. Strip them before upload. - Do not upload **SAR, BSA/AML, or CTR content**. It is legally confidential and must never be submitted. - Do not upload customer PII beyond the minimum the control requires. Redact where you can. Zovos enforces this on top of your care, not instead of it. Every uploaded artifact is content-sniffed and malware-scanned, and archives are expanded and scanned member by member. Every artifact then runs through a **credential / PII / SAR classifier**. - A credential or SAR/CTR match is **refused**. The upload is rejected, and the error names the pattern *class*, never the matched secret. A reviewer cannot override a refusal. - PII at or above a threshold is **quarantined**. It is stored but download-blocked, and it is flagged for a reviewer. The skills enforce one more habit. Summarise counts in context and attach the full file out-of-band, so sensitive raw content stays out of your assistant's model context. ## Artifacts and limits Evidence is referenced by `sha256` and uploaded with a presigned PUT. Zovos re-computes each hash server-side and rejects any mismatch. Give each file a role: `raw_tool_output`, `screenshot`, `export`, `transcript`, or `supporting`. The allowed types are PDF, PNG, JPEG, plain text, Markdown, CSV, JSON, XML, ZIP, XLSX, and DOCX. The cap is **50 MB** per file. A text-only client with no local files can instead pass an `inline_text` transcript up to 32 KB. ## Connect your AI assistant There are two ways in. Most assistants speak the **remote connector** directly over OAuth. Claude Desktop and ChatGPT cannot run a local test on their own, so they use the local bridge. The coding-capable clients can both test and submit. > **This section is the shared setup for every Zovos AI-assistant connection.** The full per-client walkthrough for Claude, ChatGPT, Cursor, Copilot, Gemini, and the local bridge is in [Connect your AI assistant](docs-connect-ai-assistant.html). The steps below are the ZEP-specific companion. ### Remote connector (Claude.ai, Claude Desktop, Claude Code, Cursor, VS Code Copilot, ChatGPT developer mode) Point the client at the Zovos MCP endpoint and sign in with your Zovos account when prompted: `https://app.zovos.ai/api/mcp` | Client | Where to add it | | --- | --- | | Claude Code | `claude mcp add --transport http zovos https://app.zovos.ai/api/mcp` | | Claude.ai / Claude Desktop | Settings → Connectors → Add custom connector → paste the URL | | Cursor | `.cursor/mcp.json` → an `mcpServers` entry of type `http` with the URL | | VS Code Copilot | `.vscode/mcp.json` → a server of type `http` with the URL | | ChatGPT (developer mode) | Settings → Connectors → add an MCP server with the URL | Your access token is short-lived. A well-behaved client refreshes it on its own, so a long test does not stall. Select your organization at sign-in. A session with no organization selected is refused with a message telling you to pick one. ### Local bridge (`npx zovos-mcp`) Some clients cannot run the test themselves, such as Claude Desktop and ChatGPT. For those, the `zovos-mcp` bridge runs on your machine and logs you in with a device flow. It also adds a local `upload_artifact_file` helper that does the presigned upload MCP cannot do on its own. - `npx zovos-mcp login` authorizes the CLI with your Zovos login. - `npx zovos-mcp` starts the local server. Point your assistant at the command `npx -y zovos-mcp`. - `npx zovos-mcp doctor` checks reachability, your token, and the tenant flags. > **Availability.** The `zovos-mcp` package publishes to npm when Zovos announces the Evidence Protocol. The commands above are how it will read once it is published. Whichever path you use, the bridge and the connector share the control-testing tools `query_controls`, `submit_control_test_result`, and `get_submission_status`. For evidence files, the connector exposes `begin_artifact_upload` and `commit_artifact`, and the bridge replaces both with its single `upload_artifact_file` helper. ## Turn it on for your workspace An administrator enables this per workspace under **Settings → Integrations → AI assistants**. It is off until they opt in. Your account also needs a **verified email**, and a sign-in without one is refused. The re-test sampling slider (0 to 100 %, default 5 %) lives on the same screen. ## Example prompts Load the [skill pack](/docs-ai-control-testing-skills.html) for the control's family first, then ask in plain language. These three prompts exercise the read tool, the submit tool (dry-run then confirm), and the status tool. 1. **Find work and fetch a procedure.** "Using the Zovos tools, list the controls that are due for testing this quarter, then fetch the full procedure package for the MFA-on-privileged-accounts control so we can run it." 2. **Run, dry-run, then submit.** "Run the asset-inventory procedure against our CMDB with your own tools, save the raw export, and upload it as `raw_tool_output`. Then call `submit_control_test_result` with `confirm=false` and show me the dry-run. I want to see the mapped outcome, the exception count, and whether it would satisfy the owner's attestation. After that, resubmit with `confirm=true`." 3. **Check the reviewer's decision.** "Check the status of that submission with `get_submission_status` and tell me whether the reviewer accepted it, requested changes, or flagged it for a re-perform." Always review the dry-run before you confirm. The assistant should never submit silently. ## Exports for auditors Once a submission is accepted, an examiner or your team can export it in two open shapes without the assistant ever having to emit them. **OSCAL Assessment Results** serve OSCAL-speaking programs, and **OCSF Compliance Finding** records serve a security data lake. Both are generated server-side from the same sealed submission, one per submission or batched across a control's test period. ## Troubleshooting - **The access token carries no organization.** Sign in again and choose your institution. Zovos never defaults you into one. - **This organization has not enabled ZEP control testing over MCP.** An administrator has not opted in yet. The switch is **ZEP control testing** in Settings → Integrations → AI assistants. - **The access token's email address is not verified.** Verify your email with your identity provider, then sign in again. - **The procedure version was rejected (409).** The procedure moved under you. The error hands back the current package. Re-run against it and resubmit. - **An artifact was refused.** The classifier found a credential or SAR/CTR pattern. Remove it and resubmit. A reviewer cannot override a refusal. ## Related - [Zovos Evidence Protocol skill packs](/docs-ai-control-testing-skills.html) has downloadable skills for all 17 control families. - [Controls & continuous coverage](platform-controls.html) - [AI assistants over MCP and ZEP control testing](platform-ai-assistants.html) is the product overview, and [control testing with your AI assistant](solution-ai-assistant.html) is the buyer-facing summary. - [How AI works in Zovos](docs-ai-in-zovos.html) - [Connecting integrations](docs-integrations.html) --- # ZEP skill packs for AI control tests Section: Integrations · Updated: 2026-09-15 · https://zovos.ai/docs-ai-control-testing-skills.html *By Adam Swenson · 15 September 2026* A **skill pack** teaches your AI assistant how to run one family of Zovos control tests correctly. It covers what the objective is, how to sample, and what raw evidence to capture. It also covers the anti-fabrication and credential/PII/SAR rules, and exactly how to submit with the Zovos Evidence Protocol tools. Load the pack for the control you are testing, then follow [Test controls with your own AI assistant](/docs-ai-control-testing.html). Each family ships the same content in three formats, so it drops into whichever assistant you use. The formats are a **Claude skill** (`SKILL.md`), **GitHub Copilot instructions**, and a **Cursor rule** (`.mdc`). ## How to load a skill - **Claude (skills).** Save the family's `SKILL.md` into your project's skills directory, or attach it to the conversation. Claude reads its front-matter and applies it when a matching control is due. - **GitHub Copilot.** Save `copilot-instructions.md` as `.github/copilot-instructions.md` in the repository (or workspace) you test from. Copilot applies it automatically. - **Cursor.** Drop the `.mdc` file into `.cursor/rules/` in your project. It is authored with `alwaysApply: false`, so invoke it by name or reference when you start a test. With the [local bridge](/docs-ai-control-testing.html#local-bridge-npx-zovos-mcp) you can also print any pack on demand with its `bundle_skill` helper instead of downloading it. ## The 17 control families | Control family | Primary objective | Method | Claude skill | Copilot | Cursor | | --- | --- | --- | --- | --- | --- | | Access review | AC-2 Account Management | TEST | [SKILL.md](/zep-skills/access-review/SKILL.md) | [Copilot](/zep-skills/access-review/copilot-instructions.md) | [Cursor](/zep-skills/access-review/zep-access-review.mdc) | | Asset inventory | CIS-1 Inventory and Control of Enterprise Assets | TEST | [SKILL.md](/zep-skills/asset-inventory/SKILL.md) | [Copilot](/zep-skills/asset-inventory/copilot-instructions.md) | [Cursor](/zep-skills/asset-inventory/zep-asset-inventory.mdc) | | Security awareness training | AT-2 Security Awareness Training | EXAMINE | [SKILL.md](/zep-skills/awareness-training/SKILL.md) | [Copilot](/zep-skills/awareness-training/copilot-instructions.md) | [Cursor](/zep-skills/awareness-training/zep-awareness-training.mdc) | | Backup and restore | CP-9 System Backup | TEST | [SKILL.md](/zep-skills/backup-restore/SKILL.md) | [Copilot](/zep-skills/backup-restore/copilot-instructions.md) | [Cursor](/zep-skills/backup-restore/zep-backup-restore.mdc) | | Business continuity | FFIEC-BCM Business Continuity Management | EXAMINE | [SKILL.md](/zep-skills/business-continuity/SKILL.md) | [Copilot](/zep-skills/business-continuity/copilot-instructions.md) | [Cursor](/zep-skills/business-continuity/zep-business-continuity.mdc) | | Change management | FFIEC-DAM Development, Acquisition, and Maintenance | EXAMINE | [SKILL.md](/zep-skills/change-management/SKILL.md) | [Copilot](/zep-skills/change-management/copilot-instructions.md) | [Cursor](/zep-skills/change-management/zep-change-management.mdc) | | Configuration baseline | CIS-4 Secure Configuration | TEST | [SKILL.md](/zep-skills/configuration-baseline/SKILL.md) | [Copilot](/zep-skills/configuration-baseline/copilot-instructions.md) | [Cursor](/zep-skills/configuration-baseline/zep-configuration-baseline.mdc) | | Data protection | SC-28 Protection of Information at Rest | TEST | [SKILL.md](/zep-skills/data-protection/SKILL.md) | [Copilot](/zep-skills/data-protection/copilot-instructions.md) | [Cursor](/zep-skills/data-protection/zep-data-protection.mdc) | | Governance program | FFIEC-IS Information Security Program | EXAMINE | [SKILL.md](/zep-skills/governance-program/SKILL.md) | [Copilot](/zep-skills/governance-program/copilot-instructions.md) | [Cursor](/zep-skills/governance-program/zep-governance-program.mdc) | | Incident response | IR-8 Incident Response Plan | EXAMINE | [SKILL.md](/zep-skills/incident-response/SKILL.md) | [Copilot](/zep-skills/incident-response/copilot-instructions.md) | [Cursor](/zep-skills/incident-response/zep-incident-response.mdc) | | Internal audit | FFIEC-AUD IT Audit Function | EXAMINE | [SKILL.md](/zep-skills/internal-audit/SKILL.md) | [Copilot](/zep-skills/internal-audit/copilot-instructions.md) | [Cursor](/zep-skills/internal-audit/zep-internal-audit.mdc) | | Logging and monitoring | AU-2 Event Logging | TEST | [SKILL.md](/zep-skills/logging-monitoring/SKILL.md) | [Copilot](/zep-skills/logging-monitoring/copilot-instructions.md) | [Cursor](/zep-skills/logging-monitoring/zep-logging-monitoring.mdc) | | MFA on privileged accounts | IA-2 User Identification and Authentication | TEST | [SKILL.md](/zep-skills/mfa-privileged/SKILL.md) | [Copilot](/zep-skills/mfa-privileged/copilot-instructions.md) | [Cursor](/zep-skills/mfa-privileged/zep-mfa-privileged.mdc) | | Network boundary | SC-7 Boundary Protection | TEST | [SKILL.md](/zep-skills/network-boundary/SKILL.md) | [Copilot](/zep-skills/network-boundary/copilot-instructions.md) | [Cursor](/zep-skills/network-boundary/zep-network-boundary.mdc) | | Risk assessment | RA-3 Risk Assessment | EXAMINE | [SKILL.md](/zep-skills/risk-assessment/SKILL.md) | [Copilot](/zep-skills/risk-assessment/copilot-instructions.md) | [Cursor](/zep-skills/risk-assessment/zep-risk-assessment.mdc) | | Vendor / SOC review | SA-9 External System Services | EXAMINE | [SKILL.md](/zep-skills/vendor-soc-review/SKILL.md) | [Copilot](/zep-skills/vendor-soc-review/copilot-instructions.md) | [Cursor](/zep-skills/vendor-soc-review/zep-vendor-soc-review.mdc) | | Vulnerability management | RA-5 Vulnerability Scanning | TEST | [SKILL.md](/zep-skills/vulnerability-management/SKILL.md) | [Copilot](/zep-skills/vulnerability-management/copilot-instructions.md) | [Cursor](/zep-skills/vulnerability-management/zep-vulnerability-management.mdc) | ## Related - [Test controls with your own AI assistant](/docs-ai-control-testing.html) - [Controls & continuous coverage](platform-controls.html) - [AI assistants over MCP and ZEP control testing](platform-ai-assistants.html) is the product overview, and [control testing with your AI assistant](solution-ai-assistant.html) is the buyer-facing summary. --- # Security overview Section: Trust & data · Updated: 2026-10-07 · https://zovos.ai/docs-security-overview.html Compliance is the product, so security is the floor. This page explains the posture in the terms a compliance officer needs for day-to-day use and for a vendor-risk file. The live status of every attestation, with dates, is on [our security page](security.html), and nothing here is stronger than what that page says. Where the two could drift apart, we point you to that page instead of repeating a number. ## Where your data lives Customer data is processed and stored in a single AWS region in the United States. We do not transfer customer data outside the United States, and we do not currently market to the EEA or the UK. A cross-region standby is on the roadmap and is not in place today, so we publish no multi-region commitment. Each tenant gets its own database schema. Isolation comes from schema separation plus transaction discipline. Each tenant also gets its own customer master key (CMK) in AWS KMS, issued and managed by Zovos. Bring-your-own-key (BYOK) is not supported. Traffic is encrypted in transit, including to the database. At rest, object storage is encrypted under a per-tenant key and the database under an environment-level key. "Per-tenant encryption keys" is routinely overstated by vendors, and we would rather state ours narrowly than let a reviewer assume more than is true. ## Signing in and access control Single sign-on over SAML 2.0 or OIDC is available on every paid tier at no extra charge. SCIM directory sync keeps membership current, so deprovisioning in your identity provider takes effect here. Multi-factor authentication is delegated to your identity provider and is not enforced by us. To be plain about what that means, if your provider does not require it, we will not catch that. Inside the product, access is role-based and fails closed on an unknown role. There are six system roles plus any custom roles you define, and every role is intersected against a frozen permission catalog bound in code, so a stray database row cannot grant an authority the code does not define. Access groups can also limit a member's permissions to the records they own or to chosen business units, and those scoped reads and writes are enforced on the server. A session ends after 30 minutes without activity. It also has an absolute lifetime that your workspace owner sets between 1 and 12 hours, with 8 hours as the default. An examiner grant lasts 4 hours by default, and your workspace owner sets its maximum, between 1 and 24 hours. An administrator can also see a member's live sessions from the team roster, including the device, where the session started, when it was last active and when it expires. The administrator can end one of those sessions or all of them. A revoked session stops working on its next request instead of staying valid until it expires. A vendor-risk reviewer asks for this control by name for the day someone leaves mid-day or a laptop goes missing. [Roles and permissions](docs-roles-permissions.html) covers who can do what. ## Tenant network controls Institutions that restrict where their compliance system can be reached from can pin Zovos to their own egress ranges. The allowlist is a governed object, not a simple settings toggle. A change is staged, approved by a second person, and only then enforced. A change that would exclude the submitter's own address is refused unless the lockout risk is explicitly acknowledged. Once in force, the allowlist is checked on every authenticated request, ahead of any permission check. Two exemptions are deliberate, and we name them here so a reviewer does not have to discover them. An examiner session does not run against your allowlist, because regulators arrive from networks you do not control. It honors only the IP range pinned on its own grant. Keys issued for third-party automation are exempt for the same reason, since the automation platform's egress is not yours either. The compensating control there is the key itself, which is scoped to one surface and individually revocable. ## Examiner access and supervisory information Confidential supervisory information is segregated by the agency it came from, and the rule fails closed. A grant that names no agency unlocks no supervisory material at all. It does not unlock all of it. An examiner from one agency cannot see another agency's findings or engagements. Examiner sessions are read-only apart from a closed set of fieldwork actions. They are also scope-limited and time-boxed, they are re-checked for revocation on every request, and they can be pinned to an IP range. Some whole areas refuse an examiner outright because they are management work product. Those areas include the mock exam, board governance and minutes, the live decision register, the launch delta and credit risk review. The AI assistant connector refuses an examiner session as well. Your exam-preparation workspace is the deliberate exception in the other direction. It is the examiner's deliverable, so it is readable in an examiner session, and you should keep that in mind when you decide what to put there. In-progress internal audit work is withheld from the auditee by the same access mechanism. See [Exam management](docs-exam-management.html) and [Internal audit](docs-internal-audit.html). ## Evidence integrity The record an examiner relies on has to be one nobody could have quietly edited. The audit log is append-only, and the database itself enforces that. There are no update or delete grants on the table. Database triggers refuse an update, a delete or a truncate of the table outright. There is no edit affordance anywhere in the product. On top of the log sits a per-tenant hash chain with proofs, so you can show that a specific event existed, unchanged, at a point in time. The verifier is a standalone tool, so you do not have to trust our running system to check a sealed artifact. The audit log is archived each month under a 400-day compliance-mode object lock, so no one, Zovos included, can delete an archived month before the lock expires. Audit events can be forwarded continuously, through the SIEM forwarder you configure on the **Integrations** tab of **Settings**, to Splunk, Microsoft Sentinel, or a generic collector. [Audit trail and exports](docs-audit-trail.html) has the detail. ## What we do not claim We hold no completed third-party security attestation of any kind. There is no SOC 2 report, no auditor is engaged, and no audit window is open. ISO 27001 sits behind SOC 2 on the roadmap. A third-party penetration test is scheduled against the production stack before launch and has not been performed, and we will not claim one until it has. A restore drill has not been run, so we publish no recovery-time commitment. Any such number today would be a design target, not a measured result. If your vendor-risk process requires a completed attestation, we do not meet that bar today. The [security page](security.html) carries the current status with dates, and lists the documents we send under a mutual NDA. That list also states plainly which artifacts we do not hold. ## Reporting a security issue Email security@zovos.ai. Reports skip the normal support queue, and we work to coordinated disclosure with credit if you want it. The commitments we publish for critical issues are on the [support page](support.html), and our current posture is on [our security page](security.html). Good-faith research is authorized. Please do not run load-generating scanners, test denial of service, or access data that is not your own test data. There is no paid bug-bounty program today. Product problems and outages go to [support](support.html) instead. --- # Your data: exports, backups & retention Section: Trust & data · Updated: 2026-10-07 · https://zovos.ai/docs-data-handling.html Your records are yours, and a compliance system that is hard to leave is a compliance risk of its own. This page covers how to get data out of Zovos, what backups exist, how retention, legal holds and deletion work, and who else touches the data. Where a figure is involved we point at [our security page](security.html), which is the page we keep current. ## Who controls what Under your agreement, your institution is the controller of everything you put in the platform and Zovos is the processor. That means your privacy practices govern that content, and requests about it run through you. Our [privacy policy](privacy.html) covers a separate and much smaller set of information. That is what we collect about site visitors, newsletter subscribers, and people who contact us. It does not govern your tenant content. Inference runs on AWS Bedrock, which does not store prompts or completions or use them to train models, and Zovos does not train on customer data. That commitment, and the boundary the model inference runs inside, are stated on the security page. AI features retrieve only content the requesting member could open themselves, and due-diligence questionnaire answers, which go to counterparties, draw on your policies only. ## Getting your data out There is no export you have to ask us for. Everything below is in the product: - **Register exports.** You get server-stamped PDF and XLSX exports for the risk register, gap report, findings, loss events and program inventory. Most tables also offer quick CSV downloads. - **Scheduled exports.** Datasets are exported on a timer and kept for you to download from Settings through a short-lived secure link, or dropped on your own SFTP server with a pinned host key. Email is configurable as a destination too, but Zovos does not send email today, so that leg stays inert until delivery is switched on. A schedule cannot widen access. It is the configuring owner's own export, executed on a timer and carrying that owner's permissions. - **Audit-log forwarding.** The SIEM forwarder you configure on the **Integrations** tab of **Settings** delivers audit events continuously to Splunk, Microsoft Sentinel or a generic collector, so your security operations team holds its own copy. - **Proof packs.** These are sealed artifacts that ship with a standalone verifier, so a third party can check integrity without trusting our running system. - **Scoped API tokens.** Use these for pulls you script yourself. A token reads only the register its scope names, which is one of risks and assessments, controls, policies, or third parties. It reads page by page, and every row carries a last-updated stamp so a scheduled job can take only what changed. Tokens are stored hashed, and revoked rather than deleted, so the record of what existed survives. [Audit trail and exports](docs-audit-trail.html) and [Connecting integrations](docs-integrations.html) cover the mechanics. ## Backups Infrastructure runs across multiple availability zones within a single United States region, with continuous backup and point-in-time recovery. The backup retention window is published on the security page. We are deliberately not publishing recovery-time commitments. A cross-region standby does not exist today and a restore drill has not yet been run, so any recovery-point or recovery-time number would be a design target rather than a measured one. Our launch service level is stated in the [Terms](terms.html), and both positions move once the drill is done. ## Retention, legal holds and deletion Retention is configured per tenant under the **Data & retention** tab in **Settings & integrations**. The tab states your region, the evidence and agent-run-log retention in force, how content is encrypted and how keys are managed, and your right-to-erasure posture. That last item states what happens to your data at offboarding. It is not a tool for making requests. Below it sit your retention classes, your legal holds, and the custom fields you have defined on the core registers. The default retention posture is a storage floor rather than a cryptographic lock, and the security page states it in those terms. A legal hold blocks erasure. A record covered by a hold is not deleted while the hold stands. The gate is enforced, not advisory. That matters when litigation or an examination outlasts a retention class. Records that reach the end of their retention class do not disappear quietly. They surface in the document library under a **Due for disposition** filter. There a named person records one of two decisions: retain the record, or clear it for disposal. The decision lands in the audit trail. Neither decision destroys anything. There is no destruction action in the product, and nothing is disposed of automatically. A record under an active legal hold cannot be reviewed at all until the hold is released. At offboarding, we erase database content by dropping your tenant schema and erase object storage by destroying your tenant key. Both sit behind the same blocking legal-hold gate. The security page publishes the timeline. Take your final export before that window closes, and put it on your exit checklist instead of relying on a last-minute request. ## Who else touches your data A small number of subprocessors touch customer data, and they are named in full on our [subprocessors page](subprocessors.html): hosting, model inference, identity, and the administrative network path. Amazon SES is provisioned for transactional email, but that email is not yet enabled. We disclose operational vendors that support the service without processing customer content as well, because omissions read as concealment in a vendor review. Customers get advance notice before a new subprocessor processes customer data. Request traces carry only the route, timing and status, never record content, and are kept in CloudWatch in our AWS account for 30 days. ## Requests from individuals If a consumer or an employee asks for access to, correction of, or deletion of information held in your Zovos tenant, that request runs through you as the controller. Zovos has no consumer-request intake of its own. What supports your response is what is already in the product: the exports above, the legal-hold controls in settings, and the audit trail's record of what was done. Requests about information Zovos holds directly, such as site visits, newsletter subscription and correspondence with us, go to privacy@zovos.ai and are answered under our [privacy policy](privacy.html), which sets out the access, correction, deletion and portability rights we honor for residents of every US state. ## Notes and limits - Zovos runs in a single region today. If a data-residency requirement outside the United States applies to you, we cannot meet it. - A restore drill has not been run, and we say so rather than publish a recovery target. - The data processing addendum we can send is a draft, available under a mutual NDA. There is no executed standard template today, and we would rather tell you that during diligence than during contracting. --- # FAQ & troubleshooting Section: Help · Updated: 2026-10-07 · https://zovos.ai/docs-faq.html The questions below are the ones compliance teams at banks and credit unions of every size ask most often in their first months with Zovos. If yours is not here, [contact support](support.html). We would rather answer it than have you guess. ## Signing in ### I never received an invitation email Ask your administrator to check the member list on the Team and roles screen. A pending invitation can be re-sent from there. Your mail gateway may also have held it. The invitation is sent by WorkOS, our identity partner, from its own sending domain instead of a Zovos address, so a gateway that quarantines unfamiliar senders will catch it. If your institution provisions access through your directory instead, there is no invitation email at all. You simply sign in with your organization's usual single sign-on button once your administrator has assigned you. ### Sign-in says I am not authorized Contact your administrator first. Access is granted through your identity provider, and the usual cause is a directory group or role assignment that has not been mapped to a Zovos role yet, or a directory sync that has not run since you were added. Zovos refuses an unrecognized assignment instead of defaulting you into a role. That is why the error appears the instant you arrive and not somewhere deeper in the product. An owner fixes it on the **Access & SSO** tab in Settings, where directory groups and roles are mapped onto Zovos roles. Once the mapping is in place, sign in again. ### I cannot invite anyone into a custom role The mapping has to exist before the invitation. Every workspace starts with directory mappings for the owner, analyst, internal audit, board and risk approver roles, so those invitations work from day one. A custom role has no mapping until an owner adds one on the **Access & SSO** tab in Settings. Until then, an invitation into that role is refused with a message saying exactly that. The same applies if an owner has removed one of the default mappings. Examiners are not invited this way. They get a separate time-boxed session, described below. The order to work in is in [Onboarding your institution](docs-onboarding.html). ### Someone has left, or a laptop was lost An administrator can open that person's row on the Team and roles screen and see their live sessions. Each one shows the device, where the session started, when it was last active and when it expires. The administrator can end one of them or all of them. A revoked session stops working on its next request. Removing the person in your identity provider is still the right first move. Ending sessions is the control for the gap before your next directory sync runs. ### My role is wrong Roles are set by your administrator. If your account is managed by your directory, the member row will say so, and the role has to change in your identity provider rather than inside Zovos. ### I need to give an examiner access Examiners are not added as teammates. An owner grants a time-boxed, scope-limited session for the examination, read-only apart from a few fieldwork actions. See [Roles and permissions](docs-roles-permissions.html). ## Browsers and access ### What do I need to run Zovos? You need a current version of Chrome, Edge, Safari or Firefox, kept reasonably up to date. Zovos is a browser application, so there is nothing to install and no desktop client. It works on a tablet, but the registers, matrices and workpaper screens are built for a laptop or desktop display. ### Where do I find the allow-list for our proxy? [Onboarding your institution](docs-onboarding.html) lists what a corporate proxy or firewall may need named. The first entry is the workspace host over HTTPS, including the WebSocket upgrade the collaborative drafts editor uses on that same host. The second is WorkOS, our identity partner, together with your own identity provider, because signing in is a redirect out to them and back. The third is our document storage endpoint, since uploads and downloads go directly between the browser and object storage instead of through the application. Ask [support](support.html) for the exact entry for your environment instead of guessing at it. One related fact belongs in the same conversation. Zovos refuses to be displayed inside a frame, so it cannot be embedded in an intranet portal page. ### Can I restrict where the workspace can be reached from? Yes. Your workspace can be limited to your institution's own network ranges, which you configure in settings. If you are travelling and suddenly cannot reach Zovos, that policy is the first thing to check with your administrator. ## Using the product ### A screen or menu item I expected is missing Anything you lack permission for is hidden instead of greyed out, so the navigation you see is the navigation you have. If a colleague can see a screen you cannot, the cause is a difference in roles or in the scope of an access group. See [Roles and permissions](docs-roles-permissions.html). ### Why can I not approve something I submitted? Separation of duties prevents it. The approver may not be the submitter, and critical items need two distinct signers. If you are genuinely the only person in the workspace holding the required permission, the decision can still proceed on the sole-operator override, which requires a written justification and is tagged as such in the audit trail. See [Approvals and delegation of authority](docs-approvals.html). ### The gap analysis says the regulatory library is not indexed Ask your Zovos contact. Agents cite the regulatory library. Until that library has been indexed for your workspace, they decline to run instead of answering without sources. The message you see is the agent naming the missing index instead of producing an uncited answer. Indexing is a one-time step on our side. Despite the wording of the message, it is not something an owner can do in settings. Confirm it before your first agent run. [Onboarding your institution](docs-onboarding.html) puts it in the day-one order. ### A panel is empty rather than showing zero That is deliberate. A panel with no data behind it, or one withheld from your role, renders nothing instead of a fabricated zero, because a confident zero in a compliance report is worse than an honest blank. ### Something looks wrong on a screen Use **Report a bug** in the in-app help center. The report carries the screen you were on and your recent in-app actions, and you see exactly what will be attached before it sends. An owner can switch the feature off for the whole workspace, because some institutions forbid sending free-text context to a vendor. When it is off, the option is not shown and you reach [support](support.html) instead. ## Getting your data out ### Can I export my registers? Yes. Registers such as findings, risks, gaps and loss events export as PDF or spreadsheet files, and most tables offer a quick CSV. Scheduled exports can deliver datasets on a cadence to your own systems. ### Can I hand an examiner or an auditor something they can verify independently? Yes. Sealed artifacts such as board packs, minutes, workpapers and exam binders carry a content hash recorded in the proof ledger, and a proof pack can be verified offline with a bundled verifier, without trusting the export or us. The audit trail itself is append-only and exports with its filters intact. See [Audit trail and exports](docs-audit-trail.html) and [Your data: exports, backups and retention](docs-data-handling.html). ### What happens to our data if we leave? Your records remain exportable throughout the term, and offboarding is a defined process described in [Your data](docs-data-handling.html). Our published security posture, including what we do and do not hold today, is on the [security page](security.html). ## How the AI behaves ### Does AI ever change my records on its own? No. Every AI output arrives as a proposal with its citations and a confidence score, and becomes authoritative only when a named person accepts it with a rationale. High confidence auto-clears into a review queue, and auto-cleared does not mean approved. ### What if a citation is wrong? A citation the model produces that does not resolve against the regulatory corpus is dropped, loudly and with an audit entry, instead of being stored. Only the immutable run record keeps the raw output. ### Can we turn AI off entirely? Yes. If your institution's policy forbids sending content to a language model, an owner can disable AI processing for the whole workspace, and every path that would trigger it refuses before anything is written. Some analysis is deterministic and uses no language model at all. That includes absence testing, mock exam checks, clause review and launch delta. There is more in [How AI works in Zovos](docs-ai-in-zovos.html). ### Can we show an examiner how an answer was produced? Yes. Every run pins its agent, model, prompt template version and hashed inputs, so a re-run reproduces the same inputs verbatim and the question is answerable a year later. ## Notifications and email ### Why have I not had any email from Zovos? The product does not send email today. Notifications are delivered in the workspace, through the bell in the top bar and the panels on the dashboard. Your email choices on the notification settings screen are stored but inert until email delivery is switched on for the deployment. The screen says so instead of quietly dropping messages. Plan around it. Nothing chases an overdue approval or an expiring attestation by email yet, so the workspace is the place to look. Slack and Microsoft Teams do not depend on email. Once an administrator connects a channel and turns it on under Notifications, those notifications reach it as well as the bell. See [Connecting integrations](docs-integrations.html). The one exception is the teammate invitation, which is sent by WorkOS, our identity partner, from its own sending domain. If invitations are the thing that is not arriving, that is the sender your mail team needs to let through. ## Connecting your AI assistant ### Can my AI assistant see other customers' data? No. Your assistant connects to your own workspace only. The workspace it can reach is derived from your verified Zovos sign-in and never from anything the assistant supplies. It can never read another customer's data, and it only ever acts within your own Zovos role. See [Connect your AI assistant](docs-connect-ai-assistant.html). ### Does Zovos send my data to the assistant vendor? No. You choose the assistant, and Zovos only answers the authenticated requests it makes on your behalf. Zovos never pushes your data to a vendor it selected, and your data is never used to train a foundation model. Your system credentials and logins never reach Zovos at all. When an assistant runs a control test, it authenticates to your systems with your own credentials on your own machine. What Zovos holds is described on the [security page](security.html). ### How do I turn the connector on, and which assistants work? An owner enables it per workspace under **Settings → Integrations → AI assistants**. It is off until they opt in. Once on, you can connect Claude, ChatGPT, Cursor, Microsoft Copilot, or Gemini by pointing the client at the Zovos endpoint and signing in with your organization selected. The per-client steps are in [Connect your AI assistant](docs-connect-ai-assistant.html). ### Can the assistant change or approve things on its own? No. A control test it submits waits for a reviewer other than you before any rating changes. Imports, rollbacks, new tasks and comments on a finding or a risk show a dry run and write only after you confirm. Evidence and import-file uploads are stored when the assistant makes them, but change no register or rating on their own. The assistant can never approve, sign, or dispose of anything, it can never change a record's status, and it cannot administer users. Those actions stay with a named person under separation of duties. Every tool call is recorded in your audit trail, and an examiner session cannot read or change any workspace data over the connector. ### How do I disconnect an assistant? An owner opens **Settings → Integrations → AI assistants → Connected clients**, which lists every connected assistant and when it was last active, and clicks **Revoke** to stop that client on its next request. It can be restored later from the same panel. ## Testing controls with your own AI assistant ### Can I really run a control test with my own AI assistant? Yes. With the Zovos Evidence Protocol you point your own assistant at Zovos. That can be Claude, GitHub Copilot, Cursor, or ChatGPT. The assistant fetches the published procedure, runs the test with its own tools against your own system, and submits the result plus the raw evidence. An administrator enables it per workspace under **Settings → Integrations → AI assistants**, and you need a verified email. See [Test controls with your own AI assistant](docs-ai-control-testing.html). ### Does an AI submission change our control ratings on its own? No. Every external submission enters "pending review" and nothing moves a rating until a person distinct from the tester accepts it. On acceptance the outcome maps to effectiveness, the owner's attestation for the period is satisfied, and a failed test opens a draft finding. By default 5 % of accepted submissions are randomly re-tested. Your administrator can set that anywhere from 0 to 100 %. ### Does Zovos get our system credentials or logins? Never. Your assistant authenticates to your system with your own credentials on your own machine. Zovos receives only the result and the artifacts you attach. The tester of record is you, derived from your Zovos login. The assistant's name and model are recorded but shown UNVERIFIED, and they are never an authorization signal. ### What must we never upload as evidence? Never upload credentials, tokens, API keys or connection strings. Never upload SAR, BSA/AML or CTR content, which is legally confidential. Never upload customer PII beyond the minimum the control requires. Strip them before upload. Zovos also scans every artifact, refuses credential or SAR content, and quarantines PII. That scan is a backstop, and it does not replace keeping this material out. ## Pricing ### Does adding an access group change our price? No. Building an access group, giving it to more people or mapping it from your directory never changes the price. An access group only bundles roles, job families and a scope. ### Do job families or seat counts change the price? No. Zovos is priced by your institution's asset tier, and every module is included at every tier. Job families never change the price. The price is not set per seat either. Your agreement records a contracted seat count for planning, and the seat usage shown in settings is informational rather than a cap. Current tiers are on the [pricing page](pricing.html). ## Reaching support Email support from the [support page](support.html). We usually acknowledge new requests within a week, and anything blocking an examination is handled first. Tell us the screen, what you expected, and the display ID of the record involved. That is usually enough for us to find it without asking you for a second round of detail. --- # What's new Section: Help · Updated: 2026-10-07 · https://zovos.ai/docs-whats-new.html This page tracks what changed in Zovos from your side of the screen. That covers new areas, workflow changes, and anything that alters what an examiner would see. We keep it in plain English, and we only list changes that are live for customers. ## October 2026 - **Examiners can see more of what their access covers.** Within the frameworks you grant, an examiner can now open the controls mapped to them with their tests and attestations, read your regulatory updates, obligations and documents, and search and follow links between those records. A request in the exam room links to the policy version that was in force, and your own impact assessments, internal audit work and suspicious activity report decisions stay out of view. - **Ready-made prompts for your AI assistant.** One prompt prepares an exam request list by gathering the evidence on file and the gaps for each open request, and another writes a monthly compliance summary from your regulatory updates, overdue findings, key risk indicators and approvals. The assistant proposes next steps and you decide. Members whose access is limited to a business line can now search their own records from the assistant and look up and acknowledge their findings in Slack. - **Follow a record to everything it touches.** Vendors, key risk indicators, risk assessments, exam requests, board meetings, decisions, models and AI systems now show their linked records, and a record ID printed elsewhere in the product opens the record it names. A linked record you are not permitted to open shows as restricted. - **See the same requirement across frameworks.** A citation now lists the requirements in other frameworks that your control objectives cover alongside it, and says how closely each one matches. Two new control baselines, one for cybersecurity and one for AI and model risk, map each objective across frameworks such as the FFIEC information security booklet, NIST CSF 2.0, the CRI Profile, ISO 27001, SR 26-2 and the NIST AI RMF. - **Report credit risk review to the board.** Each review produces an internal report that lists every credit reviewed, the rating differences and the open exceptions, and a board edition that carries totals only, as a PDF or a Word document. The board pack gains a credit risk review section that keeps overdue exceptions from earlier reviews in view. - **Ready for the new examination and MRA rules.** The exam cycle screen works out the longest interval your regulator may allow before the next safety-and-soundness examination, condition by condition, and flags an expected date that falls after it. Examiner findings record the basis of a matter requiring attention and the date it was issued, and the findings register separates items issued before and after the rule that takes effect on November 2, 2026. An examiner observation can close on an independent sign-off alone, while every other finding needs remediation evidence before it closes. - **Cybersecurity has its own home.** The Cybersecurity group brings your security frameworks, findings, controls and open incidents together, and a security incident register shows each notice your charter and the facts call for, with its deadline counted from the determination a named person records. The annual information security program report to the board is built from your registers, with the officer's recommendations written in a shared draft. An automated control test can now confirm that AWS Backup covers your resources with recent completed backups. - **Your AI assistant can now see your own work and read more of your program over the Zovos connector.** Under your own role it can show your approvals queue, find a record by its ID, and read your findings, key risk indicators, vendors, regulatory updates, exam request lists and policies. It can also create a task or comment on a finding or a risk, each shown as a dry run and written only when you confirm. - **Limit access by business line.** Access groups give their members a set of roles, and a group can be limited to a member's own records or to named business units. The limit applies to what members can read and to what they can change. - **Run credit risk review in Zovos.** Loan review teams can load the loan universe, select a sample, record their rating of each credit beside the institution's rating, and track exceptions to closure. Reviewers are assigned under an independence check, and the lead reviewer attests before the review is submitted for sign-off. - **Track fraud losses and fraud cases beside your AML/CFT program.** Fraud losses come from the loss event register, and a case log records each case with a two-person decision on whether to file a suspicious activity report. The log records the decision and not the contents of any report. - **The sidebar is organized around your job.** Each member can be given one or more job families, such as BSA/AML, third-party risk or internal audit, and the sidebar opens with My work and the sections that family uses. Families only arrange the screen. What a member can open is still decided by their permissions. ## September 2026 - **Set how long a session lasts.** An owner can set your institution's session lifetime between one and twelve hours, and a session left idle for 30 minutes ends. An owner can also record a dated attestation that your identity provider enforces multi-factor authentication, and Settings shows who attested and when. - **Model risk sections now cite SR 26-2 and OCC Bulletin 2026-13 as the operative guidance.** SR 11-7 and OCC 2011-12 appear only as history, and the retired FFIEC Cybersecurity Assessment Tool no longer shows up as a live framework in packs, templates, exports, or the regulatory corpus. - **Keep your old record IDs when you migrate.** The main registers hold the ID a record had in your previous system, imports match on it first, and each import screen offers a downloadable template. - **Connect your AI assistant.** Zovos has an MCP server, so an assistant that supports the Model Context Protocol can answer questions from our documentation and read your controls, risks and obligations under your own sign-in and permissions. - **Test controls with your own AI assistant.** An assistant can submit a control test with its evidence, and it arrives marked unverified in a review inbox where a person accepts or rejects it before it counts. - **A page for every area of the platform.** zovos.ai now explains each part of the product on its own page, from regulatory change, controls and policies to risk, third parties, internal audit and exam management. - **From rule change to exam close-out.** Take an exam from the report of examination through the board's review and your response letter into findings, let examiners upload documents in the exam room, see before-and-after rule text when a regulation is amended, and generate supervisory progress reports. - **Enterprise risk with appetite in force.** Risk appetite cascades into limits on key risk indicators and business units, residual scores draw on live control evidence, and each risk shows its treatment plans, loss experience and the severe-but-plausible scenarios you capture. - **Internal audit, end to end.** Plan an engagement, write the audit report as a document, take a structured management response, validate remediation in a follow-up, and issue the report to the audit committee. - **Consumer compliance you can show an examiner.** A compliance-management-system scorecard across the four CFPB pillars, HMDA data scrubbing with quality and macro edits, complaint root causes that can raise a finding, training rosters that name who is delinquent, and a consumer-compliance exam package. - **Third-party and model risk, deepened.** Vendor risk assessments on the same scoring scale as your risk register, questionnaire templates with SIG and CAIQ exchange, AI-assisted contract review you confirm clause by clause, and an annual third-party program report for the board. - **Approvals can be redirected to a different role.** When the named signing role cannot act on a decision, it can be reassigned or escalated to another role that holds the authority, with a rationale on the record. ## August 2026 - **An onboarding guide joined the documentation portal, covering what Zovos provisions, what your identity team supplies, and the order an owner should work in on day one.** - **This documentation portal launched.** Guides for every area of the platform, a support page, an FAQ, and a What's new page, written in plain English for the people who run the program. - **A partner's own BSA/AML figures.** Record a fintech partner's BSA/AML figures month by month, with where each one came from, and see them trended on the program. - **Thresholds on partner program figures.** Set your own threshold lines on figures such as complaint volume and the age of the oldest open diligence item, and see when a partner program breaches one. - **Fintech partners answer your diligence themselves.** Send a program's open diligence items to the partner contact as a scoped link, see which links are still live, and revoke one. Answers arrive marked unverified and await your review. - **Confidence on proposed gaps.** A gap proposed by an agent shows the confidence behind it, on the same scale used everywhere else an AI proposal is reviewed. - **Review cadences, an advisory log and more.** Disclosures carry a review cadence, fair-lending reviews can be scheduled, each examination type records its next expected date and preparation window, training programs link to the rules they teach, an advisory log records the questions your team answered and why, and a decision can record the earlier decision it supersedes. - **Internal audit sampling and co-source workpapers.** Draw a re-performable sample from a recorded seed, test each item and conclude, and import a co-source firm's workpapers from a spreadsheet manifest. - **Bulk actions and saved views.** Reassign or change the status of many findings, risks or vendors in one step, and save named views of your filters, sort and columns on the big registers. - **Your own fields and assessment templates.** Define custom fields on the core registers, and clone a curated assessment template or write your own from scratch. - **Complaint response clocks and consumer harm.** Complaints routed through the regulator's company portal carry their response clocks, and a finding records the redress, the consumers affected and where restitution stands. - **Keep your mass-notification tool in step with your continuity plans.** A signed event goes out when a plan goes into force or an exercise is recorded, and a tab shows which endpoints are live. - **End a member's sessions.** An administrator can list a member's active sessions and revoke one or all of them, and signing out ends a session immediately. - **A broader assessment template catalogue.** Curated assessment templates now cover ACH, electronic banking, remote deposit capture, insider lending, UDAAP, CRA self-assessment and more. - **Supervisory actions.** An area for consent orders, formal agreements, memoranda of understanding and matters requiring attention, holding each article, its dated milestones and the evidence of completion. - **Set your institution's timezone.** A date-only deadline now means the end of that day in your zone, and the daily digest is built for your morning. - **Scoped API keys read your registers.** A key can page through risks, assessments, controls, policies and third parties, with a last-updated stamp on every row for incremental pulls. - **The proof ledger is browsable.** Read sealed events in order, with who sealed each and when, alongside the external anchoring runs. See the content packs available to you in a content library, and manage the tokens that feed readings into your key risk indicators. - **Board portal trends and receipts.** Headline figures are plotted across board packs so directors see the direction of travel, and opening a pack records a receipt for that director. - **Comment threads with mentions.** Findings and risks carry append-only comment threads, and mentions are limited to people on your roster. - **Send a filed policy for signature.** Route a policy version's filed PDF to an attestation campaign or to named board signers, and the signed copy is archived as evidence against that version. - **Fixed statutory dates on the calendar.** The obligations calendar understands deadlines a rule fixes on the calendar, lets you move an institution-set date onto your real board cycle, and rolls an obligation forward when you record the filing. - **Correct what you created.** Edit a live policy's effective date, review cadence and board approval record. Mark a citation not applicable with your rationale, edit or retire internal authorities, and open a legal hold to see and change the documents it preserves. - **Spreadsheet imports everywhere.** Every register importer accepts an Excel workbook as well as CSV, still with a dry run and per-row errors that do not abort the file, and each core register gained an audited export in the exact shape the importer accepts. - **Choose your own notification volume.** Each person decides, per type of notification, whether it arrives immediately, waits for the daily digest, or stays off, and mentions are a type of their own. Email delivery is not switched on yet, and the screen says so. The choices are stored for when it is. When you grant an examiner access, the screen also tells you plainly whether the credential was delivered or whether you need to hand it over yourself. - **Tasks and action plans.** Assigned, dated work in its own area, where an action plan groups ordered tasks with a progress rollup and a triaged regulatory change can become a plan with an owner and a task per line. - **Search your records from the keyboard.** The command palette searches records across the product, not just navigation, and a pasted record ID is the first result. - **More dates reach the calendar.** Partner program review dates, board meetings and complaint deadlines now appear on the obligations calendar alongside everything else. - **Disposition review.** Records that reach the end of their lifecycle queue for an explicit human decision instead of aging out silently. Nothing is disposed of automatically, and a record under legal hold cannot be reviewed until the hold is released. - **Partner program oversight.** A dedicated area for banking-as-a-service and fintech partner programs, with program-level risk and oversight records, periodic reviews on a cadence, and a wind-down checklist tracked like a runbook. ## July 2026 - **An integrations directory.** Settings now lists the available integrations by category, and each one says what it reads and the permissions it asks for before you connect it. - **Single sign-on and directory sync you can see.** Settings shows your directory provisioning status and event log, guides your identity team through Entra ID, Okta or Google Workspace, and lets an owner map directory groups onto Zovos roles. - **Bring your Word policies in and publish them out.** Import a Word document as an editable draft, redline it with tracked changes, route policies to the board and procedures to management, and file a branded, locked PDF of every published version. - **Workspaces for the rest of the GRC team.** Internal audit, model risk, training oversight, marketing and disclosure review, loss events, risk appetite and board meetings each gained their own area, with internal audit walled off from the teams it audits. - **Exam rehearsal and enforcement intelligence.** A mock examiner that works your first-day letter, an enforcement radar that scores peer enforcement actions against your own controls, a time machine that shows your program as it stood on any past date, and a launch check that lists the obligations a new product brings. - **A much broader regulatory library.** The framework library added consumer-protection rules such as Regulation B, Regulation DD, RESPA and HMDA, security standards such as NIST CSF 2.0 and SOC 2, and control and audit frameworks such as COSO and the IIA standards. ## June 2026 - **HMDA data-integrity checks.** Load your HMDA loan application register and see the records that fail the federal data edits before you file. - **AI-drafted questionnaire answers.** Zovos drafts answers to due-diligence and security questionnaires from your own evidence, with the source cited for each, for you to review before anything is sent. - **Regulatory change that applies to you.** New rules and guidance from the federal agencies arrive continuously, are tagged against your frameworks and products, and come with AI-proposed impacts on the policies and controls they touch, queued for your review. - **Complaint oversight.** Log or import complaints, capture the root cause, link them to the policies, controls and findings involved, and see trends and an export for the exam binder. - **Policy templates for financial institutions.** Start a new policy from a library of starter templates written for banks and credit unions instead of a blank page. - **Write policies together in real time.** Several people can edit the same draft at once and see who else is in the document and where they are working. - **Vendor due diligence.** Send a vendor a due-diligence questionnaire and collect its documents in one place, tied to the vendor's record. - **Access reviews.** Run a periodic recertification campaign in which reviewers record a keep-or-remove decision on each person's access, and keep the result as evidence. - **Risk and control self-assessments.** Run an RCSA from launch through rating and attestation, with each assessment's history kept on the record. - **A portal for examiners.** Give an examiner time-limited, read-only access to their request list and the evidence you have attached to it. - **An AI policy drafter.** Ask for a first draft of a policy and it arrives as an editable draft, citing the regulations it draws on, for your team to review and revise. - **Every AI result waits for a person.** Agent output is queued for human review, and a reviewer accepts, edits or rejects it before it becomes part of the record. - **A trust center for your institution.** Publish your security posture on a public page, share sensitive documents behind an NDA, answer security questionnaires from a reusable library, and let subscribers hear about updates. - **Framework coverage at a glance.** Open any framework to see its requirements and which of your controls and policies cover each one. - **Key risk indicators with thresholds.** Set numeric thresholds on each indicator and its red, amber or green status follows from the readings you record. - **Remediation deadlines that enforce themselves.** Findings carry remediation due dates, and overdue remediation is flagged. ## Cadence We ship continuously and collect notable changes here monthly. Some changes affect your examination story, such as a change to a report format, an export, or audit-trail behavior. Those appear in this list the month they land.